A team can deploy software 20 times in a month and look extremely productive. But if six of those releases were urgent fixes for problems caused by earlier changes, what exactly are we celebrating?
I am cautious about judging software delivery performance by how frequently a team releases. More deployments can mean faster delivery, but they can also conceal an increasing amount of rework. The number tells us how often changes go live, not necessarily how much useful improvement reaches customers.
In its April 2026 Quick Check update, DORA included deployment rework rate alongside measures such as deployment frequency, change lead time, change failure and recovery time. Deployment rework rate looks at the proportion of deployments made unexpectedly to fix production bugs. It helps distinguish planned improvements from work done to correct previous releases.
Consider two teams making 20 deployments each month. One delivers mostly planned improvements with few incidents. The other uses six of its releases to fix problems from previous deployments. Their release frequency looks identical, but the impact on customers, team capacity and future commitments may be quite diffe
This matters when overseeing technology projects and programmes. A delivery report can look healthy while engineers are spending their time on urgent fixes, planned work keeps being interrupted and operations is dealing with avoidable disruption. We need to ask not only how often a team releases, but how reliably those changes work and how much effort is being pulled away from what was originally planned.
The answer is not to discourage frequent releases. Smaller, regular changes can reduce risk when supported by sound engineering practices. If rework is rising, however, there is more value in examining testing, the size of changes, production readiness and the pressure surrounding release decisions than simply demanding greater speed.
DORA also cautions against using these measures to rank teams working in very different environments. They are more useful for seeing if a particular service is improving over time.
A faster release cycle is progress when it delivers useful changes reliably. When a growing share of that activity is spent correcting previous releases, we need a more honest conversation about what the numbers are telling us.
Good ideas get better in conversation.
