I am often surprised to read or hear that many people think they are using a Kanban board when they stick notes on a wall. They say “We represent each stage of the process by a column and drive notes from left to right to represent work progress : a Kanban board.” This is frequently the case with Scrum teams, and you can find plenty of articles on the Web entitled “Using a Kanban board to deal with impediments” or saying things like “The main difference between a Scrum board and a Kanban board is that a Scrum board is reset after every sprint.” I’m sorry to disappoint you but sticky notes do not make Kanban.
The main confusion is due to the fact that the sticky notes we use on the board are not kanban “cards” (or just kanbans). Indeed, the sticky notes are usually used to represent work items, tasks, user stories, etc. Those work items travel through the boar. On the contrary kanbans represent the need to move work items. In a Toyota-like environment, they are messages meant to ask people before us on the process chain that we need them to refill the inventory, to produce more pieces.
So what about Kanban in software development then? Where are those famous kanbans if not the sticky notes? Let’s take an example to make this clear : a Scrum team of 5 people, 1 of them is a tester, 4 are developers. To take advantage of everyone’s specialty, they decide to change the classical Scrum board and process ( to do – doing – done) into to do – dev – test – done.
After a couple of sprints they notice a flaw with their process. Indeed, although everything goes fine most of the time, it happens that stories are easy and quick to develop, but hard to test. When this happens developers push many stories into the testing stage, the tester starts too many tests, plays too many scenarios at the same time and misses important defects, or cannot finish anything at all.
During a sprint retrospective, the team reminds itself one of the most important things about Agile : work must be completed (or done or whatever you call it). They realize that they cannot let work pile up into the “test” column and suggest several solutions. The first solution is to hire another tester, but this is impossible and would be unnecessary most of the time. The second is to implement a one-piece flow : the team swarms around a single item at a time, but it seems hard to implement and maybe a bit too extreme. Nevertheless the idea behind the one-piece flow looks good : limiting the work in progress to make sure that things are done. We could say that the tester cannot test more than one item at a time while the 4 developers can develop 2 items at once, as we practice pair-programming, plus a small buffer to improve flexibility. But how to do that : if developers push items into the test column there will be more than one item at a time sometimes. The solution : a pull system. The resulting board looks like this:
Developers will pull work from the TODO stage and the tester from the DEV DONE stage…and this board is a kanban board.
Still cannot see kanbans on this board? This is because kanbans are virtual. Here are the the two main ingredients that make kanbans appear on the board:
- Focus on demand. The team has committed to providing a list of items during this sprint. To provide those items, they must be validated (the “test” column). To be tested, items must be developed (the “dev” stage). This is what makes a kanban system be a pull system based on need. Kanbans represent this need. There is no work without a kanban.
- Limited-size inventory. To avoid piling up half-done work we need to limit WIP. Kanbans represent the availability of an empty slot to put a work item in.
So are you gonna tell us where those f***ing kanbans are? They are the difference between the WIP limits (aka the maximum size of the inventory) and the actual number of work items (aka the size of the inventory). We don’t usually represent them explicitly, but I have already seen boards on which WIP limits are not numbers but actual slots. What is important here is that kanban boards are not just about visualizing work items, they are an impressive tool to visualize resource availability, help identifying bottlenecks, help manage risk, improve predictability, etc.
In short, a kanban board is not a board with sticky notes representing work items, it is a board where is represented a demand-focused pull-system with limited work-in-progress. Sticky notes are not required.
EDIT (3 Jan 2013) : Mike Burrows just posted a very good, very complete article on this subject here. He gives an interesting value-based introduction to Kanban instead of the classical sticky-notes-based description.
One thought on “Sticky notes do not make Kanban”