Agile, DevOps and the Future of Change Management

Today, change is an expected and significant part of the business world — it’s the air we breathe. That’s especially true for organizations that have digital products or platforms. 

The publication of the Agile Manifesto in 2001 — and the software revolution it subsequently spawned — changed attitudes towards change among developers and organizations. The new assumption was that products and their requirements were meant to evolve, changing frequently to fix problems and meet customers’ needs. Change management effectively became a never-ending part of life at organizations embracing Agile.

DevOps aimed to improve upon Agile approaches, strengthening relationships between development and operations in order to eliminate silos. But despite these new ways of working, the traditional change control or change advisory board (CAB) remained in many organizations, even those employing Agile and/or DevOps.

Why? Understanding the difference in change management between Agile and DevOps can reveal why legacy institutions like the CAB have remained in place — and how we can continue to optimize value creation frameworks with the help of data analytics to accelerate changes without introducing additional risk.

The Agile Revolution Still Left Traditional Change Gatekeeping in Place

Importantly, Agile only modified part of the traditional business approach, eliminating certain problems while creating new ones. But even at organizations that embraced Agile, silos remained between development and operations. This means that once the exciting development work of a release is done, traditional processes were then invited to take over once more.

Traditionally, a Change Advisory Board (CAB) will review proposed changes once a sprint has been completed. This body acts as a gatekeeper, and they can also be a significant source of deployment delays. If an issue with a change is detected, the CAB must mitigate change risk with the help of IT operations or request the Dev team to revise the change.

In an Agile environment, Dev teams tend to be treated as a force of value creation that must be monitored and controlled. “Never assume the developer will update the story information for you,” advises one Agile consultant. “Do it yourself, and make testers part of the change discussion.”

It’s not hard to see how the effective application of change management is a major obstacle to the successful adoption of Agile. Too often, an initial assumption is that only developers had to embrace the Agile mindset. When it came to operations teams ensuring that changes functioned as intended in the production environment, traditional “waterfall” processes could remain in place.

DevOps Empowers Continuous Change Integration and Deployment — But Bottlenecks Remain

In order to truly accelerate change implementation rather than merely create product changes, IT operations must be considered part of value creation. This is where DevOps distinguishes itself: it recognizes that change integration and change deployment (CI/CD) must be continuous in order for developed changes to make it into production, creating value efficiently and quickly.

With DevOps, there’s an implicit recognition that CI/CD can be as challenging as developing new changes. And there’s an awareness that in a world with ever-accelerating releases, Dev teams need to work in cooperation with — not at odds with — IT operations. 

In a DevOps framework, we tend to see:

• A codified approach to CI/CD
• The idea that a continuous feedback loop can guide Dev strategy
• Feedback is expected, not an unwanted disruption
• Dev & Ops working collaboratively to create value through change

Additionally, we see data accelerating change processes via actions like:

• Automated testing and monitoring for coding practices that lead to defects
• Monitoring data, which can be used to automatically scan code for flaws at check-in (prior to integration)

Yet a problem remains. Many organizations still use a formal CAB to review many — if not all —  changes. 

To keep CABs focused on only major changes, expert groups such as Axelos (creator of Information Technology Infrastructure Library — ITIL) suggest modeling standard changes to automate change processes. And some big changes can be broken into smaller change releases, again allowing many changes to follow standardized change models, obviating the need for CAB review.

DevOps sets a great example for how to eliminate silos. Organizations need to recognize the value of incorporating change management into processes, instead of holding fast to a separate legacy appendage such as CAB, originally created to control change. Those days are gone; notice the shift in values signaled by the evolution of how we talk about change. Change control gave way to change management — and now, with ITIL 4, comes change enablement.   

It’s Time to Evolve Beyond Traditional Change Gatekeepers

The transition to DevOps from Agile represents an evolution that should prompt the phasing out of traditional change management techniques. Since Agile is older, its relationship with change management is more siloed, inviting not just slowdowns in change deployment but conflicts between teams working in different silos.

“Many change management processes were designed when waterfall development was the norm, and when governance, risk, and compliance were key objectives for IT,” the DevOps Institute explains. But DevOps shifts the focus from controlling changes to expediting releases. This reduced the risk of conflicts between silos.

But maintaining a formal CAB allows at least one silo to persist. So why do organizations hold on to this entity? They’re often afraid of risk. But there’s a misperception at play here: slowdowns don’t automatically reduce risk. They do impede value creation, however. 

Moreover, robust data analytics can often supply the resources needed to quantify and understand risk, and make appropriate decisions in light of it.

Agile was an important first step, and DevOps moved us forward by turning Agile principles and practices into a legitimate business operations model. But organizations need to go even further, with data as their guide, to eliminate unnecessary inefficiencies and rethink processes that rely upon traditional change gatekeepers. Only then can all value co-creation teams be given the freedom they need to excel, without the risk of failure looming overhead.

Learn about how recent advances in AI-powered analytics can help you adopt ITIL 4 best practices, realize the benefits promised by DevOps, and retain the discipline of ITIL in our recent webinar: “DevOps & AI: Do we still need ITIL Change Management?”

Watch the Webinar