What Is a Pull System? The Difference Between Work Arriving and Work Being Taken

Introduction

A pull system is usually introduced with a Toyota factory and a card travelling backwards down an assembly line. It is a good story that explains almost nothing about software: the thing being pulled on an assembly line is a physical part with a known cycle time, and the thing being pulled on your team is a half-specified idea with an unknown one.

The software version is simpler. A pull system means one thing: nobody is handed work. People take the next item themselves, when they finish the last one. That is the whole mechanic, and everything below is a consequence of it.

It sounds like a scheduling detail. It is not. Changing who decides when work starts changes where queues form and what your delivery data means.

Push and Pull, Defined Without the Factory

In a push system, work is assigned. Somebody decides this ticket belongs to this person, and it lands in their queue whether or not they finished the last one. The assigner is working from an estimate of how much that person can absorb, and estimates of other people's capacity are reliably wrong in one direction.

In a pull system, work is taken. There is one ordered list of what matters. When you finish something, you take the highest item you can work on. Nobody pre-allocated it. If nothing is available, that is information rather than idleness, and usually the most useful signal the system produces all week.

The difference shows up in the failure mode. Under push, work piles up invisibly inside individual queues: four items assigned to one person all look equally "in progress" from outside, and three of them are waiting. Under pull, it piles up in one visible place, because nobody took it. The second failure is the one you can act on.

Push vs Pull, Side by Side

The last row matters most and gets discussed least. Push optimises for nobody looking idle; pull optimises for work moving. Those two goals conflict more often than teams expect, and the conflict is why flow efficiency in a typical team sits between 5 and 20 percent.

Four Things Have to Be True First

Pull is a set of preconditions, not a policy you announce. Teams that skip them end up with a list nobody takes from and a lead who quietly goes back to assigning.

1. The list has to be genuinely ordered. Not grouped, not tagged, not sorted into four priority buckets holding thirty items each. Ordered top to bottom, so that "take the next one" is unambiguous. Every tie hands the decision back to the developer, who will resolve it by picking whichever item is more interesting. See prioritising without a board.

2. Items have to be small enough to finish. Pull only limits work in progress if finishing happens often. A three-week item holds a pull slot for three weeks and turns the WIP limit into decoration. There is a reason three-week tasks are never the hard ones: they are several tasks that were never separated.

3. There has to be a number. A pull system without a WIP limit is just an unassigned backlog. The limit makes pulling a decision rather than a formality: at the limit you cannot take the next item, so you go help finish one already in flight. That moment, where starting is blocked and finishing is the only move, is where the benefit lives.

4. Anyone has to be able to take anything, most of the time. If only one person can touch the payments code, the payments queue is a push queue wearing a pull badge. You do not have to fix that before starting, but you do have to know where your single-owner areas are, because they will be your bottlenecks and pulling will not change that. See what to do when the bottleneck is code review.

What Actually Changes on the Ground

The standup question changes. "What did you do yesterday" audits individual assignment. The pull-system question is "what is stopping the top of the list from moving", which is about the work rather than the worker and can usually be answered from a screen. Items sitting still show up in aging work in progress.

Idle becomes legible. Under push nobody is ever idle, because more work can always be assigned. Under pull, somebody with capacity and nothing takeable at the top means intake is starving or the queue is full of items that are not ready. Filling that gap with busywork destroys the signal, which is the most common way pull systems die.

Forecasting stops needing estimates. Once work is pulled in a consistent order under a consistent limit, the time items take becomes a distribution you can read instead of a number you guess. That is the mechanism behind forecasting without estimates, and it does not work under push, where assignment order keeps changing what the data means.

How FlowBoard Implements Pull

FlowBoard is built as a pull system rather than configured into one: no assignment step in the default path, no column to drag a card out of.

Work lives in one prioritised flow, sorted top to bottom by a priority score rather than by position on a board. Reprioritising means changing an input to that score, not rearranging cards, so the order stays trustworthy even when it changes daily. That is precondition 1 satisfied by construction: the ordering is computed, not curated.

Readiness is separate from status and shown as a colour: red for not ready, amber for in progress or needing work, green for ready to ship. That matters more under pull than under push, because the person taking an item judges for themselves whether it is takeable. Red says do not pull this yet, without anyone having to ask.

When you finish something, the Up Next engine surfaces related items you could take, removing the scroll that otherwise sits between every pull and the next. The pull is still yours to make. The search for what to pull is not.

Finished work lands in a release, which is a first-class object tasks belong to rather than a label applied afterwards. Freeze it to stop adding scope, ship it when every item is green, and the tasks close, the changelog generates and whoever was waiting gets told, in one action. A pull system needs a container for finished work that is not a fortnightly boundary. That is it.

What Usually Goes Wrong

Pull without a limit. The most common version. The team stops assigning, nobody sets a number, and everyone pulls a second item whenever the first is waiting on review. Work in progress rises, cycle time follows, and within six weeks somebody concludes pull does not suit this team. Set the number on day one, even as a guess.

A shared list that is actually eight lists. If the queue is filtered per person, squad or component before anyone looks at it, you have pre-assigned the work and called it pull. One list, one order, visible to everybody.

Cherry-picking. Pull assumes people take the top item, not the nicest one. This is the one legitimate objection, and the honest answer is that it happens and is easy to see: if the top three items stay stale while item nine keeps getting taken, either the ordering is wrong or the top items are not ready. Both are worth knowing.

Frequently Asked Questions

What is a pull system in simple terms?

A pull system is one where people take their next piece of work from a shared ordered list when they finish the last one, instead of being assigned it. Work starts because capacity freed up, not because someone handed it over.

What is the difference between a push system and a pull system?

Push means work is assigned based on an estimate of someone's capacity. Pull means work is taken by someone who knows their capacity exactly, because they just finished something. The practical difference is where queues form: hidden inside individual assignment lists under push, visible in one shared queue under pull.

Do you need a kanban board to run a pull system?

No. A board is one way to display a pull system, not the system itself. You need a single ordered list, a limit on simultaneous work, and the rule that people take rather than receive. Columns are a status display, and status can be a field on the item.

Does a pull system work for a team of three?

Yes, and it is easier at three than at thirty: one list, a WIP limit of roughly two items each, and no coordination layer. The main risk at small scale is skipping the limit because it feels unnecessary, which is exactly when work in progress starts climbing.

How does a pull system handle urgent or unplanned work?

It goes to the top of the shared list and is taken by whoever frees up next, rather than interrupting one person. Nothing in flight is abandoned, and the cost shows up as a visible delay to whatever it displaced, which makes the tradeoff a decision rather than a surprise. See handling urgent requests without derailing the week.

Is a pull system the same as Kanban?

Pull is one of Kanban's core practices, not a synonym for it. Kanban adds visualisation, explicit policies and feedback loops on top. You can run a pull system with none of Kanban's vocabulary, and plenty of teams run a Kanban board that is push underneath because a lead assigns every card.

What to Do This Week

Do not announce a methodology change. Run one test: for five working days, stop assigning. Put everything in one ordered list, set a WIP limit you are not confident about, and let people take the top item they can work on.

Two things will happen, and both are the point. Somebody will finish and find nothing takeable at the top, which tells you the intake or the readiness definition is broken. And somebody will hit the WIP limit and have to help finish an item instead of starting one, which is the first time that week the team optimised for finishing rather than for looking busy.

Next: how to set a WIP limit without turning into a process team for the number itself, and continuous flow project management for how pull fits with releases, prioritisation and everything else.