Kanban is the japanese word for signalling card, but a signal for what? In the 1950s a Japanese delegation including Sakichi Toyoda (founder of Toyota) and Taiichi Ohno (on of the masterminds behind the Toyota Production System) went to
the United States to observe how Ford was mass producing cars. They were not impressed. During a stop at an american supermarket they witnessed how items were automatically resupplied once sold. The beauty of this concept was its ability to ensure a sufficient number of items was available to customers, without having to bind too much cash in unneeded inventory.

Reading the InfoQ newsletter the other day, I found that "Kanban is the hottest buzz since the dawn of XP" (eXtreme Programming). It is really so? Kanban is great for limiting queues of items with a certain level of uniformity - but does software requirements fit that? We certainly have queues of work that needs to be controlled - and requirements certainly can be described in a somewhat uniform way. The question really is - before implementing a kanban system to limit work-in-process, do you know for a fact that this is your biggest issue? I look forward to see kanban systems implemented in software development organizations where highly varying task size, complexity and context is addressed effectively.

By Sune Gynthersen

A task board has been used by many teams when doing Agile development to have a shared place to manage tasks in the iteration.  I have used it myself in a lot of different formats when working with R&D development, customer projects and also working together with offshore teams.

It can be a great tool for the team and creates more collaboration, feedback and risk mitigation when having a visible task board.

But, you might also have more frequent requests from other teams or customers and maybe you also work with maintenance tasks of existing products in production. It can be challenging to combine focus in the iteration with different ongoing requests.

One alternative approach to the traditional task board and iteration planning can be a Kanban system. Kanban is the Japanese word for visible card and originates from the Toyota Production System. It is used to minimize inventory, enforce Just-In-Time and eliminate waste.

I have used the Kanban approach to extend the traditional task board with limits on the number of concurrent tasks in different states to reduce work in progress and apply a more pull oriented process. When working with many different specialists in one team, I have also seen high value by extending the board with more states to manage the work of the different specialists. It makes it much more visible and easier to follow the flow and find wastes in the process.

In one team we combined the Kanban approach with a two week release rhythm and that enabled the team to both have a rhythm of planed activities and also do more frequent business requests depending on their capacity and the business prioritization.

The combination of the more traditional iterative processes together with a Kanban approach is very interesting, and I think many teams and organizations will find a lot of value and increased productivity looking into this area.

By Mads Troels Hansen

Last week I attended an Agile conference in Copenhagen. Among the speakers were David J. Anderson, who did a session on kanban systems. He told the audience the story of the kanban system used in the Imperial Palace in Tokyo, Japan. The Imperial Palace, is really like a big park with various buildings inside. I was in the park with my colleagues during our Japan 2008 Lean study tour last spring, and I remember being impressed with the kanban system used in the park, as a simple and truly elegant solution.

When you enter the park, which can be done at several different locations, you receive a little plastic brick. When you leave the park, you hand it back to the lady in uniform at the exit. My first thought was, that it was used to ensure that everyone got out before night. Interestingly that same answer came up at the conference when David Anderson asked the audience what they thought it was used for.

However, imagine a single plastic brick is missing when the park closes. Did someone loose their brick, or are they still inside the park? Should resources be spent on going through the park looking for them? With thousands of daily visitors, bricks will be lost probably on a daily basis, so it's not a way to ensure everyone gets out.

Instead it is a way to limit the number of concurrent visitors in the park. The number of bricks is limited to the highest number of concurrent visitors accepted. That means that the entrance booth may run out of bricks, and then stop letting more people into the park. They can start letting more people in when they get some of the bricks left at the exit. If a brick is lost? No big deal - that just lower the maximum number of concurrent visitors by one.

The concept is exactly what is also used in Lean manufacturing to control the amount of work-in-process. And of course it can also be used in software development environments to limit work to current capacity.

If you should ever go to Tokyo, I would highly recommend going to the park. It is quite beautiful.

By Sune Gynthersen