Kanban as a Process Control System
Flow-based management can be understood most clearly by borrowing a concept from control theory.
Control systems have four elements:
- A Process being controlled
- Sensors that observe the state of the process
- A Controller that interprets signals and makes decisions
- Actuators that change how the process behaves
For example:
Team Level — Daily Flow Control
Process: Create user stories from Backlog
Sensor: Collect data on WIP levels and item aging
Controller: Team daily standup – review the data and decide if action needed
Actuator: Take action – swarm, slice, stop starting new work
Action Triggers
- Stories aging beyond expectation
- WIP exceeding limits
Decisions
- Swarm
- Slice
- Unblock
- Stop starting
If nothing is aging, the standup ends early.
Policies must be explicit to support the flow
Examples:
- What aging threshold requires discussion?
- What WIP breach requires stopping new work?
Without explicit policies:
- Signals are debated
- Decisions are delayed
- Governance reverts to politics
Policies remove ambiguity before pressure arises.
Work Items Must Be Small Enough to Enable Flow Control
A sprint backlog populated with stories sized to finish in 10 days (the end of a sprint) sets a team up with zero opportunities to take any meaningful action mid-sprint. In this situation stand-ups are almost pointless.
Why This Reduces, Not Increases, Governance Overhead
This may feel counterintuitive.
But when governance is trigger-based:
- Fewer items require discussion
- Meetings become shorter
- Decisions become clearer
- Escalations become rarer
As flow improves, triggers fire less often.
Silence is not neglect.
It is success.
Trigger-based governance is not dramatic.
There are no big moments.
No heroic interventions.
No crisis meetings.
There is just:
- Work flowing
- Signals appearing
- Decisions happening
- The system adjusting
Also, this pattern scales to ART and Portfolio (more later).