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.

Time:

60 – 90 minutes

Input:

• 20 Coins (any denomination)
• 3X5 Index cards – 100 pieces
• Table length to accomodate 4 to 5 people, preferably a U-Shaped table
• 3 Stopwatch’s
• Color paper – legal size, two different colors (say Purple & Brown) – 10 sheets for each color
• Facilitator
• 3 Time Keepers
• Flip chart or whiteboard
• Whiteboard markers

Setup:

• Create a table as shown below on flip chart or whiteboard

• There are two processing flows that are happening in opposite directions. One for the cards and another for the coins
• Processing steps for cards

Card processing steps

Steps to process a card are intentionally complicated and one can invent any scheme do-able in a short time however requires some mental processing.

• Processing steps for coins is rather simple however dependent on chance. At step (n-1) say the instruction is to flip a coin until it turns to ‘heads’ in step n 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

Table and participant setup

Motivation behind creating opposite flows is to amplify the bottle neck effect and demonstrate viability of kanban signaling mechanism in intersecting workflows, same as in reality where people have to switch context and work on a different stream.

Exercise Context:

I setup the context for this exercise as setting my self (facilitator) as 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 set product must have one card and one coin that makes 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 time keepers 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.

Round 1

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 staring 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.

One can easily thought experiment, soon enough a situation similar to one below will arise:

Round 1 – All items (severe bottleneck)

This causes a sever bottleneck mid-stream through the round and lot of wait periods for people when that happens.

Time keepers tabulate time taken for 1st coin that completes the flow, 1st card that completes the flow, last coin that completes the flow and the last card that completes the flow.

Round 2

After round 1 remove the constrain of processing all coins and all cards by a person before they can be passed on the next person in processing chain. A short de-brief and retrospective on round 1 participants 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.

Round 2 – Dynamic bottlenecks

In round 2 the problem of ‘waiting’ is resolved by reducing batch size, however by pushing artifacts to next step causes unpredictable bottlenecks to pop-up through out 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/producers you know that just being first to market is not goo 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 kanban system, simply fixing the first production issue really quick and demonstrating no predictable rhythm thereafter does not help your customers)

The stage is now set for round 3.

Round 3

As a facilitator/owner in this context, there is some new setup required prior to executing round 3

Setup & Rule:

Round 3 – Setup – Kanban Board

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. 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.

Execution:

As this round begins following dynamic emerges

Round 3 – Even Flow

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 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)

Debrief

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 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

X: yup!

A: Not everybody is overloaded, you have only two buckets to watch for; its not like there are hundred’s. It isn’t that you don’t have work at sometimes and you are overloaded at other times

……….

Y: In round three, 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

Summary

There are two things very sacred about using Kanban:

1. Limit Work in progress : WIP could be 1 item or 2 items or at most 5-7 items but definitely not 100.
2. 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 simple idle, twiddle thumbs. Of course this would make the organization optimizers concerned for fear of under-utilization however 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!)