Joshua Barnes
Kanban Vs. Scrum. Do you think scrum is the only solution when a company goes for an agile transformation? Do scrum work in all the departments and work culture? No, the scrum is not an ideal system to manage all the tasks.
Let’s take an example. You are a part of a big multi-national company, where you have developments teams, contributing to a product. And you have a support team too. The support team resolves the day-to-day issues that other teams face. Like installing the software, or system administration.
Imagine, one morning you reach reached the office and your laptop is not booting. You create a ticket for the support team to resolve the issue.
So, what happens if the support team decides to go with the scrum? If the support team follows the scrum implementation, the ticket will go to the backlog. They will be in a sprint. Maybe fixing some other issues as per the sprint goals assigned by the product owner.
Being an MNC, there are multiple team members with tickets, with multiple priorities. But you are still waiting because your system is not booting. You have to wait for weeks, or until the support team reaches the next sprint. Then you are lost.
Therefore, scrum is not an ideal methodology for teams where they have uncertainties. Like we discussed above, about the support teams.
Before the comparison between Kanban and Scrum, let us get an overview of Kanban. If you know it, you may skip this part and jump directly to the Kanban vs. Scrum comparison below.
What is Kanban?
Kanban is an excellent agile solution for the team that gets continuous requests, which are to be resolved in a short time. Certain priorities can’t be planned beforehand as it comes all of a sudden.
The Kanban method was first adopted by Toyota, in the late 1940s. Although it was devised to be used by manufacturing companies. While, later on, it was realized that, kanban is applicable to any type of industry.
What is an Ideal Kanban Board?
An ideal kanban board has only three columns.
- To-do
- Doing
- Done
- Blocker(optional)
Blockers are the tasks or obstacles that slow down the overall progress in work delivery. If there are blockers, the team gives more priority to the blocker. The blockers are removed by understanding the system or taking help from an experienced employee, to fix the issues.
Kanban Vs. Scrum:
Let us discuss the difference between scrum and kanban. It will help you decide the right method for your work culture.
| Sl. | Kanban | Scrum |
|---|---|---|
| 1. | Kanban focuses on continuous flow and delivery. No such fixed role or length of time. | Scrum has a regular and fixed length of tasks assigned under sprints. It is supposed to be delivered at the end of each sprint. |
| 2. | Work efficiency and progress are measured by lead time, cycle time, and work-in-progress. | Work efficiency or productivity is measured by velocity in sprints. |
| 3. | In Kanban, you can change your goals and priorities at any time. | In scrum, the changes cannot happen during the sprint. |
| 4. | No required roles or positions of specific people in kanban. | Scrums involve roles and responsibilities as product owner, scrum master, and their respective teams. |
By knowing the difference between kanban and scrum, let us go back to the previous example, we discussed above.
In the kanban system, you will create a ticket about your system is not booting. The same day, in fact at the same time, the support team will get a notification. It will be highlighted in their Kanban to-do list. One of the support team members will pick it up and solve it at the earliest. This is what is meant by continuous flow and delivery.
1. When you have no such fixed roles & responsibilities:
When your focus is more on things done and fixed as early, kanban is excellent. Like we discussed above the support team.
Kanban is suitable for teams that are autonomous. There are no predefined roles assigned to a team. Although, the same may be monitored by the project manager, the team collaborates and move on.
Scrum has predefined roles and responsibilities. You must need a scrum master. He is the owner of the sprint. You must need a product owner. He is the owner of the backlog. And the team members who execute the work. Altogether, they make a scrum organization.
Basically, for strategic decisions, business profits, software architecture, development & execution, it needs a fixed & detailed earlier planning, procedure, and implementation. Therefore, scrum is the most appropriate method for such teams.
2. Continuous delivery:
As we discussed on the support team, when a task comes to their to-do list, their rule is based on priority. They start working on it and immediately move to do. That means it is done and ready to be delivered. Also known as continuous delivery. Therefore, the Kanban method is ideal for such teams.
Scrum is an iterative model, that involves time-boxed events in sprints. Deliveries are determined by sprints. A time period, usually two weeks; when a set of work must be done and reviewed. It is mostly suitable for development, and sometimes marketing teams, who may not have priorities for frequent delivery, and needs a detailed plan and procedure, to deliver as per sprint goals.
3. Work Prioritization:
Both Kanban and Scrum use a “pull system”. Means you pull tasks from the backlog.
Kanban is simple. It is like a normal to-do list where you take one task until it is complete. The ultimate aim is to take a task and finish it off.
Kanban is more about focusing on one task. It avoids any distraction or focus switch. It ensures that the number of items in progress is proportional to the number of team members. Suppose, if the team consists of three members, there should be only 3-4 items in the progress column, so that everyone works on one task. And, unless the present task is done, no one is allowed to pull it out from the to-do list. If it goes to blocker, a few team members can be combined to work on that, after they complete their respective tasks.
Scrum involves the refinement of work, prioritization with the team, preparing backlogs, define acceptance criteria, and the goal of the sprint as defined by the product owner.
It involves the preparation of user stories, time estimates, dividing tasks into team members, with a lot of scrum events.
4. Scope changes:
Kanban is very flexible. You can change the scope, priorities, goals at any point in time. Because certain teams get tasks every day and they take it into consideration as a high priority.
In scrum, once the sprint starts, ideally the scope, goals, and priorities remain the same till the end. If the scope is charged in the middle, that becomes one of the major mistakes in scrums. That may be due to the product owner, which is rare.
5. Estimating the performance of the team:
How can you estimate the performance of a team in Kanban? In Kanban, you can estimate the performance of a team based on the cycle time. Cycle time is the amount of time it takes to complete a task from the beginning to the end.
In scrum, we use velocity to measure the performance of a team. The sprint velocity is used as a performance measure, that each additional sprint relies on the success of the previous sprint.
Verdict:
Kanban is ideal for projects with widely varying priorities. It is great for the teams who get a lot of incoming requests(as we discussed about the support team), and the turnaround time is very fast. Means you have to complete a task in short time.
Other than the support team, when a project goes for a bug fixing phase, Kanban is very handy. Because, when a bug comes, you cannot wait until the current sprint is over. You have to fix it at the earliest. Moreover, when a software project goes into bug fixing, the team should become autonomous.
Kanban is also good for software testing. Because the team is doing the verification, validation, white box testing, black box testing, etc. We can also say Kanban is more informal than Scrum.
On the other hand, scrums are very good for R&D activities, software development, where planning, analysis, and estimations are necessary. Scrums are formal and organized.
Lastly, we hope you are clear with the concepts and practical use cases of both the agile frameworks. Hope, you choose the right method that helps your organization adopt a more productive work culture.
