Blue Flower

More and more teams want to incorporate the Scrum or Kanban way of working. I am very happy when I notice that the teams of an organization have reached this decision. I will try to explain to you the similarities and differences between Scrum and Kanban.

Anyone who follows project management trends knows that technology and tools are only half of the end result (working product). Values, team relationships, and the team's focus on certain things are very important.

Scrum and Kanban: Similarities and Differences

Scrum and Kanban are two frameworks, that is, ways to organize work. Both are considered Agile. Agile - this is a mindset (way of thinking) for managing products and projects. It is a system of values, principles, and attitudes.

The Agile approach encourages repetitive, growing, and highly adaptable workflows that lead to the delivery of a working product as soon as possible after the start of the project. Reference: "Scrum and Kanban: similarities and differences", https://www.policymatters.net/scrum-and-kanban-similarities-and-differences/

I would like to explain Agile with an example:

In rugby, there is a concept of "scrum". The scrum is formed on the playing field, with eight players from each team. The purpose of the scrum is to continue the game immediately after a minor violation or suspension. As for me, this is a description of working in the Agile team.

Another example:

Let's look at a shot with the help of a self-propelled missile. It consists of approximately the following: we determine the coordinates of the target, set them in the rocket, and then launch. The missile takes off and aims at the target, constantly adjusting its trajectory so as not to collide with an obstacle and hit the target as accurately as possible. It is similar, for example, to Scrum, because throughout the segment of the road from point A to point B, we adjust our course to achieve the goal, namely to make the product itself for which the customer has approached us. Reference: "The differences between Scrum and Kanban methods of working in Agile projects", https://www.kievpress.info/differences-between-scrum-and-kanban-agile/

At Scrum and Kanban, the team takes a project and divides it into smaller tasks, this is part of the Agile philosophy. All project tasks that need to be completed are added to a common list - Backlog.

Scrum and Kanban are two frameworks that have a lot in common, but they also have differences.

The Scrum team divides the project time into equal pieces - sprints. An iteration is considered really successful if a large value is provided. As all sprints are of equal duration, rhythm appears in the work of the team. In Scrum, you can't add tasks to the current sprint, so Scrum is less flexible. Even if there is an urgent and important task, it will not take effect until the next sprint. Reference: "Working on projects with Scrum and Kanban: which to choose from both", https://eduwiki.me/projects-with-scrum-and-kanban-which-to-choose/

There are no sprints in Kanban. The project is usually divided into iterations, but they can have different durations. The rhythm of Kanban is not prescribed. In Kanban, new tasks are added at any time. If something needs to be done urgently, the team does not wait for the next sprint, the task remains in action as long as necessary until the team completes or cancels it.

Scrum has sprints and roles (Scrum Master and Product Owner), Kanban has no roles. Kanban and Scrum use the Board-Agile project management tool to visualize the work.

Kanban Board has columns, each column means a logical step in your workflow (Workflow), they add tasks.

In Kanban, the goal is to limit Work in Progress and increase efficiency, ie. to limit the accumulation of surplus stocks at each point of production. When a certain limit is exceeded, it shows inefficiency, which must be considered by the teams and the management.

In Kanban Board in each column, the number of tasks will be limited, while Scrum Board has no such restrictions. The Kanban Board is used continuously throughout the product development lifecycle, simply by changing the cards. At Scrum, the dashboard is cleaned and restarted at the end of each sprint. New tasks are added, which remain there until the end of the sprint. They are also often in columns and have the appropriate status. Reference: "Lean Management strategy for development in software companies with Scrum and Kanban"

In both cases, the teams are self-organizing. Outsiders such as customers, seniors, or any other type of management should not make decisions instead of the team.

The benefits of using Scrum and Kanban are enormous because Agile is associated with adaptive planning, evolutionary development, the fastest possible release of new product versions, continuous improvement, and quick response to emerging difficulties.

Scrum and Kanban boards for work visualization

Scrum and Kanban boards will help visualize the work. A well-organized team will no longer need to turn to management for every little thing.

I would venture to say that the team will not lose anything if it implements Scrum or Kanban. Efforts are needed: the team must be self-organized, must accept the principles, values, and way of working of Agile, to ensure full transparency and flexibility of processes. The only thing - it is almost never easy to make changes, to adapt to another way of working. It takes time, great desire, and patience. People - this is a basic thing in both Scrum and Kanban. Reference: "Waterfall vs V-Model vs Scrum vs Kanban", https://newia.info/waterfall-vs-v-model-vs-scrum-vs-kanban/

The fact that the teams want to incorporate one of them into the work process, in my opinion, is very good news. In your email, you mentioned that people constantly want things from management. Sometimes these requests have led to mistakes. Embedding the Scrum or Kanban way of working will solve this problem, because a self-organizing, responsible and disciplined team is the working principle of these two frameworks. Outsiders such as customers, seniors, or any other type of management should not make decisions instead of the team.

Because the team is autonomous and self-organizing, it is responsible for the success or failure of the project. If it is decided that Scrum or Kanban will be built into the work process, the teams must decide, discuss the possibilities of what, how and most of all why to use. It would be a mistake if such a decision and order comes down from the top management, especially if it has no direct idea of ​​the daily work of the teams, their processes, needs, problems, competence, weaknesses, and strengths. It will be good for them to experiment and go through different ways of working and decide who is best for them. Sometimes one way of working will no longer be useful and they may decide to change it.

It seems to me that changes are already needed. It is very good that the teams themselves are interested in Scrum or Kanban because one of the main difficulties in embedding these two frameworks is the reluctance of the team to accept the new reality.

I think it would be good to discuss this idea with the clients of the organization because their desire and opinion is also significant factor.