Pull-based WIP control or “how less can be more”

If there is one Kanban idea that organisations love to talk about and hate to actually practice, it’s this one.

Pull-based WIP control. Everyone you meet who knows Kanban is also an expert in WIP.

On paper, everyone agrees with it. In reality, most delivery systems are still push systems with a thin Kanban layer. Work gets started because it’s “important”, because someone senior asked, because a plan said so, or because the backlog looked scary. The fact that the system is already overloaded is treated as an inconvenience rather than a constraint.

And then we wonder why nothing finishes.

The core misunderstanding about WIP

Most teams think WIP limits exist to improve productivity.

False.

WIP limits exist to control risk.

Every item you start is a commitment to:
    •    Delay feedback on everything else
    •    Increase average cycle time
    •    Increase ageing across the system
    •    Reduce predictability
Starting work is not neutral. It has a cost. A very real one. Sadly, most people don’t get this.

Pull-based WIP control is simply the discipline of acknowledging the cost before you pay it.

Push systems feel fast

Push systems optimise for the illusion of progress:

• •     More things “in flight”
  •     More people “busy”
  •     More starts per week
  •     More status updates
  • Thinking we started it (therefore it should finish)

Push systems look healthy right up until they aren’t.
What actually happens is predictable:

•     Items wait in hidden queues
•     Dependencies multiply
•     Context switching explodes
•     Work ages silently
•     Delivery dates slip all at once

If you read this and get it, join the club - let’s be frustrated together!
This is not bad execution. It’s basic flow physics.

Pull is a decision rule, not a board feature
A system is not pull-based because it has WIP limits written on a board.

It is pull-based only if this rule is actually followed:

New work starts only when there is capacity to finish it.

That means:

•     Not when someone asks
•     Not when a sprint ends
•     Not when a plan says so
•     Not because “we’ll figure it out later”
•     Not because an engineer thinks he can do one more task while waiting for the build

If starting work does not require an explicit signal from the system, you don’t have pull, you have hope.


Why “Just This Once” destroys flow

Almost every team has exceptions:

•     “This one is urgent”
•     “This one is small”
•     “This one won’t really count”
•     “We’ll make it up later”

Individually, each exception feels reasonable. Collectively, they are catastrophic.

Exceptions accumulate silently as additional WIP. Age increases. Cycle time stretches. Forecasts degrade. And because nothing broke immediately, the system keeps lying to you.

Pull systems only work when exceptions are rare, explicit, and painful.

If breaking WIP limits is easy, your limits are decorative.



WIP control is about when you say no

This is where delivery leadership gets uncomfortable.

Pull-based WIP control forces you to answer questions you’ve been deferring:

•     What actually matters most?
•     What can wait?
•     What are we willing to delay?
•     What trade-offs are we prepared to make?

Push systems avoid these questions by starting everything and hoping reality sorts it out later.

Reality always does. It just charges interest.


Why is this happening

When WIP control fails, it’s rarely because teams don’t understand it.

It fails because:

•     Priorities change without removing existing work
•     Managers inject new work without removing old commitments
•     Capacity is assumed rather than measured
•     Expedites bypass the system entirely

From the team’s perspective, pull is impossible if leadership keeps pushing.

You cannot ask teams to manage flow while constantly overriding the mechanism that enables it.


Pull, age, and the real reason WIP matters

Here’s the connection most organisations miss:

The real reason to limit WIP is to prevent unnecessary ageing.

Every extra item you start:
    •    Increases the average age of everything else
    •    Reduces the chance of meeting SLEs
    •    Delays learning whether you built the right thing


WIP limits are not a productivity tool. They are an ageing control mechanism.
If you are tracking Work Item Age and still starting new work while old items stagnate, you are actively choosing delay.


What pull-based control looks like in practice


In a functioning pull system:

•     WIP limits are visible and respected
•     Starting work requires justification, not finishing it
•     Blocked work triggers focus, not avoidance
•     Leaders remove work to make space, not add pressure
•     Age is discussed before dates are missed

This is quieter than push. Less dramatic. Far more effective.

The hard truth: pull feels slower until it works

Pull systems often feel slower at first because they expose how overloaded you already are.

That discomfort is the signal you’ve been missing.

If adopting pull suddenly makes your delivery system look worse, that doesn’t mean Kanban failed. It means the system was already failing — you just finally stopped hiding it.


Starting Work Is a Leadership Decision

Finishing work is a team activity.
Starting work is a management choice.
If your organisation starts more than it can finish, no amount of team-level optimisation will save you. Pull-based WIP control is where leadership stops managing utilisation and starts managing flow.

In the next post, we’ll look at Flow Metrics Dashboards and why visibility without decision-making is just another form of theatre.