13 reasons to switch to Kanban. And no superstition
In development processes, as in other areas of activity, it is not always possible to immediately “grope” the right path, often having to experience many thorns. The future life of a product or service depends on the choice of a suitable development methodology. We have gathered 13 benefits from Kanban software development.
Let us examine the following example, having considered two situations.
The first situation is to imagine a conveyor factory in Soviet times, whose activities were directly dependent on the state plan. This plan clearly defined the number of products for production. As a result, overcrowded warehouses due to the fact that the compilers of the state plan could often be mistaken with demand. Products did not have time to sell.
')
The second situation is the Toyota showroom these days. The buyer chooses the model and makes the payment. However, in stock Toyota at this moment is not your car color. The order is sent to the head office of Toyota. You are informed about the time when the car will be delivered. Only from this moment the car begins to produce. Especially for you. The principle is evident: first sale, then production. In other words, the just-in-time (JIT) principle works. First, goals and deadlines, then plan and work.
Toyota stockpiles will not be overcrowded, as in the first situation, they will not have the need to store pre-manufactured parts for a long time. This is because what is being made on the line right now is a necessary norm for some recently sold car.
One of the key components of the JIT principle is Kanban . Kanban boards and cards are peculiar traffic lights in the just in time system. Kanban enables businesses to be reactive towards customer needs instead of forecasting needs, as happened in the first situation described.
You can project a similar example on a software development area:
Instead of spare parts - development tasks or bugs. The tester receives several tasks for verification. When a QA runs out of verification tasks, it must notify programmers to get new tasks from them. If programmers do not have time to complete new tasks, the tester simply remains without work for a while.
The reverse situation also happens: QA accumulates a lot of tasks and he / she does not have time to check everything in time. In this case, the release date of the product is also delayed.
In software development, Kanban is much harder to balance than in manufacturing. The specifics of the work have an effect: if the machines produce parts of the same type, then the programmers work with the code through their own efforts of the brain, in which there is something about 100 billion neurons and one, but significant human factor.
I fully discovered the advantages of Kanban in 2008, after which I use Kanban boards everywhere: from personal planning, development and even Kanban implementation in the ceramic workshop.
Here are 13 reasons why it is worth implementing Kanban in IT companies that develop software:
Switching to Kanban boards from regular task lists immediately showed us a bottleneck: a large queue of tasks accumulated in the Testing column. Our QA did not cope with checking tasks. He took the task to check with a long delay. After the tester returned the task for revision, the programmer had time to forget it. I had to look at the code again and remember the details. As you know, this is precious time. The team needed another tester.
Kanban board allows you to see the bottlenecks in your process where queues form. In Hygger.io, WIP limits help to cope with this task. If you have more or less tasks than you need - the column is highlighted in red or yellow, respectively.
Often the order of feature release is important. In lists based on priorities, it is difficult to precisely manage order. If a programmer has five tasks with a top priority at the same time, it will be difficult for him to orient which of these tasks to be taken first.
Kanban board just offers a way out when order matters. This visual solution is a vertical column with tasks. The higher the task, the more important it is. Kanban, by the way, involves defining priorities as one of the important aspects of the methodology. Requirements are constantly changing, many tasks may lose relevance and “descend” down. Some tasks can, on the contrary, sharply "rise." The manager must constantly “keep a finger on the pulse” so that programmers do the most necessary things.
Kanban teaches to focus on the main things. That which really adds value to the product. We were able to "lower" down a lot of useless bugs and improvements. This gave the result.
Distinguishing important bugs from lower priority ones is not an easy task for a product manager, but here the function Swimlanes comes to the rescue . These are the horizontal columns on the Kanban board. As a rule, programmers have the following Swimlanes on the board:
The system is similar to the Eisenhower quadrant . Important and urgent questions are Blockers. Important, but not urgent - Tasks and Bugs. Unimportant and urgent, as well as unimportant and non-urgent - this is Someday. By the way, the lack of horizontal speakers is one of the factors confirming what Trello lacks for Agile development .
The programmer must be focused on his work. Therefore, it is good when he receives a queue of tasks and he does not need to think about what to do next, the manager has already thought about this. You just need to take the next task or bug into the work.
Sometimes Kanban suggests an independent choice of programmers for any tasks on top. Then the professional level of all people should be equal, so that it does not work out that the most difficult task “falls” on the junior specialist.
My Tasks Filter helps you set the focus on your tasks. It helps to quickly see your tasks on the board.
Before your eyes - the whole picture of the project. Opening the board, you can quickly get answers to important questions:
Kanban helps to become more flexible. This is especially necessary when the product goes out and gets a lot of useful feedback. These are messages in support, behavioral analytics, results of a / b testing, reviews, etc. As soon as we “fill in” a new feature for production, we immediately begin to change it based on feedback. Previously, the programmer did not want to do "left" tasks, fearing to "fill up" the timing of the sprint. According to Kanban, a programmer works like a processor: one clock cycle is one task.
The more frequent the bars, the more flexible the development team. For our team, the perfect tact is 8-12 hours. Large tasks are necessarily decomposed.
Scrum took a lot of time to evaluate the features before starting a sprint. With Kanban, there is no need for evaluation. When we do, then it will be done.
Scrum involves a lot of communication. The beginning of the sprint is accompanied by planning: analysis and assessment of tasks. Stand-ups are required every week. After the end of the sprint is a retrospective. In summary, all communication takes about 30% of the time. But this time the team could spend on work.
With Kanban, the team starts working more consistently. Now the tester checks the feature almost immediately after the programmer has done it. Similarly in other areas: designers, UX, editors, sales.
Previously, QA checked the feature not when the programmer did it, but after a long time. The programmer during this time managed to forget everything, including the details of this task.
In Scrum, we "fill in" features on production only at the end of the sprint. About once every 3 weeks. In Kanban, almost immediately after acceptance by the tester. Every few days.
So we will quickly find out whether the feature has entered users or not. If not, an error has occurred somewhere. And it is important for us to be wrong first. This does not mean that we are lovers of mistakes. But if we find out about the error first, we will be the first to know and decide what to do.
No need to constantly "pull" programmers. Kanban opened the board, quickly glanced who and what is busy, all the statuses, and you can calmly return to the management. And the programmer continues to be in a state of flow, and in anticipation of taking new peaks.
Previously, programmers did not know what their colleagues are doing. Now with Kanban, a programmer can, just like a manager, go to the board and see what colleagues are doing. Such information they need to coordinate joint efforts on the project.
Previously, the programmer was engaged in several tasks at once in parallel. I could choose a task according to my mood, and on Monday I could forget about what I was doing on Friday.
Now WIP limits and a panoramic view intelligently limit the programmer: he cannot do more than one task at once.
It may seem that we insist that Kanban is better than Scrum. But it is not. Everything has its time. Experience Hygger suggests: Scrum is well suited at the start of product development, and Kanban - when the product has already entered the arena.
Kanban is not a panacea for any business. If you put the ladder on the wrong wall, then no matter how cool you would climb it, you would still be in the wrong place. Therefore, Kanban is a necessary but not sufficient condition for the success of a product or project.
What is Kanban?
Let us examine the following example, having considered two situations.
The first situation is to imagine a conveyor factory in Soviet times, whose activities were directly dependent on the state plan. This plan clearly defined the number of products for production. As a result, overcrowded warehouses due to the fact that the compilers of the state plan could often be mistaken with demand. Products did not have time to sell.
')
The second situation is the Toyota showroom these days. The buyer chooses the model and makes the payment. However, in stock Toyota at this moment is not your car color. The order is sent to the head office of Toyota. You are informed about the time when the car will be delivered. Only from this moment the car begins to produce. Especially for you. The principle is evident: first sale, then production. In other words, the just-in-time (JIT) principle works. First, goals and deadlines, then plan and work.
Toyota stockpiles will not be overcrowded, as in the first situation, they will not have the need to store pre-manufactured parts for a long time. This is because what is being made on the line right now is a necessary norm for some recently sold car.
One of the key components of the JIT principle is Kanban . Kanban boards and cards are peculiar traffic lights in the just in time system. Kanban enables businesses to be reactive towards customer needs instead of forecasting needs, as happened in the first situation described.
You can project a similar example on a software development area:
Instead of spare parts - development tasks or bugs. The tester receives several tasks for verification. When a QA runs out of verification tasks, it must notify programmers to get new tasks from them. If programmers do not have time to complete new tasks, the tester simply remains without work for a while.
The reverse situation also happens: QA accumulates a lot of tasks and he / she does not have time to check everything in time. In this case, the release date of the product is also delayed.
In software development, Kanban is much harder to balance than in manufacturing. The specifics of the work have an effect: if the machines produce parts of the same type, then the programmers work with the code through their own efforts of the brain, in which there is something about 100 billion neurons and one, but significant human factor.
Why does software development need Kanban?
I fully discovered the advantages of Kanban in 2008, after which I use Kanban boards everywhere: from personal planning, development and even Kanban implementation in the ceramic workshop.
13 reasons to switch to Kanban
Here are 13 reasons why it is worth implementing Kanban in IT companies that develop software:
1. Definition of bottlenecks
Switching to Kanban boards from regular task lists immediately showed us a bottleneck: a large queue of tasks accumulated in the Testing column. Our QA did not cope with checking tasks. He took the task to check with a long delay. After the tester returned the task for revision, the programmer had time to forget it. I had to look at the code again and remember the details. As you know, this is precious time. The team needed another tester.
Kanban board allows you to see the bottlenecks in your process where queues form. In Hygger.io, WIP limits help to cope with this task. If you have more or less tasks than you need - the column is highlighted in red or yellow, respectively.
2. The exact order of release features
Often the order of feature release is important. In lists based on priorities, it is difficult to precisely manage order. If a programmer has five tasks with a top priority at the same time, it will be difficult for him to orient which of these tasks to be taken first.
Kanban board just offers a way out when order matters. This visual solution is a vertical column with tasks. The higher the task, the more important it is. Kanban, by the way, involves defining priorities as one of the important aspects of the methodology. Requirements are constantly changing, many tasks may lose relevance and “descend” down. Some tasks can, on the contrary, sharply "rise." The manager must constantly “keep a finger on the pulse” so that programmers do the most necessary things.
3. Priority to the main tasks
Kanban teaches to focus on the main things. That which really adds value to the product. We were able to "lower" down a lot of useless bugs and improvements. This gave the result.
Distinguishing important bugs from lower priority ones is not an easy task for a product manager, but here the function Swimlanes comes to the rescue . These are the horizontal columns on the Kanban board. As a rule, programmers have the following Swimlanes on the board:
- Blockers - tasks and bugs that need to be corrected in real time. An example is a broken registration.
- Tasks and Bugs - the usual current tasks and bugs.
- Someday - tasks that have lost relevance for one reason or another.
The system is similar to the Eisenhower quadrant . Important and urgent questions are Blockers. Important, but not urgent - Tasks and Bugs. Unimportant and urgent, as well as unimportant and non-urgent - this is Someday. By the way, the lack of horizontal speakers is one of the factors confirming what Trello lacks for Agile development .
4. Concentration at work
The programmer must be focused on his work. Therefore, it is good when he receives a queue of tasks and he does not need to think about what to do next, the manager has already thought about this. You just need to take the next task or bug into the work.
Sometimes Kanban suggests an independent choice of programmers for any tasks on top. Then the professional level of all people should be equal, so that it does not work out that the most difficult task “falls” on the junior specialist.
My Tasks Filter helps you set the focus on your tasks. It helps to quickly see your tasks on the board.
5. Panoramic view
Before your eyes - the whole picture of the project. Opening the board, you can quickly get answers to important questions:
- Who is busy at the moment?
- What will be the future work of each individual specialist?
- What tasks were rediscovered due to bugs?
- Who is without tasks?
- Who has a big queue of tasks?
- Where have any changes happened in the last 24 hours?
- When will the specific task be done?
- How soon will the tasks of a specific specialist end?
- For which tasks has more time been spent than planned?
6. Flexibility
Kanban helps to become more flexible. This is especially necessary when the product goes out and gets a lot of useful feedback. These are messages in support, behavioral analytics, results of a / b testing, reviews, etc. As soon as we “fill in” a new feature for production, we immediately begin to change it based on feedback. Previously, the programmer did not want to do "left" tasks, fearing to "fill up" the timing of the sprint. According to Kanban, a programmer works like a processor: one clock cycle is one task.
The more frequent the bars, the more flexible the development team. For our team, the perfect tact is 8-12 hours. Large tasks are necessarily decomposed.
7. No need to evaluate features.
Scrum took a lot of time to evaluate the features before starting a sprint. With Kanban, there is no need for evaluation. When we do, then it will be done.
8. More business
Scrum involves a lot of communication. The beginning of the sprint is accompanied by planning: analysis and assessment of tasks. Stand-ups are required every week. After the end of the sprint is a retrospective. In summary, all communication takes about 30% of the time. But this time the team could spend on work.
9. Team spirit
With Kanban, the team starts working more consistently. Now the tester checks the feature almost immediately after the programmer has done it. Similarly in other areas: designers, UX, editors, sales.
Previously, QA checked the feature not when the programmer did it, but after a long time. The programmer during this time managed to forget everything, including the details of this task.
10. To make mistakes earlier - to find a solution faster.
In Scrum, we "fill in" features on production only at the end of the sprint. About once every 3 weeks. In Kanban, almost immediately after acceptance by the tester. Every few days.
So we will quickly find out whether the feature has entered users or not. If not, an error has occurred somewhere. And it is important for us to be wrong first. This does not mean that we are lovers of mistakes. But if we find out about the error first, we will be the first to know and decide what to do.
11. More flow
No need to constantly "pull" programmers. Kanban opened the board, quickly glanced who and what is busy, all the statuses, and you can calmly return to the management. And the programmer continues to be in a state of flow, and in anticipation of taking new peaks.
12. More knowledge is better for the project.
Previously, programmers did not know what their colleagues are doing. Now with Kanban, a programmer can, just like a manager, go to the board and see what colleagues are doing. Such information they need to coordinate joint efforts on the project.
13. Concentration on one task.
Previously, the programmer was engaged in several tasks at once in parallel. I could choose a task according to my mood, and on Monday I could forget about what I was doing on Friday.
Now WIP limits and a panoramic view intelligently limit the programmer: he cannot do more than one task at once.
As a conclusion
It may seem that we insist that Kanban is better than Scrum. But it is not. Everything has its time. Experience Hygger suggests: Scrum is well suited at the start of product development, and Kanban - when the product has already entered the arena.
Kanban is not a panacea for any business. If you put the ladder on the wrong wall, then no matter how cool you would climb it, you would still be in the wrong place. Therefore, Kanban is a necessary but not sufficient condition for the success of a product or project.
Source: https://habr.com/ru/post/351576/
All Articles