Using the DevOps Third Way to Improve ITIL Change and Release Practices
Yes, I’m still writing about the three ways of DevOps. Following on from my earlier blogs about using the DevOps first and second ways to enhance change and release practices, this blog now looks at using the DevOps third way to build in continual improvement (what was continual service improvement (CSI) in ITIL v3), continual learning, and increased resilience.
The DevOps third way
The DevOps third way is all about creating a culture of experimentation and learning. In other words, it’s OK to “have a play” and to make some mistakes along the way because we’ll learn from them – which will make our product or service (or operations) stronger as a result.
However, the unfortunate reality is that when running an IT department (or a team within it), creating the right culture can be at the bottom of the to-do list (just speak to my good friend Paul Wilkinson, and he’ll explain just how often this is the case). Let’s face it, most IT support teams are caught up in a cycle of break-fix, testing, deploying security patches, handling user requests, and upgrades. So, the appetite for introducing additional risk probably isn’t there.
In adopting the DevOps third way, the key to creating a culture of experimentation and learning is to make your people feel safe. Make it clear (to them) that mistakes won’t be punished – a “no blame” culture.
However, no blame doesn’t mean no accountability! What it means is that everyone works together as a team to identify and fix errors. You can shake things up a little. For example, how about having CSI Wednesdays (or continual improvement Wednesdays if you’re already in an ITIL 4 mindset) or knowledge-sharing Fridays?
The #DevOps third way is all about creating a culture of experimentation and learning. In other words, it’s OK to “have a play” and to make some mistakes along the way because we’ll learn from them. Share on XHow to use the DevOps third way to improve ITIL change and release management
No matter which version of ITIL you’re using, change and release management are the capabilities that deliver a product or service “over the line” into the production environment. They deploy the new services into the live environment, retire legacy services, and handle all transition activity.
Due to the nature of change and release management, there are always opportunities for improvement. So, here are three things to consider in light of the DevOps third way:
- Establishing a safe culture
- Dedicating time for CSI
- Working as one team and celebrating successes
1. Establishing a safe culture
No culture is going to change overnight. People need time and space to be able to adapt and to change their world view and working practices accordingly.
This being said, culture change doesn’t have to be an all-or-nothing situation. Making small, incremental changes can be really effective. Some examples to try include:
- As a change manager – rather than rejecting a change with insufficient information, sit down with the person and help them understand what’s needed. They could be new, struggling with the IT service management (ITSM) tool, or even just in need of a refresher if they haven’t raised a change in ages. The point is, it may be quicker to reject the change out of hand but if you spend some extra time at the start of the issue, you stop the same thing happening again saving you future time and effort.
- As a release manager – rather than trying to create a deployment plan in isolation, deal-in the other parties involved. Collaboratively look at pain points, tasks where potential escalations could be needed, and any area that requires additional testing. By looping in your stakeholders, you’ll create a release plan that’s more closely aligned to collective outputs and is much more likely to stay on track.
If you want to build a successful IT organization, where people feel empowered to experiment and to learn, you need to develop a culture where experimentation is normal, expected behavior. So, make it clear to your people that a key part of the process is trial and improvement, and that there are no silly mistakes as long as they’re identified, resolved quickly, and learned from.
If you want to build a successful IT organization, where people feel empowered to experiment and to learn, you need to develop a culture where experimentation is normal, expected behavior. #DevOps Share on X2. Dedicating time for CSI
Dedicate a set amount of time each week to continual improvement (or CSI if you’re still loving the ITIL v3 acronym). If time is in short supply (isn’t it always?), borrow the Kaizen approach from Lean Sigma where short bursts of improvement activity are regularly scheduled as part of the day job.
Kaizen is about making many small improvements on a continual basis – think small and agile acts of refinement. One approach could be to block out time on Wednesday mornings such that everyone on the team knows that this time is dedicated to improvement activity. Having the event blocked out also means that everyone is aware, and your engineers and techies can still carry out the day job.
Why Wednesdays? Mondays are, let’s face it, busy times and Fridays can be full of last-minute customer calls and planning for weekend release activity. If you schedule a Kaizen session for Wednesdays not only are you avoiding the busiest time slots, by focusing on something other than just the business-as-usual (BAU) you’re giving your people a change of focus and will likely energize your team for the rest of the week.
Some quick wins for change and release improvement could include the following:
- Delegated authority – whereby more changes can be approved locally (by delegated approvers) if the impact is contained.
- Considering the use of Kanban to control change activity such that changes are progressed via a Kanban board – reducing or even replacing the need for lengthy change advisory board (CAB)
- Templating release notes – such that they have a consistent look and feel, and end users know exactly what to expect when reading them.
- Storing knowledge centrally – such that everyone knows where to go for installation instructions or support contact details.
3. Working as one team and celebrating successes
It’s really important that, in a DevOps environment, there is no “them” and “us.” That there’s only one team and we win or lose as that team.
So, help this to happen by celebrating the improvements in each cycle (preferably with beer/pizza/cake – whatever the preference is in your organization) so that people can bond and identify what needs to be improved in the next cycle.
Using the DevOps third way will really improve how your change and release capabilities perform. By establishing a culture that supports innovation, dedicating time to improvement, and working as one team you’ll improve quality, responsiveness to business needs, and boost employee morale.
Have you tried incorporating aspects of the DevOps third way into your change and release practices? How did you get on? Please let me know in the comments!
