Improved Process Outcomes
The ZeroBlockers framework aims to optimise organisational processes by identifying and removing obstacles (blockers) to efficiency and effectiveness. It emphasises lean principles, agility, and continuous feedback to enhance the way teams work and deliver value.
Metrics
| Metric | Description |
|---|---|
| Evaluation Time | The time it takes from prioritising an opportunity until there is a validated solution, or the opportunity is deprioritised. |
| Lead Time to First Release | The time it takes to move from a validated solution to production. This is not necessarily your finished feature but the first version that you are using to get further feedback from customers. |
| Lead Time to Satisfied Customer | The time it takes to move from a validated solution to satisfied customer. This is the point that you are happy with the solution and are ready to move to the next opportunity. |
| Release Frequency | How often new features are released to customers. This should be individual releases and not gamed by counting multiple different teams inputting into a single large release as multiple releases. |
| Change Failure Rate | How often a change results in a failure in production. However, you want to ensure that you do not discourage teams to make changes. Some companies do not count a failure if the team recovers within 5 minutes. |
| Mean Time to Recovery | The average amount of time it takes to recover from a failure in production. This is the time from when the failure is introduced until the system is back to normal. |
The speed-stability tension
The DORA metrics fall into two camps that pull against each other. Lead Time and Release Frequency reward shipping fast. Change Failure Rate and Mean Time to Recovery reward shipping safely. A team that optimises only for speed will see change failure rate climb. A team that optimises only for safety will add gates that drive lead time up.
The ZeroBlockers position is that the four metrics have to be tracked together, and that the tension is the point. Stable systems with slow lead times can be just as bad for the business as fast systems that break in production. The team's job is to make the underlying capabilities good enough that they can move fast and recover fast.
Ryanair case study
Ryanair's engineering organisation built a public traffic-light system to manage the tension at scale.
- All teams start on green. Green-status teams are allowed to deploy to production without approval.
- Status drops if you cause issues in production. As a team moves to amber and then red, more gates are added before they can release. The team stays at the lower status until they have demonstrated stable releases for a defined period.
- All team statuses are public. Public visibility of status keeps teams motivated to stay green.
The first version of the system had an unintended side-effect: teams started releasing less often to avoid the risk of dropping status. Lead Time and Release Frequency went up, which Ryanair was also tracking publicly. They added a rule: if the team recovers within five minutes, the issue is not counted as a failed release. That changed the incentive. Teams invested in instrumentation, monitoring and automatic rollback, and release cadence increased again as confidence in recovery grew.
The cadence-and-recovery loop is the part of this story worth borrowing. The traffic-light scheme is one way to operationalise it; teams will find their own. When teams know they can recover quickly, they release more often. When they can't, they release less, which makes them rusty at releasing, which makes the next release riskier. Investing in the recovery side of the loop is what unblocks the speed side.
Impact
Good process serves you so that you can serve your customers. By improving your processes, you can deliver value more quickly, with fewer errors, and with greater customer satisfaction. The ZeroBlockers framework helps you achieve these outcomes by identifying and removing the blocking dependencies that hurt efficiency and effectiveness.