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:

As a user I can have access to the latest news from the homepage.
2d
4

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.

4
shows the number of defects found in the feature during its workflow. For simplicity, we assume teams can identify all defects, and no defective features are delivered. Any defect must be reworked by the team that caused it.

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:

  1. Push system
  2. 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.

Days
0d
Estimated Time of Arrival
0.00 days
Features 0/20
Mean lead time
0 days
Quality issues
0
  • Product
    ⚒️ [2]
    • News article bookmarking
      0d
    • News article recommendations
      0d
    ✅ [3/2]
    blue bin
    blue bin
    • Commenting on articles
      0d
    • Personalized news feed
      0d
    • Offline reading
      0d
  • Design
    ⚒️ [2]
    • Breaking news alerts
      0d
    • News article history
      0d
    ✅ [3/2]
    blue bin
    blue bin
    • Multi-language support
      0d
    • Polls
      0d
    • News article ratings
      0d
  • Development
    ⚒️ [0]
    ✅ [0/2]
    blue bin
    blue bin
    • Release
      ⚒️ [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:

      1. 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.
      2. 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 finish0.000.00
      Mean lead time0.000.00
      Quality issues0.000.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.