As organizations move towards a faster flow of automated software delivery, agile change management has become imperative. So how do you achieve it?
Change management controls the gateway between development and deployment. It does not assess the technical worthiness of a change, nor does it build, test, and deploy a release. Its objective is to control, manage, and mitigate the risk of changes to the production environment.
Many change management processes were designed when waterfall development was the norm, and when governance, risk, and compliance were key objectives for IT. To evaluate risk, organizations stood up change advisory boards (CABs) as a decision-making authority and typically met weekly. All proposed changes had to be accompanied by a request for a change in advance.
At the time, IT operations were focusing on change control, while development was exploring the faster, more iterative, and incremental approach of agile and Scrum. Agile software development paved the way for DevOps and continuous integration (CI), continuous delivery (CD) and continuous deployment. With DevOps, the focus shifted from controlling changes to expediting releases.
Despite that, change management remains an essential process.
The CI/CD model does not eliminate the need for controls and change data. In fact, faster, more frequent deployments mean even more change and risk. Regulatory controls and audits still exist. You must manage risks, whether it’s the risk of making the change or of not making it. Most importantly, everyone in IT should always be able to answer the question “What changed?”
The problem is that while today’s software delivery processes can deliver faster and more frequently, the rigor and limits of traditional change management can seem like a frustrating constraint. If you apply the Theory of Constraints, efforts to improve the adaptability of change management to the CI/CD model of app development would likely result in improvements to the end-to-end value stream.
So how does your organization adapt its change management practices to meet the ever-evolving, faster pace of continuous delivery? Here are two key steps.
1. Change your mindset
The first step is to move away from a one-size-fits-all strategy. The cadence of change is not the same for all products or circumstances. The risk profile for complex changes to monolithic applications is likely not the same as the risk profile for updates to smaller microservices.
Consider creating models for different types of changes and how they are handled. The models will define the policies and procedures for each category of change based on risk and required rigor. The model might also clarify the request/approval process, appropriate decision authorities, testing requirements, release procedures, remediation, timelines, and documentation.
The most common model is for “standard changes”—those that are pre-approved, procedural, and low risk because of a strong track record of success. For instance, releases that pass through the CI/CD pipeline could be authorized as “standard” because of the consistency of the build process, testing, deployment, and documentation that is inherent in the toolchain.
2. Become agile
Next, take a page from software developers and instill agile thinking into the change management process. The Agile Manifesto highlights the values that should be important to all IT professionals. It demonstrates that it is more important to “be agile” than to “do agile.” Most importantly, it reminds developers that while the artifacts on the right are important, they should not prize them over the outcomes on the left.
Both the Agile Manifesto and Scrum Guide encourage software engineers to have “just enough” structure, accompanied by a small set of rules. Examine your change management charter. Do the activities inadvertently emphasize the artifacts (e.g., request for change) over the outcomes (working software)? How much is “just enough” change control for your organization?
Also review your change management documentation requirements. Too many organizations require substantial information in the request for change before the CAB can accept and review it. Which is more important, the request for change or the change record? One shows intent while the other shows activity.
Determine whether the information necessary to assess and support the change is available somewhere else, such as a configuration management tool, source code repository, or defect ticketing system. It may be possible to join or auto-populate that information into a central, dynamic change record without spending time replicating it. In addition, many of the tools in a continuous delivery pipeline produce logs and reports that not only provide data about the change, but also confirm evidence of controls.
Who decides?
Finally, consider designating a hierarchy of decision authorities that aligns with your change models. Decision authorities can range from product-specific peer reviews to local change control boards to full-on enterprise CABs. Each decision authority needs to have clear approval thresholds and a well-defined escalation path.
You could designate special decision authorities for circumstances such as emergency changes or standard change designations. A multi-tiered change approval process can result not only in faster and more frequent deployments, but is likely to result in better conformance and documentation.
Time for a sea change
Adapting change management to continuous delivery is as much cultural as it is procedural, as much human as it is technical. So solicit input from developers, release engineers, and stakeholders about what they like and do not like about your current change management process. Consult auditors and other regulators to ensure continuing compliance. Do an experiment: build a model for a small set of automated changes. Then learn from the experience, improve, and repeat.
Oldest comments (0)