Change management is often hampered by cumbersome legacy processes that frequently limit the release velocity. Start optimizing with this blog post.
Change has become the most important part of modern digital product creation and curation. While these changes often involve adding new features, they are also driven by responses to customer demands as well as stakeholder priorities. The goal of DevOps teams is to prioritize not only fast changes but also those that can bring lasting, measurable value.
Unfortunately, the ideas of CI/CD are not always reflected in the actual practices of the organization. For starters, change management can be hampered by a lack of testing or feedback. In addition, cumbersome legacy processes remain in place, which frequently limit the velocity at which new value can be created within teams or organizations.
But DevOps teams can examine a number of key areas to find opportunities for improvement. These improvements all aim to optimize change management to make it faster, more agile, and more likely to result in frequent value creation through CI/CD. Based on these criteria, our top recommended improvements are:
- Limiting manual change approval through strategic change modeling
- Generating, capturing, and capitalizing on continuous feedback
- Mapping processes to look for steps ripe for elimination or revision
Expedite change approvals through standard change models
DevOps prizes rapid, iterative changes enacted by highly autonomous teams. Teams typically have the authority to make their own decisions, allowing them to pivot as needed and evolve strategies based on the information available at the given moment. This agile team structure eliminates the bottlenecks of the legacy “waterfall” approach. In old-style waterfall development, coding teams counted on directives that came from above. Many times, these directives reflected initiatives that would go on for months at a time, and the instructions weren’t expected to change until after the final product was delivered in full.
Even the agile mindset has not eliminated holdouts from this legacy waterfall approach. One of the most pernicious holdouts is the manual change advisory board (CAB) review.
Although there is a need to vet and approve of changes proposed for the next deployment release, these approvals don’t always have to be done manually. At the very least, DevOps teams should aim to limit the number of reviews requiring participation by the top-level CAB team. Limiting the number and frequency of changes that need to be reviewed by the CAB will help streamline the process and minimize disruptions. How can DevOps reduce its reliance on CAB reviews? It can start by modeling changes to fit within standard and non-standard groups.
A standard change is any routine change that is related to similar changes in the past or that represents a repeated strategy for product improvement. There is usually a wealth of data to suggest that the standard change will cause minimal risk of disruption, defects, or change failure. That way, a standard change can be automatically approved after automated review and testing pre-deployment.
Analytics can offer insights into the risk of a given change, whether standard or non-standard, through the use of expressive change risk KPIs.
For changes that don’t fit a standard model, development teams can break up the deployment into standard and non-standard components. That way the components that require scrutiny can be isolated, reducing the scope and time required by the CAB team.
It’s also possible to limit the scope of review even when a manual review is needed. According to one popular ITSM resource website, the concept of “delegated authority” can be employed when a change doesn’t quite fit the criteria for following the standard model but is instead limited to a particular department or location. This model works by ensuring that changes with localized risks are reviewed and authorized by a local authority, such as an IT manager or a business unit head. This practice can eliminate the need to convene the entire CAB to review and approve changes.
Make CI and database management more agile
Automation can eliminate the need for human touchpoints in general. But automation shouldn’t become a computer-controlled version of an inefficient process.
DevOps teams need to ensure they’re maximizing the utility of automation by building documentation capabilities within the DevOps pipeline. Any time a change alters or affects a relationship with a configuration item (CI), then the development tools should record this interaction as early as possible using automated documentation. That way, anyone wishing to audit changes to CIs can do so quickly and pull up the exact changes that affect the given CI.
CI interactions particularly tend to slow down change approvals any time a database change is needed. The change to the database can lead to performance defects in the CI if care isn’t taken to account for the given change’s effects.
To reduce the risk of defects while hastening CI-related changes, an OpenSource.com expert recommends that since “database changes tend to complicate continuous integration,” DevOps teams can simplify the process. “With database continuous integration (DBCI) using an agile cross-functional team that includes a database administrator.” The expert also recommends relying more heavily on “database as code,” and, “refactoring databases using object-oriented (OO) principles.”
Rely on continuous data feedback to improve change management
Using data analytics can provide vital feedback at all points of the value stream, allowing development and operations to work in tandem to improve change reliability.
As continuous delivery expert Matthew Skelton comments, “logging and metrics are crucial ‘sensing mechanisms’ for teams building modern software systems, rather like the radar and video pattern-recognition systems that help autonomous vehicles to travel safely at speed on the highways.”
The feedback generated by these activities can help redirect the teams’ ongoing activities, steering them towards changes that generate higher value with minimal risk of defects. Note, though, that the right metrics are necessary to promote fast and effective feedback. For example, a high defect escape rate coming from changes made by a certain team can indicate the need for more test coverage of that team’s releases or perhaps alterations to the coding practices the particular team relies upon.
Monitoring system performance and using feedback to improve is traditionally seen as the purview of operations teams. While it’s true that operations teams are responsible for final deployment and performance in the production environment, it’s crucial that development teams have access to the same monitoring tools so they can track key change performance metrics and detect possible issues. Giving development teams access to this data can allow them to detect defects and fix them, potentially even altering their coding practices to create more-stable changes. Allowing them to monitor and correct such issues on their own, without the need for directives from higher-ups, enables proactive autonomy and, potentially, higher job satisfaction.
However, know that it may take some time for development teams to adjust to being given the responsibility to review and potentially respond to operations feedback. Doing so often goes beyond the work that comes with adopting a new process or technology. It requires a culture change and a definitive strategy to ensure buy-in for agile CI/CD from the organization.
Implement process mapping to see where value is created or negatively affected
In order to identify value production bottlenecks, DevOps leaders can create a conceptual map of every stage of work in DevOps and all teams involved. The document created from this analysis is known as a “value stream map.” It can be leveraged to track the flow of not just work but actual value through each stage of the process.
Creating and tracking metrics for each stage can be extremely useful for detecting defects and improving agility. For example, tracking metrics for the total time between the arrival of work at a specific stage and its time to departure can provide valuable insights into efficiency. It will also highlight persistent issues in a given work area.
Tracking the process at each stage allows DevOps teams to go beyond just examining isolated parts. Process mapping in this manner helps to visualize how value flows through the entire process and how it is impacted by each step. For example, reducing the steps in-between build/test and deployment will add value to the entire process.
As Conflux’s Matthew Skelton observes, “long, slow deployment pipelines break rapid feedback from the deployment process. Instead, use short, wide deployment pipelines that give teams and product managers enough flexibility to decide which tests to run based on the nature of each specific change.”
Use these suggestions as the foundation for better, more-agile change management
While it’s easy to suggest possible places for optimizing the CI/CD process, the fact is every organization is unique when it comes to DevOps deployment. For this reason, process mapping is critical in order to pinpoint exactly where improvement opportunities present themselves in your organization.
Data feedback is crucial to guide your decision-making strategies towards improved agility. In addition, automated data collection can promote a culture of self-driven improvement within Dev teams, which can, in turn, enhance the CI/CD culture in both IT and in the organization as a whole.
Finally, advanced machine learning modeling can even leverage data to create a more complex understanding of things like change risks, allowing you and your teams to not just view data but act on it with precision. Giving change enablement teams access to tools like expressive risk modeling empowers a culture of rapid understanding, rapid work, and rapid decision-making — all of which allow DevOps to produce more value more often without creating unintended risk.
Discover how AI-powered analytics, like Change Risk Prediction, can bridge the gap between ITIL and DevOps in this webcast.