Kanban

Kanban is a visual workflow management method that helps teams optimize their work process by limiting work in progress, visualizing workflow, and focusing on continuous delivery. Originally developed by Taiichi Ohno at Toyota in the 1940s for manufacturing, it was adapted for software development by David Anderson in the mid-2000s. Unlike Scrum with its fixed sprints and prescribed roles, Kanban is less prescriptive and focuses on evolutionary improvement to existing processes.

Origins and Philosophy

The word "kanban" is Japanese for "visual signal" or "card." In Toyota's production system, physical cards signaled when new materials should be produced or moved through the factory. The key insight was revolutionary: instead of pushing work through the system based on forecasts, let downstream demand pull work through. This eliminated overproduction, reduced inventory, and exposed bottlenecks.

David Anderson recognized that software development suffered from similar problems — teams taking on too much work simultaneously, invisible bottlenecks, and unpredictable delivery. He formulated the Kanban Method for knowledge work, which has since been adopted by thousands of software teams worldwide.

Core Principles of Kanban

Start with what you do now. Kanban does not require a dramatic reorganization. You begin by mapping your current workflow, making it visible, and then incrementally improving it. This makes adoption far less disruptive than switching to an entirely new framework.

Agree to pursue incremental, evolutionary change. Rather than revolutionary transformations that create resistance, Kanban encourages small, continuous improvements that compound over time.

Respect the current process, roles, and responsibilities. Kanban does not mandate specific roles like Scrum does. Existing job titles, responsibilities, and reporting structures remain intact initially.

Encourage acts of leadership at all levels. Improvement ideas should come from everyone on the team, not just managers. The person doing the work often has the best insight into how it can be improved.

The Kanban Board

The Kanban board is the central artifact — a visual representation of work flowing through stages. A basic software development board might have these columns:

Each card represents a work item (feature, bug fix, task). As work progresses, cards move from left to right. The board immediately reveals the state of all work, who is working on what, and where bottlenecks exist. If the "Code Review" column is consistently full while "Testing" is empty, the team knows reviewers are overloaded.

Work-In-Progress (WIP) Limits

WIP limits are the defining feature that distinguishes Kanban from a simple task board. Each column has a maximum number of items allowed simultaneously. When a column reaches its limit, no new work can enter until something moves out.

Why does this matter? Consider a developer juggling five tasks simultaneously. Context-switching between them wastes time (studies show up to forty percent of productive time is lost to context-switching). Each task takes longer because attention is fragmented. With a WIP limit of two, that developer focuses deeply on fewer items and completes them faster.

WIP limits also create a "pull system." When a developer finishes a task and has capacity, they pull the next highest-priority item from the preceding column. This ensures work flows smoothly rather than accumulating in queues.

Kanban Metrics

Lead Time: The total time from when a work item is requested to when it is delivered. This measures the customer's experience — how long they wait for their request to be fulfilled.

Cycle Time: The time from when work actually begins on an item to when it is completed. This measures the team's processing efficiency.

Throughput: The number of items completed per unit of time (typically per week). This indicates the team's delivery capacity.

Cumulative Flow Diagram (CFD): A stacked area chart showing how many items are in each stage over time. A healthy CFD shows parallel bands of consistent width. Widening bands indicate growing queues and potential problems.

Kanban vs. Scrum

Implementing Kanban: A Real-World Example

A support team handling production incidents and feature requests implemented Kanban because their work was too unpredictable for fixed sprints. They started by mapping their existing workflow: Triage, Investigation, Fix Development, Peer Review, QA Verification, and Deployment. They set initial WIP limits of three for Investigation and two for Fix Development.

Within weeks, they discovered that peer reviews were creating a bottleneck. Items piled up waiting for review while developers focused on new fixes. By making this visible, the team agreed that anyone who finishes a fix must first review someone else's work before pulling new items. This simple policy change reduced average lead time from twelve days to five days.

Classes of Service

Kanban recognizes that not all work items have the same urgency. Classes of service define different priority levels with different handling policies:

• Expedite: Critical items (production outages) that bypass WIP limits and get immediate attention. The "fast lane" of the board.
• Fixed Date: Items with external deadlines (regulatory compliance, contractual obligations). Must be started early enough to meet the deadline.
• Standard: Normal work items processed in priority order within WIP limits.
• Intangible: Technical debt, refactoring, and improvements with no immediate customer impact but long-term importance.

Interview Q&A

Q: What are WIP limits and why are they important? A: WIP (Work In Progress) limits cap the number of items allowed in each workflow stage simultaneously. They prevent overloading, reduce context-switching, expose bottlenecks, create a pull-based system, and ultimately reduce lead time by ensuring items flow through the system rather than accumulating in queues.

Q: When would you choose Kanban over Scrum? A: Kanban is preferable when work is highly variable and unpredictable (like support teams), when you cannot commit to fixed sprint scopes, when the team handles multiple work types with different priorities, or when you want to improve an existing process without disrupting it entirely.

Q: How do you determine appropriate WIP limits? A: Start with a simple heuristic: number of team members working on that stage, plus one buffer item. Observe the flow for several weeks, then adjust. If a column is always full and the next column starves, the limit might be too high. If people are frequently idle waiting for work, the limit might be too low.