When you add approval stages to increase stability, the last thing you expect is instability. That’s the opposite of what you wanted. Yet that’s what happens when organizations respond to incidents by increasing the weight of change approval processes.
That means there’s more art to change approvals than most people realize, and it’s a threat to an organization’s ability to deploy and operate software if they don’t have change finesse.
Watch the episode
You can watch the episode below, or read on to find some of the key discussion points.
Watch Continuous Delivery Office Hours Ep.6
Organizational trauma
Change approvals don’t arrive without reason. If you have a heavyweight change approval process and frequent or extended change freezes, the chances are that they were introduced after a major incident. If you break financial software around tax year-end, banning deployments for a month before and a month after is, in theory, a reasonable resolution.
Almost every industry has a cadence it wants to protect from instability. Retail has seasonal sales events, the music industry has superstar ticket launches, and finance has a peak as the end of the tax year approaches. The goal is to make sure you can operate your business during these times.
With that goal in mind, we have to bust the myth of change approvals as the mechanism to achieve it. Attempting to protect these key moments with change freezes or cumbersome approval processes has one result: increased instability.
Heavyweight change approvals
Heavyweight change approvals make things less stable by delaying work and causing batches of unreleased changes to accumulate. Meanwhile, developers are starting new work and are losing the immediate familiarity with the oldest changes as they press ahead. One of the ways approvals gain weight is through approval chains, which we looked at in depth in the Compliance through Continuous Delivery report.
Large batches also come with admin that can introduce further problems. Testing becomes more difficult, the likelihood of merge issues increases, and pinpointing the source of a problem is far harder.
This is why the DORA research placed streamlined change approvals in their core model for software delivery. Centralized change approval boards don’t work, and process is never the solution to your stability problems.
Streamlining
There are some easy ways to streamline change approvals. Most of these don’t look like traditional change management, which is good because we know that doesn’t work.
The first way to trim the process is to automate your verification stages. At every level of review, tasks can be automated, whether it’s automatically linting and formatting code (instead of debating it), running automated builds and tests, or validating your SBOM is free from insecure dependencies.
Where you need a human review, use a peer-review process for individual changes, enforced on commit, with humans brought in only after the automated validation has passed. If you have advanced change approval needs, categorizing changes by risk lets you apply your people to the changes that most need their perspective.
You won’t achieve all of this in one day. It’s part of your continuous improvement process. You may improve your chances of stripping the bureaucracy if you follow the capability culture cycle pattern.
Small batches, again
If you follow industry experts or the research, you’ll notice that small batches keep cropping up as the answer to many kinds of dysfunction. That’s not a coincidence. Large batches cause far-reaching problems that build superlinearly as more changes collect unreleased.
Anything that causes batch size to increase, including change approvals, must be subject to fierce improvement.
Happy deployments!
Continuous Delivery Office Hours is a series of conversations about software delivery, with Tony Kelly, Bob Walker, and Steve Fenton.
You can find more episodes on YouTube, Apple Podcasts, and Pocket Casts.
