What is a Pull System and Why Should I Care?

The concept of a pull system is a simple but important one for software teams. Many teams I see struggling have problems rooted in the push nature of their environment.

A pull system reacts to customer demand and worker throughput. A customer request triggers a work request. Work starts when the requested is accepted by the workers. The critical nuance being that work does not start until the request is accepted. Anticipating work requests arriving doesn’t happen in a pull system. Starting work on a request before the workers are ready doesn’t happen in a pull system. Doing either is what happens in a push system.

A pull system working correctly delivers efficiencies that may not be obvious. Building things a customer has never asked for cannot happen. Accumulating unfinished, excess work in progress cannot happen. Both of these things prevent workers releasing business values efficiently. These may seem straightforward common sense issues; but they afflict many software teams.

How do you know which your system is? If you operate traditional project plans with fixed delivery milestones and a resource allocation schedule – that’s a push system. More subtly if a Scrum team is mechanically allocated work according to their velocity – that’s a push system.

Why should you care? Building features or architecture customers don’t care about is just like holding stock no-one buys. Software may not consume shelf space but it does add complexity, contain bugs and confuse users. Work in progress represents cost spent by the business that cannot yet generate value or sales. Regulating and minimising this improves return on investment. Self regulating teams can also be properly accountable for all aspects of production including quality.