Pull System
In lean manufacturing, a key concept is lead time: the time it takes for a company to deliver a product from the moment a client places an order. For lean practitioners, ensuring timely delivery involves optimizing their delivery system using... the pull system!
The pull system contrasts with the push system. Instead of trying to make everyone work at maximum capacity, the focus shifts to improving the time required to deliver a feature.
I wanted to create a simulation to explore the consequences of different strategic approaches and identify which one is most effective.
Imagine we're developing a mobile news app. We have several functionalities to implement and want to measure how long each takes to complete.
Note: This article includes visualizations of team workflows that can be too large for a mobile phone. For the best experience, please view it on a desktop.
The project has just begun, and our goal is to deliver a product as quickly as possible. We’ll have dedicated teams for product design, coding, and ensuring the product goes live.
First, what is a feature? A feature is a software component that provides a functionality for the user. Examples include the ability to read articles, share content, or use the app offline. In our simulation, a feature is represented as follows:
Each feature starts with an intention: "As a user I can have access to the latest news from the homepage.
". This defines what we will add to the mobile app.
2d indicates the number of days teams work on the feature. The goal is to minimize this number and deliver features as quickly as possible.
Okay! We have 20 features to deliver. Each team takes one day to complete their part for a feature.
Every day, you can choose between two strategies:
- Push system
- Pull system
In this article, we’ll examine how these strategies affect efficiency and quality. Let’s explore each one!
The Push System: Start as Many Features as Possible
In the push system, we aim to maximize the time teams spend working on the product. This ensures no downtime, as everyone always has tasks to complete.
The Pull System: Produce Features When the Next Team Needs Them
Instead of pushing features forward, the pull system waits until the next team is ready. This approach acknowledges that the ideal "push system where everything goes perfectly" is unrealistic. By prioritizing readiness, we avoid creating a backlog of pre-prepared features.
To implement this, we introduce "blue bins" as safety stock. These bins ensure teams always have work ready to process without delays but we stop whenever blue bins are full.
Product ⚒️ [2]
- News article bookmarking0d
- News article recommendations0d
✅ [3/2]
blue binblue bin- Commenting on articles0d
- Personalized news feed0d
- Offline reading0d
Design ⚒️ [2]
- Breaking news alerts0d
- News article history0d
✅ [3/2]
blue binblue bin- Multi-language support0d
- Polls0d
- News article ratings0d
Development ⚒️ [0]
✅ [0/2]
blue binblue binRelease ⚒️ [0]
✅ [0]
No features live yet
Well, what do you think? Not so simple... What are the insights from these strategies? Here are some observations:
- In a predominantly push system, teams perform well initially, but issues can snowball when problems arise. Teams struggle, leading to repeated rework, and many features are delivered all at once.
- A pull system creates a smoother workflow, with teams passing features along continuously. This results in steadier and more predictable delivery. Although defects still occur, the synchronized workflow improves quality. Features are delivered in smaller batches, which benefits users.
Let’s compare the two systems by simulating the entire project using either the push system or the pull system.
Dashboard 0/0 simulations
push system | pull system | |
---|---|---|
Total days to finish | 0.00 | 0.00 |
Mean lead time | 0.00 | 0.00 |
Quality issues | 0.00 | 0.00 |
Okay, we generally see that the pull system is a bit quicker, features are delivered sooner. The real difference seems to be on the number of issues. In a pull system, teams are focus on a small number of feature helping them having less overburden.
Do you mind comparing more projects? What happens when we simulate 1000 news mobile app! Are patterns the same?
Waiting for at least 20 simulations...
Teams often underestimate the complexity of a project and the challenges of collaborating with others. Unfortunately, this is something I’ve observed in many software projects. If a software isn’t progressing well, the response is often to "try harder"—just once. However, "Just in time" frequently turns into "Just this time" over and over. This approach causes teams to overproduce, creating unnecessary stock and latent defects that require rework. The more the project struggles, the more siloed teams become, leading to blame-shifting: "I did my part; if the project fails, it’s not my fault." The reality is, it’s not anyone’s fault—it’s the system that’s broken.
When under pressure to meet deadlines, fear and uncertainty can cause teams to overproduce. Product teams prepare extra features, designers create unnecessary screens, and developers rush through coding. This "just in case" mentality results in wasted effort and latent defects that require rework, slowing productivity.
Counterintuitively, slower is often faster. Excessive pushing slows down the system, while a pull system enforces constraints that prioritize thoughtful delivery.
The pull system shifts priorities, treating developers as clients of the design team, who in turn are clients of the product team. By focusing on lead time, teams ask, "What do you need to succeed, and how can we support you in delivering quality?" This embodies the true essence of teamwork.