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.
Love this poist! I am working at a distributor who sells to major Japanese auto manufactures in the US and I have just learned about Kanban recently. I would love to put this into action but I keep coming back to the nagging worry that it takes more time to setup and maintain than it’s worth for a small team.
How can I make sure that maintaining the system doesn’t become more important the the task itself?
This is where principles and goals are important. In LEAN, improvement projects are initiated by an A3 report which I’ll talk about some other time… but in short, you need to write down at least 3 things:
* Where are we now? (Current Reality)
* Where do we want to be? (Future Reality)
* How do I propose we get there? (Execution Plan)
Put that on the wall where everyone will see it. In a factory A3′s are facing the enterence to the plan floor so everyone always see’s them.
This technique keeps you centered on where you want to go. If you do NOT write it down, you’ll go off track as you learn and start geeking out on some aspect of it, forgetting the true intent.
And remember to also put due dates on your project plan, even if you don’t have to. If you don’t, things will slip and you won’t have the sense of urgency to do what you set out to do.
Hi John,
Start with what you know/do already, and take it from there.
The Kanban method scales very well.
Nice post Ben!
This reminds me of token ring… loved the description of kanban and kanban cards. I wonder if kanban can be used in programming algorithms or system administration?
I’ve been using Kanban for both personal and professional tasks for about two months now. I read the book “Personal Kanban: Mapping Work | Navigating Life” by Jim Benson and it caused me to ditch all my to-do lists, notepads, scribbles, work documents, and etc. Now, everything is kanban-itized!
As a visual learner, kanban has darn near revolutionized my ability to get things done. In fact, I just revamped my value flow last week into version 2.0 of my personal kanban. I’ve annoyed so many people lately with the word “kanban” that I was going to write a post about it, but perhaps I’ll just link people to this post of yours. =) This is what my latest flow looks like for all things personal and professional: http://img.ly/iZRf
I’ve tried this personally, since I am a terrible multi-tasker. Nearly impossible to implement without a high level managerial commitment because most people are evaluated by how much work is “in progress” rather than by how much gets actually done. I am rarely deemed “successful” in those situations, even if my goals are met.
The driving analogy is a good one: in my locale (en_GB) driving and using a phone has been criminalised, is now very socially unacceptable and is cracked down upon hard, therefore the first bit reads as a much stronger criticism of multitasking than you intended
This all sounds well and good until I read this line:
“At a Toyota plant, they don’t receive parts every week, they receive them every couple hours!”
There is tremendous overhead associated with making multiple parts deliveries per day (loading/unloading/delivery + all associated manpower costs). This overhead translates into a significant amount of waste. This works if you are vertically integrated and can absorb all that waste, but this seems highly implausible for anything but the largest companies with the best supply chains and strangleholds over their suppliers.
Toyota, the 9th largest manufacturer in the world, can do this. What about the little guys? This doesn’t seem like a very financially lean process to me.
Going back to kanban as a personal time management, yes, it does help highlight flaws in your workflow, but it also seems like there is a lot of overhead that never gets factored in. It strikes me as if this method really only benefits those who grossly mismanage time and have no clue how to organize their lives. For everyone else, there may be a small benefit, but the overhead digs deeply into that.
Am I missing something here?
If you’re a large manufacturer who’s able to dictate to suppliers, then it’s great. There are overheads and waste no matter what system you use – obviously the aim is just to lower them as much as possible, while also limiting the risk to the business.
As you suggest, it wouldn’t be for everyone. I imagine that most readers of this blog have experienced management reading about a system like this and then attempting to implement it in a completely inappropriate environment…
G.K.,
The issue that you mention is the challenge of dealing with Transaction Costs. This is where you find a significant difference between a kanban system in manufacturing and the Kanban method as explained by David Anderson for knowledge work.
Every type of work has its own type of transaction cost. For manufacturing this involves transport, order processing, setup time for a work station.
Knowledge work has hidden transaction costs: and all cost/waste in knowledge work is typically expressed in time. Time spent waiting, time spent in switching context.
Kanban will make this kind of cost very visible, and measurable. Once you measure things, you can do something.
Start small, and evolve your kanban system.
Brings back old memory when learning JIT for manufacturing over 15 yrs ago.
Ha. Also en_GB and was shaking my head at the idea that the consequences of driving and using the phone are ‘trivial’. I guess that social conditioning is working!
Reminds me of unix operating system internal concepts like semaphore and mutex.
Drone,
If you like that metaphor, I recommend Don Reinertsen’s book on
‘The Principles of Product Development FLOW/Second Generation Lean Product Development.’
Don takes examples from different realms, from manufacturing to Operating System Design to Military Operations. A very good read.