Comparison between Scrum and Kanban methodologies

In this article, we present a comparison between Scrum and Kanban methodologies due to the increased interest in new product development models and I would like to give more information about them.

I hope it becomes clear what exactly Kanban and Scrum are and what benefits the introduction of one or the other in the teams can lead to.

Both approaches are part of the AGILE flexible methodology popular in recent years. Reference: Lean and Agile software development, This methodology provides fast and quality delivery of the finished product, with minimal loss of strength and energy of the teams and high value (profit).

What is the SCRUM approach

Scrum is a framework in which each team as a number varies between 3 and 9 people. Reference: What is the Scrum methodology? There are 3 main roles in Scrum: product owner, scrum master, and developers who will be responsible for the implementation of the project. These roles are called the Scrum Team (a combination of everyone) Reference: Scrum example team and projects scenarios,

Product owner

He is the representative of the business (guarantor) in the team, the voice of the business in Scrum. The product owner constantly communicates between the scrum and the business, conveys to the developers any new desire to change the product, add functionality or software requirements, to finally reach a product that 100% covers the idea and desire of the customer and gives him satisfaction and satisfaction.

Scrum Master

Does not manage the team. The Scrum Master is subordinate to the team leader with the main task to remove all obstacles in the way of project implementation. Reference: Professional Scrum Master vs Professional Scrum Developer,

The Scrum Master should facilitate, support, and facilitate the work of the team so that people can maintain their creativity and productivity, and the product owner can clearly see the development of the project. The scrum master must protect his team from outside interference and irritants and do everything possible for the team to succeed.

Development Team

The team is responsible for its own organization (self-organizing) and for the completion of the project. Reference: How to Build a Scrum Development Team?

The Development Team is multifunctional. It includes software engineers, architects, programmers, QA specialists, designers. The team has the autonomy and responsibility to meet the goals of the sprint.

The Development Team in Scrum gathers at the event called Daily Scrum meeting but problems often arise and the Scrum Master needs to participate together with the Developers at their Daily Scrum event Reference: Daily Scrum meeting: problems, questions and answers,

We have reached the most distinctive feature of the Agile Scrum and that is Sprint.

However, before we explain what a sprint means, I will explain exactly how Scrum works. Reference: Kanban vs Scrum? What Are the Differences Between Scrum and Kanban? A prerequisite in the work of Scrum is that the team works physically together, in one space in one place. If this is not possible, in at least two adjacent rooms.

Imagine a project.

In the minds of anyone familiar with traditional management, the implementation of the project will have a vertical structure (head of the top, below him deputy’s head and various units). The project is, for example, to make an e-shop website.

The project manager and the project specifications

The project manager lowers the Specifications (Client’s Assignment) vertically, distributes the tasks and expects when it will be reported to him that the site is ready to see.

Each part of the detailed description of the site (what it will sell, what it will look like, what functionalities it should have, what interactions with other systems it should support, etc.) is taken over by different units and the final product is expected to be assembled when everyone is ready.

It takes a long time to reach the cherished goal – a ready site, the project manager sits down with the client to demonstrate and …… oh, a miracle! Instead of the joy of achieving the dream site, the customer is angry.

Why so? The manager asks him.

Because I don’t like many things and they are not as I imagined them – the font is not exactly what I wanted; the color differs in tones from what I thought; the buttons on the title page are too small, the product fields are shifted too far to the left ….. etc.

A change begins in every part of the things that the client has not approved. Some things return to the starting position, others are corrected, others are added. Time is running out. Instead of starting a new project with new money, we are still finishing the first one.

However, Scrum as Agile mythology can play the role of a miracle and save all these nerves and time, not to mention the money. Reference: Agile organizational culture,

How Agile project management works

The whole project is broken into very small parts. Each part of it must be a separate piece, which, when ready, we can show it to the client.
Just as a puzzle is a picture, broken into small individual parts, which, when arranged, we get back the whole picture.

We give ourselves time (sprint) to make each part. The sprint can be a maximum of 1 month but is usually 2 weeks. Within each sprint, each part of the project (puzzle) is made, which is shown to the client in the form of a demonstration (demo version). And so – part by part, part by part, until you get to the finished product. The difference, however, with the previous example, is that it is for a much shorter time and extremely high quality because the customer has approved all the time. We will not talk about money again.

But how does this fit into Scrum?

1. The product owner creates a list of tasks sorted by priority. In fact, this list contains easier-to-manage sub-projects to run gradually during sprints.

2. Sprint planning begins. In fact, every sprint starts with planning what needs to be done by the end of 2 weeks (if we stop at that time). Reference: What is Sprint Planning meeting and how to conduct it,

During this stage, the team takes the tasks that are in the first place in the list of the product owner (because they are defined as the most important), and creates its own list of tasks to be performed during the sprint. Decisions are also made on how these tasks will be performed.

3. During each sprint, the team meets every day. This is usually a meeting on foot for exactly 15 minutes. It must be held in the same place and at the same time. It is good to be every morning before the start of the work process. This is the so-called daily scrum. The aim is to assess the progress of the tasks and to make changes if necessary.

4. At the end of each sprint, a finished product is issued, which the customer should see in a demo version. This concludes the sprint.

5. After each sprint, a retrospective of the entire process of the past sprint is made. Opinions are shared, if there are ideas to improve the work are taken for the next sprint, each team member shares his assessment, if he had a problem something – too. There is also talk of the tools used during the scrum.

6. After the end of the sprint, the team focuses on another part of the list compiled at the beginning by the Product Owner and starts the next sprint. This cycle is repeated until the project is fully completed.

The repetition of each sprint is called an iteration.

In each sprint, you can use to illustrate the tasks, their movement, and solving them with a simple board.

The tasks and their progress are ready from left to right on the columns. And their importance (priorities) are in the leftmost column and move from top to bottom (with the highest priority 1 follows 2,3,4,5,6). All 6 tasks must be completed within 2 weeks (then the sprint ends).

At the end of the sprint in the “Done” column should be the finished piece, which can exist as a completely independent part of the product. At the end of each sprint, the board is erased. A new sprint begins and painting begins again.

The customer can make changes only to the finished product at the end of each sprint, but not during the sprint.
The scrum frame is applicable for larger projects, longer ones.

What is the Kanban approach?

Kanban is very similar to Scrum, but there are two significant differences. He has no sprints or roles. Reference: What is Kanban methodology, The whole project is also divided into tasks. However, their performance is not grouped by parts and sprints but is a complete stream – like a river.

One task ends and in its place immediately enters the next, followed by the next and so on until the end of the project and the finished product.

Mandatory for Kanban is the specified number of tasks that can fit in one column.

The tasks are colored leaflets (cards). The content of the task and its priority in the order of importance for the product are written on the card. Each member of the team or pair takes one task, when he joins it pulls another. If there is a difficulty or “stumbling block” somewhere in the movement of the tasks column by column (from left to right), people from the team help.

This process allows the client to intervene with his whims and desires at any time. It’s just that the new desire stands in the queue of waiting tasks and, if it has a high priority, can overtake the others on the waiting list.

The Kanban board is used from the beginning to the absolute end of the project. In any discussion of the project, the focus is on it, it is visible to everyone at any time.
Kanban delivers the finished product just in time. However, it is applicable to smaller or medium-length projects.

Both Scrum and Kanban teams are self-organized.

I can share with you my opinion that the choice of Scrum or Kanban depends on several things:

If the project on which the model will be chosen is longer, I suggest stopping at Scrum.

If we are looking for satisfaction and greater motivation for the team, I suggest we stop at Scrum. This is because every sprint is a kind of finished part. Handing it over to the client is kind of the end. This creates in our people a feeling of coping and completing the subproject in a short time.

If we want the customer to be constantly involved with his desire to change the product in step, I suggest we stop at Kanban.
However, I believe that in the process of work we can donate to combine the two methods where possible.

Conclusions and remarks
About Scrum

The word framework is generally difficult to grasp by ordinary audiences unfamiliar with formal terminology, which would be much easier to assimilate, for example, the phrase “way of working”.

About Kanban

The model of work was originally created a long time ago in the production workshops. In reality, in its original environment and original source, there were no customers who intervened at any time with desires, because the end products, if for example cars, machines or other industrial products, interference with whims and desires at all times is not would be or would be in some sense inadmissible, as the production line would be severely disrupted.

We can comment that this type of intervention from external participants is much more typical (and most appropriate) for Scrum, which provides sprints and demonstrations of parts of the finished product.

A Kanban model of working with satisfying requirements on the go would actually be a modern Scrum process or something from the new mixed currents like “Scrumban”.

Leave a Reply

Your email address will not be published. Required fields are marked *