Delivery Quality as an Early Warning System
Delivery problems become visible late. Usually, they have been growing for some time before management sees them. A milestone slips or a release creates many support tickets. These are not when the problem started, but when it becomes visible.
The important point is that the problem was visible earlier too in the delivery data. Before the milestone slips, you can already see it on work items that stay in review for a long time, for example. The same defects come back again. All of this happens while the team is still delivering, so it is easy to miss.
The first clear signal is the missed date, and by then it is often too late to react well.
So tracking delivery data is really about timing.
DORA’s measurement model has moved in this direction. Since 2024, it has separated software delivery performance into throughput and instability. Instability is measured through change failure rate and deployment rework rate: how often production changes require intervention, and how much deployment activity is unplanned work caused by problems already in production. DORA added rework after finding that change failure rate was effectively capturing part of the same phenomenon.
That distinction is useful because a team can maintain a respectable level of output but the quality of that output is deteriorating. The loss does not necessarily appear as a new cost line, but rather as capacity that was funded for one purpose and is increasingly being spent correcting previous work.
Recent benchmarks give some scale to the difference. LinearB’s 2026 study covers more than 8.1 million pull requests from 4,800 engineering teams in 42 countries. In its benchmark ranges, teams in the strongest band have rework below 3% and change failure below 1%. Rework above 8% and change failure above 17% fall into its lowest performance band. These numbers should not become universal targets because systems, risk profiles and release practices vary too much for that. Their value is in showing how far delivery economics can diverge between organisations, and why movement over time matters more than a single snapshot.
Why this matters more as AI increases output
The current push for AI-assisted development makes delivery quality more important, because generating code faster changes only one part of the delivery system. DORA’s latest work found that 90% of technology professionals surveyed were already using AI at work and more than 80% believed it had improved their productivity. At the same time, higher AI adoption was associated with higher delivery instability. DORA’s research describes AI as an amplifier of the organisation around it: stronger systems can absorb more output, while weak review, testing and deployment practices become more exposed as the volume of change increases.
This is why productivity reporting can become misleading. Faster code production is relatively easy to observe. The cost of reviewing that code, correcting it, recovering from failed changes and dealing with downstream effects is distributed across the delivery process. A company can therefore record more activity without gaining the equivalent amount of usable delivery capacity. DORA’s research on generative AI has also found cases where faster code creation is accompanied by larger batches and additional verification work, with consequences for overall delivery performance.
Delivery quality belongs in the investment conversation
These metrics can't explain a technology organisation on their own. Rework may rise during a migration or a difficult product transition for perfectly legitimate reasons. You can also achieve a low failure rate by releasing rarely and cautiously, which may create a different problem. What matters is the relationship between the signals: whether rework is increasing, recovery is becoming slower, lead times are stretching, or a particular strategic initiative is absorbing more remediation work than expected.
That is why Avalia sees delivery quality as part of the wider technology investment picture. Engineering metrics become more useful when they can be traced back to the systems, initiatives and business priorities consuming the budget. A sustained deterioration in delivery quality can then be treated for what it is: an early indication that execution is becoming more expensive or less predictable, while there is still time to understand why.
Waiting for the financial result gives management certainty (and very little warning), but the delivery quality gives an earlier view.
