Kanban,” which is Japanese for “signboard” or “billboard,” is a method in just-in-time (JIT) production systems where cards are used to signal when materials should be moved to a different location. I first heard about kanban boards being used for Agile software development about a year ago and determined that it was an inexpensive experiment to try in an effort to improve the focus and visibility of our software development process.
Why Use a Kanban Board?
You are likely already familiar with burn down charts, which show how many tasks remain and how much time is left in a sprint or iteration. Like a burn down chart, a kanban board is a visual representation of the work left to do.
However, a burn down chart typically corresponds to an iteration or sprint, while a kanban board can correspond to any milestone. It shows specific tasks to be done before a project is complete, and a project can be anything with true business value—whether it’s a feature set, getting a product to alpha or some other business goal.
Also, because burn down charts require keeping track of the ideal and actual tasks for an iteration and should be updated daily, they can be somewhat tedious to create and maintain. A kanban board does not show the time remaining or how much time each task is expected to take, and this simplicity and flexibility is one of the reasons kanban boards are easy to implement.
Implementing Kanban Boards
We use kanban boards to keep on track and monitor the progress of high-profile projects. First, we write down each task that absolutely has to get done on its own sticky note. While it may be tempting to include “desirable” tasks as well, this will slow down the project. One of the benefits of using a kanban board is that it forces the stakeholders to reach agreement on what is absolutely required. Since our development process is done using an agile process, it’s not unusual for the required tasks to change as the project is underway—and you can add or remove tasks as needed.
The sticky notes are then placed on a whiteboard (or extra-large sticky note) in the developer bullpen or other highly visible location. The title of the project should be written on top, and it should be divided up into workflow categories, such as “to do,” “in progress,” “quality assurance,” “alpha,” “done” or whatever descriptions make sense for your environment.
Initially, all the sticky notes go in the “to do” section. Then as items get worked on, they move to the “in progress” section, continuing on to “done” as they work their way through the development process. If an item doesn’t pass testing, it goes back to “in progress.” A quick glance at the kanban board tells the product manager and other stakeholders where tasks are in the development cycle, whether or not the project is progressing and how close a project is to being done.
Kanban boards can be implemented at any time during a project. We typically create the kanban board after the project is in progress, rather than at the very beginning. This way the project is better understood, so there will be less churning of sticky notes. Once all the sticky notes are on the board, the stakeholders can decide if the board works as is, if any tasks should be deferred or if the project needs to be redefined. Being able to see a visual representation of the work to do on a project makes it easier for us to decide if anything is missing or if there’s too much work for the desired completion date.
HIGH TECH OR LOW TECH?
As you might expect with a tool used by developers, people have written software to implement kanban boards. An advantage to using software is that if it links to your development software, the boards are updated automatically in real time. For teams that are geographically distributed, kanban board software might be a good choice. Our programmers are all in the same location and usually in the same room, so we currently use a low-tech implementation. A couple of things to keep in mind when making the decision between a high-tech and low-tech implementation are that 1) the product manager must be able to access and maintain it and 2) the kanban boards should be highly visible.
This article focused on using kanban boards for software development, but because of their flexibility, there’s no reason they can’t be used for other projects such as releases or marketing activities. You can even implement them while continuing to use burn down charts, using burn down charts to track iterations or sprints and kanban boards to provide greater visibility to major business initiatives that might span multiple iterations.
