Improve (feedback loops, flow signals, next experiment)
This domain tests whether you can run improvement as a disciplined loop: cadences that surface problems, flow signals that quantify them, and one explicit experiment at a time.
Feedback loops with a purpose
Name each cadence, its purpose and who attends: daily Kanban meeting (walk the board right to left, on flow, blockers and ageing work - not status reporting); replenishment (choose what enters the system, per class of service); service delivery review (flow metrics against customer expectations); risk review (deadlines, dependencies, delivery risk); operations review (whole-system, across services); strategy review (purpose, portfolio, classes of service); delivery planning (commitments to customers).
Flow signals
Lead time, cycle time, throughput, WIP, blocked time, queue size, due-date performance, failure demand, and flow efficiency = touch time ÷ lead time. Read distributions and trends, not single averages.
Evolve experimentally
Improve collaboratively, evolve experimentally: pick one problem visible in the data, state a hypothesis and the effect you predict, change one policy, timebox it, measure against a baseline, then adopt, adapt or abandon. Write the policy down so the experiment is testable.
Worked example
Six weeks of data show flow efficiency of 12%, so 88% of lead time is waiting. The analysis state exceeds its WIP limit roughly 40% of the time. Hypothesis: enforcing the limit of three will cut the 85th-percentile lead time from 18 to 14 days without losing throughput. The team runs it for four weeks, reviews weekly, and keeps the change when throughput holds; if it drops, the limit is adjusted rather than abandoned.
Traps that cost marks
- Turning the daily meeting into a status report for a manager.
- Changing several policies at once, so no result can be attributed.
- No baseline, so "improvement" is opinion.
- Using one metric as a target - the measure gets gamed.
- Ignoring failure demand, which reduces demand rather than capacity.