Kanban method

1. What Is the Kanban Method?

The Kanban method is a lightweight, evolutionary approach to improving how teams and services deliver work. It visualizes the flow of work, limits work-in-progress (WIP), manages flow using simple metrics, makes policies explicit, and installs feedback loops that drive continuous improvement. Unlike time-boxed Agile methods, Kanban operates as a pull-based, continuous flow system: new work is “pulled” in only when capacity is available, improving predictability and throughput while reducing stress and multitasking.

Within Agile, Innovation & Networked‑Organization frameworks, Kanban is a practical choice for teams facing variable demand and ongoing service delivery—platform and infrastructure teams, analytics and data operations, marketing operations, HR shared services, compliance, customer support, and maintenance/bug-fix streams in software. It complements product Scrum, DevOps, and Lean practices by focusing on flow and service delivery.

In plain terms: make the work visible, do less at once, finish faster, and improve continuously. Kanban gives you a simple system to deliver reliably without heavy ceremonies or reorgs.

2. Origin and Background

Kanban (“signboard” in Japanese) originated in Lean manufacturing at Toyota, where visual cues and pull systems regulated production, reduced inventory, and synchronized flow (pioneered by Taiichi Ohno). In the mid‑2000s, David J. Anderson adapted these principles for knowledge work and technology services, codifying the Kanban Method as a change approach: start with what you do now, evolve incrementally, and manage work as a flow of services. Since then, Kanban has spread widely in software, operations, and back‑office functions, supported by communities (e.g., Kanban University) and integrated with DevOps.

Why it emerged: plan‑driven and batch pushes create long queues, multitasking, and unpredictable delivery. Kanban provides a pragmatic path to better service without prescribing roles or time‑boxes, making it accessible in varied contexts.

3. How the Kanban Method Works

Kanban rests on two sets of principles and six core practices.

Change Management Principles

• Start with what you do now: No big-bang reorg required; map the current workflow and improve from there.
• Pursue incremental, evolutionary change: Small, safe-to-try experiments over disruptive overhauls.
• Respect current roles and responsibilities: Don’t force title/role changes up front; improve the system around people.
• Encourage leadership at every level: Improvement is everyone’s job, not just managers’.

Service Delivery Principles

• Understand and focus on customer needs: Optimize for lead time, predictability, and fitness for purpose.
• Manage work, not people: Limit WIP and let people self-organize around the flow of work.
• Continuously improve the service: Regularly review performance, policies, and demand/capacity.

Core Practices

• Visualize the work and workflow: Use a Kanban board to show states (e.g., Ready → In Progress → Review → Done), work items, blockers, and policies.
• Limit work-in-progress (WIP): Set explicit WIP limits per column (or swimlane) to curb multitasking and shorten queues.
• Manage flow: Monitor lead time, cycle time, WIP, and throughput; address bottlenecks; smooth variability; aim for predictability.
• Make policies explicit: Define pull criteria, priorities, classes of service, definitions of ready/done, and handoff rules.
• Implement feedback loops: Cadences like daily Kanban, replenishment, delivery planning, service review, and risk/operations reviews keep the system adaptive.
• Improve collaboratively, evolve experimentally: Use data, hypothesis-driven change, and small experiments (Kaizen) to refine the system.

Essential Concepts and Tools

• Kanban board: Columns represent states; cards represent work items; WIP limits appear at the top of columns; blockers are flagged; aging indicators show how long items sit in state.
• Classes of service: Different work types with distinct policies:
  • Expedite: Rare emergencies; preemptive capacity; strict WIP of 1.
  • Fixed Date: Must be delivered by a given date; schedule backward; prioritize appropriately.
  • Standard: Typical work; FIFO within column unless policy dictates otherwise.
  • Intangible: Tech debt/risk reduction; schedule capacity to avoid future disasters.
• Metrics:
  • Lead time: Time from customer commitment to delivery.
  • Cycle time: Time from “work started” to “done.”
  • WIP: Number of items in progress.
  • Throughput: Items completed per unit time.
  • Flow efficiency: Active work time ÷ total time.
  • Cumulative Flow Diagram (CFD): Visualizes WIP, throughput, and bottlenecks over time.
  • Aging chart: Highlights items aging beyond typical cycle time—early warning of risk.
• Little’s Law (intuitive version): Average WIP ≈ Throughput × Lead Time. If you want shorter lead times at a given throughput, you must lower average WIP—or increase throughput by removing bottlenecks. This is the economic rationale for WIP limits.
• Service Level Expectation (SLE): A probabilistic promise, e.g., “85% of standard items complete within 8 days,” derived from recent data; more useful than deterministic dates.

4. When to Use the Kanban Method

Most helpful when:

• Work arrives continuously and variably: support, maintenance, data/analytics requests, marketing ops, HR services, compliance reviews, infrastructure/platform work.
• Teams face too much WIP, long queues, and unpredictable delivery; stakeholders want steadier flow and reliable lead times.
• You need to improve service without reorganizing or adopting new roles/time-boxes; you want to “start where you are.”
• Multiple teams/services must coordinate handoffs and capacity across a value stream (portfolio/flight levels Kanban).

Especially powerful: Alongside DevOps/continuous delivery; with incident/problem management; for shared services and platform teams serving multiple customers; for backlogs where priorities shift frequently.

Less suitable or potentially misleading:

• Large, single-shot projects with fixed scope and a mandated, inflexible date may be better managed with project controls (or combine Kanban at the team level with project milestones).
• As a “board only” visualization without WIP limits or explicit policies—this yields little improvement.
• When leadership demands full utilization over flow; Kanban optimizes for predictability and lead time, not keeping everyone 100% busy.

5. How to Apply the Kanban Method: Step‑by‑Step

1. Define the service and customers.

   Clarify what service you provide, to whom, and what “fitness for purpose” means (e.g., typical lead times, quality, availability). Identify the value stream boundaries (where work enters/leaves your team).

2. Map the workflow and visualize it.

   Sketch the current flow (e.g., Options → Ready → In Progress → Review/Testing → Deploy/Done). Add columns to your board accordingly. Include swimlanes if you serve multiple distinct request types or classes of service.

3. Make policies explicit.

   Document simple, visible rules:

   • Entry/exit criteria for each column (what qualifies an item to move).
   • Pull policy (who pulls next, from where, in what order—e.g., FIFO for Standard items; expedite rules).
   • Definition of Done; quality gates and automation required.
   • When to split/merge items; how to handle blockers.

   Post policies on the board; keep them short and testable.

4. Set WIP limits (and expect to tune them).

   Start with conservative limits (e.g., 1–2 items per person across shared stages, lower in review/testing). State limits at the top of each column (e.g., “In Progress: 6”). If you’re constantly at the limit, stop starting and finish; reduce limits if lead times are still long.

5. Establish cadences (feedback loops).

   Adopt minimal, effective rhythms:

   • Daily Kanban (10–15 min): Walk the board right-to-left; discuss flow, blockers, aging items, and what to finish today.
   • Replenishment (weekly or on-demand): Decide what to pull next into “Ready,” based on capacity and priorities.
   • Delivery planning (as needed): Coordinate upcoming releases, dependencies, and customers.
   • Service review (monthly): Review SLEs, lead-time distributions, demand mix, risks; adjust policies/WIP/skills.
   • Operations/risk review (cross-service): Address systemic bottlenecks across teams; align WIP across the value stream.
6. Measure flow and set expectations.

   Instrument the basics: lead time, cycle time, WIP, throughput, blocked time, flow efficiency. Establish SLEs (e.g., “85% of Standard items within 8 days”). Share CFDs and aging charts to focus improvement.

7. Manage demand and classes of service.

   Define which items qualify as Expedite (rare), Fixed Date, Standard, and Intangible. Allocate explicit capacity (e.g., 10–20%) to Intangibles (debt, risk) to avoid future emergencies. Use policies to protect flow.

8. Improve collaboratively; experiment.

   Run small experiments: lower WIP in testing to reduce rework; introduce pairing; automate a quality gate; change pull order to FIFO; implement swarming on aging items. Observe impact on lead time and predictability; keep what works.

9. Scale across services (if needed).

   For end-to-end products, implement Kanban at multiple levels (“flight levels”): team boards, service/stream boards, and a portfolio board. Align WIP and SLEs across the chain; address cross-team queues and policies.

6. Example: Kanban in Action

Context: A platform engineering team (12 people) supported 30 product squads with CI/CD, observability, and developer tooling. Demand was volatile; average lead time for Standard requests was 18 days with high variability; stakeholder satisfaction lagged. The team adopted the Kanban method.

Application:

• Service definition: Customer = product squads. Fitness = reliable SLEs for Standard (≤10 days for 85% of items), Expedite policy for rare incidents, and a quarterly roadmap for Fixed Date changes (security deadlines).
• Visualization: Board columns: Options → Ready → Dev → Review/Test → Deploy → Done. Swimlanes: Standard, Fixed Date, Expedite, Intangible.
• Policies: FIFO within Standard; expedite allowed only for P1 production incidents (max WIP 1); weekly replenishment with reps from two major squads.
• WIP limits: Ready 10; Dev 6; Review/Test 4; Deploy 2. Reserve 20% capacity for Intangibles (automation, debt).
• Cadences: Daily Kanban; weekly replenishment; monthly service review with SLEs and CFD trends; cross-service ops review with Security and SRE.

Outcomes (10 weeks): Median lead time fell from 12 to 6 days; 85th percentile lead time dropped from 24 to 10 days; throughput increased 22% with lower WIP; Expedites decreased by half due to visible capacity for Intangibles; blocked time fell 30% after automating a test gate. Stakeholder NPS rose from −8 to +21. The approach was extended to data ops and marketing ops teams.

7. Strengths and Limitations

Strengths

• Start where you are: No role changes or time‑boxes required; Kanban overlays your current process.
• Predictability and speed: WIP limits shorten queues; SLEs and CFDs make delivery reliable.
• Low overhead: Minimal ceremonies; continuous flow fits teams with incoming requests.
• Scales across services: Works from single teams to multi‑team value streams and portfolios.
• Data‑driven improvement: Simple metrics expose bottlenecks and guide targeted experiments.

Limitations

• Discipline required: Without real WIP limits and explicit policies, it degenerates into a “pretty board.”
• Change of mindset: Leaders must value flow and predictability over perceived utilization.
• Not a planning substitute: Strategic prioritization and discovery still matter; Kanban optimizes delivery, not what to build.
• Coordination complexity: Cross-team queues and dependencies need portfolio‑level Kanban and ownership to resolve.

8. Common Pitfalls (and How to Avoid Them)

• No WIP limits.
  What goes wrong: Multitasking and long queues persist; no predictability gains.
  Avoid by: Setting and enforcing per‑column WIP limits; tune based on lead-time data.
• Personal swimlanes.
  What goes wrong: Local optimization; reduced collaboration; longer queues.
  Avoid by: Organizing lanes by class of service/work type; swarm on blocked/aging items.
• Push instead of pull.
  What goes wrong: Upstream pushes overload downstream; bottlenecks grow.
  Avoid by: Pulling work only when WIP allows; enforce entry/exit criteria and FIFO policies.
• Ignoring demand mix.
  What goes wrong: Expedites crowd out standard work; dates slip.
  Avoid by: Strict expedite policy; capacity allocation for Fixed Date and Intangibles.
• No metrics, no learning.
  What goes wrong: Improvements are opinion-driven; little sustainability.
  Avoid by: Tracking lead time, throughput, WIP, blocked time, and using CFDs and aging charts in reviews.
• Overfocus on utilization.
  What goes wrong: Work piles up; lead times explode.
  Avoid by: Managing to SLEs and lead time; use Little’s Law to explain why lower WIP yields faster delivery.
• Unclear policies.
  What goes wrong: Thrash and negotiation at every handoff.
  Avoid by: Posting concise, testable policies at the board; revise in monthly service reviews.
• Local optimization only.
  What goes wrong: Team improves but system lead time stays long.
  Avoid by: Adding portfolio/service-level Kanban to manage cross-team WIP and dependencies.

9. How Kanban Relates to Other Frameworks

• Scrum: Scrum uses time-boxed Sprints and defined roles/events; Kanban uses continuous flow and WIP limits. Many teams blend them (“Scrumban”): keep Sprint Planning/Retros, manage day‑to‑day flow with Kanban policies and metrics.
• Lean & Theory of Constraints: Kanban operationalizes Lean flow and bottleneck focus for knowledge work.
• DevOps/Continuous Delivery: Kanban’s flow metrics and WIP limits pair naturally with CI/CD and error budgets; both target fast, reliable delivery.
• Design Thinking/Discovery: Use discovery to prioritize the right work; deliver via Kanban for flow and predictability.
• OKRs: OKRs define outcomes; Kanban ensures steady delivery toward them; SLEs can be health metrics supporting OKRs.
• Portfolio/Flight Levels Kanban: Coordinates strategy and execution across multiple teams and services; aligns WIP with capacity and strategic priorities.
• SAFe/Scaled Agile: SAFe’s Kanban systems (portfolio/program/team) are specific scaling instantiations; Kanban can be applied with or without SAFe.

10. Key Takeaways

• Kanban improves delivery by visualizing work, limiting WIP, managing flow with simple metrics, making policies explicit, and installing feedback loops.
• Start where you are; don’t reorg. Define your service, map the workflow, set WIP limits, and learn from data.
• Focus on lead time and predictability; use SLEs, CFDs, and aging charts to drive decisions and improvement.
• Classes of service and capacity allocation protect flow from emergencies, deadlines, and debt.
• Scale Kanban across teams and portfolios to manage cross-team WIP and dependencies—optimize the system, not just a team.

11. FAQs About the Kanban Method

How is Kanban different from Scrum?
Scrum uses fixed-length Sprints, defined roles, and regular planning/review events. Kanban is continuous flow with explicit WIP limits and policies; no roles or time‑boxes are required. Choose Scrum for product teams needing cadence and goals; Kanban for services/ops with continuous demand—or blend them.

How do we set initial WIP limits?
Start small: roughly one item per person across shared stages, then tune using lead-time data. If items age or queues form, lower WIP or add capacity at the bottleneck. The aim is smooth flow and predictable SLEs, not keeping everyone “busy.”

Do we still need estimates?
Not necessarily. Many Kanban teams use historical flow (throughput, lead-time distributions) for probabilistic forecasts (e.g., Monte Carlo) instead of story points. If estimates help conversations, keep them lightweight and optional.

Can Kanban work for remote/distributed teams?
Yes. Use an online board, visible WIP limits, blocker tags, and aging indicators. Keep a short daily Kanban, share CFDs/aging charts, and maintain clear policies. Core overlap hours help with pull decisions and swarming.

What metrics should we track?
Lead time (including distribution), cycle time, WIP, throughput, blocked time, flow efficiency, SLE adherence, and cumulative flow. Use trends and distributions, not single averages, to manage predictability.

What is “Scrumban”?
A pragmatic blend: keep Scrum’s cadence (e.g., Sprint Planning, Reviews, Retros) while managing day‑to‑day flow with Kanban (WIP limits, pull policies, CFDs). Useful for product teams that want the focus of Sprints and the flow control of Kanban.

How long does it take to see results?
Often within 4–8 weeks: once WIP limits and policies are in place and you act on blockers and bottlenecks, lead times shorten and predictability improves. Deeper systemic gains (cross-team WIP, automation) take a few quarters.

Can non‑tech teams use Kanban?
Absolutely—marketing ops, legal, HR shared services, procurement, finance close, and clinical operations routinely benefit. Map the real workflow, set WIP limits, and measure lead time/SLEs.

Do we need special tools?
No. A physical board works co‑located; digital boards (Jira, Trello, Azure Boards, ClickUp, etc.) work well remotely. Choose tools that support WIP limits, aging, CFDs, and policies; avoid over‑automating before policies are clear.

What if stakeholders want more expedites?
Limit expedites with a strict policy and capacity reservation. Frequent expedites signal upstream planning or quality issues—fix root causes. Without discipline, expedites destroy predictability for everyone.

How does Kanban handle deadlines?
Use the Fixed Date class of service. Agree the due date, schedule backward, ensure capacity, and manage WIP to protect delivery. Track lead-time data to set realistic SLEs and negotiate informed commitments.