Kanban at its essence is a signaling device that instructs the moving or creating in a “pull” based system. Kanban when applied within a system enables synchronization between the rhythm of demand (customer) and rhythm of production (producer). The pace or beat, of customer demand is takt time. In other words to enable just in time production of goods it is best for producers to produce goods at the same rate as the customer demands. A faster rate of production results in finished goods waiting to be consumed (inventory) and a slower rate of production results in missed opportunity costs or dissatisfied customers. This aspect of continuously tuning the producer’s rate of production to customers demand requires a continuous improvement (kaizen) mindset. My favorite article on Kanban applied to software development is by Kenji Hiranabe. Please read that article before you dive into the details of setting up and facilitating this exercise.
60 – 90 minutes
- 20 Coins (any denomination)
- 3×5 Index cards – 100 pieces
- Table length to accomodate 4 to 5 people, preferably a U-shaped table
- 3 Stopwatches
- Color paper – legal size, two different colors (say Purple & Brown) – 10 sheets for each color
- 3 timekeepers
- Flip chart or whiteboard
- Whiteboard markers
- Create a table as shown below on flip chart or whiteboard
|Round 1||Round 2||Round 3|
- There are two processing flows that are happening in opposite directions. One for the cards and another for the coins
- Processing steps for cards
Steps to process a card are intentionally complicated and one can invent any scheme do-able in a short time.
- Processing steps for coins is rather simple, however dependent on chance. At step n-1, the instruction is to flip a coin until it turns to ‘heads’. In step, participants flip all coins until the coin turns to ‘tails’. Repeat this loop until the last person in chain is done.
- For each round, you need less than 20 coins and the same number of blank index cards
- Setup and people arrangement (click images to view larger versions):
The motivation behind creating opposite flows is to amplify the bottleneck effect and demonstrate the viability of the Kanban signaling mechanism in intersecting workflows, the same as in reality where people have to switch context and work on a different stream.
I set up the context for this exercise by making myself (facilitator) the owner/CEO of this operation. My company produces a magic set which requires a mathematically valid index card setup (see card processing steps) and a coin that has been flipped appropriately. The magic product set must have one card and one coin that make it possible for customers to do magic tricks. (All made up )
There are five team members who are producing the magic set of card + coin and three timekeepers to record production time – one for recoding 1st coin processing time and last coin processing time, second for 1st card processing time and last card processing time, and third for backup and tabulating results during each round.
In this round, all coins must be flipped to ‘heads’ by a person on one end of the table before (s)he can pass the entire set of 20 coins to the next person. On the other end of the table, the person who is starting to process cards must process all cards by executing only step 1 (demarcate quadrants) before all cards are passed onto next person for step 2.
Soon enough a situation similar to the one below will arise:
This causes a sever bottleneck mid-stream through the round and lot of wait periods for people when it happens.
Timekeepers tabulate the time taken for 1st coin that completes the flow, the 1st card that completes the flow, the last coin that completes the flow, and the last card that completes the flow.
After Round 1, remove the constraint of processing all coins and all cards by a person before they can be passed on the next person in processing chain. A short debrief and retrospective on Round 1 participants will show that they naturally gravitate to select small batch size, in this case the participants chose to pass a coin and card as soon as it was processed by a person.
This is enabling reduced batch size in a PUSH based system since the participants move their processed item to next step as soon as they are done.
In Round 2, the problem of ‘waiting’ is resolved by reducing batch size, however pushing artifacts to next step causes unpredictable bottlenecks to pop up throughout the process. Don’t be surprised if this round feels chaotic with participants egging each other on to complete their steps.
As timekeepers tabulate time taken, it is clear that Round 2 processed the 1st coin and 1st card faster than round 1. Improved time to market!
But as an owner/producer, you know that just being first to market is not good enough – you have to continuously supply the market with your product so that you can keep the market advantage gained by faster time to market. (For those fixing production issues using the Kanban system, simply fixing the first production issue really quickly and demonstrating no predictable rhythm thereafter does not help your customers.)
The stage is now set for Round 3.
As a facilitator/owner in this context, there is some new setup steps required prior to executing Round 3.
Setup and Rules:
Each person has two different colored papers next to them, except for the first and last person since they only need one (see diagram above). Each color is marked either for card or for coin. A work in progress (WIP) limit is enforced by ensuring that only one coin or only one card can be placed in on their respective color paper. Only when a participant PULLS an item from the board can the downstream person work to fill the empty color space.
As this round begins, the following dynamic emerges:
Reduced batch size eliminates wasteful wait periods as in Round 2. Establishing Kanban cards to enable PULL based system normalizes flow, preventing bottlenecks from building up. In the exercises that I have facilitated, the time for the 1st coin and 1st card processed are extremely close (almost within seconds) and the total time to process all cards and all coins is also very close (again almost within seconds).
I was fortunate to have a video recording for one of these exercises. Following is a selected transcript from the debrief. (Full transcript is 5 pages long and peoples name have been replaced by random one letters, except my name is in full.)
Y: We were producing cards and coins at the same pace, evenly in 3rd round. we got the production flow of cards and coins..
Z: We were making money sooner and continually having product available, so we got product sooner, a more consistent delivery..
X: Versus a lot of overhead of constantly keep stuff on shelf. This avoids the problem that we gave you a big batch in January but we can’t get anything for you until march
Dhaval: You said something about predictability almost 3 times, what did you mean by that?
X: Inventory was predictable, it was consistent, we had a process that was going and even though one of them was a random process you still ended up with a consistent output, because the batching system. The Kanban system allowed you to control flow and really no one was idle. Work was evenly distributed
Dhaval: So, ummm.. I liked what you said. This (flips a coin) is sort of 50% chance, it is not wildly unpredictable as some software stuff could get. And you are saying that we could control something even without knowing how much flips you are going to need.
A: Not everybody is overloaded, you have only two buckets to watch for; it’s not like there are hundreds. It isn’t that you don’t have work at sometimes and you are overloaded at other times.
Y: In Round 3, if there is a bottleneck, if somebody is not processing well then this .. this .. signal cascades down the line and makes it apparant, right? (looks around for acknowledgement and gets some) as opposed to let’s say, if I’m the bottleneck and J is tossing over and cards are queuing up it does not become apparent down the production line.
Dhaval: very interesting, so if I restate what you said was in Round 2 the output would have been a stack of queue in front of R but in Round 3 you (1st guy to process cards) could feel the effect of R not being able to process. All this with out having R to explicitly communicate that I’m blocked!
all: Yeah! Yeah!
Y: We could feel the flow, we were all interconnected. Builds cohesion and in the same vein build that dependency between us too.
There are two things very sacred about using Kanban:
- Limit Work in progress: WIP could be 1 item or 2 items or at most 5-7 items but definitely not 100.
- Have a signaling system that implicitly communicates upstream bottlenecks downstream. Never exceed your WIP limit even if this means that you have to idle (wait) for upstream process steps to free up their kanban bucket.
Most Kanban implementations either blatantly disregard their WIP limit or invent new workflows for exception handling which soon becomes the norm. Instead it would serve the organization better to plain and simply idle, twiddle thumbs. Of course this would make the organization optimizers concerned for fear of underutilization. A better alternative is to utilize unused capacity to find continuous improvement experiments that will prevent similar disruption of flow in future (a Kaizen event!)