See the whole system
This domain tests whether you can map the entire value stream end to end - upstream demand and downstream delivery included - and reason about the system rather than optimise a part of it.
Systems thinking in practice
Performance is a property of the whole. Optimising one part usually degrades another, because queues simply move. Map the current state as it is - start with what you do now - and treat the customer as part of the system, not an external observer.
What "whole" includes
- Upstream: how demand arrives, who decides what enters the system, and the queue of options.
- The states and handoffs of work, with the queue and wait between each pair.
- Downstream: delivery, customer acceptance or feedback, and what happens after (support, rework).
- The network of services: suppliers on whom your flow depends.
Measure the waits, not just the work
Count handoffs and time in queue. Typical knowledge-work flow efficiency is single-digit to low double-digit percentages, so most lead time is waiting - and most waiting lives between teams, not inside them.
Worked example
A value stream reads: idea → business case (2 weeks queue) → development (3 weeks queue, 1 week work) → test (2 weeks queue, 3 days work) → release (4 weeks waiting for a monthly window). Lead time is roughly 12–13 weeks against about 2 weeks of touch time - flow efficiency around 15%. Making development 20% faster saves about a day; releasing on demand removes four weeks. Reasoning: the constraint is the release window and the queues, not coding speed.
Traps that cost marks
- Mapping only your own team's section and calling it the value stream.
- Drawing the desired future state and presenting it as current.
- Leaving out where demand comes from and who receives the work.
- Blaming individuals for delays the system creates.