This is a discussion and definition of Kanban from Karl Scotland:
"While the word Kanban comes from the Japanese for “visual card”, the term Kanban as used by the Kanban Software Development community, represents much more than a standard task-board. Additionally, the Kanban Software Development community have not tried to replicate the mechanism of the Toyota Production System kanban tool exactly, but have taken the underlying principles in order to achieve similar effects in software development. So what is a Kanban System for Software Development?
A Kanban System visualizes some unit of value. This unit of value could be a User Story, Minimal Marketable Feature, Plain Old Requirement or something else. This is different from a task-board, which generally focuses on visualizing the current tasks.
A Kanban System manages the flow of these units of value, through the use of Work In Process limits. This is different from a task-board, which generally has no WIP limits, but aims to have all tasks complete by the end of a time-box.
A Kanban System deals with these units of value through the whole system,from when they enter a teams control, until when they leave it. This is different from a task-board, which generally only deals with the work in the build/test stage, but shows no information about what work is being prepared, or what work is ready for release.
By putting these 3 properties of a Kanban System together, we can describe a Kanban System for Software Development as one which allows value to flow through the whole system using WIP limits to create a sustainable pipeline of work. Further, the WIP Limits provide a mechanism for the Kanban System
to demonstrate when there is capacity for new work to be added, thereby creating a Pull System. Finally, the WIP Limits can be adjusted and their effect measured as the Kanban System is continuously improved.
A task-board simply shows what development tasks have been predicted to be done in the current time-box, with their status."
Kanban fills a niche in the world of Agile Development in that it provides a system to control the flow of work where the development team has other duties (production support, multiple projects) and cannot work in dedicated Scrum Sprints (Agile iterations). Kanban allows for teams and individuals to work on specific units of value and advance them through the various stages based on WIP limits.
Here is a great story from the Kanban Development Oversimplified article that illustrates some of the key pieces of Kanban:
"You’ll find a lot of terminology in Lean software development comes from Japan and from the Toyota Production System in particular. Kanban translated literally: “Kan” means visual, and “ban” means card or board.
Picture yourself on a Toyota production line. You put doors on Priuses. You have a stack of 10 or so doors. As you keep bolting them on, your stack of doors gets shorter. When you get down to 5 doors, sitting on top of the 5th door in the stack is a card — a Kanban card — that says “build 10 doors.” Well it may not say exactly that — but it is a request to build exactly 10 more Prius doors.
You pick the Kanban card up, and run it over to the guy who builds doors. He’s been waiting for you. He’s been doing other things to keep busy while waiting. The important thing here is that he’s NOT been building Prius doors. He takes your Kanban card and begins to build doors.
You go back to your workstation, and just a bit before your stack of doors is gone, the door guy comes back with a stack of 10 doors. You know that Kanban card is slid in between doors 5 & 6. You got the doors just in time. The whole thing sorta works like magic. Only you wish you had the door-building job. That guys seems to have a lotta free time on his hands.
Kanban cards are used to limit the amount of inventory the factory builds. It doesn’t do the Toyota factory any good to build doors faster then they can assemble cars. It just wastes money on excess doors, and parts of doors. Excess work in progress is considered to be waste in Lean manufacturing. (It’s probably waste in non-Lean manufacturing too.) In the above completely made up example, you’ll never have more than 15 finished doors hanging around. (Mudha is Japanese for waste. Learn it to impress your Lean friends.)"
The article goes on to the more practical aspects of the process:
"Kanban thinking in software development attempts to do a similar thing. We want to limit unnecessary work in progress to be no higher than it needs to be to match the throughput of the team. Kanban thinking applied to Agile development results in sweeping changes that throw out much of what Agile practitioners consider necessary practice.
In Kanban development:
By now you should be scratching your head a bit. Exactly what’s left of Agile if we get rid of time-boxes, change the meaning of stories, and stop measuring velocity. And, exactly what do car doors and Kanban cards have to do with software development?"- time-boxed development is out
- stories are larger and fewer
- estimation is optional or out completely
- velocity is replaced by cycle time
A key component of Kanban is the visual board that is used for managing work in process. Most of the time it is a physical board similar to this one:
There are also online versions of Kanban boards such as LeanKit Kanban and Kanban Tool. The key is to use some type of information radiator so that everyone can see what is on the board and what the status is. Seeing the flow is also important so and bottlenecks can be identified and cleared out. It is important to set limits for each stage in the process as this will govern the flow of cards from point to point.
All of the columns should be customized to the team and the project being worked on. There are several aspects of Scrum that need to be upheld, especially in the area of collaboration and communication. Just because there isn't a defined iteration schedule does not mean that the software is not demonstrated and planning meetings are not needed. These are scheduled at some interval so that the customer gets to see working software and the team is able to work together to keep the flow moving. Regular review of the process (similar to the Scrum Retrospective) is also done as part of Kanban. There are other aspects of Scrum and Agile that the team can use as part of this process. Again, customization of the process is encouraged.
This is a very brief overview of one of the emerging software development methods. Please access some of the references on the Limited WIP Society website for more in-depth information.
I hope you found this interesting and informative. Please post questions and comments below.
