Kanban - An Overview

What is not Kanban?

• A project management method (like Scrum)
• A process (not necessarily)
• Iterative

So, what the hell is Kanban?

Kanban (kahn-bahn) is a philosophy created by David Anderson for product development that has been applied for software development for about nine years. It isn’t restricted to the approach to the Lean Concept of Toyota Production System, though it follows its directives, like the continuous flow and also the improvement, through a culture called Kaizen.

Its goal is to help the team to make an efficient delivery of value over the project, through some purposes:

• makes the supply chain process visible to everybody,
• limit the work in progress (WIP)
• help work to flow

The practice of limit the work in progress makes the process different from the cascade model, where lots of work is done and no value is delivered. This is a good way to identify bottlenecks and improvements points, as well as to avoid the buildup of tasks in some point of the process.

The main idea of Kanban is to not think about time boxed iterations, but to have a continuous process. It values the team collaboration and support them to have focus and a sustainable pace.

The definition of Kanban in Japanese is related to billboard, wall – stuff that, through a mapping on the supply chain, makes those visible to everyone.

Some stories are selected on the backlog to be sticked on the first column of the production line shown on kanban using post-its, for example. This production line is defined by the team members, who are responsible for the many steps of the project, like development, quality assurance, infrastructure and so on. The first step located on the left of the kanban shows the stories to be built, and the first one located on the right of the kanban shows the stories that was done. During the course of the project, these stories will move over the wall, from the left to the right, and more stories to built will being sticked, but always respecting the WIP limit.

 Kanban doesn’t prescribe roles, there’s no a specific role to perform a determined task. Then, it’s less prescriptive than the software development methods, like Scrum.

For an organization that is getting started with Agile, the use of Kanban should be a great way to start – it is easy to install, softer, can be used in conjunction to any software development lifecycle, like Scrum, XP and Waterfall, and is less invasive than Scrum, for example, which causes a strong impact on the organization – changes the hierarchy and the roles. For this reason, Kanban should have more chances to be accepted because it can be it can be adopted gradually, and also helps the team to see the process like a queue and not like a network.

The project that I’m working, the team prefers to use RUP with the Waterfall model. By studying Agile, I’ve tried to convince them to use this set of practices, but they were still quite resistant to use it. Then I tried to start using Kanban, and it worked! After that, we started to use some of the practices of XP, and I hope I got some other advances over the time.