Kanban, which literally translates approximately into signboard, was originally a scheduling system for lean and just-in-time (JIT) production was perfected at the inspirational Toyota manufacturing plants. Kanban is a system to control the logistical chain from a production point of view, and is not an inventory control system. Kanban was developed by Taiichi Ohno, at Toyota, to find a system to improve and maintain a high level of production. Although perfected primarily with manufacturing process in mind, the same principles can be applied equally effectively in the software development process as well.
Although originally devised for the manufacturing sector, Kanban can be used effectively in the Software Development process also. It provides a method for developing software products and processes with an emphasis on just-in-time delivery while not overloading the software developers. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for participants to see and developers pull work from a queue, usually on a board, electronic or otherwise.
Cards or post-it notes are used to denote tasks and these tasks are visually moved from column to column to specify where in the development pipeline a particular task is at currently. Despite being really simple, it has found quarters in a number of different development houses the world over and is quickly becoming an integral part of the agile software development process.
The Kanban Method
A software development process can be thought of as a pipeline with feature requests entering one end and improved software emerging from the other end.
Inside the pipeline, there will be some kind of process which could range from an informal ad hoc process to a highly formal phased process. In this article, we’ll assume a simple phased process of: (1) analyse the requirements, (2) develop the code, and (3) test it works.
A bottleneck in a pipeline restricts flow. The throughput of the pipeline as a whole is limited to the throughput of the bottleneck.
Using our development pipeline as an example: if the testers are only able to test 5 features per week whereas the developers and analysts have the capacity to produce 10 features per week, the throughput of the pipeline as a whole will only be 5 features per week because the testers are acting as a bottleneck. If the analysts and developers aren’t aware that the testers are the bottleneck, then a backlog of work will begin to pile up in front of the testers.
The effect is that lead times go up. And, like warehouse stock, work sitting in the pipeline ties up investment, creates distance from the market, and drops in value as time goes by.Inevitably, quality suffers. To keep up, the testers start to cut corners. The resulting bugs released into production cause problems for the users and waste future pipeline capacity.
If, on the other hand, we knew where the bottleneck was, we could redeploy resources to help relieve it. For example, the analysts could help with testing and the developers could work on test automation.
The Kanban Principles
The Kanban method is rooted in these basic principles:
- Start with what you do now
The Kanban method does not prescribe a specific set of roles or process steps. There is no such thing as the Kanban software development process or the Kanban project management method. The Kanban method starts with the roles and processes you have and stimulates continuous, incremental and evolutionary changes to your system.
- Agree to pursue incremental, evolutionary change
The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and make them stick. Sweeping changes may seem more effective but more often than not fail due to resistance and fear in the organization. The Kanban method encourages continuous small incremental and evolutionary changes to your current system.
- Respect the current process, roles, responsibilities & titles
It is likely that the organization currently has some elements that work acceptably and are worth preserving. We must also seek to drive out fear in order to facilitate future change. By agreeing to respect current roles, responsibilities and job titles we eliminate initial fears. This should enable us to gain broader support for our Kanban initiative. Perhaps presenting Kanban against an alternative more sweeping approach that would lead to changes in titles, roles, responsibilities and perhaps the wholesale removal of certain positions will help individuals to realize the benefits.
- Leadership at all levels
Acts of leadership at all levels in the organization from individual contributors to senior management should be encouraged.
The board below shows a situation where the developers and analysts are being prevented from taking on any more work until the testers free up a slot and pull in the next work item. At this point the developers and analysts should be looking at ways they can help relieve the burden on the testers.
Notice that we’ve split some of the columns in two, to indicate items being worked on and those finished and ready to be pulled by the downsteam process. There are several different ways you can layout out the board. This is a fairly simple way. The limits at the top of the split columns cover both the “doing” and “done” columns.
Once the testers have finished testing a feature, they move the card and free up a slot in the “Test” column.
Now the empty slot in the “Test” column can be filled by one of the cards in the development “done” column. That frees up a slot under “Development” and the next card can be pulled from the “Analysis” column and so on.
As most business process experts will tell you, a process is as effective as the tool you use for the process. There are a myriad of tools available for Kanban based development. We have found great success in using simpler tools. Simpler the better. Trello is one such tool that provides a nice tradeoff between simplicity and rigidity.
You can find more tools that suit your specific needs here.