Using the DevOps First Way to Improve ITIL’s Change and Release Practices

Whether your organization is planning to stay with ITIL v3 for a while or to quickly move to ITIL 4’s new view of IT service management (ITSM) best practice, there’s a definite need to factor in aspects of DevOps to your change and release practices.

DevOps and ITIL’s Service Transition (as was in ITIL v3) are all about change. Granted, there are differences – your traditional ITIL capability has been all about blending value with governance and risk, whereas DevOps is all about speed and continual delivery. But the similarities outweigh the differences.

Both DevOps and ITIL look at controlling change effectively to deliver value (if you haven’t seen it yet, ITIL 4 has rebranded change management as “change enablement”). And while your ITIL process(es) – or “practice(s),” to use the new ITIL 4 terminology – might not yet be as fluid as DevOps, capabilities such as change models, standard changes, and delegated authority will make huge inroads in driving change-delivery efficiency.

With this in mind, my blog looks at how we can use the first of the DevOps “three ways” to improve your ITIL change and release practices. I’ll also be writing about the second and third ways, so please keep an eye out for my future blogs!

The DevOps first way

The first way looks at the performance of the system holistically rather than looking at individual departments or groups. Hence, the first way focuses on all the business value streams enabled by IT – from requirements gathering, through development, to the transition into live services.

Put simply, the first way is all about having work flow from left to right as quickly as possible – from the business through to development to operations to the customer where the value is delivered in the form of products or services.

The key outcomes of the first way are:

• Always looking to increase flow
• Always looking to understand the system

How to use the first way in ITIL change and release practices

Like Lightning McQueen in the movie Cars (who doesn’t love Disney?), the first way is all about speed. One way to increase speed in ITIL change and release is to lower the amount of work in progress or WIP.

WIP by itself doesn’t deliver value or revenue. Think about it, your customers don’t need the raw materials, they need the finished result as a usable product or service. By increasing flow, you will have smaller pieces of work going through the service pipeline which then delivers products faster.

Remove constraints

One way to increase speed is to remove constraints, “road blockers,” or anything else getting in the way of delivery. So, speak to your IT colleagues, especially your developers and IT support staff, to find out what’s causing the major pain points in their day jobs. What are the things that get in the way of them being productive?

The reality is that your flow will never be faster than your biggest constraint –The Goal and The Phoenix Project are both great books on “the theory of constraints” – so identifying your biggest bugbear might be the quickest way to improve things.

Using Kanban is another way to increase flow – where a Kanban board is an agile project management tool designed to help visualize work, limit WIP, and maximize efficiency and flow. These Kanban boards use cards, columns, and continuous improvement to help teams commit to the right amount of work, deliver it with the correct requirements, and complete it on time. If you have a change advisory board (CAB) – although I’ve not seen it mentioned in ITIL 4, well not yet – use a CAB Kanban board (along with standard changes) to keep track of key changes, ensuring that they’re quickly progressed and have the right levels of visibility and support in place.

Talking of standard changes – if you’re not using them, then you’re definitely missing a trick. Put simply, a standard change is a low-risk, low-impact piece of work that has a proven track record with a tried and tested implementation plan. Changes of this type are generally pre-authorized, freeing up the CAB to deal with medium and high-risk deployments.

Something called “delegated authority” is also useful when a change doesn’t quite fit the criteria for following the standard model but is limited to a particular department or location. The delegated authority model acknowledges that many changes have localized risk and can be effectively reviewed and authorized by a local authority. For example, the local IT manager or business unit head. Again, by reducing the number of changes going to the CAB, you increase flow and ensure that only the most visible and business critical changes are discussed by the CAB stakeholders.

Finally, look at how automation can increase speed – and ITIL 4 has added “Optimize and automate” as a new guiding principle which states that:

“Resources of all types, particularly human resources, should be used to their best effect. Eliminate anything that is truly wasteful and use technology to achieve whatever it is capable of. Human intervention should only happen where it really contributes value.”

For example, scripting the release and having deployment packages instead of manually deploying separate files, notifications, and build logs. The benefits of automation to ITIL change and release include:

• Faster deployments
• A consistent approach
• Better regulatory compliance and auditability
• Early warning of broken or incompatible code
• There’s less potential for error
• Economies of scale.

Done well, automation will increase flow, cater more capacity without compromising on speed, and reduce the potential for human error.

Using the DevOps first way is your first step towards rebooting your ITIL change and release practices. By increasing flow, reducing constraints, and looking at opportunities to add efficiency you’ll improve both speed and quality. What’s not to love?

Have you tried incorporating aspects of the DevOps first way into your change and release practices? How did you get on? Please let me know in the comments!