Pull Systems in Software Development

Pull systems are said to be one of the essential tools to eliminate waste. So let's try to understand them.

Understanding the Pull System

A pull system is based on the idea that no waste is generated. In lean manufacturing waste equals direct cost of material, stock, production costs, machine wear, material wear among others. This has to be avoided even at the cost of not utilizing each part of the system to its theoretical capacity.

Producing just in time focuses on the finished product in the hands of the customer. We know that only the finished product can yield customer feedback and give us essential information whether we are in fact building the right thing for the customer's needs.

By limiting our entire system to the cadence of the most constrained part, we eliminate waste and use our resources in a more efficient way.

One of the most important steps here is to identify the system constraints. Mapping out your process and identifying the bottleneck can be tedious, but without mapping the workflow or the process a bottleneck cannot be identified and a pull system cannot be implemented. Constraints on the system can also be measured by experimentation.

After your bottleneck is identified, we introduce buffers in front of the bottleneck. This way we ensure that the bottleneck never does anything valueless or wasteful. Since the constraint is limiting our overall output, feeding the right things to the bottleneck is essential.


In this example the dev team is the bottleneck. The product backlog has to be kept filled with sensible user stories in order to keep the dev team working.

The buffer implemented in front of the dev team (the product backlog) only keeps as many items inside as are needed in order to fulfil the dev team throughput.

A constraint of the system may also lie in the product owners or stakeholders who are often times limited in availability or capacity as they are defining how the system should look like.

So let's assume:

  • that a sprint takes 2 weeks
  • the dev team velocity is at 20 story points
  • the product is released immediately once enough value is accumulated

In this simple example the only buffer needed is the product backlog and its size has to be at most 2 weeks of work. We set the buffer to be measured in time rather than items. This makes it easy to see whether it is filled to the right amount. If the buffer contains work for less than 2 weeks, fill it up. If it is filled with more than 2 weeks, stop putting items into the buffer. Since all other parts are not the constraining system, we can order the buffer filling processes to reduce input pace which lets them take care of other valuable things.

Loose Organization

One final word on loose organization structures. Each lean approach is centered around the flexibility of organization. It is assumed that systems can automatically self-organize or be organized and optimized to reflect the demands of the business outcome.

This critical element of constant change (requirements and markets change all the time, so businesses need to, too) is hard to achieve in strict rigid top-down controlled organizations. A loosely organized organic organization is better suited to often-changing processes. This proves very hard as the recent 10th State of Agile Report shows 55 % of participants saying that agile adoption is limited because of missing Ability to change organizational culture. 42 % experienced General organizational resistance to change and said that this would bar the organization from succeeding further.