What Is Kanban? From Toyota to Software, and Why It's More Than a Board

Version note: This post is based on version 2025.5 of The Kanban Guide (ProKanban.org, May 2025); for the Kanban Method, Kanban University's official guide was consulted.

Guess First

Bookstore has a five-person team: two .NET developers, one Angular developer, one full-stack developer and a tester. The team's work comes in two kinds. On one side are small features (wishlist sharing, a publisher filter); on the other is support work that never ends: refund requests, book prices imported wrongly, "card payments are failing" alerts. The team tried two-week Sprints, but an urgent refund bug arriving on day three broke the plan every single time.

One Monday morning the team lead opens a new board in Jira: To Do, In Progress, Done. No Sprints, cards just flow to the right. Everyone relaxes. "We do Kanban now," they say.

Three questions: Is this team really doing Kanban? What is the difference between opening a board and adopting Kanban? And consider this: if six weeks later 14 cards have piled up in In Progress, is the board to blame, or something the board isn't telling you?

The Idea from Toyota: Cards, Pull and the Supermarket

"Kanban" roughly means "visual card, signboard" in Japanese. The idea is part of the system Taiichi Ohno developed on Toyota's production line in the 1950s, later known as the TPS (Toyota Production System). The problem Ohno wanted to solve was inventory: every station produced as many parts as it could and pushed them to the next one, and huge intermediate stocks piled up along the line. That stock tied up money and hid defects; by the time a bad part was noticed, hundreds more had been produced behind it.

The fix was to think about production backwards. A station produces only when the next station "pulls" parts from it. The pull signal is the kanban card: when a box of parts runs out, the card on the box goes back to the previous station and says "make one more box of this." Because the number of cards in circulation is limited, the stock between stations is limited too. The supermarket shelf Ohno described as an inspiration works the same way: the shelf is refilled as it empties, nobody piles products in front of it just in case.

Two ideas travel from this story to software. The first is pull instead of push: work is pulled when someone finishes what they have and capacity opens up. The second is limited intermediate stock: in software this is called WIP (Work in Progress, work that has started but not finished), and limiting WIP is the heart of Kanban. The card itself, the sticky note on the wall, is the least important part of the story.

Into Software: Microsoft, Corbis and David Anderson

Bringing Kanban to software teams is largely associated with David J. Anderson. In 2004 at Microsoft, Anderson tried a pull system and a WIP limit with a sustaining engineering team that did maintenance work and was always late; the team shortened its delivery times significantly without even using a board. In 2006–2007 at Corbis in Seattle, the idea came together with the physical board, columns and per-column WIP limits we know today. The Kanban Guide also states that the practices now called Kanban in knowledge work originated with a team at Corbis in 2006. Anderson collected this experience in his 2010 book "Kanban: Successful Evolutionary Change for Your Technology Business."

This history matters because it shows you that Kanban is not something that "starts with a board." The first experiment at Microsoft had no board; it had a WIP limit and pull. The board came later, to make the system visible.

There Are Two Kanbans Today: The Kanban Method and The Kanban Guide

When you say "Kanban" today you may mean one of two descriptions from two different communities. Knowing both helps you understand which branch a blog post you read or a training you attend is speaking from.

Kanban University's official guide defines the Kanban Method not as a methodology or framework but as a management approach applied on top of the way you already work. On the change management side it says "start with what you do now, change gradually and evolutionarily, encourage leadership at every level." On the service delivery side it asks you to focus on customer needs, manage the work rather than the people, and review the service network regularly. Its six general practices are: visualize, limit WIP, manage flow, make policies explicit, implement feedback loops, improve collaboratively/evolve experimentally.

The Kanban Guide was published by ProKanban.org in 2020 (first 2020.7, then 2020.12) and updated in May 2025 with version 2025.5. Its brevity is deliberate: it states only the minimum and leaves the rest to the team. The Guide is the backbone of this series, but the Kanban Method's cadences and service view will show up in post 06 where they fit. Instead of declaring one branch "the real Kanban," think of it this way: the Guide gives you the skeleton that measures and manages flow, and the Method describes how to manage change while embedding that skeleton in an organization.

The Kanban Guide's Definition: Flow, Value and Three Practices

The Guide defines Kanban as a strategy for optimizing the flow of value through a process. There are three concepts in that sentence, and all three will keep coming back throughout the series.

Flow is the movement of potential value through the system. For Bookstore, the path a work item, say a bug opened as Fix VAT rounding on invoice PDF, takes from being picked up for development to reaching production is a flow. Value is the benefit that work brings to the customer or the company; the Guide leaves value to be defined in the team's context. According to the Guide, good flow balances three goals: effectiveness (delivering what stakeholders want, when they want it), efficiency (using resources well) and predictability (being able to say when you will deliver with acceptable uncertainty).

The Guide lists systems thinking, lean principles, queueing theory, variation and quality control as the theory Kanban draws on. The practical side consists of three practices that work together:

• Defining and visualizing the workflow: making the team's Definition of Workflow (DoW) explicit and showing it on a Kanban board.
• Actively managing items: controlling WIP, keeping items from aging unnecessarily, unblocking stuck work.
• Improving the workflow: continually studying the system and changing the DoW when needed, without waiting for a formal meeting.

These three practices are measured with four flow metrics: WIP, Throughput, Work Item Age and Cycle Time. The Guide treats these four as the minimum; a team may rename them (calling Cycle Time "flow time," for instance), but must use them as the Guide describes. In post 04 we will compute these metrics ourselves in C# from a CSV (Comma-Separated Values) export.

Version 2025.5 changed a few things compared to 2020.12, and the Guide's page lists them itself: a "conventions" section for key terms was added, the SLE (Service Level Expectation) moved into the DoW section, WIP control became less prescriptive (you no longer have to write a number per column), multiple DoWs and variation were clarified, the "Kanban Measures" heading became "Flow Metrics," and the statement that the Guide is immutable was removed.

A Kanban Board ≠ Kanban

Back to the opening question. A board with To Do, In Progress and Done columns is, in the Guide's terms, only a visualization. For a board to be Kanban it needs a DoW behind it, and according to the Guide a DoW includes at least: what a work item is, when work counts as started and when as finished, the states between those two points, how WIP is controlled, explicit policies that say how items move between states, and an SLE.

The Bookstore team's board has none of these. There is no stated number of cards that may enter "In Progress," so WIP is not controlled. When a card counts as Done is not defined: on merge, on reaching the test environment, on deployment to production? So the 14 cards piled up in In Progress after six weeks are not the board's fault; the board only shows what is happening. The problem is that the team set no limit and everyone starts something new as soon as their current work starts waiting.

Without WIP control a board is not a pull system but a push system: work starts because someone wants it, not because capacity opened up. In the Guide's words, controlling WIP creates a pull system; new work starts only when there is a clear signal of capacity. That signal is exactly Ohno's card. In post 03 we will see why this shortens cycle time, with Little's Law and a small simulation.

The Bookstore Support Team: Work That Doesn't Fit in a Sprint

So why did this team leave Scrum, and what did it lose when it did? About seven or eight pieces of work reach the team every week, and a third of them are support requests that need attention the same day. As the Scrum series' post on Sprint Planning explains, a Sprint is a commitment planned around a Sprint Goal. If most incoming work is unknown in advance, the Sprint Goal breaks every week, and the team either keeps replanning the Sprint or hides behind guesses like "30% buffer for urgent work."

Kanban offers this team a continuous flow instead of Sprints: work enters the Ready column as it arrives, and when a developer finishes what they have, they pull the top item. In return, the team has to take on three disciplines. Put a limit on how many items it runs at once, define where work starts and finishes, and answer "when will it be done" with data instead of guesses. The rhythm the Sprint boundary gives Scrum is provided in Kanban by the WIP limit and the flow metrics. Without these disciplines the team has not moved from Scrum to Kanban, but from Scrum to no structure at all.

Let's also say up front that Kanban does not have to be an alternative to Scrum. Scrum teams can use flow metrics too; Scrum.org's Kanban Guide for Scrum Teams describes exactly that, and it is the topic of the last post in this series.

In Production

What a team moving to Kanban should measure in its first weeks is not speed but the system itself. From the day you set up the board, start recording the date each card entered each column. Jira and GitHub Projects keep this history, but their standard CSV exports often give only the current status and the created/resolved dates; for state transition dates you need access to the tool's history data (such as the issue changelog in Jira). Without that data you cannot compute any of the metrics in posts 04 and 05.

The second point is the limit itself. Starting the first WIP limit from today's average WIP and lowering it slowly is safer than imposing an ideal like "one item per person" on day one; on a board where nobody does anything when the limit is exceeded, the number is just decoration. The third is the rule for urgent work: a support-heavy team always gets urgent work. Managing it with a separate lane on the board and an explicit policy beats quietly breaking the limit; we will discuss this in post 06 as the expedite policy.

Common Pitfalls

The most common pitfall is the opening story: opening a board and believing you have adopted Kanban. The board is a tool; Kanban is the rules behind the board and the metrics that measure those rules.

The second pitfall is reading Kanban as "no planning" or "working without deadlines." Kanban has no Sprints, but it does have a plan: how and how often the Ready column is refilled (replenishment), in which order work is pulled and when it will finish are answered by policy and by data. Kanban's answer to "when will it be done?" is the probabilistic forecast in post 05, and that answer is far more binding than "we don't know, it's in the flow."

The third pitfall is taking sides between the two Kanban branches and declaring the other one wrong. Someone trained by Kanban University and someone who read ProKanban's Guide may use different words in front of the same board; both want to limit WIP, make work visible and improve flow. Comparing terms is more productive than arguing about which one is "right."

The fourth is thinking Kanban only suits support teams. The Guide says Kanban applies regardless of industry and scale; a Scrum team building a product and a portfolio spanning several teams can also define a DoW and measure their flow.

A Small Experiment

★☆☆ Open your own team's board and look for each of the six parts the Guide lists for a DoW: the work item definition, the start and finish points, the states, WIP control, explicit policies, the SLE. How many are written down, and how many live only in people's heads?

★★☆ Write down the number of cards in the "In Progress" column every day for the last two weeks (from the board history in Jira, or by counting every morning). What is the ratio of average WIP to the number of people on the team? If it is well above 1, talk with your team about how many items each person has open at the same time.

★★★ Read Kanban University's Kanban Method guide and The Kanban Guide side by side and produce a one-page comparison: which concepts appear in both, which only in one? Add a row that matters for your own team to the table in this post.

In the next post we will design the Bookstore team's board from scratch: we will write out the parts of the Definition of Workflow one by one, decide where work starts and finishes, and separate queue states from active states.