Kanban as a Flow Control Protocol

One of the most persistent misunderstandings about Kanban is the belief that it is primarily a visualization technique.

Boards. Columns. Cards. Visibility.

Those things matter — but they are not the point.

Kanban works when it functions as a flow control protocol.


Flow Control Is a Solved Problem (In Other Domains)

Donald Reinertsen often points out that flow control is not a new or controversial idea. It is a solved engineering problem in domains like communication networks.

When computers communicate over a network, they do not send data as fast as possible and hope the receiver can cope.

They use flow-control protocols.

These protocols:

  • Limit how much data is “in flight”

  • Detect congestion early

  • Apply back-pressure when the system is overloaded

  • Adapt behavior continuously based on feedback

Without flow control, networks collapse under load. Packets queue up, delays explode, data is dropped, and throughput decreases rather than increases.

Knowledge work systems behave the same way.


The Parallel in Product Development

In product development and delivery:

  • Work is “sent” into teams

  • Teams have finite capacity

  • Excess work accumulates as queues

  • Lead times increase

  • Quality degrades

  • Predictability disappears

And yet, many organizations respond to overload by doing the equivalent of disabling flow control:

They push more work into the system.

Pushing more work into an overloaded system is like sending more packets into a congested network — or more vehicles onto a congested highway.

It feels productive.
It makes everything slower.


Why Visibility Alone Is Not Enough

This is where many Kanban adoptions stall.

Teams create boards that:

  • Show where work is

  • Show how much work exists

  • Show that the system is overloaded

But nothing changes.

This is superficial Kanban: visibility without control.

A network would not solve congestion by:

  • Displaying a dashboard of packet delays

  • Holding a meeting about throughput

  • Asking senders to “be more disciplined”

It solves congestion by enforcing flow control.

A Kanban-controlled development process must do the same.


Kanban as a Flow Control Protocol

When Kanban works, it plays the same role as a communication protocol.

It provides:

  • Explicit WIP limits
    (window sizes — how much work may be in flight)

  • Aging and blocked-time signals
    (congestion indicators)

  • Pull policies
    (back-pressure — stop starting, finish work)

  • Pre-defined corrective actions
    (what happens when limits are breached)

At that point, Kanban stops being a board teams “use” and becomes the mechanism governing how work flows.


The Diagnostic Question

You can tell immediately whether Kanban is acting as a flow control protocol by asking one question:

When a WIP limit or aging threshold is breached, does it trigger a specific corrective action?

If the answer is no:

  • Kanban is informational

  • Governance lives elsewhere

  • Risk accumulates quietly

If the answer is yes:

  • The system regulates itself

  • Overload is constrained

  • Problems surface early

  • Decisions become simpler


What Corrective Action Actually Means

Corrective action does not mean escalation or blame.

It means the system responds predictably when congestion appears.

Examples include:

  • Stopping new work from entering the system

  • Swarming to finish aging items

  • Unblocking dependencies

  • Reducing scope to restore flow

  • Re-sequencing work based on capacity

If limits are breached and nothing changes, the limits are decorative.


Why This Matters at Scale

At small scale, teams can compensate for poor flow control with heroics.

At scale:

  • Dependencies multiply

  • Queues grow faster

  • Delays compound

  • Risk becomes systemic

Without explicit flow control, Kanban boards become more crowded — not more useful.

This is why Kanban scales only when it is treated as a control system, not a reporting tool.


The Reframe That Matters

Kanban is not primarily about seeing work.

It is about regulating work under load.

Just as networks rely on flow-control protocols to remain stable, enterprises need explicit mechanisms to limit work in progress, detect congestion early, and trigger corrective action automatically.

That is what Kanban provides — when it is taken seriously.


Closing Thought

Visibility does not create flow.

Control does.

When Kanban functions as a flow control protocol, the system becomes quieter, more predictable, and more resilient — not because people work harder, but because the system stops harming itself under load.

Scroll to Top