Scrum vs Kanban: what is the difference and what to choose?
When there are options - it is important not to make a mistake and explore all the details and possibilities in order to stay at the best. It’s not always easy to choose between development management methods, especially if it is Scrum and Kanban.
Scrum and Kanban are representatives of Agile-family methodologies. Both are considered flexible and iterative. Before you understand the difference between them, we will briefly recall what unites them.
More than 17 years ago, IT development leaders formulated an Agile manifest. The main thing that we can distinguish from the manifesto:
')
You can safely agree with all the arguments, because indeed:
Often, recently a project is a startup. In the context of start-ups, “ customer development ” comes to mind (Steve Blank described the original technique remarkably well).
In fact, during customer development, we test our hypotheses before starting the development of even a prototype. Our goals are to make sure that:
- Problems that we deal with, exist in the user's life.
- these problems are significant.
- the user will pay for them
- there is a market, and this is not a problem of one person.
- there are channels to attract users (for example, Facebook Ads, or Googl Adwords), and we will be able to find such a cost of attracting users, which will give us a profit (CAC <LTV).
These are the main ideas of the manifesto, but there are still the famous 12 principles that speak for themselves. So, we will not “dig” deeply in them, but rather we will return to the main issue of how Scrum differs from Kanban.
The basis of Scrum is short iterations or sprints, as a rule, 2-3 weeks. Before the start of the sprint, the team itself generates a list of features per iteration, then the sprint starts.
After the end of the sprint, the completed features are uploaded to the production, and the unfulfilled ones are transferred to another sprint. As a rule, the features that are made during the sprint, do not change: what was at the start of the sprint - must be done at any cost by the end of the sprint.
At Kanban, we will look where it originated. Imagine the conveyor on which parts are made for Toyota cars. There is a machine, he makes mirrors for cars. He can make left mirrors, right mirrors, rear mirrors and sun visor mirrors. The principle is simple: click on the button, change the mode - get a new product.
Here you order in Moscow on Kutuzovsky a new Toyota Camry at the "maximum speed", and mirrors in your visor are already being made for you (you chose the maximum speed just because of the mirrors in the visor). The important point here is that we can change priorities at any time. We can quickly switch the machine to another mode.
The main difference between Scrum and Kanban is in the length of the iterations. In Scrum, the iterations are 2 weeks, in Kanban, tasks can be programmed at least every day.
Kanban gives more flexibility, if by flexibility we understand the frequency of changing priorities. Yesterday you filled in a new feature, but today you received data from the front line and found out that this thing does not work as it was intended - people do not press the "buy" button. You give the UX a hat, it gives you new requirements. You raise this task up the queue, the programmer takes this task “from above”, performs it and, by the evening, fix already on sale, the conversion into payments increased by 12%. This is victory.
In Scrum, tasks are usually evaluated in Story points or in hours. Without an assessment, it will not be possible to form a sprint: after all, we need to know whether we will be able to complete the tasks in 2 weeks. After 2 weeks we get valuable statistics - how many hours or Story points the team was able to do for the sprint. Velocity is team performance in one sprint. This option allows the Scrum manager to predict where the team will be in 2 weeks.
In Kanban, it is not accepted to make an assessment. This is optional, the team decides for itself. There is no concept of “team speed”, only the average time per task is considered. Time is considered using a special report - Cycle Time.
Cycle Time for a task = task execution time minus the time to start work on the task. For example, you have columns: to do, reopened, developing, testing, stage testing, deployed. Cycle time for the task will be equal to deployed-developing, that is, how much time has passed from the moment when the task began to be done until the moment it hit deployed.
So, in Scrum, our goal is to finish the sprint, in Kanban, the task.
Scrum is a bus that stops only at certain stops where people leave in groups. And Kanban is a minibus: the passenger wanted to get out, asked the driver and got out where he needed.
What is interesting in Kanban allows you to successfully use it in the sprints? Consider the example of a tool for managing projects Hygger.io .
First, it is WIP (Work in progress). We put a limit on the number of tasks that one employee can simultaneously do. Only Napoleon and Caesar could perform several tasks at the same time. We know how they ended. Therefore, we save our people and save them from burnout: they do only one task per unit of time.
But seriously, switching “from task to task” on an average programmer takes 15 minutes. While you make tea, while looking through Habr, read the requirements for the new task, remember where you left off and find a place in the code. Each switch is an exit from the stream, and it is not always possible to enter the stream - external stimuli can interfere. Therefore, everything is strict: one task per employee. How do we control this? Here it should be clear:
When we first introduced Kanban, the WIP limits immediately showed bottlenecks in our process: there was a large queue of tasks in the Testing column — our tester could not cope with checking tasks. Tasks were in the queue for a very long time. As a result, programmers had time to forget the tasks that the tester rediscovered them after a week or two. Once forgotten, it means you have to look at the code and remember what it was about to dive into the details again. These are all the costs that have lowered our efficiency. Then we connected another QA to the project and the problem was solved.
The second is Swimlanes. Imagine that you have "laid down" the site. As often happens - during working hours. You delegate the task to your Lida or devops - “Raise the site this very minute.” And now he is doing another task and is planning to finish it tomorrow afternoon. What to do? Run to him and beg to switch to the blocker? You can, but you’ll get the nickname “Black Swan” soon. Therefore, we use Swimlanes.
In this case, we have a Swimlane called Blockers. All tasks that require solutions in real time are set in this block. Programmers immediately stop their current task, pause it and begin to make a blocker.
We also have a very useful swimlane called Someday. There we sublimate the tasks that “yes, yes, we’ll do it someday.” It really helps to get rid of everything that is superfluous from the eyes, so that people can concentrate on the main thing. And these tasks, as a rule, remain there forever.
The "right" testers find a lot of the "right" bugs, and this all gets in the queue for programmers. If these bugs are not checked and left in the main task queue, then soon you will find that the programmers are busy with some kind of unimportant nonsense. Therefore, the team must have a person, and better a few, who understand which bugs are critical and which should go to an uncertain future in Someday.
You have a Programming column, followed by Testing. When a programmer has completed a task, he transfers it to Testing. And it turns out that the tester started to test the task. But, in fact, the tester checks the other. Anyway, you set a WIP limit on the number of tasks and after the programmer transferred the task to the test, the QA violated this limit. It became two tasks.
Suppose a programmer does not transfer the task to Testing and leaves it in Programming. But how can he take the next task if he has a WIP limit that he cannot break. In this case, Sub-columns come to the rescue. For example, for the Programming column, we make the sub-columns In progress and Done. And when the programmer finishes the task, he transfers it to Done. When the tester is released, he will take a new task from the Done sub-column of the Programming column and transfer it to his Testing column.
Summing up, I want to note that Scrum is a flexible development methodology, and Kanban is even more. Everything has its time and place. If this is the development of a new product, then at the start of development and before the release it is better to use Scrum, as it makes the development more time-controlled. Also in Scrum there are a lot of communications in the team: the guys discuss the whole backlog of the sprint before the start, ask the authors of the problem questions (UX, product managers, business analysts), evaluate the tasks together using the Planning poker. Scrum helps to thoroughly immerse the team in the essence of the product.
And after the release of the product, a completely different life begins: feedback starts from the users of the product, you need to respond quickly to it. You start working on HADI cycles - you need to constantly test various hypotheses, where the button color can trite the hypothesis. You begin to measure and optimize product metrics, for example, Pirate Metrics (AARRR) and so on. Everything increases your development cycle, you start doing many small tasks in an unpredictable sequence. And for this, Kanban is just perfect.
Whichever Agile methodologies you choose, you can qualitatively implement it using the Hygger.io project management platform .
What did you choose: Scrum and Kanban? Share your examples and observations in the comments!
Two popular agile methodologies
Scrum and Kanban are representatives of Agile-family methodologies. Both are considered flexible and iterative. Before you understand the difference between them, we will briefly recall what unites them.
More than 17 years ago, IT development leaders formulated an Agile manifest. The main thing that we can distinguish from the manifesto:
')
- People and interaction are more important than processes and tools.
- A working product is more important than comprehensive documentation.
- Cooperation with the customer is more important than agreeing the terms of the contract.
- Readiness for change is more important than following the original plan.
You can safely agree with all the arguments, because indeed:
- People are more important than tools, because several people united together and “charged” to one common goal can have greater potential and end up with a greater result.
- MVP approach in development: we release a minimally viable version of the product to the ASAP market. All "svistelochki" leave for later.
- The word "customer" is very requested to change to "user." Project requirements should not be collected from the customer, but from the users of the future product. This is written in detail in Karl Wigs and Joey Beattie.
Often, recently a project is a startup. In the context of start-ups, “ customer development ” comes to mind (Steve Blank described the original technique remarkably well).
In fact, during customer development, we test our hypotheses before starting the development of even a prototype. Our goals are to make sure that:
- Problems that we deal with, exist in the user's life.
- these problems are significant.
- the user will pay for them
- there is a market, and this is not a problem of one person.
- there are channels to attract users (for example, Facebook Ads, or Googl Adwords), and we will be able to find such a cost of attracting users, which will give us a profit (CAC <LTV).
- The flexibility clause is needed when your UX or project manager changes the requirement in the task, and the programmer says, “You have seven Fridays there in the week.” Here at this point in space and time you refer to the point about flexibility. In general, you need to "dig" deeper. What is the willingness to change? In order to be able to respond to feedback. You launched a feature in production, collected statistics on user behavior, made sure that you need to change some features of the feature and sent it for redesign. And now you have an improved version of the function already on sale. To do all this, you need to be ready for changes (this is about Agile) and the ability to capture these changes (this is about analytics and data).
These are the main ideas of the manifesto, but there are still the famous 12 principles that speak for themselves. So, we will not “dig” deeply in them, but rather we will return to the main issue of how Scrum differs from Kanban.
What is the difference between Scrum and Kanban?
The basis of Scrum is short iterations or sprints, as a rule, 2-3 weeks. Before the start of the sprint, the team itself generates a list of features per iteration, then the sprint starts.
After the end of the sprint, the completed features are uploaded to the production, and the unfulfilled ones are transferred to another sprint. As a rule, the features that are made during the sprint, do not change: what was at the start of the sprint - must be done at any cost by the end of the sprint.
At Kanban, we will look where it originated. Imagine the conveyor on which parts are made for Toyota cars. There is a machine, he makes mirrors for cars. He can make left mirrors, right mirrors, rear mirrors and sun visor mirrors. The principle is simple: click on the button, change the mode - get a new product.
Here you order in Moscow on Kutuzovsky a new Toyota Camry at the "maximum speed", and mirrors in your visor are already being made for you (you chose the maximum speed just because of the mirrors in the visor). The important point here is that we can change priorities at any time. We can quickly switch the machine to another mode.
The main difference between Scrum and Kanban is in the length of the iterations. In Scrum, the iterations are 2 weeks, in Kanban, tasks can be programmed at least every day.
Kanban gives more flexibility, if by flexibility we understand the frequency of changing priorities. Yesterday you filled in a new feature, but today you received data from the front line and found out that this thing does not work as it was intended - people do not press the "buy" button. You give the UX a hat, it gives you new requirements. You raise this task up the queue, the programmer takes this task “from above”, performs it and, by the evening, fix already on sale, the conversion into payments increased by 12%. This is victory.
In Scrum, tasks are usually evaluated in Story points or in hours. Without an assessment, it will not be possible to form a sprint: after all, we need to know whether we will be able to complete the tasks in 2 weeks. After 2 weeks we get valuable statistics - how many hours or Story points the team was able to do for the sprint. Velocity is team performance in one sprint. This option allows the Scrum manager to predict where the team will be in 2 weeks.
In Kanban, it is not accepted to make an assessment. This is optional, the team decides for itself. There is no concept of “team speed”, only the average time per task is considered. Time is considered using a special report - Cycle Time.
Cycle Time for a task = task execution time minus the time to start work on the task. For example, you have columns: to do, reopened, developing, testing, stage testing, deployed. Cycle time for the task will be equal to deployed-developing, that is, how much time has passed from the moment when the task began to be done until the moment it hit deployed.
So, in Scrum, our goal is to finish the sprint, in Kanban, the task.
Scrum is a bus that stops only at certain stops where people leave in groups. And Kanban is a minibus: the passenger wanted to get out, asked the driver and got out where he needed.
What is interesting in Kanban allows you to successfully use it in the sprints? Consider the example of a tool for managing projects Hygger.io .
WIP
First, it is WIP (Work in progress). We put a limit on the number of tasks that one employee can simultaneously do. Only Napoleon and Caesar could perform several tasks at the same time. We know how they ended. Therefore, we save our people and save them from burnout: they do only one task per unit of time.
But seriously, switching “from task to task” on an average programmer takes 15 minutes. While you make tea, while looking through Habr, read the requirements for the new task, remember where you left off and find a place in the code. Each switch is an exit from the stream, and it is not always possible to enter the stream - external stimuli can interfere. Therefore, everything is strict: one task per employee. How do we control this? Here it should be clear:
When we first introduced Kanban, the WIP limits immediately showed bottlenecks in our process: there was a large queue of tasks in the Testing column — our tester could not cope with checking tasks. Tasks were in the queue for a very long time. As a result, programmers had time to forget the tasks that the tester rediscovered them after a week or two. Once forgotten, it means you have to look at the code and remember what it was about to dive into the details again. These are all the costs that have lowered our efficiency. Then we connected another QA to the project and the problem was solved.
Swimlanes
The second is Swimlanes. Imagine that you have "laid down" the site. As often happens - during working hours. You delegate the task to your Lida or devops - “Raise the site this very minute.” And now he is doing another task and is planning to finish it tomorrow afternoon. What to do? Run to him and beg to switch to the blocker? You can, but you’ll get the nickname “Black Swan” soon. Therefore, we use Swimlanes.
In this case, we have a Swimlane called Blockers. All tasks that require solutions in real time are set in this block. Programmers immediately stop their current task, pause it and begin to make a blocker.
We also have a very useful swimlane called Someday. There we sublimate the tasks that “yes, yes, we’ll do it someday.” It really helps to get rid of everything that is superfluous from the eyes, so that people can concentrate on the main thing. And these tasks, as a rule, remain there forever.
The "right" testers find a lot of the "right" bugs, and this all gets in the queue for programmers. If these bugs are not checked and left in the main task queue, then soon you will find that the programmers are busy with some kind of unimportant nonsense. Therefore, the team must have a person, and better a few, who understand which bugs are critical and which should go to an uncertain future in Someday.
Sub-columns
You have a Programming column, followed by Testing. When a programmer has completed a task, he transfers it to Testing. And it turns out that the tester started to test the task. But, in fact, the tester checks the other. Anyway, you set a WIP limit on the number of tasks and after the programmer transferred the task to the test, the QA violated this limit. It became two tasks.
Suppose a programmer does not transfer the task to Testing and leaves it in Programming. But how can he take the next task if he has a WIP limit that he cannot break. In this case, Sub-columns come to the rescue. For example, for the Programming column, we make the sub-columns In progress and Done. And when the programmer finishes the task, he transfers it to Done. When the tester is released, he will take a new task from the Done sub-column of the Programming column and transfer it to his Testing column.
Conclusion
Summing up, I want to note that Scrum is a flexible development methodology, and Kanban is even more. Everything has its time and place. If this is the development of a new product, then at the start of development and before the release it is better to use Scrum, as it makes the development more time-controlled. Also in Scrum there are a lot of communications in the team: the guys discuss the whole backlog of the sprint before the start, ask the authors of the problem questions (UX, product managers, business analysts), evaluate the tasks together using the Planning poker. Scrum helps to thoroughly immerse the team in the essence of the product.
And after the release of the product, a completely different life begins: feedback starts from the users of the product, you need to respond quickly to it. You start working on HADI cycles - you need to constantly test various hypotheses, where the button color can trite the hypothesis. You begin to measure and optimize product metrics, for example, Pirate Metrics (AARRR) and so on. Everything increases your development cycle, you start doing many small tasks in an unpredictable sequence. And for this, Kanban is just perfect.
Whichever Agile methodologies you choose, you can qualitatively implement it using the Hygger.io project management platform .
What did you choose: Scrum and Kanban? Share your examples and observations in the comments!
Source: https://habr.com/ru/post/351048/
All Articles