How the four key metrics get gamed specifically
Deployment frequency rises when trivial changes are artificially split into more deploys. Lead time improves when work is reclassified to start the clock later. Change failure rate looks better when failures are quietly reclassified as "known issues" rather than incidents. None of this reflects genuine delivery improvement.
The metrics were designed as a research instrument correlating practices with organisational outcomes — not as individual team KPIs to optimise directly, which is precisely the confusion that enables gaming.
What catches it, and what doesn't
Pairing the four metrics with a qualitative check — does this deploy represent genuine user-facing value, is this incident classification consistent across teams — catches gaming that the numbers alone can't. Comparing metric trends against actual customer-facing outcomes is the real cross-check worth investing in.
A metric optimised directly as a target stops measuring what it was built to measure. DORA metrics are not immune to that.MNB DevOps Practice
Key actions
- Treat DORA metrics as a research signal, not a direct team KPI target
- Pair quantitative metrics with qualitative incident classification checks
- Cross-check metric trends against actual customer-facing outcomes
- Audit for metric gaming patterns specifically, not just celebrate improving numbers