Kanban in IT (Kanban Development)
I am going to write several articles about the new agile development methodology of Kanban (Kanban Development) in order to prepare for the Scandinavian Agile Conference 2009 , where I will do one of the reports (by the way, I invite everyone to the conference).
Today I publish the first of articles.
The main objective of the first article is to describe the basics of Kanban as simply as possible: what it is, how it differs from other flexible methodologies, and why it is needed.
I would also like to collect as many questions and doubts in the comments as possible in order to answer them in the following articles, so write everything that you don’t understand, or what else you would like to know about Kanban.
I am not a great expert on this new methodology, but we, within the team, came to Kanban on our own and consistently went through all the stages of the mutation from SCRUM to Kanban, so there is practical experience.
To begin, I will write about the origin of the term Kanban .
This term came to us from Japan thanks to the well-known production system Toyota in narrow circles. I would like as many people as possible to read about this system and the basic principles embodied in it - lean manufacturing, continuous development, customer orientation, etc. All these principles are described in the book of Taichi Ono Toyota Production System , which is translated into Russian.
')
The term Kanban has a literal translation: “Kan” means visible, visual, and “ban” means a card or plaque.
At the factories of Toyota, Kanban cards are used everywhere in order not to clutter up warehouses and workplaces with previously created spare parts. For example, imagine that you put doors on Toyota Corolla. You have around the workplace is a pack of 10 doors. You put them one by one on new cars and when there are 5 doors left in a pack, then you know that it’s time to order new doors. You take a Kanban card, write an order on it for 10 doors and refer it to the one who makes the doors. You know that he will make them just by the time you have run out of the remaining 5 doors. And that's exactly what happens - when you put the last door, a bundle of 10 new doors arrives. And so constantly - you order new doors only when you need them.
Now imagine that such a system operates throughout the plant. There are no warehouses anywhere where parts lie for weeks and months. All work only on request and produce exactly as many spare parts as requested. If suddenly orders become more or less - the system itself easily adapts to changes.
The main task of kanban cards in this system is to reduce the amount of “work in progress at the moment” (work in progress).
For example, exactly 10 door cards can be allocated to the entire production line. This means that at any given time on the line there will be no more than 10 ready-made doors. When to order new doors and how much is a task for the one who installs them. Only he knows his needs, and only he can place orders to the door manufacturer, but he is always limited to 10.
This method of Lean manufacturing (Lean manufacturing) was invented in Toyota and now many manufacturing companies around the world are introducing it or have already implemented it.
But this all refers to production, not software development.
And what is Kanban development for software, and how does it differ from other flexible methodologies, be it SCRUM or XP?
First, you need to immediately understand that Kanban is not a specific process, but a value system. As, however, and SCRUM with XP. This means that no one will tell you what to do and how to take steps.
Secondly, the whole Kanban can be described in one simple phrase - “Reduction of the work currently being done (work in progress)” .
Third, Kanban is an even more flexible methodology than SCRUM and XP. This means that it is not suitable for all teams and for all projects. And it also means that the team should be even more ready for flexible work than even commands using SCRUM and XP.
Difference between kanban and scrum:
- There are no timeboxes for anything in Kanban (neither for tasks, nor for sprints)
- Kanban tasks are bigger and smaller.
- In Kanban, estimates of deadlines for a task are optional or not at all.
- In Kanban, “team speed” is absent and only the average time to complete the task is considered
And now look at this list and think about what remains of a flexible methodology if we remove sprints, increase the size of tasks and stop measuring the speed of the team? Nothing?
How can we talk about development control, if we remove the main control tools - timing, speed and sprints? For me, this question is almost the most important.
managers always think about control and try to get it, although they never really have it. Development control by the manager is a fiction. If the team does not want to work, then how not to control it, it will fail the project.
If a team gets a fan from work and works with full dedication, then no control is needed, but it only hinders, increases costs.
For example, the well-known problem of SCRUM is the big costs of discussions, meetings and big losses of time at the sprint junctions (when at least a day goes to close one sprint, and then a day to open a new one. And if the sprint is 2 weeks, then 2 days out of 2 weeks - it's 20%, damn a lot). As a result, almost 30-40% of the time spent on SCRUM is spent on maintaining the process itself - on daily rallies, at 5% workshop, on sprint retrospectives, etc. thirty%!
Kanban development differs from SCRUM primarily in task orientation. If in SCRUM the main orientation of the team is the successful performance of sprints (it must be admitted that this is so), then in Kanban the first place is the task.
There are no sprints, the team is working on the task from the very beginning to the end. Task deployment is done when it is ready. The presentation of the work done - too. The team should not evaluate the time to complete the task, because it makes little sense and is almost always wrong at the beginning.
If the manager believes the team, then why have a time estimate? The task of the manager is to create a prioritized task pool, and the task of the team is to complete as many tasks from this pool as possible. Everything. No control is needed. All that is needed from the manager is to add tasks to this pool or change their priority. That is how he manages the project.
The team uses a kanban board for work. For example, it might look like this (picked up here ):
Left to right columns:
Project goals :
Optional but useful column. Here you can put the high-level goals of the project so that the team can see them and know everything about them. For example, “Increase work speed by 20%” or “Add support for Windows 7”.
Queue of tasks :
There are stored tasks that are ready to start to perform them. Always the top priority task is taken for execution and its card is moved to the next column.
Design study :
this and the rest of the columns to "Finished" may change, because it is the team that decides what steps the task passes to the “Finished” state.
For example, this column may contain tasks for which the design of the code or interface is not yet clear and is being discussed. When discussions are finished, the task moves to the next column.
Development :
Here the task hangs until the development of the feature is completed. After completion, it moves to the next column.
Or, if the architecture is not correct or not accurate - the task can be returned to the previous column.
Testing :
The task is in this column while it is being tested. If errors are found, it is returned to the Development. If not, it moves on.
Deployment :
All projects have their own deployment. For someone, this means putting a new version of the product on the server, and for someone, just sticking the code into the repository.
Finished :
The sticker gets here only when all the work on the task is completed.
In any work there are urgent tasks. Scheduled or not, but those that need to be done right now. For these, you can allocate a special place (in the picture it is noted as “Expedite”). You can put one urgent task into Expedite and the team should start it immediately and complete it as soon as possible. But there can be only one such task! If one more appears, it should be added to the “Task Queue”.
And now the most important thing. See the numbers under each column? This is the number of tasks that can be simultaneously in these columns. The numbers are chosen experimentally, but it is believed that they should depend on the number of developers in the team.
For example, if you have 8 programmers in a team, then you can put the number 4 in the “Development” line. This means that at the same time programmers will do no more than 4 tasks, which means they will have many reasons to communicate and exchange experience. If you put the number 2 there, then 8 programmers involved in two tasks may get bored or lose too much time in discussions. If you put 8, then everyone will do their job and some tasks will linger on the board for a long time, and the main task of Kanban is to reduce the time to complete a task from the beginning to the stage of readiness.
No one will give the exact answer, what should be these limits, but first try to divide the number of developers by 2 and see how it works in your team. Then these numbers can be adjusted to your team.
By “developers” I mean not only programmers, but also other specialists. For example, for the Testing column, developers are testers, because testing is their responsibility.
The tasks on such a board are not just tasks, but what is called the Minimum Marketing Feature, that is, a feature that can be “sold” to customers.
A good test for MMF is a question for yourself “Would I write about this feature in the company's blog?”. If not - this is not a muff.
What's new and useful gives such a board with limits?
First, reducing the number of tasks performed in parallel will greatly reduce the time to complete each individual task. There is no need to switch the context between tasks, track different entities, plan them, etc. - only what is needed is done. There is no need to arrange sprint plannings and 5% workshops because planning has already been done in the “task queue” column, and detailed task processing starts ONLY when the task starts to be executed.
Secondly, the plugs are immediately visible. For example, if testers do not cope with testing, they will very soon fill their entire column and programmers who have completed a new task will no longer be able to move it to the testing column, since it's full. What to do? It's time to remember that “we are a team” and solve this problem. For example, programmers can help testers complete one of the testing tasks and only then move a new task to the vacant space. This will allow both tasks to be completed faster.
Thirdly, you can calculate the time to perform the averaged task. We can mark the date on the card when it hit the task queue, then the date when it was taken to work and the date when it was completed. For these three points for at least 10 tasks, you can already calculate the average waiting time in the task queue and the average task execution time. And from these numbers, the manager or product owner can already count on everything he pleases.
All kanban can be described with just three basic rules:
1. Visualize production
- Divide the work into tasks, write each task on a card and place it on a wall or board.
- Use the named columns to show the position of the task in production.
2. Limit WIP (work in progress or work performed simultaneously) at each stage of production.
3. Measure the cycle time (average time to complete one task) and constantly optimize the process to reduce this time.
Only 3 rules!
For example, in SCRUM - 9 basic rules. In XP - 13, and in the classic RUP - as many as more than 120. Feel the difference.
With this, I finish the first article about Kanban.
Waiting for your feedback and comments, as well as suggestions for the following articles.
Additional links (unfortunately everything is only in English):
Today I publish the first of articles.
The main objective of the first article is to describe the basics of Kanban as simply as possible: what it is, how it differs from other flexible methodologies, and why it is needed.
I would also like to collect as many questions and doubts in the comments as possible in order to answer them in the following articles, so write everything that you don’t understand, or what else you would like to know about Kanban.
I am not a great expert on this new methodology, but we, within the team, came to Kanban on our own and consistently went through all the stages of the mutation from SCRUM to Kanban, so there is practical experience.
To begin, I will write about the origin of the term Kanban .
This term came to us from Japan thanks to the well-known production system Toyota in narrow circles. I would like as many people as possible to read about this system and the basic principles embodied in it - lean manufacturing, continuous development, customer orientation, etc. All these principles are described in the book of Taichi Ono Toyota Production System , which is translated into Russian.
')
The term Kanban has a literal translation: “Kan” means visible, visual, and “ban” means a card or plaque.
At the factories of Toyota, Kanban cards are used everywhere in order not to clutter up warehouses and workplaces with previously created spare parts. For example, imagine that you put doors on Toyota Corolla. You have around the workplace is a pack of 10 doors. You put them one by one on new cars and when there are 5 doors left in a pack, then you know that it’s time to order new doors. You take a Kanban card, write an order on it for 10 doors and refer it to the one who makes the doors. You know that he will make them just by the time you have run out of the remaining 5 doors. And that's exactly what happens - when you put the last door, a bundle of 10 new doors arrives. And so constantly - you order new doors only when you need them.
Now imagine that such a system operates throughout the plant. There are no warehouses anywhere where parts lie for weeks and months. All work only on request and produce exactly as many spare parts as requested. If suddenly orders become more or less - the system itself easily adapts to changes.
The main task of kanban cards in this system is to reduce the amount of “work in progress at the moment” (work in progress).
For example, exactly 10 door cards can be allocated to the entire production line. This means that at any given time on the line there will be no more than 10 ready-made doors. When to order new doors and how much is a task for the one who installs them. Only he knows his needs, and only he can place orders to the door manufacturer, but he is always limited to 10.
This method of Lean manufacturing (Lean manufacturing) was invented in Toyota and now many manufacturing companies around the world are introducing it or have already implemented it.
But this all refers to production, not software development.
And what is Kanban development for software, and how does it differ from other flexible methodologies, be it SCRUM or XP?
First, you need to immediately understand that Kanban is not a specific process, but a value system. As, however, and SCRUM with XP. This means that no one will tell you what to do and how to take steps.
Secondly, the whole Kanban can be described in one simple phrase - “Reduction of the work currently being done (work in progress)” .
Third, Kanban is an even more flexible methodology than SCRUM and XP. This means that it is not suitable for all teams and for all projects. And it also means that the team should be even more ready for flexible work than even commands using SCRUM and XP.
Difference between kanban and scrum:
- There are no timeboxes for anything in Kanban (neither for tasks, nor for sprints)
- Kanban tasks are bigger and smaller.
- In Kanban, estimates of deadlines for a task are optional or not at all.
- In Kanban, “team speed” is absent and only the average time to complete the task is considered
And now look at this list and think about what remains of a flexible methodology if we remove sprints, increase the size of tasks and stop measuring the speed of the team? Nothing?
How can we talk about development control, if we remove the main control tools - timing, speed and sprints? For me, this question is almost the most important.
managers always think about control and try to get it, although they never really have it. Development control by the manager is a fiction. If the team does not want to work, then how not to control it, it will fail the project.
If a team gets a fan from work and works with full dedication, then no control is needed, but it only hinders, increases costs.
For example, the well-known problem of SCRUM is the big costs of discussions, meetings and big losses of time at the sprint junctions (when at least a day goes to close one sprint, and then a day to open a new one. And if the sprint is 2 weeks, then 2 days out of 2 weeks - it's 20%, damn a lot). As a result, almost 30-40% of the time spent on SCRUM is spent on maintaining the process itself - on daily rallies, at 5% workshop, on sprint retrospectives, etc. thirty%!
Kanban development differs from SCRUM primarily in task orientation. If in SCRUM the main orientation of the team is the successful performance of sprints (it must be admitted that this is so), then in Kanban the first place is the task.
There are no sprints, the team is working on the task from the very beginning to the end. Task deployment is done when it is ready. The presentation of the work done - too. The team should not evaluate the time to complete the task, because it makes little sense and is almost always wrong at the beginning.
If the manager believes the team, then why have a time estimate? The task of the manager is to create a prioritized task pool, and the task of the team is to complete as many tasks from this pool as possible. Everything. No control is needed. All that is needed from the manager is to add tasks to this pool or change their priority. That is how he manages the project.
The team uses a kanban board for work. For example, it might look like this (picked up here ):
Left to right columns:
Project goals :
Optional but useful column. Here you can put the high-level goals of the project so that the team can see them and know everything about them. For example, “Increase work speed by 20%” or “Add support for Windows 7”.
Queue of tasks :
There are stored tasks that are ready to start to perform them. Always the top priority task is taken for execution and its card is moved to the next column.
Design study :
this and the rest of the columns to "Finished" may change, because it is the team that decides what steps the task passes to the “Finished” state.
For example, this column may contain tasks for which the design of the code or interface is not yet clear and is being discussed. When discussions are finished, the task moves to the next column.
Development :
Here the task hangs until the development of the feature is completed. After completion, it moves to the next column.
Or, if the architecture is not correct or not accurate - the task can be returned to the previous column.
Testing :
The task is in this column while it is being tested. If errors are found, it is returned to the Development. If not, it moves on.
Deployment :
All projects have their own deployment. For someone, this means putting a new version of the product on the server, and for someone, just sticking the code into the repository.
Finished :
The sticker gets here only when all the work on the task is completed.
In any work there are urgent tasks. Scheduled or not, but those that need to be done right now. For these, you can allocate a special place (in the picture it is noted as “Expedite”). You can put one urgent task into Expedite and the team should start it immediately and complete it as soon as possible. But there can be only one such task! If one more appears, it should be added to the “Task Queue”.
And now the most important thing. See the numbers under each column? This is the number of tasks that can be simultaneously in these columns. The numbers are chosen experimentally, but it is believed that they should depend on the number of developers in the team.
For example, if you have 8 programmers in a team, then you can put the number 4 in the “Development” line. This means that at the same time programmers will do no more than 4 tasks, which means they will have many reasons to communicate and exchange experience. If you put the number 2 there, then 8 programmers involved in two tasks may get bored or lose too much time in discussions. If you put 8, then everyone will do their job and some tasks will linger on the board for a long time, and the main task of Kanban is to reduce the time to complete a task from the beginning to the stage of readiness.
No one will give the exact answer, what should be these limits, but first try to divide the number of developers by 2 and see how it works in your team. Then these numbers can be adjusted to your team.
By “developers” I mean not only programmers, but also other specialists. For example, for the Testing column, developers are testers, because testing is their responsibility.
The tasks on such a board are not just tasks, but what is called the Minimum Marketing Feature, that is, a feature that can be “sold” to customers.
A good test for MMF is a question for yourself “Would I write about this feature in the company's blog?”. If not - this is not a muff.
What's new and useful gives such a board with limits?
First, reducing the number of tasks performed in parallel will greatly reduce the time to complete each individual task. There is no need to switch the context between tasks, track different entities, plan them, etc. - only what is needed is done. There is no need to arrange sprint plannings and 5% workshops because planning has already been done in the “task queue” column, and detailed task processing starts ONLY when the task starts to be executed.
Secondly, the plugs are immediately visible. For example, if testers do not cope with testing, they will very soon fill their entire column and programmers who have completed a new task will no longer be able to move it to the testing column, since it's full. What to do? It's time to remember that “we are a team” and solve this problem. For example, programmers can help testers complete one of the testing tasks and only then move a new task to the vacant space. This will allow both tasks to be completed faster.
Thirdly, you can calculate the time to perform the averaged task. We can mark the date on the card when it hit the task queue, then the date when it was taken to work and the date when it was completed. For these three points for at least 10 tasks, you can already calculate the average waiting time in the task queue and the average task execution time. And from these numbers, the manager or product owner can already count on everything he pleases.
All kanban can be described with just three basic rules:
1. Visualize production
- Divide the work into tasks, write each task on a card and place it on a wall or board.
- Use the named columns to show the position of the task in production.
2. Limit WIP (work in progress or work performed simultaneously) at each stage of production.
3. Measure the cycle time (average time to complete one task) and constantly optimize the process to reduce this time.
Only 3 rules!
For example, in SCRUM - 9 basic rules. In XP - 13, and in the classic RUP - as many as more than 120. Feel the difference.
With this, I finish the first article about Kanban.
Waiting for your feedback and comments, as well as suggestions for the following articles.
Additional links (unfortunately everything is only in English):
Source: https://habr.com/ru/post/64997/
All Articles