| name | coach-kanban-method |
| description | Coach a team on the Kanban Method's six core practices (visualise, limit WIP, manage flow, make policies explicit, feedback loops, evolve experimentally), when Kanban beats Scrum (discovery, ops, irregular arrival), and the Scrumban hybrid. Use when a team's work doesn't fit sprints or to introduce pull-based flow. |
| argument-hint | [team name and work type] |
| user-invocable | true |
| allowed-tools | Read, Write, Edit, Glob, Grep |
Coach the Kanban Method
Coach $ARGUMENTS on the Kanban Method. Kanban is evolutionary: it starts with what
the team already does and improves incrementally, rather than prescribing a framework. It fits work that Scrum
serves poorly. This skill pairs with coach-flow-metrics (Kanban's measures) and audit-scaling-framework. Source:
David J. Anderson, Kanban: Successful Evolutionary Change.
Step 1: Confirm Kanban fits the work
Don't introduce Kanban by default — confirm it fits. Kanban beats Scrum when:
| Work type | Why Scrum fits poorly | Why Kanban fits |
|---|
| Discovery / research | Continuous, not sprint-bounded; sprints pressure learning | Pull-based, no artificial cadence on learning |
| Operations / support | Irregular, unpredictable arrival | WIP limits + explicit interrupt policy handle interrupts |
| Maintenance | Mix of planned and unplanned, unpredictable | Pull system absorbs variation |
If the work is sprint-sized complex feature work with meaningful stakeholder feedback, Scrum may fit better — say
so. If the team needs both a cadence and pull, coach Scrumban (Step 5).
Output: a one-line judgement on whether Kanban fits and why.
Step 2: Coach the six core practices
Coach the team through the practices in order — visualisation first, because everything else depends on seeing the
work:
- Visualise — make invisible work visible. A board with columns for workflow states and cards for work items.
Problems hide without it.
- Limit WIP — set explicit WIP limits per state. When a column is full, no new work enters until something
exits. This is the central mechanism: it converts a push system (start work whenever) to a pull system (start
only when there's capacity).
- Manage flow — monitor speed and smoothness. Track blockages, find bottlenecks, measure cycle time. Aim for
even flow, not bursts followed by queues.
- Make policies explicit — document the rules: what counts as done per column, what triggers a handoff, how
blockers escalate, how interrupts are handled. Explicit policies enable rational discussion.
- Implement feedback loops — Anderson's cadences run at different frequencies: daily standup (team),
replenishment (what enters), service delivery review (metrics/flow), operations review (cross-team). Coach the
team to run the cadences it needs, not all of them by rote.
- Improve collaboratively, evolve experimentally — change one thing at a time, measure before and after. Use
models (Theory of Constraints, systems thinking) to guide changes rather than guessing.
Step 3: Set the first WIP limits
WIP limits are where teams resist most. Coach the why with Little's Law (handled in depth by coach-flow-metrics):
less WIP means shorter cycle time without adding people. Start with a limit slightly below current WIP so the team
feels the pull effect, then evolve experimentally. A WIP limit nobody enforces is decoration.
Step 4: Make the interrupt policy explicit (for ops/support)
For operations and support teams, the interrupt is the defining challenge. Coach the team to write an explicit
policy: what classes of work can jump the queue, who decides, and what WIP is reserved for interrupts. An implicit
interrupt policy means every urgent request wins and planned work never finishes.
Step 5: Coach Scrumban where the team needs both
Scrumban (Corey Ladas, 2009) is a pragmatic hybrid: keep a cadence for retrospectives and planning checkpoints, but
manage daily work on a Kanban board with WIP limits and drop the sprint commitment. It fits teams transitioning from
Scrum or running mixed planned/unplanned work. Its failure mode: losing the discipline of both methods — name that
risk explicitly.
Rules
- Don't introduce Kanban by default. Confirm the work doesn't fit Scrum first — the right method matches the work.
- Visualise before limiting. You can't set sensible WIP limits on work you can't see.
- WIP limits must be enforced. An unenforced limit is decoration; the pull effect only happens when "full means
full."
- Make the interrupt policy explicit for ops/support. Implicit means urgent always wins and planned work starves.
- Evolve experimentally — one change, measured. Don't redesign the whole board at once; you won't know what worked.
- Name the Scrumban risk. A hybrid that drops the discipline of both methods is worse than either alone.
Output Format
---
title: Kanban Coaching — [team]
date: YYYY-MM-DD
author: agile-coach
category: Coaching
---
## Fit judgement
- Kanban fits because: [...] (or: Scrum fits better because [...])
## Six practices — current state and coaching
| Practice | Current | Coaching action |
|----------|---------|-----------------|
| Visualise | [...] | [...] |
| Limit WIP | [...] | [...] |
| Manage flow | [...] | [...] |
| Explicit policies | [...] | [...] |
| Feedback loops | [...] | [...] |
| Evolve experimentally | [...] | [...] |
## WIP limits set
| State | Current WIP | Limit | Rationale |
|-------|-------------|-------|-----------|
## Interrupt policy (ops/support)
[Explicit policy, or N/A.]
## Scrumban
- Recommended: [yes/no — and the risk named]
