Releases kept slipping; the team’s burndowns were fine; the real problem sat in plain sight. Every change waited in a test environment queue that moved slowly, shared across products, with surprise rebuilds and handoffs. Items aged there for days, sometimes weeks. Once we plotted WIP aging and queue time for the last 20 items, the picture snapped into focus; velocity looked steady, throughput was throttled by the test environment.
You might think to yourself, why was that not part of our Definition of Done? Great question; not all testing activities can be completed in a team's Sprint. "Well then you aren't doing Scrum"! Well, hold your horses. You can't expect teams to shift all activities into a 2-week Sprint immediately. Yes, we need to do testing to satisfy "releasable increment", but perhaps we have to learn how to do regression testing (and it's a 6-week manual cycle right now). So we roll up our sleeves, meet the team where they are, and strive to "shift left", all of the activities we eventually want to be part of our Definition of Done.
What.
Theory of Constraints gives us simple focusing steps: identify the constraint, exploit it, subordinate everything else, elevate it, then find the next one. In Lean terms, we measure where work waits, not just where it is touched. Three signals expose the constraint quickly:
- WIP aging; items pile up and age in a specific column, often “Ready for Test Env” or “Waiting for Data.”
- Queue time; the waiting portion of lead time dwarfs touch time at that station.
- Dependency risk; many items depend on one scarce capability or environment; when it hiccups, everything slips.
Once found, we protect the constraint with visible policies; we exploit it by keeping it constantly fed with the right work and zero internal friction; we elevate it with targeted investment, then re-measure.
Practical moves that work:
- Protect with policies; publish a “Constraint First” rule; the constraint chooses the next job; expedite blockers at the constraint; no drive-by interrupts; upstream WIP limits keep arrivals ≤ sustainable throughput.
- Exploit via pairing and automation; pair at the constraint to reduce setup time; script environment creation; pre-stage data; shrink batch size so the constraint finishes more often.
- Elevate with investment; add a dedicated environment, improve tooling, or cross-train two engineers to run the station. Use Throughput Accounting to justify spend; if each day removed from the queue returns X in contribution, a small tool or headcount is an easy bet.
So What?
Improving non-constraints is local optimization; throughput does not budge; lead time does not fall; predictability does not improve.
Teams feel busier; customers still wait. When you align the system around the actual constraint, the entire stream benefits; upstream stops overproducing; downstream stops starving; managers stop issuing “go faster” requests that only add WIP and stress.
This is why Reinertsen’s queueing economics matter; long queues create long delays; variability plus big batches multiplies pain; the constraint is where those dynamics hurt most.
Now What?
Run a 2-week “Constraint Sprint” that treats the test environment as the product. Please keep it simple, make the policy visible, and measure the deltas.
Day 0; baseline
- Pull the last 20 completed items; record lead time, cycle time, and queue time at the test environment.
- Capture throughput per week and a WIP aging snapshot for the “Ready for Test Env” column.
- Note one or two notable events; rebuilds; blocked data; long approvals.
Publish the policy
- Post a card at the board; “Constraint First; the test environment selects the next job; blockers at the constraint are top priority; upstream WIP limited to N until queue ≤ M; batch size capped at S.”
- Share a one-liner in chat; “We are running a 2-week Constraint Sprint; all teams subordinate to the test environment until the queue clears.”
Exploit; keep it fed; cut friction
- Pair or mob at the constraint 2 hours daily; rotate in help from adjacent teams.
- Pre-stage data and deployment scripts; checklists prevent setup thrash.
- Shrink batches; split big releases into small, testable slices that can clear in hours; not days.
Subordinate upstream; reduce arrivals
- Add an upstream WIP limit that matches the constraint’s weekly throughput.
- Route questions and interrupts away from the constraint; create a buffer column that only the constraint pulls from.
Elevate wisely
- If simple changes do not clear the queue, prepare a one-page pitch; current queue time; cost of delay; two options; a low-cost tool to auto-provision envs; a part-time SRE rotation; expected throughput gain; a 2-week trial; then decide with data.
Measure mid-sprint and at 2 weeks
- Plot Process Behavior Charts for lead time and throughput; look for a signal; a point beyond limits; a visible shift.
- Publish a tiny before-after; “Env queue down 43%; lead time down 22%; throughput up 18%.” If there is no signal, keep the learning; adjust the policy; try the next lever.
Let's Do This!
Focus where the stream is thinnest; the whole system moves. When you treat the test environment as the constraint, protect it, exploit it, and elevate it, throughput rises without heroics; lead time falls; teams stop overproducing work the system cannot absorb.
Two disciplined weeks with a visible policy and simple measures will teach your organization more about flow than months of status meetings. Identify the constraint; act together; let the data show you when to move on to the next one.