Inspire, develop, and guide a winning organization.
Create visible workflows to achieve well-architected software.
Understand and use meaningful data to measure success.
Integrate and automate quality, security, and compliance into daily work.
Understand the unique values and behaviors of a successful organization.
Explore our extensive library of experience reports.
An on-demand learning experience from the people who brought you The Phoenix Project, Team Topologies, Accelerate, and more.
Learn how making work visible, value stream management, and flow metrics can affect change in your organization.
Clarify team interactions for fast flow using simple sense-making approaches and tools.
Multiple award-winning CTO, researcher, and bestselling author Gene Kim hosts enterprise technology and business leaders.
In the first part of this two-part episode of The Idealcast, Gene Kim speaks with Dr. Ron Westrum, Emeritus Professor of Sociology at Eastern Michigan University.
In the first episode of Season 2 of The Idealcast, Gene Kim speaks with Admiral John Richardson, who served as Chief of Naval Operations for four years.
Weekly discussion around “Deming’s Journey to Profound Knowledge” with author John Willis.
VIRTUAL — Helping leaders succeed and organizations thrive (formerly DevOps Enterprise Summit).
Venue: Fontainebleau — Helping leaders succeed and organizations thrive (formerly DevOps Enterprise Summit).
DevOps best practices, case studies, organizational change, ways of working, and the latest thinking affecting business and technology leadership.
Is slowify a real word?
Could right fit help talent discover more meaning and satisfaction at work and help companies find lost productivity?
The values and philosophies that frame the processes, procedures, and practices of DevOps.
This post presents the four key metrics to measure software delivery performance.
July 27, 2021
This post is an excerpt of the Breaking the Change Management Barrier whitepaper by Ron Forrester, Sr., Jayne Groll, Chris Hill, Dr. Steve Mayner, Erica Morrison, Scott Nasello, Scott Prugh, and Rosalind Radcliffe.
During an era of rising regulation and linear, waterfall software development, enterprises adopted a rigorous approach to IT’s change-management process in order to regulate releases into production systems and demonstrate auditable Information Technology (IT) controls. (For the purposes of this post, the term “change management” refers to enterprise technology changes.)
In the past best practice frameworks advocated for the creation of Change Advisory Boards (CABs) that would be responsible for assessing requests for change (RFC) against risk and impact, as well as collision avoidance. The intent was to create a holistic advisory group with the skills and experience to evaluate “normal” changes and strike a balance between stability and innovation. By definition, normal changes were unique and had no history of risk or reward.
As change management became entrenched in the enterprise, the CAB shifted from an advisory group to a decision authority for most, if not all, requested changes. The burden on the change initiator grew as RFC details, timelines, and level of pre-submission approvals increased.
Traditional change management places more emphasis on managing RFCs over the change traceability, or change record. The net result has made for longer lead times, increased impediments and overhead costs, and frustration from the Development and Operations teams, business leaders, and customers. Once an enabler of innovation, command-and-control change management is now considered a constraint.
The business climate has changed, and IT must adapt its processes accordingly. IT has to implement changes more rapidly to gain or sustain a competitive advantage in this disruptive landscape. Smaller releases with risks mitigated by frequent and automated testing can deliver value faster and more frequently if allowed to deploy into production with a minimum viable process. Determining what’s “just enough” change management depends on the risk appetite and compliance requirements of the organization. However, even small improvements to change management and the CAB can result in big advancements.
This post offers several patterns that can be applied in tandem or as appropriate by leaders seeking ideas and opportunities for optimizing the ongoing value of change management while reducing its complexity.
Any discussion of transforming the change-management process must begin with a recognition that legacy change practices were put in place for a reason. Boards of directors and officers of corporations have fiduciary accountability for ensuring the ongoing viability of the organization. Public-sector leaders are similarly responsible for the use of taxpayer funds to provide vital services to citizens. These responsibilities frequently involve compliance with a complex spectrum of laws and regulations. As organizations become increasingly dependent on technology for critical business capabilities, system failures represent an unacceptable threat to them and to society, requiring business leaders to institute measures that anticipate and reduce these risks.
More specifically, laws such as the Sarbanes-Oxley Act of 2002 in the United States, international standards bodies such as the Payment Card Industry (PCI) and International Standards Organization (ISO), and regulatory agencies such as the Food and Drug Administration (FDA) prescribe adherence to change management best practices as a compliance requirement. The governing bodies commonly write standards with a bias toward traditional, process-heavy change practices. Executives, compliance officers, and internal and external auditors can all be held personally accountable for failure to comply to these guidelines. This frequently, and understandably, leads to a range of responses, from skepticism to outright rejection, when considering proposals for implementing modern change management practices.
IT leaders including chief information officers (CIOs), chief information security officers (CISOs), program managers, technical managers, and even teams themselves are invested in ensuring changes are applied to production systems in ways that don’t result in outages, invalid data, poor responsiveness, and more. Failures in critical technology capabilities lead to a loss of confidence in the IT organization, as well as the diversion of limited resources away from innovation to recovery and remediation activities.
Well-intentioned, traditional change-management processes frequently display a series of dysfunctions and anti-patterns. They include:
Before exploring the specific patterns in evolving the change-management process for modern systems development, it’s important to address the foundations that provide a principled backdrop for each of the below recommendations.
The first overarching pattern is to understand and embrace Lean thinking. “Lean” refers to a body of knowledge that was first pioneered in manufacturing by Toyota in the 1940s. It describes a set of principles, practices, and tools that enable people to continually improve their work.1 These improvements focus on reducing waste and increasing quality.
The concepts of Lean have been adapted to technology development by Allen Ward, Don Reinertsen, and others. In addition to reducing waste and increasing quality, the application of Lean to product development aims to create a continuous flow of value in the form of working systems and software features. While these thought leaders have described many concepts and practices for Lean product development, three are particularly relevant to the discussion of rethinking the traditional change-management process.
One of the keys to creating continuous flow of value in product development is to reduce the batch size of work. Research cited by thought leaders, such as Reinertsen, shows that smaller batches move through the end-to-end development process quicker, with less variability and fewer defects. In the context of change management, smaller, more frequent changes represent less risk as there are fewer variables that have the potential to result in an error or outage. Smaller batches are easier to test, and defects are easier to find and correct.
Another important concept from Lean is that longer queues increase the lead time in which it takes new features to flow through the process from inception to delivery. This principle is described in the queuing theory known as Little’s Law that states the average wait time for a service from a system equals the ratio of the average queue length divided by the average processing rate. In other words, the longer the queue, or list of committed items in the backlog, the longer the wait time for customers to receive the value represented by the new feature.
Applied to change management, long queues of changes cause delays. Therefore, the change-management process needs to be optimized to commit to short lists of changes, while all other changes are simply “forecasted.” This maximizes the flexibility to add, delete, or re-sequence changes to deliver the highest value changes in the shortest lead time. Not only do queues create long lead times, but they also create an opportunity for lost context and knowledge as the work is handed off from one team to another. We like to say that: “Not only do queues not scale, but they also don’t learn.”
An impediment to proposing a new approach for change management is the daunting prospect of replacing deeply rooted processes that were once widely accepted as best practice. It’s ironic that the fear of change is one of the biggest barriers to improving how we change. Fortunately, the principles of Lean and Agile once again provide a path forward. Each of these bodies of knowledge draw from the language of the scientific method by initiating change as a hypothesis, followed by experiments testing that hypothesis. Once the experiments have concluded, observations and learnings develop the next hypothesis based on the results. The guidance here is to evolve change-management practices as a series of small experiments, enabling the organization to iteratively understand and adapt these processes over time based on validated learning and measured improvements in quality and flow.
The next foundational pattern’s purpose is to empower teams to participate in and contribute to the development of modern change-management practices. After all, the teams generate changes that ultimately flow into the production system and have valuable insights into techniques such as automation that can manually providepreviously performed validations. Not only do they provide better solutions for improving change management but being a part of the improvement process also engenders ownership and accountability in the teams for the overall execution. Lyssa Adkins, a well-known thought leader in Agile coaching, states, “Accountability sticks when you mindfully work towards getting to a solution rather than passively receiving directions from another.”4
We understand that many organizations have deeply entrenched change processes that have evolved over years and even decades. This includes lengthy CAB meetings, multiple approvers, and dedicated people who manage these changes. Disrupting this head-on will be difficult. With this post, our hope is to provide a set of patterns that can be applied incrementally to improve change in your organization. We recommend an approach that “eats the edges incrementally” of your change-management process. For example: start with applying easier patterns, such as low-risk classing and exemptions to reduce overhead and gain wins. Then, begin moving to more complexpatterns, such as localizing changes and CAB. By this manner, you can deliver both value and credibility faster. Attacking the entire change process at once will likely lead to setbacks, and we do not recommend starting with that approach.
The figure below represents a set of patterns that can be adopted in support of the transformation. Each pattern provides a brief summary of the pattern, the problem it’s addressing, and a proposed solution. Our goal is to demonstrate ways organizations have transformed and to help provide specific guidance that will improve thechange process in your organization. Where applicable, we also include concrete examples of what has worked in other organizations. The patterns are introduced by increasing difficulty of adoption for traditional organizations with entrenched change processes.
To read the details on each pattern, please download the Breaking the Change Management Barrier whitepaper here.
Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.
Welcome to the twelfth installment of IT Revolution’s series based on the book Investments…
In today's fast-paced and ever-evolving business landscape, organizations are constantly undergoing transformations to stay…
Holy cow, Enterprise Technology Leadership Summit Europe Virtual is happening next week, and I’m…
Welcome to the eleventh installment of IT Revolution’s series based on the book Investments…