Pull-based delivery

Pull-based delivery is a way of scheduling work where a team starts something new only when it finishes something else and real capacity frees up. Nothing arrives on a fixed date; the next item is pulled by a signal from the work itself.

The signal is the whole idea. In a push system, a plan decides when work lands on a team, whatever state that team is in. In a pull system the receiving team decides, and the plan has to live with the answer.

Pull started on car assembly lines and moved into software, support desks and finance back offices. Anywhere work forms a queue the same arithmetic applies: the longer the queue, the longer the wait, and waiting is what customers feel.

Key takeaways

• Work starts when capacity frees up, not when a schedule says it should.
• A cap on work in progress is what makes the pull signal real.
• Most of the time a job spends in a system is spent waiting, not being worked on.
• You cannot pull from a pile nobody can see, so the queue has to be visible.

How it works

Pull-based delivery runs on three rules: cap how much work is open at once, make the queue visible to everyone, and start something new only when a finished item leaves. The cap is what forces a choice.

That cap is unpopular for about a week — then the team notices that finishing three things takes less time than starting nine, because nothing sits half done while somebody waits for an answer.

Push is not stupid, it is just blind. A schedule written three weeks ago cannot know that two people are off sick and a third is stuck on an escalation that will run all afternoon.

Two numbers tell you whether pull is working. Lead time runs from the moment a request enters the queue until it is done, and throughput counts the items finished each week. How busy anyone looks is not on the list.

The idea comes out of lean production, where anything that does not add value is treated as cost. The Environmental Protection Agency describes lean manufacturing as eliminating non-value added activities while delivering quality on time at least cost.

Waiting is the first waste pull goes after.

Queue management is the discipline underneath all of it, because the length of the queue, not the speed of the worker, sets how long a job waits.

Teams borrow the word lean from several places. Lean six sigma attacks waste and variation in a process, lean startup methodology pulls build decisions from evidence, and a lean canvas does the same for a business model on one page.

A continuous delivery strategy applies the rule to releases. Small changes go out when they are ready rather than waiting for a quarterly date, so the release queue never builds.

Pull fails in two places. Either the queue is invisible, so nobody can see what to pull next, or the cap has no teeth and a manager overrides it every time a client calls.

Examples

Pull shows up wherever a queue forms and people are the constraint. Three settings make it easy to see: a factory line, an outsourced back office, and a software team shipping changes.

Car plants have run this way since the 1950s. A station builds a part because the bench after it asked for one, not because a weekly schedule said so — and the line stops when the signal stops.

Smaller manufacturers reach the same methods through public programmes. The Manufacturing Extension Partnership, the United States field network for small and medium manufacturers, offers value stream mapping across more than 450 service locations.

Mapping the stream is how a team finds the queue it did not know it had.

An outsourced claims team in Manila can run the same way. Everyone works from one shared queue, each processor takes the next item on closing the last, and nobody hands out batches at the start of a shift.

The effect is easy to miss on a monthly report. Average handling time barely moves, while the hours a claim spends waiting for somebody to pick it up fall away — which is most of what the customer was feeling.

Software teams cap each column on the board. If testing is full, nobody starts coding; they go and help clear testing, which is exactly the behaviour the cap exists to produce.

Related terms

• agile release train: the fixed cadence several teams ship inside, where pull decides what each team picks up next.
• workflow outsourcing: handing a whole flow to a provider, which turns queue limits into contract terms.
• queue management: the arithmetic of waiting time that explains why pull works at all.
• continuous delivery strategy: the same small batch rule applied to releasing software.
• lean six sigma: the wider method for stripping waste and variation out of a process.

FAQ

What is the difference between push and pull delivery?

Push starts work on a date set in a plan. Pull starts work when a team finishes something and has room, so the trigger is capacity rather than the calendar.

Does pull-based delivery mean there are no deadlines?

No. Dates still exist and still get committed to, but nothing extra is injected into a full team to try to hit one.

What limits the amount of work in progress?

A number the team sets per column, per person or per service. The limit is deliberately uncomfortable, because its job is to force a conversation when work piles up instead of hiding it.

Does pull work under a fixed scope contract?

Yes, when the contract measures throughput and lead time instead of how busy people look. Providers willing to quote on queue limits are usually the ones already measuring both.

Is pull-based delivery just a kanban board?

No. A board only shows the queue, while pull is the rule about when work may start — and that rule can be broken on the tidiest board in the world.

Compare how providers describe their delivery and capacity models across the Outsource Accelerator industry hubs.