05 - Kanban Method: Continuous Flow and WIP Limits

Kanban Method: Continuous Flow and WIP Limits

Kanban is an Agile method based on continuous flow of work, without time-boxed iterations. Originated from the Toyota production system, Kanban focuses on visualization, WIP limitation (Work In Progress) and flow optimization.

Origins of Kanban

Kanban (看板, literally "signboard" in Japanese) was born in the 1940s at Toyota as a Just-In-Time (JIT) production management system. The goal: produce only what's needed, when it's needed, reducing waste and inventory.

The 4 Fundamental Principles of Kanban

🔵 1. START WITH WHAT YOU DO NOW
   └─ No revolution needed: start with current process

🔵 2. AGREE TO PURSUE INCREMENTAL, EVOLUTIONARY CHANGE
   └─ Small, continuous changes (no big bang)

🔵 3. RESPECT CURRENT ROLES, RESPONSIBILITIES & TITLES
   └─ No drastic organizational change required

🔵 4. ENCOURAGE ACTS OF LEADERSHIP AT ALL LEVELS
   └─ Anyone can propose improvements

The 6 Kanban Practices

1. Visualize the Workflow

Make work and its flow explicit and visible to everyone through a Kanban board.

KANBAN BOARD - Software Development
┌────────────┬────────────┬────────────┬────────────┬────────────┬────────────┐
│  BACKLOG   │   TO DO    │IN PROGRESS │CODE REVIEW │  TESTING   │    DONE    │
│            │            │  (WIP: 5)  │  (WIP: 3)  │  (WIP: 4)  │            │
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
│            │            │            │            │            │            │
│ [Story 50] │ [Story 12] │ [Story 8]  │ [Story 5]  │ [Story 3]  │ [Story 1]  │
│ [Story 51] │ [Story 13] │ [Story 9]  │ [Story 6]  │ [Story 4]  │ [Story 2]  │
│ [Story 52] │ [Story 14] │ [Story 10] │ [Story 7]  │            │            │
│    ...     │            │            │            │            │            │
│            │            │            │            │            │            │
│ 100+ items │  10 items  │  3 items   │  3 items   │  2 items   │ 25 items   │
└────────────┴────────────┴────────────┴────────────┴────────────┴────────────┘

🔴 WIP LIMIT VIOLATED: "Code Review" has 3/3 items → BLOCKED!
   ⚠️ Team must complete reviews before pulling new work

2. Limit Work In Progress (Limit WIP)

The most important Kanban concept: limit the number of tasks that can be "in progress" simultaneously in each column.

📊 METHODS TO CALCULATE WIP LIMIT

🔵 METHOD 1: Number of People
WIP limit = Number of people × 1.5

Ex: Team of 5 people
- In Progress WIP = 5 × 1.5 = 7-8 max tasks

🔵 METHOD 2: Start Conservative
WIP limit = Number of people ÷ 2

Ex: Team of 6 people
- In Progress WIP = 6 ÷ 2 = 3 tasks (very tight!)
- Adjust if team gets blocked too often

🔵 METHOD 3: Current State + Reduce
1. Count how many tasks are typically "in progress"
2. Reduce by 20-30%
3. Monitor and adapt

Ex: Average 12 tasks in progress
- Set WIP limit = 8-10
- Observe effects on lead time

🔴 GOLDEN RULE: Start low, adjust up
Better to start with WIP limit too low and raise it
than vice versa (high limits = status quo)

3. Manage Flow

Monitor and optimize the flow of work through the system. Goal: smooth, predictable flow without accumulations or blocks.

🚨 RED FLAGS

❌ QUEUE BUILDUP
   Column always full, tasks accumulate
   └─ Bottleneck! Increase capacity or reduce upstream WIP

❌ FREQUENT BLOCKERS
   Tasks blocked (🚫) for days
   └─ Unmanaged dependencies, slow decisions

❌ INCREASING LEAD TIME
   Average time to complete tasks increases over time
   └─ System is slowing down, technical debt?

❌ "SKIPPED" WORK
   Tasks skip columns (e.g: To Do → Done without Code Review)
   └─ Board doesn't reflect real process

✅ GOOD FLOW INDICATORS

✅ Work moves steadily left-to-right
✅ Lead time stable or decreasing
✅ WIP limits respected
✅ Consistent throughput (e.g: 10 tasks/week)

4. Make Policies Explicit

Clearly define the rules for when a task can move from one column to another (Definition of Done for each step).

📋 PULL POLICIES (When can I move a card?)

To Do → In Progress:
✅ Clear acceptance criteria
✅ Dependencies resolved
✅ Assigned to developer
✅ WIP limit "In Progress" not reached

In Progress → Code Review:
✅ Code compiles without errors
✅ Unit tests written and passing
✅ Self-review completed
✅ WIP limit "Code Review" not reached

Code Review → Testing:
✅ At least 2 reviewers approved
✅ All comments resolved
✅ Merged to main branch
✅ WIP limit "Testing" not reached

Testing → Done:
✅ Test plan executed
✅ No P0/P1 bugs open
✅ Product Owner accepted
✅ Deployed to staging

5. Feedback Loops

Implement regular feedback loops for inspection and adaptation of the system.

6. Improve Collaboratively

Use scientific models and experimental method for kaizen (continuous improvement).

Kanban Metrics: Lead Time, Cycle Time, Throughput

1. Lead Time

Definition: Total time from when task enters system to when it's completed.

📅 STORY #123: "Add forgot password feature"

Timeline:
├─ Day 1:  Task added to Backlog
├─ Day 3:  Task pulled to "To Do"
├─ Day 5:  Development starts ("In Progress")
├─ Day 8:  Code review ("Code Review")
├─ Day 9:  Testing ("Testing")
└─ Day 10: Done

📊 LEAD TIME = 10 days (from entry to done)
📊 CYCLE TIME = 5 days (from "In Progress" to "Done")

Lead Time includes waiting time in backlog/queue
Cycle Time is only active work time

2. Throughput

Definition: Number of tasks completed per time unit (e.g: tasks/week).

Tasks Completed per Week
   ↑
14 │                    ●
12 │         ●     ●
10 │    ●         ●        ●
 8 │ ●                  ●
 6 │
 4 │
 2 │
 0 └───────────────────────────────→ Weeks
   W1  W2  W3  W4  W5  W6  W7

Average Throughput: 10 tasks/week
Min: 8, Max: 14

📊 INSIGHTS:
- Team completes average 10 tasks/week
- Use for forecast: "80% confidence: 8-12 tasks/week"
- Relatively low variability (good!)

3. Cumulative Flow Diagram (CFD)

The CFD is Kanban's most powerful chart: shows work accumulation in each column over time.

Cumulative Tasks
   ↑
60 │                        ┌─ DONE
   │                  ┌────┘
50 │            ┌────┘      ├─ TESTING
   │      ┌────┘            ├─ CODE REVIEW
40 │ ┌───┘                  ├─ IN PROGRESS
   │ │                      ├─ TO DO
30 │ │                      └─ BACKLOG
   │ │
20 │ │
   │ │
10 │ │
   │ │
 0 └─┴────────────────────────────────→ Time
   W1   W2   W3   W4   W5   W6

✅ HEALTHY CFD:
- Parallel bands (constant flow)
- Band width = WIP in that phase
- Slope = completion velocity

🚨 VISIBLE PROBLEMS:
- "TO DO" band widens → Accumulation! Downstream bottleneck
- "CODE REVIEW" band very wide → WIP limit too high or slow process
- Irregular bands → Unstable flow

Kanban vs Scrum: Detailed Comparison

When to Use Kanban

Scrumban: Best of Both Worlds

Scrumban combines Scrum and Kanban, taking the best of both:

🔵 FROM SCRUM:
├─ Time-boxed sprints (1-2 weeks)
├─ Sprint Planning meeting
├─ Sprint Review/Demo
├─ Retrospective
└─ Optional roles (PO, SM)

🟢 FROM KANBAN:
├─ Kanban board with flow visualization
├─ Explicit WIP limits
├─ Pull system
├─ Metrics: Lead Time, CFD
└─ No fixed scope commitment

✅ WHEN TO USE SCRUMBAN:
- Scrum teams wanting more flexibility
- Kanban teams wanting regular rhythm
- Mixed support + development
- Gradual transition Scrum → Kanban

Implementing Kanban: Step-by-Step Guide

Conclusions

Kanban is a powerful and flexible method to manage workflow, particularly suited to contexts with high variability and continuous delivery. The key to success is discipline in respecting WIP limits and constant use of metrics to guide improvement.