March 20, 2018 at 09:4213 reasons to switch to Kanban. And no superstitions
In development processes, as in other areas of activity, it is not always possible to immediately “find” the right path, often you have to experience many thorns. The future life of a product or service depends on the selection of an appropriate development methodology. We have compiled 13 benefits from implementing Kanban for software development.
Let us examine the following example, considering two situations.
The first situation - imagine a conveyor factory in Soviet times, the activities of which directly depended on the state plan. This plan clearly defined the quantity of products for production. As a result, overfilled warehouses due to the fact that the drafters of the State Planning Committee could often be mistaken with demand. Products did not have time to sell.
Second situation- Toyota showroom these days. The buyer selects the model and makes the payment. However, Toyota is not in your vehicle color at this time. The order is sent to Toyota Head Office. You are notified when the machine will be delivered. Only from this moment the car begin to produce. Especially for you. There is a principle: first sale, then production. In other words, the just-in-time (JIT) principle works . First goals and deadlines, then plan and work.
Toyota's stocks will not be full, as in the first situation, they will not have to store spare parts for a long time. This is because what is being produced right now on the line is a necessary norm for some recently sold car.
One of the key components of the JIT principle isKanban . Kanban boards and cards are a kind of traffic lights in the just in time system. Kanban enables the business to be responsive to customer needs instead of forecasting needs, as happened in the first described situation.
You can project a similar example to the software development area:
Instead of spare parts, development tasks or bugs. The tester receives several tasks for verification. When 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 some time.
The opposite situation also happens: QA has a lot of tasks accumulating and he / she does not have time to check everything on time. In this case, the release date of the product is also delayed.
In software development, balancing Kanban is a lot harder than in manufacturing. It affects the specifics of the work: if the machines produce the same type of details, then the programmers work with the code using their own efforts of the brain, in which there are about 100 billion neurons and one, but significant human factor.
I discovered the full benefits of Kanban in 2008, after which I use Kanban boards everywhere: from personal planning, development and even implementation of Kanban in the ceramic workshop.
Here are 13 reasons why you should implement Kanban in IT companies that develop software:
Switching to Kanban boards from the usual task lists immediately showed us a bottleneck: a large queue of tasks was accumulating in the Testing column. Our QA did not cope with task verification. He took tasks to check with a long delay. After the tester returned the task for revision, the programmer already managed to forget it. I had to look at the code again and remember the details. As you know, this is a precious time. The team needed another tester.
Kanban board allows you to see bottlenecks in your process where queues are formed. 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 release of features is of great importance. In priority-based lists, it’s hard to accurately control the order. If a programmer has five tasks at the same time with the main priority, it will be difficult for him to find out which of these tasks to take first.
Kanban board just offers a way out of the situation 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 prioritization as one of the important aspects of the methodology. Requirements are constantly changing, many tasks can lose relevance and “go down”. Some kind of task can on the contrary sharply "rise". The manager must constantly "keep abreast" for programmers to fulfill the most necessary.
Kanban teaches you what to focus on. One that really adds value to the product. We were able to "lower" down a lot of useless bugs and improvements. It gave a result.
Distinguishing important bugs from those of lower priority is not an easy task for the product manager, but here the Swimlanes function comes to his aid . These are the horizontal columns on the Kanban board. As a rule, programmers on the board have such Swimlanes:
The system is similar to the Eisenhower quadrant . Important and urgent issues 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 columns is one of the factors confirming what Trello lacks for Agile development .
The programmer should 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 to work.
Sometimes Kanban involves programmers independently choosing any tasks from above. Then the professional level of all people should be equal, so as not to happen that the most difficult task "falls" on the junior specialist.
The My Tasks filter helps set focus on your tasks. It helps to quickly see your tasks on the board.
Before your eyes - the whole picture of the project. By opening the board, you can quickly get answers to important questions:
Kanban helps to become more flexible. This is especially necessary when the product comes out and gets a lot of useful feedback. These are support messages, behavioral analytics, results of a / b testing, reviews, etc. As soon as we “upload” a new feature to production, we immediately begin to change it based on feedback. Previously, the programmer did not want to do “left-handed” tasks, being afraid to “fill up” the sprint deadlines. According to Kanban, a programmer works like a processor: one clock cycle - one task.
The more frequent the measures, the more the development team becomes more flexible. For our team, the ideal tact is 8-12 hours. Large tasks are necessarily decomposed.
Scrum took a lot of time to evaluate features before starting the sprint. There is no need for evaluation with Kanban. When we do, then it will be done.
Scrum involves a lot of communication. The start of the sprint is accompanied by planning: analysis and assessment of tasks. Stand-ups are required every week. After the sprint, a retrospective is done. As a result, all communication takes about 30% of the time. But the team could spend this time on work.
With Kanban, the team begins to work more in concert. Now the tester checks the feature almost immediately after the programmer made it. Similarly, in other areas: designers, UX, editors, sales.
QA used to check the feature not when the programmer did it, but after a long time. The programmer during this time managed to forget everything in the world, including the details of this task.
In Scrum, we “upload” features to production only at the end of the sprint. About once every 3 weeks. In Kanban - almost immediately after acceptance by the tester. Once every few days.
So we quickly find out if the feature has gone to users or not. If not, an error occurred somewhere. And it is important for us to make mistakes first. This does not mean that we are lovers of error. But if we learn about the error first, we will be the first to know and decide what to do.
No need to constantly "pull" the programmers. We opened the Kanban board, quickly looked at who and what was doing, all the statuses, and you can safely return to management. And the programmer continues to remain in a state of flow, and in anticipation of taking new heights.
Previously, programmers did not know what colleagues were doing. Now with Kanban, a programmer can, just like a manager, go to the board and see what colleagues are doing. They need such information to coordinate joint efforts on the project.
Previously, a programmer was engaged in several tasks at once in parallel. He could choose task according to his mood, but he could completely forget on Monday what he was doing on Friday.
Now WIP limits and panoramic view correctly limit the programmer: he can not do more than one task at once.
It may seem that we are insisting that Kanban is better than Scrum. But this is not so. Everything has its time. The experience of Hygger allows us to state: 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 stairs on the wrong wall, then no matter how steep you climb it, you will still be not where you need it. 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, considering two situations.
The first situation - imagine a conveyor factory in Soviet times, the activities of which directly depended on the state plan. This plan clearly defined the quantity of products for production. As a result, overfilled warehouses due to the fact that the drafters of the State Planning Committee could often be mistaken with demand. Products did not have time to sell.
Second situation- Toyota showroom these days. The buyer selects the model and makes the payment. However, Toyota is not in your vehicle color at this time. The order is sent to Toyota Head Office. You are notified when the machine will be delivered. Only from this moment the car begin to produce. Especially for you. There is a principle: first sale, then production. In other words, the just-in-time (JIT) principle works . First goals and deadlines, then plan and work.
Toyota's stocks will not be full, as in the first situation, they will not have to store spare parts for a long time. This is because what is being produced right now on the line is a necessary norm for some recently sold car.
One of the key components of the JIT principle isKanban . Kanban boards and cards are a kind of traffic lights in the just in time system. Kanban enables the business to be responsive to customer needs instead of forecasting needs, as happened in the first described situation.
You can project a similar example to the software development area:
Instead of spare parts, development tasks or bugs. The tester receives several tasks for verification. When 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 some time.
The opposite situation also happens: QA has a lot of tasks accumulating and he / she does not have time to check everything on time. In this case, the release date of the product is also delayed.
In software development, balancing Kanban is a lot harder than in manufacturing. It affects the specifics of the work: if the machines produce the same type of details, then the programmers work with the code using their own efforts of the brain, in which there are about 100 billion neurons and one, but significant human factor.
Why does software development need Kanban?
I discovered the full benefits of Kanban in 2008, after which I use Kanban boards everywhere: from personal planning, development and even implementation of Kanban in the ceramic workshop.
13 reasons to switch to Kanban
Here are 13 reasons why you should implement Kanban in IT companies that develop software:
1. Identification of bottlenecks
Switching to Kanban boards from the usual task lists immediately showed us a bottleneck: a large queue of tasks was accumulating in the Testing column. Our QA did not cope with task verification. He took tasks to check with a long delay. After the tester returned the task for revision, the programmer already managed to forget it. I had to look at the code again and remember the details. As you know, this is a precious time. The team needed another tester.
Kanban board allows you to see bottlenecks in your process where queues are formed. 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 release of features is of great importance. In priority-based lists, it’s hard to accurately control the order. If a programmer has five tasks at the same time with the main priority, it will be difficult for him to find out which of these tasks to take first.
Kanban board just offers a way out of the situation 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 prioritization as one of the important aspects of the methodology. Requirements are constantly changing, many tasks can lose relevance and “go down”. Some kind of task can on the contrary sharply "rise". The manager must constantly "keep abreast" for programmers to fulfill the most necessary.
3. Priority to the main tasks
Kanban teaches you what to focus on. One that really adds value to the product. We were able to "lower" down a lot of useless bugs and improvements. It gave a result.
Distinguishing important bugs from those of lower priority is not an easy task for the product manager, but here the Swimlanes function comes to his aid . These are the horizontal columns on the Kanban board. As a rule, programmers on the board have such Swimlanes:
- Blockers - tasks and bugs that need to be corrected in real time. An example is a broken registry.
- Tasks and Bugs - regular 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 issues 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 columns is one of the factors confirming what Trello lacks for Agile development .
4. Focus on work
The programmer should 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 to work.
Sometimes Kanban involves programmers independently choosing any tasks from above. Then the professional level of all people should be equal, so as not to happen that the most difficult task "falls" on the junior specialist.
The My Tasks filter helps set 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. By opening the board, you can quickly get answers to important questions:
- Who is doing what at this moment in time?
- What will be next for each individual specialist?
- What tasks were rediscovered due to bugs?
- Who is without tasks?
- Who has a large queue of tasks?
- Where did any changes happen in the last day?
- When will the specific task be done?
- How soon will the tasks of a specific specialist end?
- What tasks have already been spent more time than planned?
6. Flexibility
Kanban helps to become more flexible. This is especially necessary when the product comes out and gets a lot of useful feedback. These are support messages, behavioral analytics, results of a / b testing, reviews, etc. As soon as we “upload” a new feature to production, we immediately begin to change it based on feedback. Previously, the programmer did not want to do “left-handed” tasks, being afraid to “fill up” the sprint deadlines. According to Kanban, a programmer works like a processor: one clock cycle - one task.
The more frequent the measures, the more the development team becomes more flexible. For our team, the ideal tact is 8-12 hours. Large tasks are necessarily decomposed.
7. No need to evaluate features
Scrum took a lot of time to evaluate features before starting the sprint. There is no need for evaluation with Kanban. When we do, then it will be done.
8. More business
Scrum involves a lot of communication. The start of the sprint is accompanied by planning: analysis and assessment of tasks. Stand-ups are required every week. After the sprint, a retrospective is done. As a result, all communication takes about 30% of the time. But the team could spend this time on work.
9. Team spirit
With Kanban, the team begins to work more in concert. Now the tester checks the feature almost immediately after the programmer made it. Similarly, in other areas: designers, UX, editors, sales.
QA used to check the feature not when the programmer did it, but after a long time. The programmer during this time managed to forget everything in the world, including the details of this task.
10. Mistake earlier - find a solution faster
In Scrum, we “upload” features to production only at the end of the sprint. About once every 3 weeks. In Kanban - almost immediately after acceptance by the tester. Once every few days.
So we quickly find out if the feature has gone to users or not. If not, an error occurred somewhere. And it is important for us to make mistakes first. This does not mean that we are lovers of error. But if we learn about the error first, we will be the first to know and decide what to do.
11. More flow
No need to constantly "pull" the programmers. We opened the Kanban board, quickly looked at who and what was doing, all the statuses, and you can safely return to management. And the programmer continues to remain in a state of flow, and in anticipation of taking new heights.
12. More knowledge is better for the project.
Previously, programmers did not know what colleagues were doing. Now with Kanban, a programmer can, just like a manager, go to the board and see what colleagues are doing. They need such information to coordinate joint efforts on the project.
13. Concentration on one task
Previously, a programmer was engaged in several tasks at once in parallel. He could choose task according to his mood, but he could completely forget on Monday what he was doing on Friday.
Now WIP limits and panoramic view correctly limit the programmer: he can not do more than one task at once.
In conclusion
It may seem that we are insisting that Kanban is better than Scrum. But this is not so. Everything has its time. The experience of Hygger allows us to state: 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 stairs on the wrong wall, then no matter how steep you climb it, you will still be not where you need it. Therefore, Kanban is a necessary but not sufficient condition for the success of a product or project.