Three teams, one value stream, one growing queue
A company sells an online subscription product. Three teams-Discovery, Build, and Release-work in sequence. Discovery writes specs; Build develops; Release runs QA and deploys. Each team has its own board and manager. Discovery is praised for 100% utilization and starts 12 specs per month. Build has a WIP limit of 8 and completes 7 features per month. Release has 3 QA engineers and a queue averaging 28 items; average time from entering Release to deploy is 32 working days. Sales promises features quarterly. Last quarter, Discovery completed 36 specs, Build delivered 21 features, and Release deployed 18. The VP of Engineering wants Build to increase WIP to 12 so more features reach Release. Meanwhile, two features sat in Release for 30 days waiting for a shared test environment that is booked by an offshore team. Customer support reports that deployed features often miss the sales promise.
1. Map the value stream at system level. Where is the constraint, and what evidence supports that?
Read the worked answer
Map the end-to-end value stream, not three local boards. Data: Discovery starts 36 specs per month, Build completes 21, Release deploys 18. Upstream is producing 15 more specs than Build can absorb and 18 more than Release can deploy; the growing queue is predictable. Release has 3 QA staff, a 28-item queue, and 32 working days from entry to deploy. At 18 per month, about 0.86 per day, Little's Law gives WIP of roughly 27.5, consistent with the queue. The constraint is Release test capacity and the shared test environment booking. Build's WIP limit of 8 is not the problem; raising it to 12 would push more work into an already constrained downstream stage and increase end-to-end lead time. Discovery's 100% utilization is overproduction. The system constraint is Release, with a secondary constraint on the shared environment. The sales promise is disconnected from system capability. Measure end-to-end lead time and flow efficiency, not local utilization.
2. What would you change, and what would you explicitly not change?
Read the worked answer
Stop starting and start finishing. Cap Discovery intake at the rate Release can deploy, or at Build's completion rate until Release improves. Create a pull signal from Release: Build does not start a feature until Release has capacity and the feature meets ready criteria. Protect the shared test environment with a booked capacity allocation and make the offshore team's use visible; if it is a hard constraint, add a second environment or schedule it. Do not raise Build WIP. Reduce the Release queue by limiting input, not by pushing QA to work faster. Establish a cross-team service review with one end-to-end board. Use classes for sales commitments: fixed-date features get reserved capacity, standard features flow. Treat the two 30-day items as a system blockage, not a QA failure. Change measures to end-to-end lead time, Release queue age, flow efficiency, and on-time delivery against sales promises. Local efficiency in Discovery and Build should not be rewarded if it creates downstream queues.
3. How would you make the whole-system problem visible to the VP who wants to raise Build WIP?
Read the worked answer
Show a value-stream map with queues, wait times, and throughput at each stage; a cumulative flow diagram across all three teams; and an end-to-end lead-time distribution. Add a simple promise-versus-capability chart: sales commitments per month versus Release deployments per month. Walk the board with the VP from Discovery to Release, starting at the Release queue. Show the impact of the proposed WIP increase: at 18 deployments per month, adding Build WIP increases the Release queue and end-to-end lead time; it does not increase throughput. Present the shared test environment as the binding constraint with booking data. Propose one system experiment: cap intake at 18 per month for four weeks and measure end-to-end lead time and Release queue age. Make the cost of delay visible for the 28 queued items. Ask the VP to sponsor a cross-team improvement, not a local Build change. This reframes the request from 'make Build busier' to 'increase system throughput.'