kanban

is an excellent book by David Anderson (isbn 978-0-9845214-0-1). As usual I'm going to quote from a few pages:

The essence of starting with Kanban is to change as little as possible.

Failure to make a delivery on a promised date gets noticed much more than the specific content of a given delivery does.

Counter-intuitively, most bottleneck management happens away from the bottleneck.

Speed is most useful if it is in the right direction… If your priority is to find and reduce the constraint you are often solving the wrong problem... The dramatic success of the Toyota Production System (TPS) had nothing to do with finding and eliminating bottlenecks. Toyota's performance gains came from using batch-size reduction and variability reduction to reduce work-in-progress inventory [Don Reinersten]

Kan-ban is a Japanese word that literally means "signal card" in English. In a manufacturing environment, this card is used as a signal to tell an upstream step in a process to produce more work. The workers at each step in the process are not allowed to do work unless they are signalled with a kanban from a downstream step.

Trust is a hard thing to define. Sociologists call it social capital. What they've learned is that trust is event driven and that small, frequent gestures or events enhance trust more than large gestures made only occasionally.

High-trust cultures tend to have flatter structures than lower-trust cultures.

The traditional approach to forming a commitment around scope, schedule, and budget is indicative of a one-off transaction. It implies that there is no ongoing relationship; it implies a low level of trust.

The more groups involved, the longer the meeting is likely to take. The longer the meeting, the less frequently you are likely to hold it…

Buffers and queues add WIP to your system and their effect is to lengthen lead time. However, buffers and queues smooth flow and improve predictability of that lead time. By smoothing flow, they increase throughput, so more work is delivered through the kanban system. Buffers also ensure that people are kept working and provide for greater utilisation. There needs to be a balance, and buffers help maintain it. In many instances you are seeking business agility through shorter lead times, and higher quality partly through lower work-in-progress. However, do not sacrifice predictability in order to achieve agility or quality. If your queue and buffer sizes are too small and your system suffers from a lot of stop-go behaviour due to variability, your lead times will be unpredictable, with a wide spread of variability. The key to choosing a WIP limit for a buffer is that it must be large enough to ensure smooth flow in the system and avoid idle time in the bottleneck.

The first principles of Kanban are to limit work-in-progress and to pull work using a visual signalling system.

You need slack to enable continuous improvement… In order to have slack, you must have an unbalanced value stream with a bottleneck resource.

The width of a bottle's neck controls the flow of liquid into and out of the bottle. We can pour quickly from a wide neck, but often with a greater risk of spillage. With a narrow neck, the flow is slower but it can be more precise… In general, a bottleneck in a process flow is anywhere that a backlog of work builds up waiting to be processed.

As we all know, there really is no such thing are multi-tasking in the office; what we do is frequent task switching.

security scan kanban

There's something about the typical kanban board I see that feels wrong. Let me try to explain. It's to do with what kanban means; what a kanban is. A true kanban is a physical thing used to regulate supply and demand. For example, consider putting your hand-luggage through an airport security scanner. You put your hand-luggage into empty trays. The trays go through the scanner. At the other side you take your hand-luggage out of the trays. The emptied trays go back to the start (often on a separate conveyor belt underneath) for someone else to put their hand-luggage into. Often you're ready to put your hand-luggage through the scanner but you have to wait because there are no empty trays. The number of trays represents the capacity of the system. Each tray is a kanban.

Now let's take a look at a typical kanban board such as the one on the left. It has two columns; one column for the activity of Wibbling which has a work-in-progress (WIP) limit of 5, and one column for the activity of Fubaring which has a work-in-progress limit of 4. There are 3 blue stories being Wibbled and 4 blue stories being Fubar'd.

How is this board supposed to be used? I count the number of blue stories currently being Wibbled - 1,2,3. I look up to the top of the Wibbling column and see its WIP limit is 5. I know 3 is less than 5 so I know there is some spare Wibbling capacity. If I want to know how much I can do the math, 5-3==2. And repeat... I count the number number of blue stories currently being Fubar'd - 1,2,3,4. I look up to the top of the Fubaring column and see its WIP limit is 4. I know 4 is the same as 4 so there is currently no spare Fubaring capacity.

It seems odd to have two columns that look exactly the same when one has spare capacity and the other does not!

My problem is that 5 and 4 are abstractions!
5 is not the same as 5 trays.
5 is just 5.
But 5 trays is [Tray Tray Tray Tray Tray].

What's important about the 5 isn't the 5.
What's important about the 5 is that it represents 5 trays.
What's important about the 5 is the relationship between the 5 and the number of blue stories it limits. The Wibbling blue story WIP limit is abstracted to a 5 but the blue stories are not. I have 1,2,3 blue stories in the Wibbling column but I'm not representing them with a 3, I'm representing them with 1,2,3 actual blue story cards.

Here's the alternative 'scan kanban' I'm thinking of.
I remove the 5 WIP limit from the top of the Wibbling column. Instead I put in 1,2,3,4,5 orange  Tray s.
I remove the 4 WIP limit from the top of the Fubaring column. Instead I put in 1,2,3,4 red  Tray s.

I add the rule that every  Story  must always be in a tray.

Now I can instantly see the Wibbling column has some spare capacity because there are some  Tray s with no  Story  in them. I can count the spare capacity if I want -  1 ,  2 . No math needed. Easy. I can instantly see the Fubaring column has no spare capacity because all the  Tray s contain a  Story .

Now I have a kanban board that actually has kanban on it!
Each tray is a kanban.
Now I can experience pull.

Suppose the workers to the right of the Fubaring column use green  Tray s. They send an empty  Tray  to the Fubaring column to signal they're ready to pull a  Story .

The workers in the Fubaring column move a done  Story  from their  Tray  into the empty  Tray .

The workers to the right of the Fubaring column pull the  Story  in its  Tray  back into their column.

The workers in the Fubaring column now have an empty  Tray .

The workers in the Fubaring column can send their empty  Tray  to the Wibbling column to signal they're ready to pull a  Story .

Thus each  Story  flows left to right while each empty  Tray   Tray   Tray  moves right to left.

Once we have a system under control we can try to improve. For example, we can see what happens when we reduce the WIP limit by 1 in the Wibbling column. We simply remove a  Tray .





Caveat Emptor: I've never seen this style of kanban in actual use. It's just an idea so far. As always, if anyone has any feedback it would be much appreciated.

Update! Here's a follow up blog entry.

my kanban 1's board game

Here's a slide deck explaining the essence of my kanban 1s board game. Jon Jaggers Kanban 1s Board Game

• You can play an early session with no clips so the players can see how inventory builds up (you can also push done story-cards to the next edge's corner, rather than waiting for them to be pulled).
• The clips that hold the story-cards are a crucial part of the game. They make it a kanban game.
• You can limit the number of clips per edge to create a natural work-in-progress (wip) limit.
• You can add a new rule: players can also spend a 1 to split a story-card in two, eg a 4 into a 3 and a 1 (assuming they have a spare clip).
• You can record the day a story-card comes off the backlog, and also the day it gets to done and thus measure the cycle time.
• You can simulate scrum-style discrete sprints.
• You can vary the number of dice at different edges.

Bordeaux kanban 1's game

Philippe Launay is an Agile team lead and Coach for AGFA in France.

Phillipe recently organized a Kanban 1's game in Bordeaux after he and Fabrice Aimetti translated the slide-deck into French.

Way to go Phillipe.



Phillipe gave me some great feedback

• printed handouts of the rules on each table.
• instead of story-cards with numbers on why not have story-card with dots on. Instead of a 4 have 4 dots.

He writes:

We really had some fun and we learned a lot. The feedback is very very positive... All attendees, the two observers, and the two organizers are more than satisfied with the result. So again thank you to for providing the game.

It's my pleasure Phillipe. And in case any else is wondering, please feel free to translate the Kanban 1's Game slide-deck if you want to. Just send me an email and I'll collect links in this blog.

My Kanban 1s Game

Update! I've now created a Kanban Board Game around this idea.

Here's the latest slide-deck for my kanban 1s game. Based on feedback from several recent sessions I've changed two features:

• Backlog It now costs 1 unit of work to create a backlog item. Also a worker on any table can create a backlog item at any time.
• Bugs There's now a much simpler way of simulating bugs - simply lose all the current work on the story-card.

Jon Jagger's Kanban 1s Game

Kanban 1's Game Notes

Some notes from Kanban 1's Game's I've played at a few clients sites...

First, some teams have been exploiting the splitting rule. If they have a 4-work-item with 2 bugs on it, they simply split it into a 3-work-item and a 1-work-item and put both bugs onto the 1-work-item and then abandon it, and carry on with the bug-free 3-work-item. They have to check for bugs on the abandoned buggy 1-work-item but otherwise it doesn't affect velocity. This is obvious in hindsight but I hadn't foreseen it. It is amazing how simple rules can create complexity when used in combination. To counteract this I introduce a rule that when you split a work-item into two smaller work-items both new work-items get the bugs. So, for example, if you split a 4-work-item with 2 bugs into a 3-work-item and a 1-work-item, then the 3-work-item and the 1-work-item both get 2 bugs.

Second, the way backlog work-items are created (without any 1's cost), and then moved onto the first table (also without any 1's cost) creates another unintended (from my point of view), but nonetheless very interesting possibility that a few teams have also recently exploited. What they've done is simply created masses and masses of backlog work-items and immediately pulled them all onto the first table. They effectively move the entire backlog onto the first table. The price they pay for this is having to check for bugs on every work-item. Naturally lots of bugs accumulate on the masses of work-items on the first table. However, this does not directly affect the velocity since they can simply any abandon any buggy work-item on the first table and pull in a newly created bug-free backlog work-item at any time.
So I'm currently wondering if it's better to have to pay a 1 to create a backlog work-item and possibly also pay a 1 to move a backlog work-item onto the first table. I think this will be effective for two reasons

• it simplifies the backlog rules a bit since I can now drop the rule that backlog work-items have to move onto the first table in strict creation order.
• I can allow 1's thrown from any table to create backlog work-items. This will give players on tables other than table 1 something to do during the early days of the sprint.

It seems clear to me that the game should somehow take into account the total number of bugs on all work-items on all tables. I'm pondering that.

Thirdly, rather than recording the bugs on an index-card paper clipped to the work-item, simply use the paper clips! Two paper-clips on a work item (as in the photo) means two bugs. Much simpler. Again this is obvious in hindsight.

kanban 1's game

NB: Heres a more recent slide-deck

I ran my Kanban 1's Game as an open space session at both the xpday conference and also at the Lean, Agile eXchange conference. It proved quite popular so here is how to play it if you're interested. Kanban1sGameRules

Some notes on new game variations/updates

Thank you to Kevlin Henney and Liz Keogh who helped to improve the game.