Skip to content
AslanWay
ENKO
Library

Delivery performance·5 min read

Four measures that survived 23,000 responses

Speed and stability are not a trade-off. That finding is the most useful thing anyone has said about software delivery in twenty years.

Source

Accelerate: The Science of Lean Software and DevOps

Nicole Forsgren, Jez Humble & Gene Kim · IT Revolution · 2018

Read the original

AslanWay is not the author of this work. The summary below describes the source; the commentary that follows is ours and is not endorsed by the author.

What it argues

Accelerate reports on multi-year research drawing on more than 23,000 survey responses from over 2,000 organisations. Its contribution is that it applied statistical method to a field that mostly ran on anecdote.

The four measures it identifies are deployment frequency, lead time for changes, change failure rate and time to restore service — two about tempo, two about stability.

The counter-intuitive result

The research found that the tempo measures and the stability measures move together. Teams that deploy more often also fail less often and recover faster. The received wisdom that you slow down to be safe is not supported by the data.

The mechanism is small batches. A smaller change is easier to review, easier to test, easier to diagnose when it breaks and easier to reverse. Change approval boards and long release trains make batches larger, which makes each release more dangerous.

The book also links these delivery measures to organisational outcomes — profitability, market share, productivity — which is what made it usable in board conversations rather than only in engineering ones.

What we do with it

  • Measure all four or none. Deployment frequency on its own rewards shipping junk; change failure rate on its own rewards shipping nothing.
  • If an organisation wants to be safer, the intervention is smaller batches and better automated tests, not more approval gates. The gates make the batch bigger, which is the thing that hurt you.
  • Note that DORA's own 2025 report has moved away from the elite/high/medium/low clusters toward team archetypes. Use the four measures as a trend line for your own team rather than as a league table.

The full library

Operating model4 min read

Your architecture will look like your org chart whether you like it or not

Conway wrote this down in 1968. Sixty years on, most target architectures are still drawn without anyone checking who will be allowed to talk to whom.

Source: Melvin E. Conway, How Do Committees Invent?, Datamation, 1968

Programme risk6 min read

0.5%. That is how many big projects land on budget, on time and on benefits.

Flyvbjerg has the largest dataset on big projects anyone has assembled. The headline number should change how you plan, and usually does not.

Source: Bent Flyvbjerg & Dan Gardner, How Big Things Get Done, Currency / Penguin Random House, 2023

Legacy modernization4 min read

The alternative to a big-bang rewrite has had a name for twenty years

Fowler named the pattern after a plant that grows around its host and replaces it in place. Most failed replatforming programmes are ones that ignored it.

Source: Martin Fowler, Strangler Fig Application, martinfowler.com, 2004, rewritten 2024

Have a programme that has stalled between slideware and shipping?

Tell us where it is stuck. We will come back within two business days with a point of view — and an honest answer on whether we are the right partner.

Start the conversation