I'm pleased to be visiting here as a guest this week at Jeff's invitation. The topic at hand is kanban. Unfortunately, this entry is a bit long, because I want to go beyond the usual level of sound bites afforded to an important topic.
A Terminology Tour
Kanban is a Japanese word that just means sign. It is used to control work in progress, in the context of a production line where flow has already been established (Ohno, Toyota Production System, Chapter 2). The concept has found its way into software development, where it is often contrasted with Scrum or suggested as a complement to Scrum implementations. However, though most uses of the term hearken back to its origins in the Toyota Way, its popular use misconstrues much of its original intent.
The Toyota Way is a system of building things that, as a formalism, goes back to the mid-20th century, and has explicit roots in the early 20th century or even the latter 19th century. It is the way Toyota runs. Many other Japanese companies, starting with Toyota's suppliers but including many others, follow the same principles of overlapping development phases, self-organization, and learning. We find many of these companies mentioned in Harvard Business Review's El nuevo juego del desarrollo de nuevos productos by Hirotaka Takeuchi and Ikujiro Nonaka. This is the paper that inspired Scrum, and Jeff Sutherland continues to work closely with Nonaka today, as Jeff describes in "Takeuchi and Nonaka: The Roots of Scrum."
Takeuchi spent six years studying Toyota and summarized the apparently paradoxical culture in the book Extreme Toyota. The historic relationship between the Harvard Business Review paper, and Toyota, is sometimes indirect, though the principles of the two align well. For example, the notion of starting design before analysis is complete (which we will revisit later, below) is explicit both in the Takeuchi and Nonaka paper and in Liker's description of the Toyota Way. The use of versatile, diverse teams comes out both in the Harvard Business Review paper and in Extreme Toyota.
En Jeff''s blog describes, it's important to distinguish The Toyota Way from Lean. "Lean" in its common, vulgar use — particularly in methodological settings — is too often interpreted as a shallow way to apply Toyota Way tools to production without adopting its deeper foundations. Kanban is one such tool. It can be a powerful part of a production system that already has working flow, but it's crucial to understand that the foundations of flow must come first. In this article, the term "Lean" will arise occasionally in quoted material that, unless explicitly mentioned otherwise, refers to the Toyota Way.
Scrum is a framework for building product that is based on The Toyota Way. There are few differences between their fundamentals: e.g., the Toyota Way has a Chief Engineer which Scrum splits into a Product Owner and a ScrumMaster. As we'll discuss below, Scrum is neither built on kanban nor has a need for kanban, because it is ideally suited to a mechanism for limiting work-in-progress called one-piece continuous flow.
How is Kanban used?
In Toyota, kanban is used in two major ways. The original application of kanban (as a sign — see the example at the right, from Liker's book The Toyota Way, Chapter 2) was to placate a failure mode in the Toyota Production System. Sometimes you can't have one-piece continuous flow, because of impediments like multisite development, poor organizational structure, or bad assignment of workers to work locations. If you are a supplier far away from your consumer, you need a semaphore to synchronize the handoff of goods. The kanban card is that semaphore. When the consumer is running low on parts, the consuming work cell puts a kanban card in a supply cart that requests additional supplies. The cart is wheeled to the point of supply. Its arrival is a signal to the supplier to build more and to fill the cart, after which it can be wheeled back to the consumer. The consumer can initiate the request a little while in advance, giving the supplier time to respond to the request, or the supplier can keep some inventory on hand so that most requests can quickly be satisfied.
The supplier builds inventory which is put in a cart and delivered to the point of use. The cart is left there. When the cart starts becoming empty, you put a kanban card (a sign) in it giving information on projected need, and the cart is again taken to the point of supply so it can be filled up. You don't have kanban without the muda (waste) of moving the card and the cart, of the cost of storage for the inventory. You don't have kanban without the mura that comes from low-bandwidth communication between the supplier and consumer. By definition, kanban is based on having muri: instead of continuously flowing, the work bunches up. So this failure mode creates a need to limit work in progress. A disciplined use of kanban limits work in progress.
The other application is within a work cell, to ensure that only a limited number of parts (usually one) are on the table in front of the worker at any time. The table has kanban squares drawn on it. Parts being worked on must be within one of these squares. If parts stack up, it means that there is overproduction somewhere. If I'm a producer, I should produce something only if I can see that my neighbor needs, or is about to need, the part I build. I build that part to deliver to my neighbor just in time. Kanban squares are also used at a larger scale on the factory floor, as placeholders for pallets of parts or for larger parts (see figure at right; from leanmanufacture.net).
Kanban is a Wasteful Fall-Back for Repetitive Manufacturing Work
Kanban applies to repetitive work — building the same item again and again. Liker — author of The Toyota Way and highly regarded authority on the Toyota Production System — tells us:
Not everything can be replenished based on a pull system; some things must be scheduled. Take the example of high-end products, like a Rolex, a sports car, or those killer high-tech golf clubs advertised by Tiger Woods. Whenever you are buying a special or single-use item, you have to think about what you want, consider the costs and benefits, and plan when to get it. In a sense, you create a schedule to purchase, since there is no immediate need for it. (Chapter 9)
That is what software is like: We rarely build the same thing again and again. In manufacturing someone has to build any new parts that we need. In software, we can reuse a function as many times as we want by adding as many calls to it as we like, or reuse a class by instantiating a new object of it. Much design is based in innovative, incremental aggregation and extension of existing artefacts. This is particularly true in software, but also extends to industries such as building architecture and construction. Few design jobs plough totally new territory, yet none knowingly crafts a replica of past construction. It is about building new things to a scheduled market need rather than stochastic, repetitive production of the same basic form.
Liker goes on:
TPS experts get very impatient and even irritated when they hear people rave and focus on kanban as if it is the Toyota Production System... The challenge is to develop a learning organization that will find ways to reduce the number of kanban and thereby reduce and finally eliminate the inventory buffer. Remember: the kanban is an organized system of inventory buffers and, according to Ohno, inventory is waste, whether it is in a push system or a pull system. So kanban is something you strive to get rid of, not to be proud of. (Chapter 9)
Software Has Misappropriated Kanban
The fascination with kanban in Europe and North America has its roots in misinformation about how kanban fits into the Toyota Way, but there is a cultural element to the misunderstanding as well. Kanban is properly applied as a selective, detailed fix to a specific problem. It is not a philosophy of development. Sharon Begley observes:
Westerners prefer abstract universal principles; East Asians seek rules appropriate to a situation. (Sharon Begley, "East Versus West: One Sees Big Picture, Other Is Focused,"The Wall Street Journal, March 28, 2003.)
Taichi Ōhno, who invented the kanban system, tells us in his landmark book Toyota Production System:
Close supervision of the kanban rules is a neverending problem...
Rule 6 urges us to reduce the number of kanban... (Chapter 2)
The ideal is flow rather than kanban. Again, Liker advises us, "inventory buffers are used judiciously where continuous flow is not possible today. But the ideal of flow provides a clear direction." (Liker, The Toyota Way, Chapter 8)
The word kanban is also used as the name of a recently packaged methodology based on visualizing and mathematically analyzing work in progress. We see teams adopting this form of kanban, as a tool or methodology in its own right rather than as a worldview, without first having built foundations and disciplines of one-piece flow. Kanban (the methodology) discourages teamwork and increases the risk of not completing agreed work loads within a time box like a Sprint. It does give managers a lot of flexibility. That is, it allows the Product Owner to come to the team in the middle of the Sprint and stop what they are doing while introducing a new PBI or task. This interpretation of kanban sells to managers feeling a need to regain the control they lost with Scrum. The ability to patch things up, rather than solve root problems, gives a higher sense of immediate success without having to ponder long-term consequences of short-term decisions.
These misunderstandings of the Toyota foundations are deep, and though they often have kanban as a common thread they are not limited to software. If we look at Kanban.com we find a claim from the director of IT at CVG Systems: "To get the most benefit from kanban, we needed a closed-loop solution that would support a continuous-flow process, a solution that any of our suppliers could access easily." Kanban is a stopgap in the absence of one-piece flow — not a method to achieve it.
It is about separate groups controlled by a kanban protocol that replentishes inventory on demand (pull instead of push), in a highly structured way. It is a six-step, highly structured process (Ōhno, Toyota Production System, Chapter 2)
A Truly Lean Solution: One-Piece Continuous Flow
Instead of depending on kanban, true Lean eliminates mura, muriy muda — inconsistency, lack of continuous flow, and waste. Instead of tracking the movement and processing of materials, a good Scrum co-locates the teams or the devices that make the artefacts. The foundations of Scrum encourage one-piece continuous flow. Team members swarm around one PBI at a time. A common dysfunctional alternative is "swim-lane Scrum:" each team member individually taking ownership of a PBI through the stages of the process. If an individual gathers up multiple PBIs, or tries doing all the tasks in the PBI at once, you can get the context switching that comes from having too much work in progress. Kanban says to track the number of PBIs in progress, supported by pseudo-queuing theory math, to limit how many cards can be on the task board.
Good Scrum practice follows The Toyota Way by instead focusing on a single PBI at a time, building on the team's intelligence and self-organization — rather than a method — to manage work in progress. There are no longstanding subteams in a Scrum team: the Developers work together as a unit. It's individuals and interactions over processes and tools. If the team works as a unit, it eliminates the problem of waiting for work items to arrive from another development stage. It also eliminates both the inventory necessary to keep the development team busy at the local site, and the inventory being readied for shipment in parallel at the supplier. Kanban fundamentally depends on both of these inventories.
One-piece continuous flow can take place in a single team working as a tightly-knit unit, in a single work cell (or Scrum team), to apply several transformations to work in progress (which is limited to a single piece at a time). The team does a little analysis, a little design, a little building, and a little testing all at once in very short cycles. Individuals are multi-talented, reflecting the Toyota concept of chaku-chaku. See the illustration at right, taken from Figure 8-4 in The Toyota Way. It reflects a quite unstructured way of working, as Takeuchi and Nonaka relate in the Harvard Business Review paper:
Rather than moving in defined, highly structured stages, the process is born out of the team members' interplay... A group of engineers, for example, may start to design the product (phase 3) before all the results of the feasibility tests (phase two) are in. Or the team may be forced to reconsider a decision as a result of later information. The team does not stop then, but engages in iterative experimentation. This goes on in even the latest phases of the development process.
Liker underscores one-piece flow in Chapter 3 of The Toyota Way:
... the one-piece-flow cell is the ultimate in lean production. It has eliminated most of Toyota's eight kinds of waste.
In fact, the ultimate goal of lean manufacturing is to apply the ideal of one-piece flow to all business operations, from product design to launch, order taking, and physical production.
Pair programming is one of the best analogies we have in software. There is no coder and no tester: there are two developers working together in a work cell continuously testing and developing until the work in progress is done-done-done. Good pair programming is quite unstructured. Because the feedback loops happen locally and immediately there is no need for a literal kanban card. Because it happens as two minds working as one, there is no need for kanban squares below the keyboard. Again, Liker says, "In a one-piece-flow cell, there is very little non-value-added activity like moving materials around. You quickly see who is too busy and who is idle." (The Toyota Way, Chapter 17)
It doesn't stop at pair programming. One-piece continuous flow is a staple of the techniques we teach ScrumMaster Certification course attendees to apply across the entire team throughout the sprint. In the Velocity Game exercise we emphasize that the entire team should work on one PBI at a time — swarming instead of playing Swim-Lane Scrum. The pace is frantic but the flow becomes smooth after two or three sprints — because there is complete visibility of who is doing what, second by second. Kanban cards would just get in the way. Good development teams are like football, hockey or basketball teams. The players and artefacts of the game are the most important considerations to understand the nature of work in progress.
Pair programming as a technique depends on having the larger Scrum flow in place: good enabling specifications from the Product Backlog, self-organization and task selection among the developers, and so on. The same is true with the other forms of flow within a Scrum team. It's not a quick fix, and there is no quick path to building the foundations of quality and efficiency. In fact, kanban was one of the later additions to the Toyota Production System because it had to wait until the broader flows were in place. As Ōhno relates, "Outsiders seem to think that the Toyota Production System and kanban are the same thing... But... Unless one completely grasps this method of doing work so that things will flow, it is impossible to go right into the kanban system when the time comes." (Ōhno, Toyota Production System, Chapter 2)
Kanban: A Good Fit for Teams that View Work as Firefighting
Toyota production plants and Scrum teams exist to build product. The literature speaks of successful application of kanban in the service industry, analogous to firefighting or hospital emergency rooms. It's tricky to schedule your next fire unless you live in the world of Fahrenheit 451. Many development teams run in firefighting mode, often with "swooping" from the Product Owner during a Sprint. And getting into a discipline is hard: it's easy to want to be able to react immediately to customer change instead of integrating a request into the business plan, and it feels good to release whenever you see fit. Some Scrum teams never learn the disciplines of planning and estimation. It is easy to see how these organizations gravitate to kanban.
It is difficult for these teams ever to develop a true sense of teamwork and working together, of feeling a sense of ownership for completing work to a forecast, or to develop the disciplines of long-term planning and enabling specifications that are at the foundation of long-term value. The problem with kanban (as with Scrum-butt) is that the resulting poor execution won't kill you. In his book, Liker expresses astonishment at the ignorance of supposed Lean practitioners, and has seen as much as 80% reductions in inventory after their understanding is clarified (Liker, The Toyota Way, Chapter 14). He says:
I have visited hundreds of organizations that claim to be advanced practitioners of lean methods... [H]aving studied Toyota for twenty years it is clear to me that in comparison they are rank amateurs.
He feels that less than 1% of companies outside Toyota "get it." (Liker, The Toyota Way, Chapter 1) Many of these companies are following the pop buzzword Lean instead of the core Toyota Way. The Scrum framework, as defined, has carefully avoided this trap (see "Takeuchi and Nonaka: The Roots of Scrum").
The same is true in software. Teams that have done both have found that kanban can actually afford less visibility to the business of work in progress than Scrum does, and take away the sense of teamwork and "positive pressure" that comes from the flow of a Scrum team (see Samuli Heljo's reflections).
Taking on Kaizen Mind: Back to the Foundations
Spanish 
English 
French