Scrum or Kanban: What’s Better for Software Development?
Choosing the right option between the methods of development management is not an easy thing. Especially, if it is about Scrum and Kanban.
It’s all about Agile. The methods that represent a big Agile family are both are flexible and iterative.
What unites them? The Agile Manifesto does. It was formulated more than 17 years ago by IT development leaders. There are 12 principles:
People are more important than tools. People united together and committed to the common goal will achieve more.
Scrum or Kanban?
Scrum is about short iterations or sprints that last as a rule no longer than 2–3 weeks. Teams make a set of features for iteration and then start running a sprint.
Usually, features that are being worked on during a sprint do not change. Everything that was started at the beginning of the sprint must be done by its end.
What’s about Kanban? Let’s consider it at the place where it was created.
Imagine a product line that produces the components for Toyota. There is a machine that produces different kinds of mirrors for Toyota cars. All they need to do is to press a button, change the mode and get a new product.
The crucial idea here is that they can change priorities at any moment. The can quickly switch on the machine to the different mode.
Now we can easily define the key difference between Scrum and Kanban — the iteration length.
There are 2 weeks in Scrum, while in Kanban you may provide developers with tasks every day.
What’s more?
Kanban is more flexible. By flexibility we mean priorities change the frequency.
Yesterday you added a new feature. Today you get information on how it works in real life and learn that that thing doesn’t work as it was planned. Customers simply don’t buy. The team proposes new requirements and you move the task up to the top in a queue. Developers do their best and start working on this task and that’s it!
The fix is ready for production by the evening and conversion rate is increased. This is a win for sure.
Scrum allows you to estimate your tasks with story points or hours. You will not form a sprint without estimation. We need to know if we finish all tasks in 2 weeks.
After 2 weeks, we get valuable statistics on how many hours or story points the team managed to complete during a sprint. This allows a Scrum manager to predict where the team will be in 2 weeks.
In Kanban, it is optional and the team decides whether they do it or not. There is no team velocity here. You take into account only an average time for task completion that s counted by a special Cycle Time Report.
The goal in Scrum is to finish a sprint while for Kanban you need to finish a task.
If you want to know all the details about how to use friendly product management tools to manage Scrum and Kanban, you may dive into the following tutorials:
Which Kanban practices could be useful in Scrum?
Work in Progress
Work in Progress or WIP is about the number of tasks, which an employee can work on at the same time.
Your team members are not Caesar or Napoleon who were famous for their multitasking skills, so care of them and save them from burning out, to work only on one task at one unit of time.
According to research, it takes 15 minutes for a developer to switch from one task to another one!
Switching from task to task is a leaving from a flow of thought to another and it’s not always easy to get back to that stream of thought.
We have a strict rule: One task per person. How do we control it? Here’s the answer:
Swimlanes
Swimlanes are horizontal columns. They are quite useful to visually separate different aspects of projects.
Let’s imagine that your site is down during working hours. You assign a task to fix it immediately to your team leader. They are working on another task and are going to finish it tomorrow. What to do?
You can beg them to switch to a blocker but are you willing to work that way all the time? That’s why we use Swimlanes.
All tasks that need a real-time solution are set in a “Blocker” Swimlane. Developers stop doing their current tasks immediately. They pause them and start working on blocking things.
“Someday” is also a really useful Swimlane. We can put all the tasks that we will likely do one day under that block. It helps to set aside all unnecessary things and people can focus on the important tasks. These “Someday tasks” usually stay in that Swimlane forever.
Testers find many “right” bugs and they go to developers. If you leave them in the main line of tasks then you will realize that developers are working on some unimportant stuff.
So it’s a good idea for every team to have a responsible person who understands which bugs are critical and which ones should go straight to Someday.
Sub-Columns
You probably have columns named “Coding’ and “Testing”.
When developers finish their task, they move it to “Testing”. You may think that testers sort of started working on a task already, but they are doing another one.
Once developers move a task for testing, they disturb that limit for QA. Now there are two tasks already. Let’s say developers will leave the task in “Coding”. Nevertheless, how can they take next one if they have a WIP limit?
Sub-columns are the solution. When developers finish their tasks, they move them to “Done” Sub-column. When testers are free, they will take another new task from “Done” sub-column of “Coding” column to the “Testing” column.
To sum up
The crucial thing we want to highlight here is that Scrum is a flexible development methodology but Kanban is more flexible.
It’s better to use Scrum at the beginning of product development as it’s easier to manage deadlines with the method.
In addition, there is a lot of communication in the team. They discuss all the Backlog sprint before the start and ask questions to tasks creators. The team estimates tasks together using a planning poker. Scrum helps a team to understand a core of the product.
But after the launch, you start receiving feedback from users and need to react quickly. You start measuring and optimizing product metrics. Everything breaks your development cycle into smaller units. You start doing many small tasks in unpredictable order. And Kanban is perfect for it.
What do you think about both methods? Which is appropriate for you? It seems that to understand this we need some time. How do you think?
