Scrum vs Kanban: Pointless Fights All Agile Teams Have

The concept of Agile has gradually gone far beyond the IT industry. Nowadays many entrepreneurs and companies apply Agile methodology and do need any alternative.

For project management methodologists, Agile is divided into:

• Mindset – the way of thinking, attitudes, and paradigms aimed at the quick reaction.
• 4 basic principles and 12 rules – the philosophical foundation of Agile.
• A set of Agile practices – what to do and how to build work so that the way of thinking and the principles of the Agile manifesto naturally combine.

The most popular approaches to Agile methodology are Kanban and Scrum. In this post, we compare these frameworks and highlight their advantages.

Kanban and Scrum: the key advantages and identities

Kanban and Scrum are quite similar in their main features. That is why some people think that there is no difference between Scrum and Kanban. However, this is an incorrect point of view. In spite of the fact that both methodologies serve the same goal (managing Agile projects), they have some differences in their approaches to work and its organization.

While implementing Agile methods it is necessary to understand that Kanban and Scrum are two different methodologies and you cannot use them simultaneously.

To identify the differences between Scrum and Kanban we should, first of all, provide the definition for each of these methods and its main features.

Scrum

Scrum is a method of software development that is focused on teamwork. The team is the main aspect of Scrum. It acts independently and performs the whole amount of the work required to complete the project.

The Scrum team does not require managers. It manages the project in a team way and all of its members are responsible for the final product. Scrum is an iterative method. The work of Scrum teams is subdivided into sprints. Each of these sprints is an independent piece of work that has its own plan.

It’s interactive in nature and focuses on maximizing the team’s ability to adapt and respond quickly to changes.

• Based on Sprints – a set period of time (2-4 weeks) during which the team completes specific work.
• Scrum meetings: Sprint Planning Meeting, Daily Scrum Meeting, Sprint Review Meeting, Sprint Retrospective.
• Has three key roles: Scrum Master, Product Owner, and Scrum team.

Scrum works by assigning certain jobs into Sprints and committing the team to complete them by the end of the Sprint.

• The Product Owner (PO) prioritizes the Backlog.
• At the Sprint Planning Meeting, the PO describes the top items to the team. The team decides which items they can complete during the coming Sprint.
• These items go from the product backlog to the Sprint Backlog.
• The team has Daily Scrum Meetings to inform about what each person accomplished yesterday, what will accomplish today and what impediments they’ve had along the way.
• The Sprint Review Meeting revolves around what was done. Participants typically include the Product Owner, the Scrum team, the ScrumMaster, management, customers.
• Sprint Retrospective is for the team to inspect their last sprint. They concentrate less on what was done and more on how it was done.

Kanban

Kanban is a method of software development that does not pay great attention to the team’s self-managing abilities. The structure of teams in Kanban depends on the certain project and the progress of workflow.

Generally, Kanban is an approach to software development that is focused on the workflow. In Kanban, the progress of work can truly be a game-changing issue in terms of the team structure. The workflow is usually visualized on a special Kanban board which is quite similar to the Scrum task board.

It focuses on bringing more value to the end customer using workflow visualization and removing waste.

• Based on a visual board for managing work in progress. Tasks start on the left side of the board and move across the board (“done.”)
• No pre-determined timeline but the work is broken down and displayed visually.
• No specific roles; meetings as needed.
• WIP is matched with a team’s ability to deliver.

Kanban vs Scrum: defining key differences

The main difference between Scrum and Kanban is:

• In Scrum – once the Sprint is planned and the tasks are placed in the queue, all the team can do is to pull.
• In Kanban – after the tasks are placed in their appropriate columns, it’s up to the team which items they prefer to work on first.

Kanban aims at giving team members just enough work so that the team is working at capacity. In this case, the team benefits from flexible planning and total transparency because whatever’s on the board is the top priority.

By contrast, Scrum divides work into fixed-length iterations (Sprints). Whatever is scheduled for a Sprint is the team’s top priority. So, Kanban is more flexible in this respect.

Differences in process

We have already mentioned that Scrum is an iterative method of software development. Division of the work process into sprints is its main principle. The Kanban process, on the other hand, is not an iterative process. The workflow in Kanban is inseparable from its beginning to its end.

Difference in roles

There are at least three roles that can be defined in every Scrum team: the team itself, the Product Owner, and the ScrumMaster. All the process is organized by sharing responsibilities between people who perform these roles. In Kanban, there are no defined roles. The structure of the team can change from one project to another, or even during one project.

The difference in task boards

The columns of the Scrum task board are designed to reflect the periods of the workflow from the beginning of the sprint until its end. The columns of the Kanban board limit the number of items in each column to make the workflow faster.

Here’s how a typical Scrum board looks in Hygger:

Here’s a Kanban-focused board:

Can you get the most from both approaches?

Since Kanban is fitting in nicely with Scrum, there are no reasons not to try their combination – Scrumban. The team divides work into iterative processes and monitors it with the help of a visual board.

Scrumban Process

1. Goals. The team defines its goals. A goal may be a broad one, In this case, the team accomplishes it by doing multiple smaller tasks.
2. Story Queue. The team breaks goals into multiple Stories.
3. Analysis. The team analyzes the Stories and select a few of them for future work.
4. Development. The team works on the selected Stories.
5. Testing. QA teams test the results.
6. Deployment. The team puts results into practice.
7. Done. The team marks all completed stories as Done.

WIP Limits

With Scrum, teams are limited to working within Sprints. In Scrumban, there are no time-based limitations. The work is limited through WIP limits on columns on the task board.

The goal is to move stories from left to right on the board, still maintaining quality standards. If too many things are in progress at the same time, quality can be at risk.

Meetings

Planning meetings, Daily standups, Review meetings, Retrospective meetings are a standard practice of Scrumban. Though you see them as pointless (in fact, many teams do) but if applied mindlessly, the benefits of such meetings will far outweigh the time and efforts spent on them.

Final Thoughts

Scrum, Kanban, Scrumban – none of them is easy. If you try to switch to Kanban, Scrum or Scrumban without solving the existing problems and challenges, a new approach won’t bring the desired benefits. Once you’ve fixed what bothers you, it’s time to try something new and see if it meets your expectations.

Have you tried switching from Scrum to Kanban? Feel free to leave comments.