Kanban in IT (Kanban Development)

Alexander Sergeev

wrote this on Авг 10, 2015

We've found and translated a great article on Kanban telling about its advantages and main competitors. We can't but share it with you.

The term Kanban has appeared in Japan due to a widely known in narrow circles Toyota Production System. We’d like more people to learn about this system and its main principles: careful production, constant development, client-orientation, etc. All these principles are described in Taiichi Ohno’s book “Toyota Production System: Beyond Large-Scale Production”.

Kanban has a word-for-word translation: “Kan” means visible, visual and “ban” — a desk or card.

Kanban cards are used everywhere at Toyota factories in order not to overload stocks and working places with details made in advance. For example, imagine that you fix car doors at Toyota factory. There are 10 doors beside your working place. And when there are only 5 left, you know it’s time to order new doors. You take a Kanban card, write an order on it and send it to a person who makes doors. So, you’ll get 10 doors before you run out of the 5 doors you had. You order doors only when you need them.

Now imagine that such a system work in every department of the factory. There are no stocks where details are stored for weeks and months. Everybody works according to an order system. And if there are more or less orders, the system will adjust to changes.

The main task of Kanban cards in this system is to decrease the amount of “work in progress”.

For example, there are only 10 cards for doors for all production line. It means that there won’t be more than 10 doors on the line in a definite period of time. It’s a task for a person who fixes doors to define how many and when to order doors. It’s the only person who knows his/her demands.

This method is called Lean manufacturing. It was made up in Toyota and many manufacturing companies throughout the world use it.

But still it concerns manufacturing, not development.

So what’s Kanban if we talk about software? How does it differ from other flexible methodologies (SCRUM or XP)?

Firstly, you should understand that Kanban is not a definite process but a value system. Along with SCRUM and XP. It means that nobody will tell you what and how to do.

Secondly, all Kanban can be described as  “decreasing the amount of work in progress”.

Thirdly, Kanban is a more flexible methodology than SCRUM and XP. It means that it won’t do for all teams and all projects. A team should be ready for such a flexible work.

The difference between Kanban and SCRUM:

• there are no timeboxes in Kanban.
• tasks are bigger but the amount is fewer in Kanban.
• deadlines are optional or are absent in Kanban.
• there’s no “team’s work speed” in Kanban. Only average time for a full task realization is calculated.

Have a look at the list now and think about what’s left from a flexible methodology, if we remove sprints, increase task sizes and stop evaluation team’s work speed? Nothing?

How can we talk about development control, if we remove all main control tools — deadlines, work speed and sprints? The question seems to be the most important.

Managers always think of control and try to get it, although they never have it. Development control by a manager is a fiction. If a team don’t want to work, they will fail a project, no matter how hard you try to control them.

If a team have fun during work and work to the fullest, you don’t need control. In such a situation control may even be a hindrance.

For example, a widely-known problem of SCRUM is big meeting expenditures and big time losses on sprint borders. As a result, if you use SCRUM, 30-40% of time is wasted on keeping the process: daily meetings, workshop and so on.

Unlike SCRUM, Kanban is task-oriented. The main team orientation in SCRUM is a successful sprint fulfillment. As for Kanban, tasks are the most important thing here.

There are no sprints, a team works on a task from the beginning till the end. Task deployment is made when a task is fulfilled. The same is for presentation of the work done. A team shouldn’t evaluate time on task fulfillment as it has no sense and inaccurate most of the time.

If a manager believes a team, why does he/she need time evaluation? A manager’s task is to create a prioritized task pool, a team’s task is to finish as many tasks as possible from the pool. And that’s it. You don’t need control. All that a manager need to do is to add tasks and change priorities. That’s the way he/she manages a project.

A team uses a Kanban desk. For example, it can look like this (it was taken from here):

 

Project goals:

Not a necessary but useful column. You can place high-level project goals here so that team know them. For example, “increase work speed by 20%”.

 

Task queue:

Tasks ready to fulfillment are kept here. A top one always goes first, the most priority task and its card is placed to the following column.

 

Elaboration and acceptance:

This one and other columns may be changed (except “Done”) as it’s team who decide what steps a task goes through.

 

Development:

A task stays here until a feature development isn’t finished. Then it goes to the following column. If the architecture isn’t right or precise, you can move the task back to the previous column.

 

Test:

A task stays here while it’s being tested. If there are bugs, it goes back to “Development”. If no, moves forward.

 

Deployment:

Each project has its own deployment.

 

Done:

A sticker gets here only when all the work on the task is finished completely.

 

There are urgent tasks in any work. Planned or not, but the ones that must be done at once. You can create a special place for them (“Expedite”). You can place one urgent task there and a team will start doing it at once and will finish it as soon as possible. But there can be only one task of such a type. If there’s one more, add to a “Task queue”.

And the most important. Do you see the numbers on each column? It’s the number of tasks that can be simultaneously in each column. It’s considered that the numbers should depend on developers.

For example, if there are 8 developers in your team, place number for on “Development”. It means that developers will perform not more than 4 tasks simultaneously. They will also be able to exchange their experience.

Nobody will give an exact answer what these limits should be. But try to divide the number of developers by 2 and see how it will work in your team. The same principle works for other specialists as well.

 

What new and useful things does such a board with limits give you?

Firstly, decreasing the number of tasks being done simultaneously significantly decreases time for fulfilling each separate task. There’s no need to change context among tasks, track various essences, plan them and so on. You only do what’s necessary. You don’t have to conduct 5% workshops and sprint plannings as planning is already done in “Task queue” column and a detailed work starts only when a task goes into execution.

Secondly, you see problems at once. For example, if testers can’t cope with testing, they will soon fill all their column and developers who have finished a new task won’t be able to move it to “Test” column as it’s full. So what can be done? It’s time to remember that we’re a team and solve the problem. For example, developers can help testers to finish one of testing tasks and move their own task to a vacant place. It will help to do tasks quicker.

Thirdly, you can calculate time for an average task. We can mark the date on a task when it appeared in a task queue and the date it was moved to development and finished. Calculate an average time for 10 tasks according to these 3 points.

All Kanban may be described by 3 main rules:

1. Visualize manufacturing:
   - divide work into tasks, write down each task on a card and pin it to a wall or desk.
   - use named columns in order to see the place of a task in manufacturing.
2. Limit WIP (work in progress) on each stage of manufacturing.
3. Track cycle time (average time for solving one task) and constantly optimize the process in order to reduce time.

3 rules only!

For example, there are 9 basic rules in SCRUM, 13 in XP and more than 120 in classic RUP.

Feel the difference.