How & Why to Use the Kanban Methodology for Software Development

You’ve probably heard of the Kanban project management methodology, but you may not know a lot about it. What are the differences between Kanban and other agile methodologies like Scrum, and instruments like the Gantt chart? What is the Kanban methodology used for?

Let’s take a look at the origins of Kanban, answer these questions, and see how it’s used in practice.

The Main Principles of the Kanban Methodology

The term Kanban comes from Japan thanks to the Toyota production system, which is well-known in narrow circles. It would be great if everyone knew about the Kanban methodology and its basic principles: lean manufacturing, continuous development, customer orientation, etc. All the principles are described in Taiichi Ohno's book, Toyota Production System: Beyond Large-Scale Production.

The term Kanban has a verbatim translation. “Kan” means visible or visual and “ban” means a card or board. Cards of the Kanban methodology are used throughout the Toyota plants to keep inventory management lean — no cluttered warehouses, and workshops with sufficient access to parts.

Imagine that your workshop installs Toyota Corolla doors and there is a pack of 10 doors near your workspace to be installed, one after another, onto new cars. When there are only five doors in the pack, you know that it is time to order new doors. Therefore you take a Kanban card, write an order for another 10 doors on it, and bring the card to the workshop that manufactures doors. You are sure that new doors will be manufactured by the time you have used the remaining five doors.

That's the way it works in Toyota workshops: when you are installing the last door, another pack of 10 doors arrives. You constantly order new doors only when you need them.

Now imagine that this Kanban system works all over the plant. There are no warehouses with spares laying around for weeks or months. All the employees work upon requests and manufacture the only the necessary amount of spares. If there are more or fewer orders, the system will match the changes.

The main idea of Kanban methodology cards is to scale down the amount of work in progress. For example, due to the Kanban methodology, only 10 cards for doors may be given for a whole manufacturing line. It means that only 10 ready-made doors will be on the line at any time during the production loop. Deciding when those doors are ordered is a task for those who install them. Always limited to 10 doors, only the installers know the upcoming needs of the workshop and can place orders with the door manufacturer.

This methodology of lean manufacturing was first introduced at Toyota, but many companies all over the world have adopted it. But these examples refer to manufacturing, not to software engineering.

How Does the Kanban Methodology Work for Software Development?

Let's start by looking at the differences in project planning between Kanban and other agile methodologies.

The difference between the Kanban methodology and SCRUM is that:

• There are no time boxes in Kanban for anything (either for tasks, or sprints)
• The tasks in the Kanban methodology are larger, and there are less of them
• The period assessments in Kanban are optional, or there are none of them at all
• There is no “speed of team” in Kanban — only average time for a full implementation is counted

Now look at this list and think: what will remain of the agile methodology, if we remove sprints, increase dimensions and stop counting the speed of the team’s work? Nothing?

How is it even possible to talk about any supervision over development if all the major tools of control are removed? This is, probably, the most important question for me in the Kanban methodology.

Managers always think about control and try to attain it, though they don’t really have it. A manager’s supervision over the development process is a fiction. If a team doesn’t want to work, it will fail a project despite any level of control.

If a team has fun while working and works with total efficiency, then there is no need for control, because it just disturbs the process and increases costs.

For example, a common problem with the SCRUM methodology are higher costs due to discussions, meetings and big losses of time at the joints of the sprints, when at least one day is wasted to complete a sprint and one more day to start another. If a sprint is two weeks, then two days out of two weeks is 20%, which is a heck of a lot. So while using SCRUM methodology, just about 30-40% of the time is wasted on supporting the process itself including daily rallies, sprint retrospectives and so on.

The Kanban development methodology differs from SCRUM with its focus on tasks. The main objective of a team in SCRUM is the successful completion of a sprint. In the Kanban methodology, tasks take first place. There aren’t any sprints and a team works on a task from beginning to end. The deployment is made when it is ready based on the presentation of work done. A team that follows the Kanban methodology should not estimate time to fulfill a task, since there is no sense in it and these estimates are almost always incorrect.

Why should a manager need a time estimate, if he or she believes in the team? The objective of a manager who uses the Kanban methodology is to create a prioritized task pool, and the team's objective is to fulfill as many items from this pool as possible. That’s it. There is no need for any control measures. All the manager needs to do is add items to the pool or to change their priority. This is the way a Kanban manager runs a project.

The team works from a Kanban board. It may look like this:

Continue reading %How & Why to Use the Kanban Methodology for Software Development%

by Sergey Laptick via SitePoint