Kanban

Kanban is a visual system for managing work as it moves through a process. Originating from Toyota's manufacturing practices in the 1940s, it has evolved into one of the most widely adopted methodologies in software development and product management. The word "kanban" translates to "visual signal" or "card" in Japanese, reflecting the method's core principle: making work visible to improve flow and efficiency.

Why it matters

Traditional project management often hides the reality of how work actually flows through a team. Tasks pile up in invisible queues, bottlenecks go unnoticed until deadlines loom, and teams struggle to answer the simple question "what should I work on next?" Kanban addresses these problems by making work visible and establishing clear rules for how work moves through the system.

For product managers, Kanban provides real-time insight into team capacity and delivery flow. Instead of planning in rigid iterations, you can respond to changing priorities while maintaining predictable delivery. The method reveals where work gets stuck, enabling data-driven conversations about process improvement rather than finger-pointing when deadlines slip.

Core principles

Kanban rests on four foundational principles that distinguish it from other methodologies.

Start with what you do now. Kanban doesn't prescribe a specific process or organizational structure. It overlays on your existing workflow, making it easier to adopt than methods that require wholesale process change. This respect for current roles and responsibilities reduces resistance and enables gradual improvement.

Agree to pursue incremental, evolutionary change. Rather than revolutionary transformation, Kanban encourages small, continuous improvements. This approach reduces risk and allows teams to learn what works in their specific context.

Respect the current process, roles, and responsibilities. Kanban recognizes that existing processes often contain valuable institutional knowledge. Instead of discarding everything, it provides tools to identify and address specific problems.

Encourage acts of leadership at all levels. Improvement isn't solely management's responsibility. Everyone who sees an opportunity to improve the process should feel empowered to suggest and implement changes.

The kanban board

The most recognizable element of Kanban is the board - a visual representation of work flowing through defined stages. A basic board includes three columns: To Do, In Progress, and Done. Most teams customize their boards to reflect their actual workflow.

A typical product development board might include:

Each work item is represented by a card that moves across the board as it progresses. The board provides immediate visibility into what's happening: where work is accumulating, what's blocked, and how much capacity remains.

Work-in-progress limits

The most powerful - and often most challenging - aspect of Kanban is limiting work-in-progress (WIP). Each column on the board has a maximum number of items it can contain. When a column reaches its limit, no new work can enter until something moves out.

WIP limits force teams to finish work before starting new work. This sounds obvious, but most teams naturally accumulate too much work-in-progress, leading to:

Setting appropriate WIP limits requires experimentation. Start conservatively - if a column's limit feels comfortable, it's probably too high. The right limits create productive tension that surfaces problems and drives improvement.

Key metrics

Kanban uses specific metrics to measure and improve flow.

Lead time measures how long it takes from when a request is made until it's delivered. This is what customers care about - how long they wait for value.

Cycle time measures how long it takes from when work begins until it's complete. The difference between lead time and cycle time reveals how long items wait before work starts.

Throughput counts how many items are completed in a given time period. This metric helps teams understand their capacity and make realistic commitments.

Cumulative flow diagrams visualize how work accumulates and moves through the system over time. The shape of the diagram reveals bottlenecks, variability, and trends.

Kanban vs. scrum

Both Kanban and Scrum fall under the agile umbrella, but they take different approaches.

Many teams blend elements of both approaches, using Scrum's structure for planning while applying Kanban's WIP limits and flow metrics. This hybrid, sometimes called "Scrumban," takes useful practices from each method.

Implementing kanban

Starting with Kanban requires less organizational change than most methodologies, but it still demands discipline.

Map your current workflow. Before creating a board, understand how work actually flows through your team. Interview team members, trace recent projects through the system, and identify where handoffs occur. The board should reflect reality, not an idealized process.

Make work visible. Get all current work onto the board. This often reveals surprising amounts of hidden work-in-progress. Don't clean it up yet - visibility is the first step to improvement.

Establish initial WIP limits. Start by measuring current WIP in each stage, then set limits slightly below that level. The goal is to create enough constraint to surface problems without paralyzing the team.

Manage flow, not people. Focus conversations on how work moves through the system rather than who's doing what. This shift from resource management to flow management changes team dynamics and improves outcomes.

Improve collaboratively. Use the data the system generates to drive improvement discussions. When bottlenecks appear, involve the team in identifying root causes and experimenting with solutions.

Common pitfalls

Teams new to Kanban often stumble in predictable ways.

Treating the board as a status report misses the point. The board isn't for management oversight - it's a tool for the team to manage their own work and identify improvements.

Setting WIP limits too high removes the productive tension that drives improvement. If limits never cause anyone to pause and help clear a bottleneck, they're not doing their job.

Ignoring blockers undermines the entire system. When items get stuck, they need immediate attention. A culture that tolerates blocked items for days or weeks won't see Kanban's benefits.

Skipping the metrics means flying blind. Without lead time, cycle time, and throughput data, you can't tell if changes improve flow or just feel different.

When to use kanban

Kanban works well in environments with variable workloads and frequent priority changes. Support teams, maintenance work, and operations teams often find it more suitable than sprint-based methods. Product teams use it effectively for continuous delivery environments where waiting for sprint boundaries adds unnecessary delay.

Kanban may be less suitable for teams that need predictable delivery dates for large features, or organizations that require the structure of defined iterations for planning purposes. In these cases, Scrum or a hybrid approach might serve better.

The choice ultimately depends on your context. Kanban's strength is its adaptability - it meets you where you are and provides tools to improve from there, one small change at a time.