Kanban has become an increasingly popular “agile” technique which is consider as similar to Scrum and Extreme Programming.  David Anderson created the agile form of Kanban from his experience in Japan.  In his book he tells the story of his visit to the Imperial Palace Gardens where there is no admission cost, but the flow of visitors is constrained by a stack of kanban (cards), people can enter until the kanban are exhausted, then as people leave and return the kanban someone new may enter.  From his experience he translated the technique into project management as a way to visualize and thus constrain the flow of work in progress (WIP).

WIP is the hidden killer of productivity among what Peter Drucker calls “knowledge workers”, most of us know this phenomenon as “multi-tasking”.  Multi-tasking is an illusion that a person is doing more than one thing at a time, however in reality most of the time you are in fact context-switching back and forth between multiple tasks very quickly and thus not fully engaged in either.  In some cases the consequences of multi-tasking are trivial, such as driving and talking on the phone, you are dividing your mental attention between both the conversation and your driving, but this is generally acceptable.  However, even in this common case, should either the driving situation or the conversation become serious, the facade of multi-tasking will reveal itself for the lie that it is; your attention can only be truly devoted to one thing at a time.  Think of a time you got into a serious discussion while driving… how much of the drive do you actually remember?

Anderson’s adaptation of kanban involves creating a card board by drawing rows and columns into which index cards or post-it notes can be placed.  Each kanban (card) represents work (a discrete task).  The rows  (swimlanes) are workers (a person, a team).  The columns are steps in the value chain representing state and have a work limit associated which limits how many cards may be in any given state at a given time.

In its most simplistic form, as shown above, there are 2 advantages gained: visualization and constraint of WIP.  Anyone can easily see how much there is to do, how much as been completed, and whats in progress, but most importantly we enforce our per-determined WIP limit.

Indeed truly constraining WIP is the strength of this system.  Any manager could create a “no multitasking” policy, but without visualizing the flow of work there is no way to enforce it.

But you probably already know all this, if your reading this, there are lots of “intro to kanban” blog posts and videos out there.  What few people know is what kanban is in a LEAN context… where it really came from and is intended to do.

Kanban was created by Taiichi Ohno as the primary signaling mechanism of the Toyota Production System (TPS) which enables “Just-In-Time (JIT) manufacturing”.  JIT is the evolution of Henry Ford’s “mass production” in which work was done in large batches and produced a lot of excess goods, aka waste.  The Toyota Production Systems foundational principles is on the reduction and elimination of waste (“muda”) so they decided to only build what they need when they needed it.. obviously there must be a buffer of finished goods inventory (cars waiting on a dealers lot to be sold), but they would keep that amount as low as possible.  So now, let me explain kanban again, but this time in the manufacturing (TPS or LEAN) context:

Kanban is Japanese for card.  At the assembly line sits a worker who puts the break assembly on the car.  The worker has a number of  “kits”, a plastic container which includes all the needed parts to build one break assembly.  The kits have kanban attached to them, so when she picks up a kit, she takes out the kanban and puts it into a tray and then builds the assembly.  Every hour a boy comes around and collects all the “used” kanban from the trays and goes to the parts dept.  The parts dept then refills the trays, attaches kanban to them, and sends them back to the assembly line.  So we’re effectively controlling and signalling the flow of goods in this closed loop. Here is an example of a real kanban:

But here is the really really important part… the kits are assembled from supplies of parts which have their own kanban, which control their flow.  So when a box of Part B is pulled from inventory to create a kit, that kanban signals the ordering of that part from the supplier.  The result is that instead of buying 200 of Part B every week because it matches our production schedule, we only order as many of Part B as we have kanban signaling us to do so.  At a Toyota plant, they don’t receive parts every week, they receive them every couple hours!  Kanban proliferated throughout Japan because when your using it for JIT, it requires that your suppliers do so as well to keep up with your speed… and their suppliers as well.  Here is a pallet of parts, look for the kanban attached:

So Just-In-Time manufacturing, with signaling from kanban, pulls along the entire supply chain from the final assembly line.  If you aren’t using the parts, they never get ordered… no mistakes.

Lets look at how this put Japan on top of the car industry in the 1970’s.  In 1973 there was an oil crisis, oil prices soared out of control.  People stopped buying cars.  The American mass production systems continued to build cars, which, thanks to “planned obsolesces” (new cars each year), caused a lot of those cars to go straight into scrap heaps.  American car makers suffered terrible losses all because the push based mass production system depends entirely on accurate forecasting, if its off you makes to few or, in the 1970’s, way too many.  Toyota, however, stopped making cars because people stopped buying cars… and because the supply chain only moves based on the speed of the final assembly line, it stopped too.  Toyota took losses on the small amount of inventory it had in the market, but didn’t continue to spit out cars until they were sold.  JIT saves the day thanks to kanban!

Both David Anderson’s Kanban and LEAN’s Kanban use cards, but I hope you can now see that the goals are very different.  In another blog post I’ll go into more detail on how we can apply LEAN principles to get the most out of your agile implementation.