Change Management and DevOps

Change management (or change enablement if you live in an ITIL 4 world) and DevOps are two practices that can help your IT departments transform customer experience. Used effectively, they can help enable change while protecting live services. But here's the thing - so many people think they're mutually exclusive - that somehow change management is the anti-DevOps. By assuming that the two are at odds, IT departments across the globe are missing a trick. This blog will examine how change management and DevOps practices can work together to enable transformation without compromising stability and performance.

The basics

Change management is the practice that delivers change effectively, efficiently, and safely. It's also undergone something of a makeover in the last few years. Depending on your ITIL version, you could also use change management, control, or enablement practices. The latest guidance from "ITIL Towers" is that it is a newly minted practice called change enablement, which is all about enabling business outcomes. For this article, I'll use the terms enablement and management interchangeably.

DevOps is a software development methodology that integrates IT development and IT operations and makes things more efficient by introducing automation and better, faster work practices. It aims to improve service delivery by integrating and making the activities carried out by development and support teams more closely aligned.

How DevOps and Change Management blend together

By working together, DevOps and change management can streamline and standardize the change process, from design to BAU support. Change management can help development teams assess risk, understand business impact, and agree on implementation windows if the deployment could disrupt services and DevOps practices, such as testing, monitoring, version control, and feedback loops, to ensure that changes are deployed consistently, reliably, and in a way that delivers customer outcomes.

Blending aspects of change management and DevOps best practices enables organizations to combine the best parts of change enablement and innovation. DevOps suggests that development and operational support teams work closely together throughout the software development life cycle, where IT operations teams get heavily involved in the testing stage and help the development teams create support documentation and working practices. The development team, in turn, is involved in the early life support period, allowing the service desk and support teams to deal with incidents related to the new or changed service. This approach leads to a more cohesive approach, successful deployments, and improved service levels and customer experience.

Putting things into practice

Now we've established that change management and DevOps can enable and support each other, here are some top tips for blending the two:

• Give your CAB a glow-up. The new ITIL4 guidance has initiated a shift in approval roles. The recent change authority role has replaced the change advisory board (CAB) model used in previous versions of ITIL. One of the biggest pain points technicians, developers, and project managers had with traditional change management was the expectation that everything had to be reviewed and approved by CAB. Replacing the CAB with a change authority means that peer reviewers and automation can assess and authorize changes.
• Another option could be replacing the CAB entirely with a daily stand-up to review release activity. Rather than a traditional CAB meeting, this approach is more for technical experts to review the day's change schedule, discuss any issues, and prompt thinking so the person rolling out the change can sense check their approach and ask for additional support.
• Use models and standard changes to improve flow. Models are a set of predefined steps, so if the nature of the change is known and understood, it should be able to be approved via your tool by the appropriate stakeholders. Standard changes take this a step further by having pre-approval in place for low-risk, routine change activity.
• Use your Definitive Media Library (DML) and Hardware Store (HS) to deploy releases so that you know the assets involved are under version control. Meet the required specifications, secure from external threats, and appropriately licensed.
• Ensure that naming conventions are agreed upon beforehand, making deploying the correct code to the right environment easier.
• When building and testing code in pre-production environments, release all the code together in cycles so that any dependencies can be identified sooner rather than later.
• Introduce the concept of safe-to-fail testing. If something is going to fail, it's better to find out sooner rather than later. Safe-to-Fail applies that concept to test different ways of achieving the best possible outcome through change. A key aspect of Safe-to-Fail is the culture shift it brings. By creating safe spaces, colleagues feel empowered to experiment and learn. Make it clear to your people that a key part of the process of trial and improvement is that there are no silly mistakes as long as they're identified, resolved quickly, and learned from.
• Use canary or pilot environments to sense-check bigger changes. If we embrace best practices, we should be able to trust our code, working practices, and people. Still, we can't plan for everything — operating system quirks, defects that only occur in certain scenarios, and network changes. By first deploying to one contained group, you can understand how your deployment behaves in a live environment without risking the service for your entire user base.
• Use continuous monitoring to detect compliance and security issues associated with your production environment. Build-in automation to trigger events and alerts so that your event and incident management teams can take the appropriate action if an issue is flagged.
• Use stories to reduce the backlog. Reducing batch sizes and having small, frequent changes enables fast flow into production but also supports fast and constant feedback flow throughout the design and transition lifecycle. One way to accomplish this is to reduce the size of your release packages and increase the frequency. By batching work into small, achievable chunks instead of larger deployments, you can make it easier to deploy code and reduce the risk of major defects, supporting continuous integration and delivery.
• Increase speed by talking to your teams about removing constraints and blockers. As a starting point, please speak to your techies, developers, and project managers and make it your mission to find out the pain points in the day job and fix them.
• Create a template for release notes to have a consistent look and feel and link them to your knowledge base so they can be stored centrally and easily accessible.
• Speaking of knowledge bases, storing knowledge centrally so everyone knows where to go for installation instructions, troubleshooting guides, or support contact details.
• Act as one team. All work is peer-reviewed before it can progress, and work with everyone to build a supportive work environment so that everyone feels comfortable challenging when things don't look right, asking questions, or even asking for help. Have technical teams involved in the code development and testing so they can understand and support new services effectively. Have colleagues from the development team assist the service desk and operational support teams on the initial implementation and support phase so that any troubleshooting can be carried out quickly, efficiently, and safely,
• Get your toolsets to do some of the heavy lifting. Integrate the DevOps toolchain with your IT service management (ITSM) tool so that notifications can be sent to the relevant stakeholders at key points in the pipeline, and you move to a pull-based approach to increase efficiency and flow. Consider how automation can increase speed, for example, by scripting the release and having deployments packaged together instead of manually deploying separate files.
• Create a central code repository so that every change to source code is captured and can be rolled back quickly and easily if needed,
• Understand and respond to all stakeholder feedback and make sure that feedback is acknowledged, recorded, and acted on.
• Manage your feedback loops: Shortening and amplifying feedback loops means that quality issues can be fixed at the source, avoiding defects and rework.
• Make time for continual improvement. One approach is to use the concept of marginal gains, the theory that improving and optimizing your performance by a small amount across multiple areas will lead to more significant, noticeable improvements overall. The idea is to carry out a small, achievable chunk or improvement activity, give it time to embed with your organization, and then go again for your next improvement cycle. In the words of Walt Disney, "Keep moving forward," and things will improve over time. Another option is to use 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 continually so that your products, services, and ways of working are continuously refined.

Benefits of Combining Change and DevOps

• Business outcomes are delivered consistently, effectively, and safely.
• Switching up your CAB meeting will free up time and resources to focus on more complex changes. One of my favorite use cases is around the changing role of CAB. There's still a place for it, but my money is changing the scope so that it is a very infrequent meeting that focuses on high-risk, complex changes that could cause service disruption.
• Following a continual release model means that software is deployed in a way that can be tailored to the organization's and its stakeholders' needs.
• Better communication between IT and business teams. By blending change management and DevOps, you ensure that deployments are managed effectively while building on a communication, collaboration, and trust culture. Everyone will be heard, and having additional perspectives can generate new ideas and improve working methods.
• Reduced risk and increased responsiveness; if there is an issue with the code, the change isn't progressing, or something isn't quite right, then it's visible to all, enabling the right action to be taken.
• Increased use of automation increases speed and reduces the potential for human or process error.
• The change queue is more controlled, hand-offs are more efficient, and business outcomes are realized more quickly. In short, DevOps helps your change management process move from a perceived blocker to a key enabler for the business.
• A culture of continual improvement: IT becomes a platform for continual improvement and innovation because experimentation is encouraged, people are encouraged to try new things, and everyone works as one team.

Final thoughts

Change management/enablement and DevOps are much more effective when used together. By blending aspects of change into DevOps practices, you have increased support for governance, GRC, and escalations. By incorporating DevOps into your change practice, your workflows become more efficient, automation will increase flow, and there will be more support for collaboration and teamwork. The result? Faster, leaner, safer outcomes and improved #CX. Deal me in!