Secrets of Speed #1: Throughput

Speed is complicated. I’m often asked to help make teams move faster – more stuff in less time – but when I dig a bit deeper I find that the asker is unclear on what speed really is. Without clarity you can't make the tradeoffs in quality and adjustments to process and culture needed to achieve it.

If you want to approach maximum velocity of a work system – while maintaining quality, culture and other things you care about – you need to be aware of the factors that limit systems and how they express themselves in yours.

By identifying these leverage points you can increase the amount of stuff you get done in the time available. While many equate “speeding up” with rushing nothing could be further from the truth. If you really want to speed up a team or organization then you need to understand a few principles of how complex systems operate.

For these principles we're going to take our inspiration from lean theory. Specifically, I want to introduce you to throughput and cycle time – the separate but interdependent components of speed.

Throughput is the amount of work that a team can do within a given time period. When people ask a team to speed up they are usually thinking about throughput.

A useful metaphor is a stretch of highway. A mile of highway has a certain capacity – there's a maximum number of cars that can pass through it per hour. A team is similar – there's a maximum amount of work they can do in a given period of time.

Since cars are much easier to measure than work items let’s stick with that metaphor for a bit.

The natural thing to do when maximizing throughput is to shove as much as you can into the start of the pipeline. On our idealized highway it will look something like this:

But that leads, unsurprisingly, to a real-life highway that looks like this; gridlocked.

The reason we get gridlock is that filling the pipeline leaves no room for error and creates a brittle system. One fender-bender between two cars can mean hours of impact as system failures cascade.

Some models have shown that one person cutting off another on a crowded highway can impact traffic patterns hours later. When you’ve got an interdependent pipeline like this impact ripples dynamically out into the system in both distance and time.

Work flowing through a team can be similarly impacted by other pieces of work. Say you’re focused on a task but get interrupted by a request to handle something small and urgent. This metaphorical fender bender can cause a cascading disruption in your individual productivity.

This is why many programmers choose to work at night. Not because they are night people, per se, but because it’s a time that is naturally free from distraction.

When you analyze delays in a complex work system you usually find that the delay is not because it took too long to complete a piece of work, but rather the time it sat in a queue waiting to be worked on. So rather than asking people to work faster on the tasks they’ve taken on its more effective to analyze how items flow through the system. Small reductions in wait time can have outsized impact in the throughput of your pipeline.

In order to avoid system wide breakdowns caused by periodic interruptions – and thus maximize throughput – you need to plan for them.This requires a mindset shift on the part of leaders. Rather than constantly worrying if your people are taking on too little you need to worry if they are taking on too much. Taking on too many items is what slows you down.

In coming posts we’ll take a deep dive into throughput, cycle-time and how to balance the needs of both and how to speed up systems.

 
Bob Gower