The Chickens Have Flown the Coop: Change Management Is Back!

Chickens come home to roost. That idiom, or something like it, has been around for hundreds of years. While it refers to the consequences of actions, it also builds in a mistaken assumption that chickens will always go right back to where they belong, even without cages. As many cage-free farmers have learned, that’s not a sure thing.

It’s just as likely that the chickens will go crazy and start eating each other. No, really… 🤯🤪😳

This brings us to modern development. We’re dealing with the consequences of a “cage-free” system. The focus has been on innovation without parameters for so long that essential checks and balances get swept aside.

Broad, unfettered development has been important for progress. But it also gave us pacemakers that could be used to trigger mass heart attacks via radio waves and vehicles that can be remotely stolen or crashed. Over the last decade, it could be said that our thirst for innovation and profit has created a situation where developers are launching code all over the place with no restrictions. And now, the chickens are coming home to roost.

It’s time for a return to change management. However, “return” doesn’t mean recreating the problematic change controls of the past. I have no desire to sit or watch lengthy day-long change review boards. Those days are for certain over, but that doesn’t mean we can use our great DevSecOps automation skills to implement quality gates or change controls. It’s not a return to the cramped coop, nor is it as boundless as cage-free. It’s controlled innovation built on automation.

Controlling Changes in Development

While the term “change management” gets thrown around a lot, the specific term discussed here comes from the Information Technology Infrastructure Library. The goal of ITIL is the standardization of IT service best practices. One of those areas of focus is change management. ITIL is currently in its fourth iteration.

The 2019 version is the first significant update to ITIL since 2007, which was based on systems that in no way resemble our modern ones. Change control was a strict, stringent process led by boards that did not have the ability to make split-second decisions. Changes needed to go through reviews and discussions.

Now compare that to the current state of development, with companies like Facebook and Netflix setting the standards. Both companies are notorious for daily updates being pushed by thousands of developers. Of course, with all their active users and desirable UI features, they become the companies that everyone wants to emulate. So enterprises followed suit, encouraging developers to “move fast and break things.”

The part that gets glossed over is that things actually get broken. User data gets leaked, systems don’t work right and general mayhem ensues (see above chicken reference).

What about compliance? What about security? Those aren’t fun, sexy concepts that are going to drive the next big change. As developers are tinkering with the UI and pushing changes, those two very important pieces get left out. By the time their importance is realized, it’s too late to go back and fix it.

This is a problem that’s going to grow exponentially along with low code/no code development. A new generation of citizen developers are about to take to the internet and create their own apps and programs using modern platforms that make it as easy as clicking a button. Even more change barriers have been removed.

So picture mass-scale development, much of which is managed by people who have never even heard of change control, and try to place old standards on that. Tell a Netflix engineer to fill out a form for every line of code they push and watch that development screech to a halt.

Luckily, that’s not necessary. It’s not about returning the developers to the metaphorical chicken coop with all its boundaries and restrictions. It’s about reimagining the coop entirely.

3 Steps to Implementing Modern Change Management

It’s not possible to return to old styles of change management to support current development — but we can’t continue to go without. To overcome that, we need to build change management on three key tools: automation, best practices and exception-based human-in-the-loop (HITL).

• Automation: Tasks that are high volume, repeatable and predictable are also automatable. Many traditional change management steps are ripe for automation. Look at the traditional change control board. The job involved a committee, filling out cards and checking off boxes to determine if a change was ready. There’s no reason an automated system can’t use the same benchmarks and make those kinds of decisions in moments, rather than days.
• Best practices: Many developers creating different things their own way is a recipe for disaster. Organizations can’t follow the flow of development, nor can they trace issues. Best practices provide development standardization. Everyone who touches the code follows the same rules. That limits anomalies that make maintenance and error detection a challenge.
• Exception-based HITL: Automation is great, but there needs to be human ownership over certain higher-risk tasks. In an exception-based approach to HITL automation, a baseline is set for normal operations. Anything within parameters passes by without further scrutiny. When something comes along that falls outside of those parameters — like a change that has potential system-wide repercussions — a notification triggers.

These three tools set the foundation for an automated but fully functional change management process that still allows for human oversight. The pace of development is maintained, but the problems are reduced.

Modernizing the Coop with Change Management

Security and compliance should be a foundation in any change management process, but how can there be a foundation with no framework in place? It’s not possible to use the change management of the past — it can’t keep up with modern needs. So instead, it’s time to redefine it.

That’s something ITIL has already addressed. The most recent adaptation, ITIL 4, renames the practice change enablement, making it clear it’s not the strict review of the past. Instead, it’s a technology-driven process built on automation and value creation.

Change management used to be primarily human-oriented. It was an unsophisticated pipeline focused on operations. DevOps was meant to pull the two together, resulting in one single goal — to accelerate production. That’s an obvious operations mindset. But there also needs to be room for security and compliance — which in many cases, can be embedded into the CI/CD pipeline.

Strategies like these let Netflix and Facebook get away with hundreds of updates and minimal problems. Sophisticated CI/CD pipelines and quality gates control the flow. That allows their developers to focus their attention in other areas. Human-level authorization is implemented at machine scalability and speed.

Change management is back, but not in any way we’ve seen before. It’s a modernized, flexible process designed to keep up with the speed of today’s development. In a way, new change management brings the coop to the chickens, rather than the other way around.