After the end of the Second World War, the Toyota Motor Co. set a daring objective: Catch up to America within three years. Back then, Japanese automobile manufacturing lagged far behind American powerhouses. Few outside of Japan took it seriously.
But then Toyota did it.
Production engineer Taiichi Ohno set out to minimize as much inefficiency within the manufacturing process as possible. He recognized the company's habit of stockpiling excess inventory was hurting their productivity and that “pushing” cars down the assembly line before stations were ready to work on them caused blockages, resulting in wasted time and half-finished products.
Ohno cut inventory down to the bare minimum and created a new system relying on kanban—signboards—to ensure smooth flow of products down the production line, allowing Toyota's factories to process more orders, faster. The result was the Toyota Production System (TPS), often referred to as “lean” or “just-in-time” (JIT) manufacturing. The TPS quickly became the gold standard for manufacturing and was soon being emulated by factories worldwide.
In the early 2000s, software development was struggling. Engineering teams had an inventory problem of their own—huge backlogs of work which resulted in half-finished products, unpredictable delivery dates, and burnt-out workers. Not unlike the postwar Japanese automobile industry. Inspired by the Toyota Production System, David J. Anderson created the Kanban Method.
In Japanese, kanban (看板) means “signboard” or “signal card.” In a factory environment like Toyota, workers use these signboards to signal upstream stations on the production line to produce more. This ensures that each station only makes more products when the next station is ready for new goods.
The Kanban Method devised by David J. Anderson—which we'll just call Kanban (capital K) from now on—applies the manufacturing theories of the Toyota Production System to knowledge work, particularly software development. Simply put, “Kanban is an approach that drives change by optimizing your existing processes,” explains Anderson.
Kanban is an approach that drives change by optimizing your existing processes.
-David J. Anderson, creator of the Kanban Method
Anderson's methodology is based on four main ideas:
Anderson first tested Kanban at Microsoft in 2004, to great success. After some further experiments at other companies, he began to share his findings. Soon, the idea took off. It was quickly adopted by tech companies like Yahoo! and spread around the world. The success of the method prompted Anderson to codify it in his 2010 book, Kanban.
Kanban is a mirror. It reveals your processes as they are, not what you think they are or want them to be. While software development and other kinds of knowledge work may not physically move along a factory production line, projects do move through production stages from beginning to end—this is what Kanban illustrates. In software, this is known as the development pipeline.
Kanban begins by mapping these stages and figuring out how much work-in-progress (WIP) is at each phase, using a kanban board. Here's an example of what such a board could look like:
As teams begin to make incremental changes to their workflows, the kanban board reflects these changes back to them. One key first step in Kanban is to limit the amount of work-in-progress (WIP) in the entire system. This was one of Taiichi Ohno's most important observations: Excess inventory slows work down and results in a worse final product. Anderson recognized that this principle applies just as much to virtual work as physical manufacturing. In a knowledge work environment, more WIP incentivizes multitasking—which is more inefficient and ineffective than single-tasking—and draws out the time between feedback cycles.
Less WIP allows team members to work on one thing at a time and complete production cycles more quickly. These shorter iterations allow for faster feedback, meaning that teams can correct problems quickly and design quality into products from their earliest stages. In addition to improving efficiency, reducing WIP helps reveal where bottlenecks are. For instance, visualizing your team's work on a kanban board may reveal that you have the capacity to design and build five new features simultaneously, but only test two—meaning that testing is your bottleneck.
Once teams can identify their bottlenecks, they can begin to make small changes to make the most of them. This is where the pull system comes in. Teams can strategically implement queues so that a bottleneck pulls in new work from earlier stages, when it's ready, not when earlier phases push new work along. As a result of these improvements, the bottleneck may actually move, and the process of identifying and optimizing it begins again—that's the philosophy of kaizen in action.
“A strength of Kanban is that it does not start with an anxiety-inducing upheaval,” writes Kanban blogger David Peterson. “It starts simply by mapping out the existing process exactly as it stands.” This makes it easy for teams to start implementing Kanban. Crucially, it also reduces fear around change. “Asking people to change their behavior creates fear and lowers self-esteem, as it communicates that existing skills are no longer valued,” writes Anderson. By contrast, Kanban lays a foundation of trust which enables ongoing, incremental improvement.
We know from studies of human conduct that observation can be a powerful driver of behavior change. In one Dutch study, households with highly visible electric meters used 30 percent less power than their neighbors whose meters were located out of sight. They adjusted their habits in response to visual feedback. Similarly, “Kanban will reveal opportunities for improvement that do not involve complex changes to engineering methods,” says Anderson.
Kanban does not demand conformity. Rather, the method is adaptable to diverse practices, team structures, and goals. Since Kanban relies on simple changes to drive sustained improvement, these practices can be adopted in almost any work environment with little disruption. Teams or individuals can use Kanban in vastly different ways and still experience the same benefits of shorter production cycles and better quality results.
By enabling teams to track, understand, and gradually improve their workflows, Kanban helps practitioners establish a regular production cadence. Regular, high-quality releases improve customer satisfaction and build trust with other departments and stakeholders. A sustainable work pace is also important for teams' overall well-being—it prevents people from scrambling to meet last-minute deadlines, at the cost of their mental and physical health.
Unlike other systems, “Kanban is not a software development lifecycle methodology or an approach to project management,” says Anderson. “It requires that some process is already in place so that Kanban can be applied to incrementally change the underlying process.” Teams use Kanban in tandem with their existing SLDC and project management approaches to refine and optimize them.
“The way kanban boards make WIP visible is striking, but it is only one small aspect of this approach,” writes Don Reinersten in the foreword to Kanban. The board is a tool that enables teams to reduce their batch size, implement a pull system, and strive for continuous improvement. These techniques result in faster production cycles and better quality output.
Kanban can be used for all kinds of work. That's the beauty of Kanban: It's highly malleable to different projects, workflows, and team structures. In fact, it's so simple to learn that some families use the Kanban system to help kids manage chores at home. Anyone, individual or team, who produces some kind of output—be it software, blog posts, or even clean laundry—can benefit from Kanban and customize their board to their needs.