Problem Detection and Continuous Improvement
This domain tests how you detect delivery problems early and improve the system rather than blaming individuals. Expect flow metrics, cumulative flow diagrams, WIP limits, Little's Law, root-cause analysis, retrospectives, and improvement experiments.
Core rules
- Make work visible with a board, WIP limits, and a cumulative flow diagram to expose queues and bottlenecks.
- Little's Law: average cycle time is approximately WIP divided by throughput. If WIP rises without throughput, cycle time will rise.
- Prefer system measures such as lead time, cycle time, escaped defects, and flow efficiency over vanity metrics such as velocity comparisons and utilisation.
- Find causes with 5 Whys, fishbone, or value-stream mapping, then run a small experiment with an owner, measure, and review date.
- Continuous improvement needs a backlog and protected time; otherwise it becomes a retrospective ritual.
Worked example
A cumulative flow diagram shows the ready-for-QA column growing while done stays flat. The team adds more developers to coding. Reasoning: the bottleneck is QA capacity or batch size, not coding throughput. Adding coding WIP increases the queue and cycle time. Better: limit WIP, swarm on QA, reduce batch size, and add automated checks. Measure cycle time and queue size before and after.
Traps
Blaming individuals for systemic delays; comparing velocity across teams; treating a retrospective as a complaint session; starting improvements with no owner or measure; optimising a local step while the constraint is elsewhere; ignoring escaped defects.