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.