Most agile advice is unfalsifiable. “Foster collaboration” and “embrace change” cannot be measured, so they cannot be wrong, so they survive forever regardless of whether they help.
There is a body of research that does make measurable claims. DORA — the DevOps Research and Assessment programme, running annual surveys since 2014 — has spent a decade correlating specific engineering practices with specific delivery outcomes. Its findings are far more concrete than the usual advice: not “integrate frequently” but three or fewer active branches, merged to trunk at least once a day, with no code freezes.
They are also more fragile than most articles admit. Between 2024 and 2025 DORA’s headline finding on AI adoption reversed direction, and the metrics everyone quotes quietly changed underneath the quoting. This guide covers the practices the research supports, the specific thresholds attached to them, the anti-patterns, and — because the title promises evidence — an honest account of what this kind of research can and cannot establish.
Table of Contents
- The Short Answer
- What DORA Is, and Why It Gets Cited
- The Metrics
- The Practices That Actually Correlate
- The Finding That Reversed
- Anti-Patterns
- A Checklist You Can Actually Check
- What This Evidence Can and Cannot Tell You
- Key Takeaways
- Frequently Asked Questions
- Conclusion
The Short Answer
Which agile practices actually correlate with performance? The engineering ones. Trunk-based development, continuous integration, continuous delivery, test automation and small batches. The evidence is much stronger for engineering capabilities than for particular ceremony choices — Scrum versus Kanban, sprint length, stand-up format.
How do I know if my team is improving? Measure DORA’s five delivery metrics: deployment frequency, change lead time, failed deployment recovery time, change fail rate and deployment rework rate. They are team outcomes, not targets to game.
What is the single most common mistake? Adopting the ceremonies and skipping the engineering. A team can run flawless stand-ups on two-week feature branches and get none of the measured benefit.
What DORA Is, and Why It Gets Cited
DORA is an annual research programme that surveys technology professionals and uses cluster analysis to group teams by software delivery performance, then looks for practices that correlate with the higher-performing clusters. It has run since 2014 and was acquired by Google in 2018. Its best-known output is a small set of software delivery metrics — four of them originally, five since 2024 — and a catalogue of technical and cultural capabilities that predict better outcomes.
The 2025 edition drew on nearly 5,000 survey responses. That is a large sample for this field, and it is why DORA gets cited in places software research usually does not reach.
It is survey data, though, not controlled experiment. That distinction matters enough that this article returns to it at the end rather than burying it.
The Metrics
| Metric | Factor | What it measures |
|---|---|---|
| Deployment frequency | Throughput | How often you release to production |
| Change lead time | Throughput | Commit to running in production |
| Failed deployment recovery time | Throughput | How fast you recover from a deployment that broke something |
| Change fail rate | Instability | Share of deployments causing degraded service |
| Deployment rework rate | Instability | Unplanned deployments triggered by a production incident |
Two of those names are recent. Failed deployment recovery time replaced time to restore service in 2023, narrowed deliberately to failures a deployment caused rather than any outage — a data-centre failure no longer counts against you. Deployment rework rate was added in 2024, taking the model from four metrics to five, after DORA’s researchers concluded that change fail rate was acting as a proxy for rework rather than measuring it directly.
Reliability is not one of the five. DORA added it in 2021 and it is frequently listed alongside them, but it measures operational performance — whether you meet your own availability targets — rather than software delivery. It is worth tracking; it is not a delivery metric.
The pairing is the point. Throughput and instability are usually assumed to trade off — go faster, break more — and the finding that upended that assumption is DORA’s most durable contribution. In its own words, speed and stability are not trade-offs, and for most teams the metrics are correlated: top performers do well across all five, and low performers do poorly.
Two cautions before you put these on a dashboard. They are team-level outcome measures, not individual productivity metrics, and using them to compare engineers is a well-documented way to corrupt them. And any of the five can be gamed in isolation — deployment frequency rises nicely if you deploy nothing of consequence — which is why they are read as a set.
The Practices That Actually Correlate
This is where evidence-based advice diverges most sharply from the usual list. The practices with the strongest support are engineering practices, and they build on each other.
Trunk-based development
The most specific and most ignored finding in the whole catalogue. DORA’s analysis of its 2016 and 2017 data found teams performed better on delivery speed, stability and availability when they:
- keep three or fewer active branches in the repository
- merge to trunk at least once a day
- have no code freezes and no integration phases
These are thresholds from DORA’s published guidance, derived from its 2016 and 2017 data — useful because they are checkable, not because they are laws. A team with four active branches has not broken a rule; it has moved away from the configuration the research associates with better outcomes.
DORA’s continuous delivery capability adds a fourth: branches and forks should have lifetimes under a day before merging to mainline.
Compare that with the advice in most agile guides, which stops at “use version control.” The thresholds are what make the practice checkable — you can look at your repository this afternoon and know whether you qualify. The thresholds are what make the practice checkable — you can look at your repository this afternoon and see where your team stands.
DORA names the usual obstacle plainly: an overly heavy code review process requiring multiple approvals before anything merges. If review latency is measured in days, daily merging is arithmetically impossible, and no amount of process enthusiasm fixes that.
For the version control fundamentals underneath this, see our guide to why version control systems are essential.
Continuous integration
DORA defines CI as trunk-based development plus a suite of fast automated tests running after each commit to trunk. The 2015 report found teams perform better when developers merge to trunk at least daily, and the research associates CI with higher deployment frequency, more stable systems and higher quality.
The operational rules are unglamorous:
- every commit triggers a build
- the build status is visible to the team — DORA specifically recommends chat notifications over email, because email notifications get filtered and ignored
- a broken build stops other work. Fix it immediately or revert within minutes
That last one is the acid test, and it is DORA’s own rule rather than mine: fix immediately, or revert within minutes. A build left red for a day is the clearest available sign that the practice is nominal. Martin Fowler’s article on continuous integration remains the fullest description of the practice as its originators meant it.
Continuous delivery
Four components in DORA’s framing: test automation, deployment automation, trunk-based development, and pervasive security — security review integrated into design and testing rather than bolted on before release.
The goal is that software is always in a releasable state. Whether you then choose to release it is a business decision, not a technical one.
Small batches
The enabling discipline beneath all of the above. You cannot merge daily if your unit of work takes three weeks. Notably, the 2025 DORA report found that working in small batches amplified AI’s positive effects and reduced friction — the oldest practice on the list turning out to matter more, not less, as tooling changes.
User-centricity
The 2024 report identified this as the strongest driver of performance in its data: organisations that prioritise end-user experience build higher-quality products, and developers working with a user-centric mindset were more productive, more satisfied and less prone to burnout. The 2025 report reinforced it from the other direction — teams with a user-centric focus got the strongest gains from AI adoption, and without that focus AI adoption could hurt performance.
Code quality practices
Peer review and automated analysis both belong here, with the review-latency caveat above: review is required, but slow review is the thing that breaks trunk-based development. Our comparison of static code analysis tools covers the automated half.
The Finding That Reversed
This is worth dwelling on, because it is the clearest available lesson about how much weight to put on any single year of research.
In 2024, DORA reported that AI adoption significantly increased individual productivity, flow and job satisfaction — while negatively affecting both software delivery stability and throughput. The conclusion drawn at the time was that AI was not a panacea and that fundamentals like small batches and robust testing remained crucial.
In 2025, with roughly 5,000 responses and about 90% of respondents reporting they use AI in their work, the throughput finding flipped: AI adoption now correlated positively with delivery throughput. The instability finding did not flip — AI-heavy teams still showed higher change failure rates and more rework. Gene Kim, one of the report’s authors, went as far as calling the previous year’s result “the DORA 2024 anomaly”.
The 2025 report also reframed itself substantially, publishing as State of AI-Assisted Software Development, grouping organisations into seven archetypes by their delivery and organisational outcomes, and building its central argument around AI as an amplifier — accelerating teams with solid foundations and magnifying the problems of teams without them. The delivery metrics feature far less prominently than in previous years, though DORA’s current guidance still recommends all five; this was a shift of emphasis, not an abandonment.
Three things follow, and none of them is “ignore the research”:
- What persisted across both years is the pressure, not the direction. Both reports found AI adoption associated with greater instability, while highlighting the importance of review, testing and feedback as counterweights to faster change. The throughput result moved; that one did not.
- A single year is a data point, not a law. Anyone citing DORA 2024 on AI in 2026 is citing a result its own authors have since qualified.
- The framework’s owners revise it more readily than the industry quotes it. The metrics went from four to five in 2024, one was renamed and moved between categories, and the 2025 report led with something else entirely. Treating any single formulation as the definition of engineering excellence overstates what it was meant to be.
Anti-Patterns
Failure modes that appear in the research or follow directly from it:
- Ceremonies without engineering practices. Stand-ups, sprints and retrospectives on top of long-lived branches and manual deployment. This is the most common shape of “we tried agile and it did not work.”
- Velocity as a performance target. Velocity is a planning aid, calibrated per team and not comparable between teams. Managed as a target it inflates, because estimates are the easiest thing in the system to change.
- DORA metrics used to rank individuals. They are team-level outcome measures. Applied to people they stop measuring delivery and start measuring who games them best.
- Retrospectives with no follow-through. A meeting that generates observations but no owned, scheduled changes is a recurring cost with no return.
- Unstable priorities. The 2024 report found unstable organisational priorities caused meaningful drops in productivity and substantial increases in burnout. Reprioritising every sprint is not agility.
- Heavyweight review as a quality gate. Named by DORA as a specific obstacle to trunk-based development. If a change waits days for two approvals, batch size grows to match.
- Adopting a framework to fix a culture problem. Neither Scrum nor SAFe addresses unclear priorities, absent testing or a punitive incident culture.
A Checklist You Can Actually Check
Every item here is observable this week, which is the point — nothing on it depends on how agile anyone feels. The first eight rows come from DORA’s published thresholds; the last four are my own additions, and I have flagged them as such rather than letting them borrow authority they do not have.
| Check | Threshold |
|---|---|
| Active branches in the main repository | 3 or fewer |
| Longest-lived open branch | under 1 day |
| Merges to trunk per developer | at least daily |
| Code freezes or integration phases in the last quarter | none |
| Build triggered on every commit to trunk | yes |
| Time a broken build stays broken | minutes, not hours |
| Deployment requires manual steps | no |
| Median code review turnaround | hours, not days |
| Delivery metrics measured at all | yes |
| Delivery metrics used to rank individuals | no |
| Retrospective actions with a named owner and a date | yes |
| Someone on the team has spoken to a real user this month | yes |
What This Evidence Can and Cannot Tell You
The title of this article promises evidence, so here is the honest scope of it.
What it is. Large-sample survey research — nearly 5,000 responses in 2025 — analysed with clustering and correlation, run annually for over a decade by researchers who publish their methodology. That is unusually good for software engineering, a field where most “best practices” rest on nothing but confident repetition.
What it is not.
- Not a controlled experiment. DORA measures correlation. Teams that merge daily perform better; whether daily merging causes the performance, or capable teams do both, is not settled by a survey. DORA’s own writing argues for causal inference in places, but the underlying data is observational.
- Not independent of who pays for it. DORA has been part of Google since 2018 and reports carry commercial sponsors. That does not make the findings wrong, and the methodology is published — but it is not disinterested academic work and should not be cited as though it were.
- Not self-reported-free. Respondents describe their own deployment frequency and failure rates. Self-report has known biases, and there is no independent telemetry behind most of the numbers.
- Not stable year to year. Demonstrated above.
- Not universal. The sample skews toward organisations that participate in DevOps surveys. Whether the findings transfer to safety-critical firmware, regulated medical devices or a two-person team is genuinely unknown.
What I did not do. No original research, no survey, no measurement of any team. This article reads and cites published work — every figure and threshold in it is attributed and linked. That is a weaker form of evidence than the compiled-and-measured results in our programming articles, and it would be dishonest to present it as the same thing.
How to use it. As a well-supported prior, not a law. The practices below are the best available bet, and the checklist gives you a way to find out whether they work for your team, which is the only evidence that settles the question locally.
Key Takeaways
- The engineering practices carry the evidence, not the ceremonies. Trunk-based development, CI, CD, test automation and small batches.
- The thresholds are specific and checkable: three or fewer active branches, merged daily, branch lifetime under a day, no code freezes.
- Throughput and stability are not a trade-off. The highest-performing teams score well on both, which was DORA’s most durable finding.
- DORA’s delivery metrics are team outcomes, not individual ones, and reading them as a set is what stops them being gamed.
- The AI finding reversed between 2024 and 2025 — negative for throughput, then positive — while the instability finding held. Cite the year, not just the source.
- The metrics themselves changed while everyone was quoting them — four became five in 2024, and one was renamed and reclassified. The industry is more attached to the 2018 formulation than its authors are.
- This is correlational survey research, run annually by a Google-owned programme with commercial sponsors. Strong evidence for the field; not a controlled experiment.
Frequently Asked Questions
Conclusion
The gap between agile advice and agile evidence is mostly a gap in specificity. “Integrate frequently” cannot be checked. “Three or fewer active branches, merged to trunk daily, branch lifetime under a day” can be checked before lunch — and that is the difference between a practice and a slogan.
The research is not settled, and this article has tried to be clear about where it is soft: correlational, self-reported, commercially sponsored, and demonstrably capable of reversing direction in a single year. Held to that standard it is still far better than the alternative, which is repeating advice that has never been tested against an outcome at all. Start with the checklist, measure the four keys for a quarter, and let your own numbers arbitrate. The rest of our software development section covers the neighbouring ground.
