Definition by 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 visualises 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 visualising 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.
Visual management tools are very common in agile shops, and for good reason - they work very well. It should come as no surprise, then, that kanban software development also employs various visual management tools, including a kanban board.
On the surface, there isn't much difference between an average task board and a kanban board. Each of these boards has various columns that represent the stages that a card needs to go through before it is considered done. The real difference in a kanban board, is not the board itself. The board is just a visual indicator, the same as any task board, and the intention is still to get the cards to the "done done" state - that is, delivered to the customer so that they can use the features from that card. The real difference is how the process is approached - by pulling value through the system.
When dealing with a kanban process and visualizing it into a kanban board, the various steps that a card goes through is often called a pipeline. A single card starts at one end of the pipe and flows through to the other end. This flow is enabled via the pull system that happens at the end of the pipe.
A Simple Software Development Pipeline
A software development pipeline works the same way as the grocery store pipeline. In this case, though, the product flowing through the pipe is likely to be a feature of the software package.
Consider the following three columns in a simple pipeline for software development: Analysis, Development and Testing. When a customer requests a given feature for a software product, they want to pull that feature out of testing so that they can start using it.
Customers Pull From Testing To Use A Feature
Once that feature has been moved out of Testing and the customer is ready to pull the next feature out, there isn't anything to pull. At this point, the Testing people would then try to pull the next feature out of Development.
Testers Pull From Development To Test A Feature
And the same pull happens from Analysis to Development.
In the end, we have created a pipeline for how our development process works. The work that is done flows through that pipeline based on how often the customer wants to pull features out. As one feature exits the pipeline, another feature can be added into the pipeline.
Kanban Pipeline - Features Flow Through
The key to all of this is, again, pulling the features through the system.