Speed and stability are not a trade-off: the case for small batches

The four measures that matter

The DORA research programme, summarised by Nicole Forsgren, Jez Humble and Gene Kim in Accelerate (2018), found that delivery performance can be described by four measures: how often you deploy, how long a change takes from commit to production (lead time), how often a change fails, and how quickly you recover when one does. The first two measure speed. The last two measure stability. In their data, the same teams tended to do well on both.

• Deployment frequency. How often you release to production.
• Lead time for changes. From code committed to code running.
• Change failure rate. The share of changes that cause a failure needing a fix.
• Time to restore service. How long recovery takes.

Why small batches work

A large change is hard to review, hard to test and hard to undo. When it fails, you do not know which part failed. A small change fails in a way you can see and fix quickly. There is also arithmetic behind this. Little’s Law, proved by John Little in 1961, says that the average time work spends in a system equals the amount of work in progress divided by the rate at which it finishes.

Waterfall was never the plan

Winston Royce’s 1970 paper is often cited as the origin of the strict sequential “waterfall”. Read it and you find the opposite: he warned that a single sequential pass is risky and recommended building a pilot first so the hard problems appear early. The lesson is to find risk early, not to follow phases in order.

Define “done” so a reviewer can check it

A good quality bar is binary. Tests pass, the change is reviewed, security checks have run, the feature can be switched off. If “done” depends on someone’s feeling, it will drift under pressure. Automating the bar, in a pipeline that blocks release when a check fails, replaces a meeting with a rule.

Anti-patterns

• Water-Scrum-Fall. Sprints in the middle, but requirements are fixed up front and release is a separate big event at the end.
• Velocity inflation. Points are used to compare teams, so they inflate, and the number stops meaning anything.
• Long-lived branches. Integration is deferred until it hurts.

What to do on Monday

1. Measure your lead time for the last 20 changes. Do not guess.
2. Limit work in progress so that finishing matters more than starting.
3. Pick one manual gate and automate it.

Engineering Governance & Agile Delivery is 28% of the ATP exam and 24% of the CTP exam. The specialist Agile Delivery Practitioner (ADP) goes deepest. See exam facts.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.