Push vs. Pull Systems - Lean Software Development

1Defining Push and Pull

Push systems start work based on forecasts or schedules. A manager assigns work. A sprint is planned. Work enters the system whether or not there's capacity.

Pull systems start work based on capacity and demand. Work only enters when a downstream step signals it's ready. Nothing is pushed in—it's pulled through.

The Toyota origin: In a push system, parts are manufactured based on forecasts and pushed downstream. In Toyota's pull system, downstream processes send a signal (kanban card) when they need parts. Parts are produced only when signaled.

In software:

Push: Sprint planning commits to 20 stories. The team works on all 20 simultaneously. By sprint end, 12 are "in progress" and 8 are complete.
Pull: Team has WIP limit of 3. When one story completes, they pull the next. By sprint end, 15 stories are fully complete.

The math is counterintuitive: fewer items at once, more items finished.

The Visibility Difference

Push systems hide problems. The pile of unfinished work accumulates invisibly. Pull systems reveal problems. When you can't pull new work because you're blocked, the block is visible. This visibility forces resolution.

2Why Push Systems Hide Problems

In a push system, problems get buried.

The team has 15 items in progress. Three are blocked waiting for architecture decisions. But work continues on the other 12. The blocks are invisible among the activity.

Late in the sprint, those 3 items are still blocked. Now it's a crisis. "Why didn't anyone raise this?" Because the system didn't force it.

Push systems also hide capacity problems. If you push in more work than you can handle, the excess just piles up. Lead time grows, but from the outside, "everyone is working hard."

Push systems optimize for starting. Pull systems optimize for finishing.

Push thinking: "We started 20 items this sprint!" (But finished 8.) Pull thinking: "We finished 15 items this sprint." (And started 15.)

Which would your customers prefer?

Push: The Overcommitted Sprint

The team commits to 20 stories based on velocity. Halfway through, three stories are blocked on a dependency. Work continues on others. At sprint end: 8 complete, 12 partially done. The 3 blocked items are still blocked.

Pull: Blocked Work Surfaces Immediately

WIP limit is 3. Developer pulls a story but it's blocked on a dependency. They can't pull anything new—limit is hit. The block is immediately visible. Team swarms to resolve it. Lead time stays short.

3Pull Creates Accountability

Pull systems are harder to game than push systems.

In a push system, you can look productive while accumulating debt. "I'm working on 8 things!" (None finished.) "I completed 50 story points!" (But half are stuck in review.)

In a pull system, the only valid work is finished work. You can't start something new until something finishes. Gaming is harder because the system forces completion.

This accountability extends to blocking issues:

In push: "That's blocked, but I'm working on other things." (Block festers.)
In pull: "I can't start anything new until that block is resolved." (Block forces attention.)

Pull systems align incentives with outcomes. The system rewards finishing, not starting. It rewards unblocking, not working around blocks. It rewards throughput, not busyness.

This is uncomfortable for some teams. Push systems let you feel productive even when you're not delivering. Pull systems make the gap visible. That's a feature, not a bug.

Pull Requires Courage

Pull systems surface problems that push systems hide. Some organizations adopt pull and then abandon it because 'it's exposing too many problems.' Those problems always existed—pull just made them visible. The goal is to fix them, not re-hide them.