Continuous Improvement with Kanban Retrospectives

Continuous Improvement in Kanban

Kanban's sixth core practice -- "improve collaboratively, evolve experimentally" -- means that the process itself is always evolving. Retrospectives are the primary mechanism for this improvement.

The Flow-Focused Retrospective

Unlike Scrum retrospectives that ask "what went well / what didn't," Kanban retros focus on flow data:

1. Review metrics -- Show cycle time, throughput, and WIP charts for the past period.
2. Identify blockers -- Which items spent the most time stuck? What column were they in?
3. Analyze outliers -- Which items took much longer than the 85th percentile? What caused the delay?
4. Evaluate experiments -- Did last retro's experiment (e.g., lowering WIP limit by 1) improve flow?

The Experiment Cycle

Every retrospective should produce one small, measurable experiment:

1. Hypothesis: "Lowering Code Review WIP from 4 to 2 will reduce
   review cycle time."
2. Experiment: Set WIP limit to 2 for the next two weeks.
3. Measure: Track average Code Review cycle time.
4. Decision: Keep, adjust, or revert based on data.

Common Experiments

• Lower WIP limit on a bottleneck column
• Add a "Ready" column with explicit entry criteria
• Introduce pair reviews to speed up code review
• Set a maximum card age policy (escalate if older than N days)
• Split a column into two (e.g., "Coding" and "Unit Testing")

Frequency

Hold Kanban retrospectives every 2-4 weeks. Some teams tie them to a cadence; others trigger them when metrics show a significant change. The key is consistency -- regular reflection drives continuous improvement.

Documentation

Record each experiment and its outcome on a card or in a shared document. This creates an institutional memory of what has been tried and what worked.