There’s been a great deal of discussion recently about the phrase “Change Control” – especially with ITIL4 switching from Change Management to Change Control in the initial release of the foundation book.
I wrote about it in What’s with Change Control in ITIL4. But shortly thereafter, it somewhat unceremoniously changed to Change Enablement. Akshay Anand covers it in Continuous Integration/Continuous Deployment (Of Guidance).
In a well written article (Control, Enablement? Why a word matters) that both summarizes the history and articulates a certain perspective, Jon Hall says “The challenge here is the word “Control”. Rob (England) didn’t like it, and neither did I. We weren’t alone. Rob and I have both spoken at a number of DevOps conferences, and spent a lot of time in that community, and perhaps we knew more than most how much “control” would be problematic.” (emphasis mine)
The call is “Control” is a bad word. That’s the call.
And I’m throwing the challenge flag.
A Rose by another name?
Meanwhile, there’s confusion between (IT) Change Management and Organizational Change Management (OCM), both of which have long been known as simply ‘Change Management.’ Unfortunately, “Change Management”, without context, is ambiguous.
Undoubtedly this was part of the rationale for renaming the practice to “Change Control” in ITIL4. It’s not an uncommon term, and I’ve seen it used many times as a synonym to ‘IT Change Management’.
Be that as it may, in the postmodern world, we’ve all become more sensitive to the nuances and subtle messages words carry. Could it be that “control” truly is, in itself, offensive – especially to application developers?
To find out, I explored some of the haunts of application development.
I immediately came across ‘version control’. The ability to manage complex combinations of code being updated by one, several, or many developers has long been critical in successful applications development. While it goes under various names – source control, version control, code control – the one thing they all have in common (outside the value in coordinating code in development teams larger than one) is the word ‘control’.
A few popular tools-of-the-trade that prominently and unapologetically feature “version (or code) control”: Azure DevOps (Microsoft Team Foundation Server), Git, AWS Code Commit, Helix Core, Subversion, ITBM Rational Clear Case, and many more.
In an article for Devops.com, Tim Russell says “While not the answer to everything, version control—that long-established foundation of software development toolchains—has become a central part of DevOps, particularly DevOps at scale.”
Microsoft, in the Azure DevOps user guide (“What is Source Control“) says succinctly: “Source control is an essential tool for multi-developer projects.”
In an article published on DZone.com , DBmastero CEO Yariv Tabac says “As DevOps adoption has accelerated in recent years, GitHub has taken an active role in automation, with dozens of reference points throughout the automation and build sequences, version control has long since been adopted as the gospel for code development.”
But it doesn’t stop there.
The 2018 State of DevOps Report lists “Version Control” as one of “The two practices that define Stage 1 work to reduce complexity”. In fact, the term “Version Control” appears no less than 45 times in the report – each time in a positive light.
From a DevOps.com article, Sudhi Seshachala says: “Version control is well-supported by the Puppet ecosystem. It is possible to use a mature Software Development Lifecycle to manage the development and maintenance of your Puppet manifests, tightly integrated with a branch-based workflow that truly realizes the ideals of “infrastructure-as-code.”
The popular workflow tool Jira includes a really cool feature – the control chart, which “helps you identify whether data from the current sprint can be used to determine future performance. The less variance in the cycle time of an issue, the higher the confidence in using the mean (or median) as an indication of future performance.” Here, the concept is directly from the field of Statistical Process Control, where it helps understand if a process is in a “state of control”. In other words, it’s a data driven approach to understanding if variation in the work stream is associated with known sources.
In Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (2018, IT Revolution Press, Portland Oregon), ‘version control’ is used 55 times, and in a section directly addressing compliance controls related to managing changes, authors Nicole Forsgren PhD, Jez Humble, Gene Kim had this to say:
In regulated industries, segregation of duties is often required either explicitly in the wording of the regulation (for instance, in the case of PCI DSS) or by auditors. However, implementing this control does not require the use of a CAB or separate operations team. There are two mechanisms which can be effectively used to satisfy both the letter and the spirit of this control.
Note that the authors used the term “implementing this control”. They used the term because it’s a non-optional business control put in place by a company in order to maintain regulatory compliance (which is important if you want to stay in business.) They didn’t say the control wasn’t important, or that compliance with a control was insulting or offensive. They’re simply saying the control can be implemented without a “CAB or separate operations team”
And I wholeheartedly agree.
In other words
While we’re at…
Modern trains are equipped with Positive Train Control systems, which is “…a system designed to prevent train-to-train collisions, derailments caused by excessive speeds, unauthorized train movements in work zones, and the movement of trains through switches left in the wrong position.” This system supplements the age-old Centralized Traffic Control system, which is the red/yellow/green signals with which we’re all familiar.
Air traffic is managed by a system of Air Traffic Control which includes Ground Control, Takeoff Control, Area/”Center” Control, Arrival Control, and others, all of which work together with skilled and experienced pilots in a highly complex system to keep global air travel safe and efficient.
It’s not the word
If the word itself is problematic and offensive, then why does it play so prominently, so close to those for whom the term is said to be offensive? Even if it were an old school legacy artifact, surely the leading works and tools of Agile/DevOps thought leadership would have phased it out in favor of a less-offensive term.
But they havent.
And that gets us to the heart of the matter: it’s not the word that’s offensive.
CAB Is Useless*
Dr. Nicole Forsgren helped underscore the issue at DevOps Enterprise Summit 2018 when she infamously said from the stage (The Data Behind DevOps: Becoming a High Performer – DORA 29:28): “Change Advisory Boards are useless”, and, as if to make her point clear, she added “so if you think you’re helping; you’re not. Sorry”. Her words drew cheers and applause from the predominately application development audience.
Application developers have long hated the traditional “bring all changes to CAB where a bunch of non-devs will ask questions that add no value” approach to Change Management. Dr. Forsgren was citing data from the State of DevOps report, demonstrating that there was no positive correlation between the existence of something called “CAB” and change failure rates and recoverability.
And she’s (still) not wrong.
After further review
However, in the 2019 State of DevOps Report, “heavyweight change processes” are specifically called out. Those that “… require the approval of an external body such as a change advisory board (CAB) or a senior manager for significant changes have a negative impact on software delivery performance”.
What’s called out is a very relevant issue – use of ‘heavyweight change processes”.
Not the words used.
The report goes on to suggest that “…heavyweight change management processes…” are explicitly “…proposed by ITSM frameworks…”. I don’t care to debate the point with the authors, but this simply isn’t true.
As an industry, ITSM is not recommending heavyweight change management processes as a best practice. Neither does ITIL in the latest revision. For that matter, the previous ITIL (2011) Change Management process included emphasis on delegation of change authority, the use of Standard Changes and Change Models to facilitate accelerated change delivery where it’s been demonstrated that change outcomes are consistently achieved, and risks are managed appropriately.
This is precisely what Agile/DevOps seeks to do as well – manage changes in the flow, as part of the value stream, and not an add-on inspection point at the end.
Interestingly, in response to Dr. Forsgren’s CAB comments in the clip above, Jez Humble added; “…we think they (CABS) should meet a governance function. Thinking about how can we make more effective change management processes. It should be about governance, and not about inspecting individual changes, which is a terrible idea.”
I’m well aware that all this seems to have been lost at many companies, and Change Management practices, in far too many cases, continues its bureaucratic bent. So, let me make this perfectly clear: THAT is the problem, not the word “control”.
Keep in mind that “Control” has a proper definition, especially when it comes to regulatory and compliance requirements (as mentioned above by the authors of Accelerate.) Controls are put into place by organizations to ensure certain aspects of the business are conducted as expected and required.
PCI/DSS, for instance, groups 12 specific requirements under 6 Control Objectives.
Cobit, widely used in Governance, Risk and Compliance as well as audit communities, also prominently features Control Objectives.
NIST 800-53, widely viewed as the authoritative work on information security, features over 200 controls grouped into 18 Control Families.
In a broader sense, the word ‘control’ is an integral part of effectively managing a company. From 35 Business Controls Your Company Needs to Successfully Scale, controls are not about “…being a traffic cop hiding in the bushes to leap out and give an unwary team member a speeding ticket, rather, you want your controls to be more like a speedometer or cruise control system that helps individual team members autonomously do better work. Your controls, which are really just a specialized subset of your business systems, help your team members do better work.”
When control is understood in this sense, it is not only not offensive, it is completely in sync with managing changes at high velocity.
In the case of Agile/DevOps – the goal is to make sure the value stream is achieving the organization’s change outcome expectations, including all required/relevant control objectives, and let it roll. (Oversight and governance, not inspecting individual changes)
In other cases, like a major project migrating from an internally-developed, legacy system to a SaaS ERP – appropriate oversight and governance must be applied to ensure the organization’s change outcome expectations are met, sensitive information is adequately protected, and the business is not adversely impacted. How this is accomplished is less important than ensuring that it is done effectively, consistent with the organization’s needs.
The goal of Change Management (Control/Enablement) is precisely this.
So, after further review, the ruling on the field is overturned. “Control”, when used properly, is not offensive and does not advocate for bureaucratic command and control of people.