Kanban

1. What Is Kanban?

Kanban is a lightweight, visual framework for managing work as a flow of value. It helps teams and organizations deliver faster and more predictably by limiting work-in-progress (WIP), visualizing the end-to-end workflow, and continuously improving how work moves from request to done.

Within Agile & Iterative Delivery, Kanban is a delivery and operations framework. It does not prescribe roles or timeboxes; instead, it introduces a pull-based system where teams start new work only when they have capacity, making bottlenecks visible and reducing context switching. Consultants and executives use Kanban because it is simple to start, easy to scale, and compatible with existing processes—often yielding substantial improvements in lead time, quality, and predictability without reorganization.

Kanban (Japanese for “signboard” or “visual card”) centers on three ideas: visualize work to create shared reality, limit concurrent work to improve flow, and use data to manage and improve performance. It is as effective for software and digital operations as it is for marketing, finance, HR, and shared services.

2. Origin and Background

Kanban originated in manufacturing within the Toyota Production System (TPS), primarily associated with Taiichi Ohno and colleagues in the 1950s–1960s. Physical Kanban cards and boards signaled demand and controlled inventory, enabling just-in-time (JIT) production and exposing process constraints.

In the late 2000s, Kanban was adapted to knowledge work—most prominently by David J. Anderson—translating pull signals, WIP limits, and flow management into software development and service delivery contexts. The approach spread quickly through lean/Agile communities, consulting practices, and training programs, largely due to its pragmatism: “start with what you do now,” visualize it, then improve incrementally.

Today, Kanban is widely used across industries and functions. It is often paired with DevOps, Scrum, ITSM, and OKRs to connect day-to-day flow with strategic outcomes.

3. How Kanban Works

Kanban turns invisible work into a managed flow. A team maps its workflow, visualizes items on a board, constrains WIP at each step, and manages to flow metrics (lead time, throughput, aging). Regular feedback loops drive improvement.

Core principles

• Start with what you do now: No wholesale reorganization. Make the current workflow visible and manage it.
• Agree to pursue incremental, evolutionary change: Improve through small, low-risk experiments rather than big-bang transformations.
• Respect current roles, responsibilities, and titles: Kanban overlays existing structures; it doesn’t mandate new roles.
• Encourage leadership at all levels: Anyone can suggest improvements; decisions are data-informed and collaborative.

Foundational practices

• Visualize the workflow: Build a Kanban board with columns that reflect the steps from request to completion (e.g., “Requested → Analysis → In Progress → Review/Testing → Done”). Include swimlanes for different classes of work if helpful.
• Limit work-in-progress (WIP): Set explicit WIP limits for columns or swimlanes to reduce multitasking and expose constraints. New work enters only when WIP is below the limit—this is the pull mechanism.
• Manage flow: Monitor how work moves through the system; aim for smooth, predictable flow. Respond quickly to blockers, imbalances, or aging items.
• Make policies explicit: Define entry/exit criteria for each column, service classes (e.g., standard vs. expedite), prioritization rules, and defect-handling policies so everyone plays by the same rules.
• Establish fast feedback loops: Use short, regular meetings (e.g., Daily Kanban, Replenishment, Service Delivery Review) to inspect flow, make decisions, and adapt.
• Improve collaboratively, evolve experimentally: Use data and small experiments (A/B of WIP limits, process tweaks) to optimize throughput, lead time, and quality.

Key concepts and tools

• Classes of Service: Guidelines for how different work types are handled. Common classes include:
  • Standard: normal priority, first-in-first-out (FIFO).
  • Fixed Date: must complete by a certain date; schedule backward and protect capacity.
  • Expedite: urgent, pre-emptive; tightly controlled to avoid abuse.
  • Intangible: maintenance/improvement items that prevent future risk or cost.
• Flow metrics:
  • Lead time: elapsed time from request to completion (customer perspective).
  • Cycle time: time from start of active work to completion (team perspective).
  • Throughput: number of items completed per unit time.
  • Work-in-progress (WIP): number of items currently in the system.

  These metrics are linked by a simple law of flow: on average, the number of items in progress ≈ arrival rate × average time in system (Little’s Law). In plain terms: if you want faster delivery at steady demand, you must reduce WIP.

• Visualization aids: Cumulative Flow Diagram (CFD) to spot bottlenecks; aging charts to identify items stuck too long; scatter plots of cycle time to forecast service levels.

Cadences (lightweight governance)

• Daily Kanban: 10–15 minutes at the board, focusing on flow (aging, blockers, WIP imbalances), not individual status.
• Replenishment (1–2x/week): Decide what new items to pull into the system based on capacity, classes of service, and priorities.
• Service Delivery Review (biweekly/monthly): Review performance (SLE adherence, lead time, quality), discuss risks, and agree improvements.
• Operations Review (monthly/quarterly): Cross-team/system-level review to balance demand and capacity across services and value streams.

4. When to Use Kanban

Especially powerful when

• Work is continuous and demand varies: Operations, support, DevOps, shared services, compliance, and marketing/content teams with ongoing intake.
• You need predictability without heavy process: Stakeholders care about reliable lead times; teams want minimal ceremony.
• Multiple work types and urgencies: Managing standard flow alongside fixed-date commitments and occasional expedites.
• You want to improve without reorganization: Kanban overlays current structures; it’s an evolution, not a reset.
• Scaling across functions: Coordinating flow across product, operations, and enabling teams using visual portfolios and consistent metrics.

Less suitable or requiring adaptation

• Highly projectized, date-certain initiatives with complex networks: Use Kanban for team flow but complement with Critical Path/Program governance at the initiative level.
• Pure discovery with ill-defined work items: Start with design thinking/lean discovery to shape work into minimal slices; then flow it through Kanban.
• Teams lacking basic quality practices: Kanban exposes problems; without test automation or basic engineering hygiene, lead times can worsen before improving.

Data and time requirements

• Data: A clear workflow map, item definitions (entry/exit criteria), WIP limits, and simple flow metrics (lead time, throughput). Most can be captured from existing tools.
• Time: A workable board and initial WIP limits can be in place in 1–2 weeks. Meaningful improvements in predictability often appear within 4–8 weeks; cultural and system-level gains compound over 3–6 months.

Kanban remains powerful today, particularly when paired with DevOps and product management, and when applied beyond software to enterprise services and operations.

5. How to Apply Kanban: Step-by-Step

1. Map the workflow from request to done

   Run a short workshop with the team to diagram the current process. Identify key states (e.g., triage, analysis, in progress, review/testing, deploy, done) and common sources of delay (handoffs, approvals). Keep it simple; aim for a board you will actually use.

2. Define item types and policies

   Agree on work item types (features, defects, support requests, maintenance) and classes of service (standard, fixed date, expedite, intangible). Make entry/exit criteria explicit for each column. Decide how items are prioritized (e.g., FIFO within class) and when you can bypass rules (e.g., strict thresholds on expedites).

3. Set initial WIP limits

   Pick conservative WIP limits for each column or swimlane (e.g., current average WIP minus 20%). The goal is to expose constraints and reduce multitasking. These limits are hypotheses; expect to adjust them based on data and team feedback.

4. Stand up the board and visualize everything

   Create a physical or digital board. Represent each item as a card with owner(s), class of service, due date (if any), and blockers. Add visual cues: blockers (red tags), aging (background color by age), and swimlanes if multiple service classes share the board.

5. Establish the Kanban cadence

   Schedule a Daily Kanban to review aging and blockers; a Replenishment meeting to select new items; and a Service Delivery Review to look at performance and agree improvements. Keep meetings short, focused on flow, and data-informed.

6. Instrument flow metrics

   Start measuring lead time, cycle time, throughput, WIP, and block time. Use a Cumulative Flow Diagram to spot bottlenecks. Publish a simple dashboard visible to the team and stakeholders—transparency builds trust.

7. Manage demand against capacity

   Balance intake with actual throughput. Set explicit intake policies (e.g., intake freeze when WIP breaches limits, or a maximum “Requested” queue size). For fixed-date work, schedule backward and reserve capacity; keep expedites rare and audited.

8. Triage blockers and aging items aggressively

   Visualize blocked items prominently. Assign owners and escalation paths. Track aging against your typical lead-time distribution; intervene early on items exceeding expected age for their stage.

9. Set a Service Level Expectation (SLE)

   Once you have a few weeks of data, establish an SLE (e.g., “85% of standard items complete within 8 working days”). Use scatter plots of cycle time to set and refine SLEs. Communicate SLEs to stakeholders to set realistic expectations.

10. Run improvement experiments

    Choose one bottleneck at a time and experiment: adjust WIP limits, add explicit policies (e.g., “swarm when any column exceeds WIP”), change batch size (break big items down), or re-sequence steps. Measure before/after; keep what works.

11. Scale across services and teams

    When multiple teams interact, create an upstream/downstream view or a portfolio Kanban. Align classes of service and SLEs across teams; use an Operations Review to manage cross-system flow and capacity.

12. Sustain with leadership and incentives

    Reinforce flow-based objectives (predictability, lead time, quality) rather than output-only targets. Recognize behaviors that improve flow (e.g., swarming, reducing handoffs). Keep policies visible and current.

6. Example: Kanban in Action

Context: A global fintech’s onboarding and compliance function (120 people across product, engineering, risk, and operations) struggles to deliver regulatory changes and customer onboarding improvements. Lead times average 28 working days with large variability; stakeholders complain about unpredictability and excessive “urgent” requests.

Problem: Work arrives from many channels; teams start too much in parallel; handoffs between product, engineering, and compliance create queues. Expedite requests are common, further destabilizing flow.

Applying Kanban:

• Workflow visualization: The group maps a shared workflow: Intake → Triage → Analysis → Build → Review/Testing → Compliance Approval → Deploy → Done. Entry/exit criteria are defined; compliance creates a dedicated “Compliance Review” column with its own WIP limit.
• WIP limits: Initial limits: Analysis (12), Build (20), Review/Testing (10), Compliance Review (6). A policy requires swarming on the most aged items when a column breaches its limit.
• Classes of Service: Standard (FIFO), Fixed Date (regulatory), Expedite (strict cap of 1 system-wide, with CFO approval), Intangible (tech debt and automation).
• Cadence and SLEs: Replenishment twice a week; Daily Kanban per team; monthly Service Delivery Review. After four weeks, data shows a median cycle time of 12 days for standard items; an SLE is set: “85% within 15 working days.”
• Improvements: Analysis and Compliance Review are the main bottlenecks. They pilot paired analysis (product + compliance) and introduce automated pre-checks. WIP in Build is reduced from 20 to 14 to cut context switching; item size is constrained to “finish within 5–7 days,” with larger items split.

Outcomes (12 weeks):

• Average lead time drops from 28 to 15 working days; 85th percentile falls from 48 to 22 days.
• Throughput stabilizes at 38–42 items/week versus 25–30 prior, with less variability.
• Expedite usage decreases by 70% after introducing a strict cap and visible audit.
• Stakeholder satisfaction improves (on-time delivery for fixed-date regulatory items rises from 68% to 96%).
• Defect escape rate in production down 35% due to explicit “Definition of Done” and reduced multitasking.

7. Strengths and Limitations

Strengths

• Fast to start, minimal disruption: Overlay on current processes; improvements begin within weeks.
• Predictability through flow control: WIP limits and SLEs make delivery more reliable without heavy ceremony.
• Transparency and alignment: Visual boards, explicit policies, and shared metrics reduce friction and subjective debates.
• Scales across functions: Portfolio and service-level Kanban align multiple teams and services using a common language of flow.
• Data-driven continuous improvement: Simple, powerful metrics (lead time, throughput, aging) guide practical change.

Limitations

• Exposure of hidden problems: Initially, bottlenecks and quality gaps become painfully visible; leadership must support fixing them, not blame teams.
• Not a full product management system: Kanban governs flow; you still need strategy, discovery, and prioritization practices (e.g., OKRs, discovery/UX).
• Requires discipline to enforce WIP: Without adherence to limits and policies, benefits erode and boards become status theater.
• Complex projects need complementary tools: For interdependent, date-certain initiatives, use Kanban alongside program planning (CPM, PI planning) to manage milestones and dependencies.

8. Common Pitfalls (and How to Avoid Them)

• Board without WIP limits

  What goes wrong: The board becomes a dashboard of chaos; multitasking persists; no flow improvement.

  How to avoid: Set and enforce WIP limits from day one; adjust based on data, not comfort.

• Too many expedites

  What goes wrong: Expedites pre-empt everything; standard flow suffers; unpredictability spikes.

  How to avoid: Cap expedites (system-wide limit of one), require senior approval, and track cause to remove upstream issues.

• Vague entry/exit criteria

  What goes wrong: Rework and backflows increase; “done” is subjective.

  How to avoid: Define clear policies per column (Definition of Ready/Done); audit compliance in reviews.

• Ignoring aging and blockers

  What goes wrong: Items stall; lead time tails grow; stakeholders lose trust.

  How to avoid: Use aging charts and blocker tags; swarm on oldest items first; escalate promptly.

• Excessive batching and large items

  What goes wrong: Long, variable lead times; high rework; missed dates.

  How to avoid: Slice items to deliver in days, not weeks; set size policies; separate spikes/exploration from delivery items.

• Unbalanced demand and capacity

  What goes wrong: Intake overwhelms the system; WIP spikes; morale falls.

  How to avoid: Institute an intake policy and Replenishment cadence; throttle demand based on throughput and WIP.

• Metric misuse (e.g., gamed throughput)

  What goes wrong: Teams slice unhelpfully or prioritize easy work to “look good.”

  How to avoid: Pair metrics (lead time + quality + customer outcomes); focus on trends and predictability, not single numbers.

• Static process—no experiments

  What goes wrong: Initial gains plateau; systemic issues persist.

  How to avoid: Run regular improvement experiments; time-box, measure, and adopt/abandon based on evidence.

9. How Kanban Relates to Other Frameworks

• Scrum: Scrum uses timeboxed Sprints and prescriptive roles/events. Kanban uses continuous flow with minimal prescription. Many teams blend them (“Scrumban”): maintain Sprint cadence for planning/review while limiting WIP and managing flow via Kanban.
• DevOps and Continuous Delivery: Highly complementary. Kanban stabilizes flow; DevOps automates build/test/deploy, reducing lead time and variability.
• Lean and Theory of Constraints (ToC): Kanban operationalizes lean flow (reduce waste, unevenness) and ToC (identify and elevate constraints) in day-to-day work management.
• SAFe/LeSS/Nexus (scaled agile): Most scaling frameworks incorporate Kanban at team and portfolio levels to visualize and limit WIP, manage dependencies, and align cadence.
• ITSM (e.g., ITIL): Incident, problem, and change workflows benefit from Kanban’s visualization and WIP limits; classes of service map naturally to urgency and priority.
• OKRs and product strategy: Use OKRs to set outcomes; use Kanban to flow the work that delivers them. Review flow metrics alongside OKR progress in governance forums.
• CPM/PERT/EVM: For projectized, date-driven work, use CPM/PERT/EVM for planning and portfolio control, while teams deliver day-to-day via Kanban to maintain flow and predictability.

10. Key Takeaways

• Kanban improves delivery speed and predictability by visualizing work, limiting WIP, and managing flow with simple, actionable metrics.
• It overlays existing processes—no big-bang changes—making it fast to adopt and easy to scale across functions.
• Success hinges on explicit policies, disciplined WIP limits, attention to aging/blockers, and small, data-driven experiments.
• Kanban pairs naturally with DevOps, product management, and portfolio governance—and complements Scrum when a cadence is useful.
• Beware boards without WIP limits, excessive expedites, and vague policies; these erode flow and trust.

11. FAQs About Kanban

Is Kanban only for support and operations teams?
No. While it shines in continuous flow environments (support, DevOps, shared services), product development, marketing, finance, and compliance teams also benefit—especially when work arrives steadily and priorities shift.

How is Kanban different from Scrum?
Scrum uses fixed-length Sprints and defined roles/events; Kanban uses continuous flow and minimal prescription. Kanban emphasizes WIP limits and flow metrics over timeboxes. Many teams blend them: maintain Sprint planning/review while managing flow via Kanban.

How do we set WIP limits?
Start with current average WIP per stage and reduce by 10–30% to expose constraints. Adjust based on data (aging, throughput) and team feedback. If items frequently wait, limits may be too high; if idle time rises or bottlenecks shift dramatically, recalibrate.

How long until we see results?
You can visualize and limit WIP within 1–2 weeks. Predictability and lead-time improvements typically appear within 4–8 weeks as policies stabilize and bottlenecks are addressed. System-level gains (fewer expedites, higher quality) accrue over a quarter or two.

Can we use Kanban at the portfolio level?
Yes. Portfolio Kanban visualizes initiatives (not tasks), limits concurrent bets, and aligns capacity with strategy. It improves cross-team predictability and exposes systemic constraints (e.g., shared functions, approvals).

Do we need special tools?
No. A wall and sticky notes work to start. Most teams adopt digital boards integrated with source control, CI/CD, and ticketing systems to automate metrics and improve transparency—choose tools that keep policies and flow data visible.