Ask most teams whether they use Kanban and they will point at a board. To Do, Doing, Done. Maybe a few extra columns, a swarm of sticky notes, and a card that has lived in Doing since spring.
The board is the most visible part of Kanban, and the least understood. Behind it sits a set of principles and practices that most teams have never looked at, and that is where the value lives.
Where Kanban comes from
Kanban grew out of Toyota’s manufacturing system in the 1940s and 1950s. The word is Japanese and loosely means signboard or sign. Toyota used cards to signal that a part was needed, which supported a just in time approach: bring in the parts the line needs, when it needs them, and nothing more.
The logic was simple. Why keep 30,000 of one part in a storehouse when you may never build 30,000 cars? Hold just enough to keep the system flowing and keep building.
Kanban as it is used in knowledge work today draws on several deeper ideas: systems thinking, Lean principles, queuing theory, and the study of variation in quality control. It pulls them together with one aim: to optimize the flow of value, not simply the flow of activity. A team can be optimized for execution and still not be optimized for delivering value. Kanban asks you to look at the whole thing.
Principles before practices
Most people know what Kanban does. Fewer know what it believes. The Kanban Method rests on two sets of principles.
- Start with what you do now.
- Agree to pursue improvement through evolutionary change.
- Encourage acts of leadership at every level.
Three service delivery principles
- Understand and focus on your customers’ needs and expectations.
- Manage the work, and let people self-organize around it.
- Regularly review the network of services.
The first change principle deserves special attention. Kanban does not ask you to rip everything out and start again. Visualize how work flows today. Yes, you already know some of it needs to change. Do not worry about changing it yet. Make it visible first, then see where the roadblocks are.
The six practices
On top of those principles sit six general practices:
- Visualize the work.
- Limit work in progress.
- Manage flow.
- Make policies explicit.
- Implement feedback loops.
- Improve collaboratively, evolve experimentally.
These are better known than the principles, which mirrors what happens with Scrum. Teams tend to know the doing, the events and accountabilities, better than the thinking underneath. Here is what each practice looks like when a team takes it seriously.
1. Visualize the work: you have more than one workflow
A useful first question on any team is: tell me how work moves through your system. Then check whether the tool you use reflects those steps. It rarely does, and walking through it usually produces the same reaction: there is a lot more going on here than we thought.
Teams often insist they have one workflow. They do not. Think about ordering a pizza. I order, I get pizza: that is one workflow. Behind it, the pizza place runs another to keep dough, cheese and pepperoni in stock. Another keeps boxes, napkins and crushed red pepper on hand. Another gets the delivery out the door.
Once you can see all of them, you can manage them. If you usually get ten pepperoni orders on a Friday and only have enough pepperoni for five, a visible workflow tells you before your customers do.
If you can name it, you can fix it. If you can’t see it, you can’t fix it.
2. Limit work in progress: stop starting, start finishing
Work in progress limits are the practice teams blow past first. The usual argument is multitasking. The usual result is a lot of things started and very little finished.
Picture a motorway on-ramp. When the motorway is already packed bumper to bumper, sending more cars on at once does not speed anything up. You meter them on, a few at a time, so traffic keeps moving. Or picture a printer. It prints as fast as it prints. Stuffing more paper into the tray does not make it faster. It just jams.
WIP limits are especially useful in chaotic environments. Keep a backlog that stakeholders can prioritize to their heart’s content, but cap what is in progress. With five developers, that might mean six or seven items at once. Something has to finish before something new comes in. Stakeholders can still reprioritize, and the team can focus on what is in front of it instead of dodging interruptions.
The whole idea fits in four words: stop starting, start finishing.
3. Manage flow: find the real constraint
One support organization was moving its development teams to Scrum when the head of maintenance and support pushed back. Scrum would work for the builders. It would not work for the teams keeping the lights on. So those teams tried Kanban instead.
They mapped their workflow on a board:
ready for analysis => analysis in progress => ready for dev => dev in progress => ready for testing => testing in progress => ready to deploy => done
The picture was clear almost immediately. Work was piling up at analysis.
The team had one analyst, several developers, and several testers. The analyst was not doing anything wrong. The team had the wrong balance of roles for the work. One of the testers could also do analysis, so they moved to the front end of the flow, and the work started moving again.
Without the board, nobody would have seen it. Blocked work behaves like a blockage in the bloodstream: everything downstream suffers, and the cure is to find the blockage and release it.
This is the theory of constraints in action. Every process has constraints, including getting out of the door in the morning, and you often do not discover the next one until you fix the one right in front of you. Kanban will not solve your problems for you. It makes the ones you were not aware of visible, so you can deal with them.
4. Make policies explicit: the forgotten practice
This is the practice most organizations skip. Teams may have a WIP limit, but few have clear pull criteria or defined classes of service.
Explicit means specific. “I can help you become a better Scrum Master” is vague. “I can help you improve your retrospectives in three months” is explicit, and explicit policies are measurable and improvable.
Consider a sandwich shop with a simple promise: your sandwich will be ready by the time you finish paying, about three minutes. If it is not, it is free. Everyone behind the counter knows the standard, and everyone can see when something is going bump in the night.
For a team, explicit policies look a lot like Scrum working agreements. Pull from the top of the backlog, and if an item does not match your skills, take the next one that does. Is this item ready, yes or no? Keep them light. Nobody needs pages of rules. But because Kanban does not build in refinement or planning, the team has to define those habits for itself, and someone needs to help bring them into existence.
5. Feedback loops, and measuring the right things
Kanban does not tell a team to hold retrospectives. It tells a team to establish feedback loops. So ask: what do our feedback loops look like? How does the team sync? How is it looking at what it could keep doing better?
Feedback loops need the right measures. Counting output misses the point. “We made 20 burgers today” means nothing if 50 were ordered. Throughput and cycle time tell you how value is moving through the system.
6. Improve collaboratively, evolve experimentally
The last practice ties the others together. Improvement is not a one time fix, and it is not something one person decides alone. The team looks at the data together, forms a hypothesis (“if we lower our WIP limit, cycle time will drop”), tries it, and checks what happened. Keep the experiments small and safe to fail. Fix the constraint in front of you, then look for the next one, because there is always a next one. Over time those small changes add up to a system that works better than any big redesign could have delivered.
Kanban and Scrum are not rivals
Kanban does not have to replace Scrum. Many teams use both, on purpose.
Some use Kanban for refinement and Scrum for development. The Product Owner works items up on a Kanban board, and the ready column feeds backlog refinement and Sprint Planning. Others split the work by type: a new build delivered with Scrum, and maintenance and support run with Kanban. Teams in continuous deployment environments, or flooded with small last minute requests, often find Kanban the better fit, and some long, fixed projects benefit from it too.
For many organizations, the freeing realization is that teams do not all need the same process, the same sizing, or the same ticket types. The framework is the frame. What happens inside it is yours to shape.
See it, name it, fix it
Kanban was never really about the board. The board is just where the truth shows up: the work that is stuck, the queue nobody owns, the team with the wrong mix of roles. Once you can see it, you can name it, and once you can name it, you can fix it.
You do not need a transformation program to begin. Draw how work flows today. Put a limit on what is in progress. Write down one policy the team already follows but has never said out loud. Then watch where things get stuck, and keep finishing. The flow will follow.
Stop starting. Start finishing!