Using the DevOps Second Way to Improve ITIL Change and Release Practices

Following on from my blog about using the DevOps first way to improve ITIL change and release practices by increasing flow, my latest blog looks at driving efficiencies using feedback loops.

Before I start though, I should mention that I appreciate that many IT organizations that employ ITIL best practice might be looking at the new ITIL 4 update while still using ITIL v3 best practice to deliver change and release capabilities. If you haven’t seen the update yet, then this ITIL 4 blog by my good friend Stuart Rance is very helpful.

And it’s worth noting that from an ITIL change and release terminology perspective, ITIL v3 best practice processes have evolved to ITIL 4 practices, and change management is now “change enablement.”

So, let’s start with what the DevOps second way is.

The DevOps second way

The second way is about using feedback loops to increase responsiveness. This is done by building in frequent opportunities for stakeholders to respond and comment on what’s being delivered.

One of the biggest issues with traditional approaches to product or service creation is that results often aren’t visible until too late in the process – meaning that we’re likely to deliver a product or service that’s potentially suboptimal.

The impact of minimal feedback

The reality is that if you’re not getting timely feedback, it may be too late to fix any issues come release time – with feedback critical to designing and building the service to the customers’ requirements.

In an IT environment, feedback is needed early and regularly so you can continually adapt and course-correct your product in line with the customer requirements. Think about it, it’s much easier to make small tweaks as you go along rather than trying to do it all at once and at the last minute when you’re under increasing pressure. Getting regular feedback, via feedback loops, allows you to do just this.

Feedback loops and process improvement

The goal of almost any process improvement initiative is to shorten and amplify feedback loops so that the necessary corrections can be made (ensuring continual service improvement, or continual improvement as it’s now known in ITIL 4).

Shortening and amplifying feedback loops means that any quality issues can be fixed at the source, avoiding defects and rework. Used effectively, feedback loops will significantly increase overall service quality. So, let’s take a look at how we can apply this in the real world of ITIL-inspired change and release practices.

How to use the second way to improve ITIL change and release practices

So how do, and should, feedback loops work in the real world? Here are some suggestions:

• Reducing batch sizes and having small, frequent changes not only enables the fast flow into production mentioned in my first blog, but also supports fast and constant feedback flow throughout design and release. All too often organizations stick to the traditional release cycle, whereby they release a couple of times a year. Sounds reasonable right? Everyone knows when the release is due, the downtime is planned for, and everyone knows to “batten down the hatches.” But we also need to talk about the downsides. Firstly, by limiting your release cycles, you’re limiting your opportunities for engagement and feedback. Secondly, the bigger the release, the greater the risk (as the complexity increases). By making releases smaller and more frequent, you get people used to a new cycle, it’s easier to automate, and – with less complexity – there’s less potential for unknowns and unplanned downtime. In terms of feedback loops, this is one case where bigger isn’t always better!
• As per the first way, use standard changes and models where possible to ensure increased change volumes don’t slow down your overall flow. And build in “check backs” so that you know exactly how your standard change offering is performing and can identify any potential bottlenecks.
• If possible, use a/your Definitive Media Library (DML) to deploy software releases so that you know the software involved is the correct version, secure from external threats and appropriately licensed. And when using your DML, build in checks to your process such that the deployment method is tested to ensure there are no issues with installation, access, or network bandwidth.
• Look at continuous integration, with the build and deployment process working together with a fast, automated suite of tests. Having development teams involved in early life support and operational teams taking part in testing the code means that both areas will be more invested in the overall product and will be equally invested in seeing it work. This will shorten feedback considerably as both teams will be working closely together.
• Understand and respond to all customers. Make sure that feedback is acknowledged, recorded, and acted on. Ensure that the end customer is kept in the loop and is regularly updated.

A key purpose of the second way is to understand that a value chain can only be optimized by incorporating feedback. Done well it continues the results generated by the first way while setting up a solid basis from which the third way can continue (this will be in my third blog).

Using the DevOps second way is a great way to improve your ITIL change and release capabilities. By introducing frequent feedback opportunities and check backs, not only will you get a better understanding of business needs, but you’ll also get to course correct quickly and effectively – improving both speed and quality. What’s not to love?

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