Pull vs. Push Systems

In a push system, work is assigned to people. A manager or system decides who does what and when.

Characteristics of push:

• Central authority makes assignments
• Work is pushed onto queues in front of workers
• Workers process whatever lands in their queue
• Overload is invisible until crisis

Problems with push:

• Doesn't account for actual capacity
• Creates local overloads
• No feedback loop to demand source
• Encourages starting over finishing

In a pull system, workers take the next item when they have capacity. Work is "pulled" through the system by downstream demand.

Characteristics of pull:

• Workers self-select next item based on priority
• WIP limits prevent overload
• Capacity governs the pace
• Demand is smoothed naturally

How it works:

1. Developer finishes a task, creating capacity
2. Developer looks at "Ready" column and pulls the next priority item
3. This creates capacity in "Ready" which gets replenished
4. Signal propagates upstream, limiting new work intake

The key shift: nothing starts until something finishes. This is what WIP limits enforce.

In Toyota's factories, physical kanban cards created the signal: "I used this part, send more."

In knowledge work, the signal is: space in the next column.

When the Code Review column has capacity (WIP not at limit), it signals that Development can finish something and move it over.

When the Code Review column is full (at WIP limit), it signals that Development should either help with reviews or not start new dev work.

This is why WIP limits are essential—without them, there's no signal. Work just piles up.

Making pull work:

1. Clear priorities: When pulling, what's next? FIFO within class? Most impactful? Teams need shared criteria.

2. Visible capacity: The board shows when capacity exists (column below WIP limit).

3. Team agreement: Everyone pulls; nobody pushes. Managers don't assign—they might highlight priorities, but workers pull.

4. Psychological safety: Pulling requires agency. If people fear choosing wrong, they'll wait for assignments.

The role of product owners/managers:

• Set priorities (what should be pulled first)
• Protect the backlog (what enters the system)
• Don't assign work to individuals

Transitioning from push to pull:

• Start by making assignments visible, not eliminating them
• Gradually shift to self-selection
• Coach managers away from assigning
• Celebrate successful pulls