This is a pretty good visual of a ‘flowing’ process that is interrupted by an unwelcomed constraint. (cash vs. the Visa check card.)
Kanban is a lean approach to agile software development.
Actually, Kanban means many things. Literally, Kanban is a Japanese word that means “visual card”. At Toyota, Kanban is the term used for the visual & physical signaling system that ties together the whole Lean Production system.
Most agile methods such as Scrum and XP are already well aligned with lean principles. In 2004, however, David Anderson pioneered a more direct implementation of Lean Thinking and Theory of Constraints to software development. Under the guidance of experts such as Don Reinertsen, this evolved into what David called a “Kanban system for software development”, and which most people now simply refer to as “Kanban”.
So while Kanban as applied to software development is new, Kanban as used in Lean Production is over a half century old.
Does Kanban matter to me?
Do any of these sound familiar?
- “We’ve done Scrum for a long time now and our process improvement has levelled off. How can we take our process to the next level?”
- “Our needs and priorities shift on a daily basis”
- “We don’t like fixed-length, fixed-commitment iterations”
- “We are spending too much time planning and estimating”
If so, read on. Along with Scrum and XP, Kanban should be part of the process toolkit of any agile company. The choice of where & when to use it can only be made by you though.
How does Kanban work?
There are many flavors, but the core of Kanban means:
- Visualize the workflow
- Split the work into pieces, write each item on a card and put on the wall.
- Use named columns to illustrate where each item is in the workflow.
- Limit WIP (work in progress) – assign explicit limits to how many items may be in progress at each workflow state.
- Measure the lead time (average time to complete one item, sometimes called “cycle time”), optimize the process to make lead time as small and predictable as possible.
This is a direct implementation of a lean pull scheduling system.
Here’s an example of a simple Kanban board, with WIP limits in red.
Here’s a more complex one (see Kanban kick-start example for a closer look & description)
What are the benefits of Kanban?
Some commonly observed benefits are:
- Bottlenecks become clearly visible in real-time. This leads people to collaborate to optimize the whole value chain rather than just their part.
- Provides a more gradual evolution path from waterfall to agile software development, thereby helping companies that previously have been unable or unwilling to try agile methods.
- Provides a way to do agile software development without necessarily having to use time-boxed fixed-commitment iterations such as Scrum sprints. Useful for situations where sprints don’t make much sends, such as operations and support teams with a high rate of uncertainty and variabilty.
- Tends to naturally spread throughout the organization to other departments such as HR and sales, thereby increasing visibility of everything that is going on the company.
Can I combine Kanban with my current process?
Yes. In fact, you should combine it.
In Kanban the first step is to visualize your current process, just as it is, in order to see where the bottlenecks are. Then you introduce WIP limits and start a path of evolution that may or may not modify or replace your current process over time.
Where is Kanban used?
Our coaches at Crisp have helped several clients use Kanban to improve their process. In fact, a surprising number of our clients have found that Kanban is an extremely useful complement (or sometimes even a replacement) to other popular agile methods such as Scrum. Typical manager comment: “It really helps us visualize our projects and situation”.
There is also an increasing number of case studies available at www.limitedwipsociety.org. Here are a few examples:
- Improving operations using Kanban, Mattias Skarin, Developerdays 2009
- David Anderson’s case study – and why lead time is best metric
- David Joyce shows how a Scrum team improves by moving to Kanban with Statistical process control data
Common misunderstandings about Kanban
- Myth: With Kanban you don’t use iterations
- Fact: With Kanban iterations are optional. Do it only if you have a need for it in your context.
- Myth: With Kanban you don’t estimate
- Fact: With Kanban estimation is optional. Do it only if you have a need for it in your context.
- Myth: Kanban is better than Scrum/XP/RUP/whatever
- Fact: Kanban is just a process tool, and there is no such thing as a universally good or bad tool. It all depends on your context
- Myth: Kanban is a drop-in replacement to Scrum/XP/RUP/whatever
- Fact: Kanban is just about managing workflow. It hardly replaces anything. What it does do, however, is drive change. In Kanban you start with whatever process you have, visualize it, introduce WIP limits, and then evolve from there.
- www.limitedwipsociety.org – main Kanban resource site
- Kanban & Scrum, making the most of both (article by Henrik & Mattias)
- One day in Kanban land (comic strip by Henrik)
- Kanban kick-start example (template by Henrik)
- How can support and operations be Agile (slides by Mattias)
- Mattias’ blog entries on Kanban
- Henrik’s blog entries on Kanban
- Queue utilization is a leading indicator (Corey Ladas)
from GBMP (http://www.gbmp.org/)
Learning About Process Improvement
The #1 selling Lean training tool in the world is the Perfect introduction to Continuous Improvement.
Narrated by and featuring Bruce Hamilton, Shingo Prize Recipient and GBMP President, this 27-minute video highlights the seven deadly wastes found in both administrative offices and in manufacturing processes. In this training tool, the process of making toast is used to represent the before condition and the target condition of a manufacturing or transaction-based process and helps your people to identify with the process of Kaizen(small and continuous improvements). Whether you are already on the Continuous Improvement journey or you are just beginning to realize the power of continuous improvement implementation, this video is an essential learning tool for your entire workforce.
Click here to open the video file.
The “Thinking” Production System:
TPS as a winning strategy for developing people in the global manufacturing environment
At the 2003 Automotive Parts System Solution Fair held in Tokyo, June 18, 2003, Teruyuki Minoura, Toyota’s an aging director of global purchasing at the time, talked about his experiences with TPS (the Toyota Production System), and what it means for suppliers and for the future of the auto industry.
At the 2003 Automotive Parts System Solution Fair, held in Tokyo, June 18, 2003, Teruyuki Minoura, then-managing director of global purchasing, Toyota Motor Corporation, talked about his experiences with TPS (the Toyota Production System), and what it means for suppliers and for the future of the auto industry.
Teruyuki Minoura is confident that the long-standing principles of the Toyota Production System will not change in the future, and that TPS will be able to meet any challenge. He noted that the system originally emerged through a trial-and-error approach aimed at solving practical problems and meeting the needs of the company. Recalling painful memories of the labor dispute of 1950 that destroyed so many friendships, he observed, “Businesses suffer if efforts are devoted to raising productivity when the products themselves cannot sell.” It was through such experiences, that the basic concept of just-in-time was born.
In simplest terms, Just-in-time is “all about producing only what’s needed and transferring only what’s needed,” says Minoura. Instead of the old top-down “push” system, it represented a change to a “pull” system where workers go and fetch only what is required. Tools, including the kanban (information card), andon (display board), and poka yoke (error prevention) were developed to implement the pull system. But, Minoura warns “simply introducing kanban cards or andon boards doesn’t mean you’ve implemented the Toyota Production System, for they remain nothing more than mere tools. The new information technologies are no exception, and they should also be applied and implemented as tools.”
Early in his career, Minoura worked under Taiichi Ohno, recognized as the creator of the Toyota Production System. Ohno, through tireless trial and error, managed to put into practice a “pull” system that stopped the factory producing unnecessary items. But Minoura observes that it was only by developing this “loose collection of techniques” into a fully-fledged system, dubbed the Toyota Production System or TPS, that they were able to deploy this throughout the company.