Tag Archives: agile

change management – agile, continuous delivery, ITIL, CABs

Jez Humble’s work blog: Continuous Delivery and ITIL: Change Management

(emphasis mine)

Many large organizations have heavyweight change management processes that generate lead times of several days or more between asking for a change to be made and having it approved for deployment. This is a significant roadblock for teams trying to implement continuous delivery. 

…. it’s possible to follow ITIL principles and practices in a lightweight way that achieves the goals of effective service management while at the same time enabling rapid, reliable delivery.

…. Normal changes are those that go through the regular change management process, which starts with the creation of an RFC which is then reviewed, assessed, and then either authorized or rejected, and then (if authorized) planned and implemented.

Standard changes are low-risk changes that are pre-authorized.

….the approval can be made by somebody close to the action – it doesn’t need to work its way up the management chain.

…. Often CAB approval can be a lengthy and painful process. However it certainly doesn’t need to be. The ITIL v3 Service Transition book specifies both that CAB approval can be performed electronically, and that not everybody in the CAB needs to approve every change (pp58-59). Getting agreement on exactly who needs to authorize a given type of change, and making sure those people know in advance the information they need to decide whether to approve it, can mean a fully compliant authorization process that can be performed in seconds in a just-in-time fashion.

…. We can see that ITIL provides several mechanisms which enable lightweight change management processes:

  • Standard changes that are pre-approved.
  • CAB approvals that are performed electronically, rather than at face-to-face meetings.
  • Arranging in advance which subset of CAB members are required to approve each type of change.

…. ITIL follows the common-sense doctrine that each change must be evaluated primarily in terms of both its risk and value to the business. So the best way to enable a low-ceremony change management process is to reduce the risk of each change and increase its value.

….

In a traditional delivery lifecycle, even with agile projects, the delivery cadence looks rather like figure 1. The first release can often take some time: for really large projects, years, and even for small projects typically at least six months.

…. In the world of continuous delivery, …. projects will provision their production environment as part of project inception, and begin releasing to it as early as possible in the delivery process – potentially long before the service is actually made available to users. Further changes are made as frequently as possible

…. Project managers will focus on optimizing for cycle time, ensuring that changes to the system get put live as rapidly as possible.

…. early and iterative release process also exerts a strong pressure to ensure that the system is production ready throughout its lifecycle.

…. The value proposition of continuous delivery – keeping systems in a working state throughout their development and operational lifecycle – is threefold.

…. allows the customer much more fine-grained control over what is delivered, and perhaps even to discover more radical changes that need to be made to the service in order to make it even more valuable. Second, incremental releases from earlier on are much less risky than a big-bang release following an integration phase. Finally, it allows project and program managers real data on the progress of the project.

…. [pre-approved] standard changes should be much more widely used than they are. 

…. sufficient level of automated testing at all levels before a build ever gets towards operations-controlled environments. That means implementing a deployment pipeline which includes unit tests, component tests, and end-to-end acceptance tests (functional and cross-functional) that are run in a production-like environment. Worried that pressing the “deploy” button might break stuff? That means your automated testing and deployment processes are not up to snuff.

…. Once all this automation in place, it is possible to kick off a positive feedback cycle. 

agile testing: who i listen to

with agile testing i’m thinking about work to improve quality, and work to reveal quality (or lack thereof).

first an interesting idea for learning:
testing dojos

www.methodsandtools.com/archive/archive.php?id=114

www.testingdojo.org/Public+Dojos

a few people:

Gojko Adzik

Michael Bolton

A few more links about testing heuristics

Lisa Crispin

 

Updates:

“…and we test here, of course…” – on continuous testing in devops.


 

why kanban? why focus on lead time reduction?

nicely put by David Anderson: agilemanagement.net/index.php/Blog/why_kanban/

(my emphasis)

knowledge workers such as software developers are overburdened, and … suffer from interruptions, task switching and too much multi-tasking as a result of the overburdening. The overburdening comes from a drive to manage for efficiency (or utilization), that knowledge work is invisible and because the future is uncertain

… demand always exceeds capability to supply, and workers are always busy. Often they start more and more work without a focus on finishing it. This in turn leads to long lead times.

Long lead times are correlated with poor quality. This is almost certainly because … much of the knowledge is tacit

…Much of the work is invisible and a shared understanding of the work and the dynamics of the process that created it are often not achieved. …. Misunderstanding of invisible work require large amounts of coordination effort to reconcile and rework is often needed. Insuring quality and an outcome that matches with original expectations is a constant challenge.

Early delivery of knowledge work often creates additional value. … shortening lead times … is almost always desirable.

Short lead time … demonstrate agility. They also create liquidity in the system. Hence, short lead times (or cycle times) are desirable from a risk management perspective.

…. Kanban systems enable us to limit WIP and avoid overburdening by only pulling work when there is capacity. …. Idleness is a signal that there is an opportunity for improvement. Idleness also provides slack with which to make improvements.

Kanban visualizations …. helps immensely with shared understanding reducing coordination effort and improving quality.

Limiting WIP reduces lead time by reducing multi-tasking. Other kanban system design strategies and staff allocation strategies may reduce task switching. …. Knowledge is often stored between and across members of a network. By keeping the time from starting to finishing short, the risk of knowledge perishing or information becoming stale due to external forces, is greatly reduced. The result is a better product and usually a lot faster.

…. IS LEAD TIME THE ONLY CAPABILITY WE CARE ABOUT?

No …. throughput …. quality …. social capital …. customer satisfaction …. governance … risk …

What we care about is always contextual and has to be based on a mix of customer and other stakeholder expectations.

However, lead time is nearly always one of [the things we care about] because it provides benefits in so many dimensions of risk that reducing lead time nearly always improves the satisfaction for one or more stakeholders.