One of the most common misunderstandings about Kanban is that it is a way of doing the work.
It isn’t.
Kanban does not tell teams how to turn requirements into working software. It tells organizations how to regulate the flow of that work once it has started.
A useful way to understand this distinction is through a concept borrowed from distributed systems and networking:
The separation of the data plane and the control plane.
The Data Plane: Doing the Work
The data plane is where value is actually created.
In a software context, this includes:
-
Turning a sprint backlog into working software
-
Writing code
-
Designing, testing, integrating, and deploying
-
Applying engineering practices and craftsmanship
Scrum, XP, DevOps practices, CI/CD pipelines, and technical architecture all live here.
Kanban does not replace any of this.
Kanban is deliberately agnostic about:
-
How teams estimate
-
How they design
-
How they test
-
How they deploy
Those choices belong in the data plane.
The Control Plane: Regulating Flow
The control plane exists for a different purpose.
It does not do the work. It regulates how work flows through the system.
In Kanban, the control plane is responsible for:
-
Deciding when new work is allowed to start
-
Detecting when the system is overloaded
-
Identifying early signs of risk
-
Triggering corrective action when limits are breached
This is why Kanban can sit on top of Scrum, SAFe, or any delivery model.
It governs the system without interfering in execution.
This separation is critical.
Scrum, XP, DevOps, and engineering practices primarily operate in the data plane — with embedded, cadence-based feedback loops that regulate local execution.
Kanban operates as a system-level control plane, continuously regulating how much work is allowed to enter and remain in the system, independent of delivery cadence.
Flow problems are almost always control-plane problems. Changing data-plane behavior to fix them is treating the symptom, not the cause.
Note: Scrum includes important feedback loops — daily inspection, sprint reviews, and retrospectives — that help teams adapt how they work. These feedback mechanisms regulate execution within a timebox. They do not regulate how much work the system is allowed to take on, nor do they respond continuously to flow conditions once work is in progress.
Kanban complements Scrum by providing a control plane above execution: continuously regulating admission, WIP, and flow stability regardless of sprint boundaries.
Why This Separation Matters
Many agile failures come from mixing these two planes.
Organizations try to fix flow problems by:
-
Changing team practices
-
Adding new ceremonies
-
Replanning more frequently
-
Asking teams to “commit harder”
These are data-plane changes applied to a control-plane problem.
When flow breaks, the issue is rarely how teams are working.
It is how much work the system has allowed to start.
WIP and Aging Are Control-Plane Signals
Kanban’s key metrics are often misunderstood as performance measures.
They are not.
-
Work in Progress (WIP) tells the control plane how much load the system is carrying
-
Aging tells the control plane how long work has been in progress without completion
Together, they answer a single question:
Is the system still operating within its expected limits?
When WIP is high or work ages beyond expectation, the control plane intervenes.
The data plane keeps executing.
Corrective Action Happens in the Control Plane
When a Kanban system responds to a signal, it does not micromanage execution.
Typical control-plane actions include:
-
Stop starting new work
-
Swarm to finish aging work
-
Reduce scope, or re-slice a work item
-
Re-sequence priorities
-
Stop work entirely
Notice what is missing:
-
No changes to coding practices
-
No new roles
-
No reorganization of teams
The control plane adjusts flow, not behavior.
Cadence Is a Container, Not a Controller
Scrum sprints, PI boundaries, and review cycles often get mistaken for control mechanisms.
They are not.
They are time containers in the data plane.
The control plane operates continuously:
-
It reads signals every day
-
It reacts when thresholds are crossed
-
It stays quiet when the system is healthy
This is why well-run Kanban systems feel calm.
The control plane intervenes only when necessary.
Scaling Without Entanglement
The power of the control-plane model is that it scales cleanly.
The same logic applies at every level:
-
Teams regulate story flow
-
Products regulate feature flow
-
Portfolios regulate investment flow
The work changes.
The economic impact changes.
The control plane does not.
This is how organizations scale without entangling governance with execution.
A Simple Diagnostic Question
You can tell whether an organization understands this separation by asking:
When delivery slows down, do we change how teams work — or do we reduce the amount of work in progress?
If the answer is the former, the control plane is missing.
Closing Thought
Kanban is not a delivery methodology.
It is a control plane for knowledge work.
It allows teams to focus on execution while the system quietly regulates flow in the background.
When this separation is respected:
-
Teams regain focus
-
Governance becomes lighter
-
Decisions arrive earlier
-
Flow stabilizes
And the system finally starts telling the truth about its capacity.