Why Software Teams Need Speed Limits

It's no fun dealing with roadworks and bottlenecks when you're trying to get out of the city to your holiday destination. This is especially true if you have kids in the back asking, "Are we there yet?"

The road system can't handle that amount of traffic. The result? Sitting in traffic for hours with that stop-start motion, guzzling fuel. A two-hour journey turns into five hours.

In software engineering, we also have bottlenecks that create major problems for delivering features quickly. These bottlenecks often appear during software testing phases, as stories and epics converge into test environments where they can be tested end-to-end. Many people call these environments SIT (Systems Integration Testing).

This is particularly true in large enterprises, where combinations of legacy systems, COTS products, and newer technologies create numerous unknown dependencies waiting to merge into this critical testing phase. While we know ways to test better (early and often in an isolated and decoupled way), the pressure to deliver often means shortcuts are taken.

As quality professionals, we encourage teams to adopt better practices. But it's an uphill battle when teams often throw stuff over the fence to be handled in this testing phase, further exacerbating the problem.

This can be fixed. Advocating for better testing and visualising dependencies is part of the picture, but it requires teams to be given agency, time, and sufficient space to do proper dependency mapping and improved testing in lower environments.

The Solution: Theory of Constraints

What if I told you there's a way to help teams reduce delivery time and improve product quality? There is. It's called the Theory of Constraints and the use of WIP limits.

The Theory of Constraints encourages us to optimise for waste. Drive change and improvement by identifying your biggest bottleneck and constraining the downstream work before the bottleneck to flow at a sustainable pace that the bottleneck can handle.

This is the equivalent of reducing the speed limit before a known bottleneck so traffic flows smoothly, rather than the stop-start motion we're used to enduring. The result? While we feel we're going slower, we actually get to our destination faster.

How do we make this work in software engineering? We use WIP (Work in Progress) limits right before the bottleneck. This prevents build and system testing phases from taking new work off the backlog until existing work has been completed and is working in production.

Start small: identify your current testing bottleneck and set a WIP limit of 2-3 items. Monitor delivery time for 2-3 sprints to see the impact.

Without new work to focus on, the whole team must complete whatever testing work is at hand to reduce the bottleneck. That means everybody tests.

This benefits quality enormously. It shifts ownership from the test engineers to the whole team completing the product. Teams learn about the product's behaviour, which feeds into the context and understanding of the why of the product. This is very handy knowledge when on call at 3 AM. As the whole team has a vested interest in reducing bottlenecks, software engineers will discover an engineering approach to reducing testing problems—be it test data, test automation, or environments. Understanding of key risks will grow, with software engineers building with these in mind.

Preventing teams from taking on too much work does feel like you're slowing down—in the same way that reducing speed feels like it's taking longer—but the reality is different. Yes, the team is taking on fewer epics, but the throughput is the same and the delivery time is reduced.

Yes, stakeholders may initially resist "doing less work," but focus conversations on faster delivery of completed features.

To summarise, sometimes the solution is to speak to the measurements that companies really value. If quality is not top of mind, speak to what is. Reducing delivery time is a compelling argument for whole-team collaboration on a definition of done that is working in production.

The next time your team is stuck in testing traffic jams, remember: sometimes slowing down is the fastest way forward.

---

Further Reading

Theory of Constraints: Goldratt's official explanation of Theory of Constraints - perfect if you want the theory straight from the source. https://www.goldratt.com/what-is-theory-of-constraints/

The Phoenix Project: The Phoenix Project by Gene Kim and team. A novel about IT departments learning these principles. If you've ever worked in a chaotic tech environment, you'll recognize the characters. https://itrevolution.com/the-phoenix-project/

WIP Limits Implementation: AWS has a solid blog post on implementing WIP limits in DevOps pipelines. Less theory, more "here's how to actually do it." https://aws.amazon.com/blogs/enterprise-strategy/deliver-faster-by-limiting-work-in-progress/

Lean Software Development: Mary and Tom Poppendieck's Lean Software Development shows how these manufacturing principles apply to software. Their website has loads of additional resources too. https://www.poppendieck.com/