Cover of Data-Driven Agility by Justice Conder

Justice Conder · Data-Driven Agility

A rigorous approach to software delivery.

Asked what makes a great team, people say collaboration and never whether the team delivered. The book’s answer is to write the process down, measure it, and change it from the numbers. Flow, the iteration, and the release are one system. The sōzu is the picture: how often the tube dumps is set by the trickle, and the basin is a release you can carry off whenever you want. The charts below are that system, running.

01 · end-to-end delivery

The sōzu

The tube still tips at the same volume. Only the time between strikes changes. Cadence falls out of the flow. Shipping empties the basin whenever you decide it is enough.

02 · cycle time

Cycle time scatter

Each dot is a finished item. Height is days from start to done. Hold 95% of them under the dashed line, fourteen days, and the iteration becomes predictable. No estimates required.

Move this while the plot runs. A mark is drawn on that day. Expedites are red. They finish fast and push other work up the chart.

03 · work item age

What is still in flight

The same clock, read while the item is still open. This is the standup view: swarm whatever is about to cross fourteen days. Red is past that line, or an expedite.

04 · cumulative flow

Where work is piling up

Short cycle times can still hide a jam. Parallel bands mean each state is entered and left at a similar rate. A bulge is a pile-up. A pinch is a state that has been starved.

done review ready for review build not started

05 · iteration

Iteration burndown

A pull system replaces finished work, so a single burndown line never falls. Green is what remains of the original commitment. Red includes whatever was pulled in after the iteration started.

06 · release

Release burndown

A release is three iterations packaged as one theme. Because value has been landing all along, the basin can go early or late. Dashed is the plan. Solid is what is actually left, including work pulled in later.

07 · classes of service

What expedites cost

An expedite finishes in a couple of days and looks like a win. The cost is the wait it leaves on everything it displaced. Same team, five policies. Only the odds of cutting in line change.

Green: at least 95% of ordinary items finished inside 14 days, and the iteration commitment was met.

08 · flow and the sprint

Estimates, kept next to cycle time

A sprint total can look honest while individual estimates were wrong, because high and low cancel. A flow-only forecast has the opposite problem: it treats the next items as interchangeable with the last ones. Points times the historical cycle time for that type of work uses both. The edge shrinks as the estimate gets noisier.

One sprint, item by item

Residual is actual cycle time minus what that item’s points implied from the team’s overall ratio. The sprint can sum near zero while every bug sits high.

Predicting the next cycle time

History is mostly stories. The next items are mostly bugs. Error is the average miss as a fraction of actual cycle time. Drag the estimate toward noise and the type modifier’s advantage shrinks.

09 · the talk

Presentation