Kanban
Visualize, limit, streamline. The Kanban method transforms your workflow into a predictable pipeline, from Toyota in the 1940s to your product board.
Description
Kanban is a visual work management system that uses boards and cards to represent tasks, limits work in progress (WIP), and optimizes delivery flow through continuous improvement. Created by Taiichi Ohno at Toyota in the late 1940s, then adapted to software development by David J. Anderson at Microsoft in 2004, its purpose is to make the invisible visible: the bottlenecks, overload, and waste that slow down your deliveries. Your team is working on twelve topics in parallel, finishing few things, and shipping even fewer. Everyone is busy, nobody is making progress. That is the paradox Kanban solves with a counterintuitive principle: ship faster by doing fewer things at once. Like a restaurant that refuses to take twenty simultaneous orders because the kitchen can only handle eight properly, the Kanban board makes the team's real capacity visible and forces respect for its limits. The core mechanism is the WIP limit (work-in-progress limit), which caps the number of tasks allowed in each column. When a column is full, nobody adds work until an item moves out. This simple mechanism, formalized by Little's Law (cycle time = work in progress divided by throughput), mathematically demonstrates that reducing WIP reduces cycle time. David J. Anderson codified these principles in his book Kanban: Successful Evolutionary Change for Your Technology Business (2010), laying the foundations of agile Kanban as practiced today. Unlike Scrum, which mandates sprints, roles, and ceremonies, the Kanban system adapts to your existing processes without organizational revolution. You start where you are, visualize what you do, and improve incrementally.
Objectives
- Prioritize work
- Structure development
- Improve team collaboration
Used by
- -Toyota (creator of the original Kanban system in the 1940s, integrated into Taiichi Ohno's Toyota Production System)
- -Microsoft (first application of Kanban to software development by David J. Anderson in 2004)
- -Spotify (uses Kanban in its squads to manage the continuous delivery flow)
Advantages
- Start without disruption. Kanban applies to your existing processes without reorganization, unlike Scrum which requires sprints and defined roles.
- Measurable predictability. Cycle time and throughput replace subjective estimates with data. At Vanguard, teams multiplied their throughput by 4 after adopting Kanban.
- Reduced bottlenecks. WIP limits force the team to finish before starting, eliminating unproductive multitasking.
- Total flexibility. No rigid sprints. Priorities change? You reorganize the backlog without waiting for the end of a cycle.
Limitations
- No built-in planning cadence. Without sprints, long-term planning relies on your discipline. If you need cadence, combine Kanban with periodic reviews.
- Risk of complacency. Without sprint goal commitments, the team can slow down without realizing it. Monitor throughput as an alert indicator.
- Less structured for junior teams. Scrum provides a more directive framework (roles, ceremonies, sprints). Kanban requires autonomy and maturity.
- Does not manage cross-team dependencies. If your tasks depend on other teams, the Kanban board alone is not enough. Look at SAFe or Program Boards.
How to apply Kanban
- 1
Map your current workflow
Draw the actual steps a task goes through, from idea to delivery. Do not create an ideal process, document what exists. Common examples: Backlog, To Do, In Progress, In Review, Done. Add intermediate columns if your flow requires it (Design, Dev, QA). Output: a Kanban board reflecting your operational reality (Trello, Jira, Linear, or physical board).
- 2
Make all work visible on the board
Every task in progress must have a card on the board. If a task exists but has no card, it is invisible and therefore unmanageable. Include ad hoc requests, bugs, and technical debt. The goal is to see the entirety of the workload. Output: a board where 100% of active work is represented.
- 3
Define WIP limits per column
This is the step that changes everything. Set a maximum number of tasks per column. Starting rule: number of people on the team divided by 2, rounded up. Example: team of 6 people, WIP limit = 3 in the "In Progress" column. If the column is full, no one adds a task. Help finish what is already started first. Output: WIP limits displayed on each column of the board.
- 4
Establish the pull system
Team members no longer receive tasks pushed by a manager. They pull the next priority task when they have available capacity. This empowers each contributor and eliminates micromanagement. Simple rule: when you finish a task, pull the next one from the previous column. Output: a self-organizing team around the flow.
- 5
Measure cycle time and throughput
Start tracking two metrics: cycle time (how long a task takes from "In Progress" to "Done") and throughput (how many tasks completed per week). These data points replace rough estimates with reliable forecasts. Little's Law gives you the mathematical relationship between WIP, cycle time, and throughput. Output: a dashboard with average cycle time and weekly throughput.
- 6
Identify bottlenecks
Look at your board: where cards pile up, there is a bottleneck. If 8 cards are stuck in "Code Review" and 2 in "Dev", the problem is not developer velocity but review capacity. Resolve the bottleneck before speeding up other steps. Output: identification of blocking columns and corrective actions.
- 7
Organize a flow-focused standup
Replace the classic standup ("yesterday I did, today I will do") with a flow standup: walk the board from right to left. Start with what is almost done, not what is just beginning. Central question: "What is blocking cards from moving forward?" Output: a 10-15 minute standup focused on unblocking.
- 8
Continuously improve (kaizen)
Every 2-4 weeks, analyze your metrics as a team. Is cycle time increasing? Find out why. Is throughput dropping? Identify the cause. Adjust WIP limits if needed, add or remove columns, refine the criteria for moving from one column to another. Kanban has no "end", it improves continuously. Output: a continuous improvement plan with 1-2 adjustments per cycle.