When it comes to choosing between two options, there is always a risk to be influenced by opinions and dubious facts. Selecting any methodology or work approach, we strive to avoid mistakes and study as many facts and details about the subject as possible to make the right choice.
In Agile software development, this choice is also challenging, especially if it's about Scrum and Kanban.
Before you come to such a difficult selecting, you could be probably faced with another preliminary dilemma related to the choice between Waterfall vs Agile. However, you've made the right choice and now you face two independent paths in the world of Agile development.
Scrum and Kanban are two branches of the Agile family (however, many people do not consider Kanban an independent methodology and put it apart from other methods). Both are flexible and iterative.
There was a survey, conducted in 2018 among 101592 software developers from all over the world. Almost 86% of them use Agile in their work. Looks impressive, right?
Scrum allows people to address complex adaptive problems, while productively delivering products of the highest value.
The Scrum framework is lightweight and simple to understand but can be difficult to master. It consists of short iterations or Sprints, that usually last 2-3 weeks.
The list of possible features for iteration is created by the team. Then they start running a Sprint. Typically, the features that are being worked on during a Sprint do not change. What was started at the beginning must be done by the end anyway.
Scrum contains various terms, concepts and artifacts. In order to understand them all, read and study and Scrum glossary or ultimate guide.
Kanban can be overviewed from the perspective of the place where it was created — Toyota company.
Everyday conveyor lines produce cars' components. A special machine designs mirrors for Toyota cars: left, right, back mirrors and the mirrors for sun visors. Just one click on a button, the mode is changed and they get a new product.
The key moment here is that they can change priorities at any moment. They are able to switch the machine to a different mode and that's it.
However, if you need some more theory about Kanban, you can consider it as a visual system for managing work as it moves through a process. It visualizes the workflow and the actual work passing through that process.
Kanban assists to identify potential bottlenecks in processes and fix them to provide a cost-effective flow.
The core difference between Scrum and Kanban is the iteration length:
Kanban is more flexible. Imagine that yesterday you released a new feature to production server with some events for tracking feature's KPIs.
With the help of analytics, your product manager understands that something went wrong. He decides to make some changes to the logic of the feature. He puts the task on a Kanban board and raises it up in a column. As soon as the programmer is free, he will take up this task and will release it right after testing. It will take several days for everything.
In the case of Scrum, you will have to wait a whole Sprint, that is 2-3 weeks.
Scrum requires task estimation with Story Points or Hours. You'll not be able to form a Sprint without this estimation. And you should know exactly, whether you'll finish all the tasks in 2 weeks.
After 2 weeks you get valuable statistics about how many story points or hours your team managed to complete during a Sprint. With the help of this info, a Scrum master predict where the team will be in 2 weeks.
In Kanban, people also can estimate, but this is optional. There’s no team velocity. You take consider only an average time for task completion and count it in a Cycle Time Report.
Task Cycle Time = Time spent working on a task – Time when the task was started
Just imagine that the current goal in Scrum is to finish a Sprint but for Kanban, you have to finish a task.
WIP is Work in Progress. It's important to limit the number of tasks that specialists can work on at the same time. Yes, there are no Caesar and Napoleon among us to be famous for incredible multitasking skills.
It's optimal when people work only on one task at one unit of time. It usually takes 15 minutes for a developer to switch from one task to another one.
You need time to make tea, to look through some articles on the web, to read requirements for a new task, to remember where you’ve paused and found that spot in the code.
Be sure, switching from task to task is a leaving from one thoughts route to another and it’s not always easy to get back.
Noone is in safe from failures and your site may not work during business hours. You create and assign a task to fix it immediately to your DevOps engineer, for example.
But he is doing another task and is planning to finish it tomorrow by lunch. What to do? It's not a good idea to whirl around him, tap on the shoulder and beg to switch to a blocker. You can do it once, but is it the right way to act? Definitely no, that's why we use Swimlanes.
In this example, the «Blocker» Swimlane is the solution, making the developer stop doing his current task immediately, pause it and start working on blocking things.
We also utilize a «Someday» Swimlane that covers all tasks that we will likely do one day under that block.
The Swimlane helps to set aside all unnecessary things so people could focus on the important tasks.
There is a «Coding» column and a «Testing» one right after it. When the developer finishes his task, he moves it to the «Testing». You may think that the tester has started working on this task already, but in fact, he is doing another one. Once the developer moves the task for testing, he disturbs WIP limit for QA. This is a real challenge!
Actually, the developer is free to not move this task to the «Testing» column and will leave it in the «Coding» one. This is also not good because his task will remain in the «In Progress» column, although he has already completed it.
Nevertheless, how to take the next task if WIP limits should not be broken? Sub-columns do assist. The developer simply moves the completed task from the «Coding To-do» sub-column to the «Coding Done». And the tester, when the time comes, will take a new testing task from the «Coding Done» sub-column.
Summarizing all together, let's define Scrum as a flexible development methodology but will title Kanban as even more flexible.
Scrum looks better at the beginning of product development as it helps to manage deadlines easier. Additionally, there’s enough communication in teams. They thoroughly discuss Sprint Backlog before the start.
They discuss tasks with their creators. The team estimates tasks according to Planning Poker system. In fact, Scrum helps to understand the core of the product.
However, after the product launch, you receive feedback from users and you need to react quickly. You start measuring and optimizing product metrics, everything breaks your development cycle into smaller units and you start doing many small tasks in chaos. This is the right time to recall Kanban that perfect for such case.
Have you applied both methodologies? What is your favorite in the Kanban vs Scrum opposition?
In Agile software development, this choice is also challenging, especially if it's about Scrum and Kanban.
Scrum vs Kanban: two methodologies, one choice
Before you come to such a difficult selecting, you could be probably faced with another preliminary dilemma related to the choice between Waterfall vs Agile. However, you've made the right choice and now you face two independent paths in the world of Agile development.
Scrum and Kanban are two branches of the Agile family (however, many people do not consider Kanban an independent methodology and put it apart from other methods). Both are flexible and iterative.
There was a survey, conducted in 2018 among 101592 software developers from all over the world. Almost 86% of them use Agile in their work. Looks impressive, right?
Scrum or Kanban: what is the best choice?
Scrum allows people to address complex adaptive problems, while productively delivering products of the highest value.
The Scrum framework is lightweight and simple to understand but can be difficult to master. It consists of short iterations or Sprints, that usually last 2-3 weeks.
The list of possible features for iteration is created by the team. Then they start running a Sprint. Typically, the features that are being worked on during a Sprint do not change. What was started at the beginning must be done by the end anyway.
Scrum contains various terms, concepts and artifacts. In order to understand them all, read and study and Scrum glossary or ultimate guide.
Kanban can be overviewed from the perspective of the place where it was created — Toyota company.
Everyday conveyor lines produce cars' components. A special machine designs mirrors for Toyota cars: left, right, back mirrors and the mirrors for sun visors. Just one click on a button, the mode is changed and they get a new product.
The key moment here is that they can change priorities at any moment. They are able to switch the machine to a different mode and that's it.
However, if you need some more theory about Kanban, you can consider it as a visual system for managing work as it moves through a process. It visualizes the workflow and the actual work passing through that process.
Kanban assists to identify potential bottlenecks in processes and fix them to provide a cost-effective flow.
The core difference between Scrum and Kanban is the iteration length:
- You work for 2 weeks in Scrum.
- In Kanban, you may provide developers with tasks even every day.
Kanban is more flexible. Imagine that yesterday you released a new feature to production server with some events for tracking feature's KPIs.
With the help of analytics, your product manager understands that something went wrong. He decides to make some changes to the logic of the feature. He puts the task on a Kanban board and raises it up in a column. As soon as the programmer is free, he will take up this task and will release it right after testing. It will take several days for everything.
In the case of Scrum, you will have to wait a whole Sprint, that is 2-3 weeks.
Scrum requires task estimation with Story Points or Hours. You'll not be able to form a Sprint without this estimation. And you should know exactly, whether you'll finish all the tasks in 2 weeks.
After 2 weeks you get valuable statistics about how many story points or hours your team managed to complete during a Sprint. With the help of this info, a Scrum master predict where the team will be in 2 weeks.
In Kanban, people also can estimate, but this is optional. There’s no team velocity. You take consider only an average time for task completion and count it in a Cycle Time Report.
Task Cycle Time = Time spent working on a task – Time when the task was started
Just imagine that the current goal in Scrum is to finish a Sprint but for Kanban, you have to finish a task.
From theory to practice: the way how we do it
Limiting WIP
WIP is Work in Progress. It's important to limit the number of tasks that specialists can work on at the same time. Yes, there are no Caesar and Napoleon among us to be famous for incredible multitasking skills.
It's optimal when people work only on one task at one unit of time. It usually takes 15 minutes for a developer to switch from one task to another one.
You need time to make tea, to look through some articles on the web, to read requirements for a new task, to remember where you’ve paused and found that spot in the code.
Be sure, switching from task to task is a leaving from one thoughts route to another and it’s not always easy to get back.
Swimlanes
Noone is in safe from failures and your site may not work during business hours. You create and assign a task to fix it immediately to your DevOps engineer, for example.
But he is doing another task and is planning to finish it tomorrow by lunch. What to do? It's not a good idea to whirl around him, tap on the shoulder and beg to switch to a blocker. You can do it once, but is it the right way to act? Definitely no, that's why we use Swimlanes.
In this example, the «Blocker» Swimlane is the solution, making the developer stop doing his current task immediately, pause it and start working on blocking things.
We also utilize a «Someday» Swimlane that covers all tasks that we will likely do one day under that block.
The Swimlane helps to set aside all unnecessary things so people could focus on the important tasks.
Sub-columns
There is a «Coding» column and a «Testing» one right after it. When the developer finishes his task, he moves it to the «Testing». You may think that the tester has started working on this task already, but in fact, he is doing another one. Once the developer moves the task for testing, he disturbs WIP limit for QA. This is a real challenge!
Actually, the developer is free to not move this task to the «Testing» column and will leave it in the «Coding» one. This is also not good because his task will remain in the «In Progress» column, although he has already completed it.
Nevertheless, how to take the next task if WIP limits should not be broken? Sub-columns do assist. The developer simply moves the completed task from the «Coding To-do» sub-column to the «Coding Done». And the tester, when the time comes, will take a new testing task from the «Coding Done» sub-column.
Final thoughts
Summarizing all together, let's define Scrum as a flexible development methodology but will title Kanban as even more flexible.
Scrum looks better at the beginning of product development as it helps to manage deadlines easier. Additionally, there’s enough communication in teams. They thoroughly discuss Sprint Backlog before the start.
They discuss tasks with their creators. The team estimates tasks according to Planning Poker system. In fact, Scrum helps to understand the core of the product.
However, after the product launch, you receive feedback from users and you need to react quickly. You start measuring and optimizing product metrics, everything breaks your development cycle into smaller units and you start doing many small tasks in chaos. This is the right time to recall Kanban that perfect for such case.
Have you applied both methodologies? What is your favorite in the Kanban vs Scrum opposition?
