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.