Kanban: Engineering the Flow of Value

Kanban is more than a board; it is a pull-based system for managing the flow of value through a process. For engineering leaders, the goal is not to maximize activity, but to minimize Cycle Time by managing the primary constraint: Work-in-Progress (WIP).

I. The Theoretical Foundation

A. Little's Law

The fundamental law of flow states that in a stable system, the average number of items ( $L$ ) is equal to the average arrival rate ( $\lambda$ ) multiplied by the average time an item spends in the system ( $W$ ).

L = \lambda W \implies \text{WIP} = \text{Throughput} \times \text{Cycle Time}

The Practitioner's Insight: To reduce Cycle Time ( $W$ ) without changing your team's throughput capacity ( $\lambda$ ), you must reduce the WIP ( $L$ ). Adding more work to the board mathematically guarantees longer wait times.

II. WIP Limits: The System Governor

WIP limits are non-negotiable constraints applied to columns on a Kanban board.

Stage	WIP Limit	Logic
Ready	5	Prevents the "Backlog Explosion."
In Dev	$2 \times \text$	Allows for pairing but prevents context switching.
Review	2	Forces the team to "Stop Starting and Start Finishing."
Testing	3	Prevents a bottleneck at the QA gate.

The "Swarm" Protocol

When a WIP limit is hit, the team must stop pulling new work. Instead, all available capacity "swarms" the bottleneck to move items to "Done."

III. Cumulative Flow Diagrams (CFD)

The CFD is the most powerful diagnostic tool in Kanban. It tracks the cumulative number of items in each state over time.

How to Read a CFD

Vertical Distance: The vertical gap between the "Arrivals" line and the "Departures" line is your current WIP.
Horizontal Distance: The horizontal gap between the lines represents the Lead Time.
Slope: The slope of the "Done" line is your Throughput.

Diagnostic Patterns

Diverging Lines: If the top line (Arrivals) rises faster than the bottom line (Done), your WIP is growing, and your Lead Time is expanding. You have a bottleneck.
Parallel Lines: Indicates a stable system with predictable delivery.
Steps/Flatlines: Indicates a "Stagnant Flow" where work has stopped, likely due to a systemic blocker or external dependency.

IV. Calculating Optimal WIP Limits

Don't guess. Use the Bottleneck Capacity method.

Identify the slowest stage in your process (the bottleneck).
Calculate its capacity ( $C$ ) in items per week.
Set the WIP limit for the bottleneck stage to $C$ .
Set upstream stages to $C + 1$ (to ensure the bottleneck is never starved).

Formula for Multi-team Flow:

\text{WIP}_{\text{max}} = \frac{\text{Target Cycle Time}}{\text{Historical Mean Processing Time}}

V. Flow Metrics Practitioner Template (YAML)

Use this format for your weekly flow audit.

audit_date: "2025-05-12"
team: "Core_Platform"
metrics:
  avg_wip: 14
  throughput_items_per_week: 4.2
  avg_cycle_time_days: 23
  flow_efficiency: "35%" # (Value-add time / Total time)
bottlenecks:
  - stage: "Code_Review"
    reason: "Low reviewer availability due to off-site"
    action: "Implement mandatory 24h review SLA"
wip_adjustments:
  - stage: "Testing"
    old_limit: 5
    new_limit: 3
    rationale: "Lead time is diverging in CFD; reducing input to match QA capacity."

VI. Critical Failure Modes

Invisible WIP: Work that isn't on the board (emails, "quick favors") destroys the predictability of the system.
Violating Limits: Treating WIP limits as "suggestions." If you don't stop pulling work when the limit is hit, you aren't doing Kanban.
Ignoring the "Done" Column: If work is finished but not shipped (e.g., waiting for a release train), the "Done" column becomes a hidden inventory of waste.