The report explains in detail the Scrum framework and Kanban methodology and presents the similarities and differences between these two similar Agile approaches.
Traditional methodologies in the 90s of the twentieth century began to suffer a lot of criticism, which necessitated the search for new Agile methodologies.
The main criticisms are regarding the use of strong control, rules, micro-management, and an overly partial approach. Thus, in search of new solutions, practices are borrowed from the Western world, which concerns rather the production processes and product management. These terms are woven into Agile, which has gained immense popularity in recent decades.
In 2001, 17 software developers published The Agile Manifesto, which reads as follows:
- People and communications are the above processes and tools. Motivation and self-organization, according to them, are extremely important.
- The working software is above the detailed documentation, ie. is more useful during meetings with clients than the presentation of project documentation.
- Cooperation with a client is above the negotiations during the conclusion of the contract. The continued participation of all stakeholders is key.
- Addressing change is above following the plan. The focus is on the rapid response to change and continuous development.
The 12 Agile principles
This Manifesto is based on twelve principles.
- Customer satisfaction through fast software delivery.
- Changing the specifications is possible at any stage, even in the late stages of the project.
- Often provide working software, within a week, not a month.
- Running software is the key to progress.
- Sustainable development that manages to maintain a constant pace.
- Close daily collaboration between business employees and developers.
- Face-to-face conversations are the best form of communication.
- Projects are built around motivated people who are trusted.
- Constant attention to technical excellence and good design.
- Simplicity – the art of maximizing the amount of work to be missed is essential.
- Self-organizing teams.
- Regular adaptation to changing circumstances.
Scrum is an Agile methodology
The Scrum method is representative of Agile methodologies, as it is an iterative step-by-step project management framework. Reference: What is Scrum methodology, agileprogramming.org
The process in this method consists of separate iterations called sprints. The sprint is the smallest unit of time to develop, and each sprint is an attempt at improvement within a fixed time frame. Reference: All about the Scrum sprint, vbprojects.org
The sprints last from one to four weeks, and at the end of each sprint, the team has a working version of a part of the product, which includes all the ready-made tasks from the SPRINT backlog.
The Scrum methodology gives more power to developers, the people who perform operations, and processes. Reference: BVOP.org
Scrum methodology has been developed for companies whose value chain of activities, through which products pass sequentially, increasing their value after each activity / makes long-term product planning difficult.
The Scrum team
The Scrum Team consists of:
Product Owner – monitors the organization to add value to the customer, he is the voice of the customer, meets with the customer, sets priorities, and enters everything in the backlog. This should only be one person on the team. He must be different from the Scrum manager, but can be a member of the development team.
Scrum Master – is responsible for removing obstacles to the implementation of the tasks agreed in the sprint and to achieve the desired goals. He is not a team leader, but something like a team leader. Make sure that the rules are followed and that things happen according to the rules of the Scrum concept. He makes sure that the team is not distracted by side factors and that everything is subordinated to the goals of the sprint.
Development Team – does the “dirty work” – analyzes, makes the architecture, writes the code, tests, works on technical communication, documents. It consists of 3 to 9 people with similar skills. The task of this team is at the end of each sprint to deliver an increased or improved type of software and to make them in some way suitable for customer presentation or sales. The team is self-organized, even with the cooperation of the project manager.
What is Sprint
Sprint is the smallest unit of time to develop. The sprints are of constant length from 1 week to 1 month. Each sprint is an attempt at improvement within a fixed time frame.
Before each sprint, there is a meeting to plan the sprint. It sets measurable goals for the sprint and identifies the tasks that will be completed within its framework. During each sprint, the team creates finished pieces of a product. The activities for each sprint are described and taken from the “product backlog”.
Often these activities are described as characteristics that the product must have and be achieved for the sprint. Ie product backlog is a prioritized list of requirements. Which of the list to enter a sprint is decided at the planning meeting before the sprint. The product owner informs the team which parts of the list of requirements he wants to be completed in the upcoming sprint. The development team reviews discuss, decides, and record in the Sprint Backlog which of these requirements and goals it will be able to fulfill in the upcoming sprint.
Sprint Backlog is owned by the development team. The goals listed in this document should not be changed during the sprint. A fixed duration is set for the development, such that the sprint ends on time. Requirements that are not met for the sprint are excluded and returned to the product backlog. After the sprint is completed, the team demonstrates how to use the software.
SCRUM allows the organization of self-organizing teams by encouraging all team members to be in the same place and communicate live.
A key principle of SCRUM is that it is accepted at the very beginning of the project that the requirements cannot be complete and fully understood. Ie innovations are expected from the client – change of his wishes. SCRUM focuses on the team’s ability to deliver quickly and be prepared to respond quickly to unexpected changes. This is a positive feature for SCRUM because abrupt changes cannot be well refuted by traditional guessing or planning methods.
As in other Agile project management methodologies, SCRUM can be implemented through different types of tools Reference: Agile, Scrum and Waterfall project management, kievpress.info
Spreadsheets (Excel spreadsheets or their equivalent in Google Docs) are most commonly used. They make so-called SCRUM “artifacts” such as sprint backlogs. Other organizations implement SCRUM using whiteboards, sticky notes, and paper documents.
As mentioned above, this is a priority list of requirements, editable by everyone, but the responsibility of the product owner. When prioritizing, the latter takes into account risks, added value, costs, dependencies, date of delivery to the customer, etc. The characteristics are added to this document following the history format: “As a <user type> I want to <do some action> so that <desired result>”.
List of work to be done by the development team (document owner). Identified tasks are entered in it during the daily SCRUM meetings. However, they are not assigned to anyone in particular.
Programmers choose their own tasks from there according to priorities. A board/table is often used to enter the status of the tasks – “to be done”, “in progress”, “done”.
The tasks are identified as the development team selects stories from the product backlog. Then he breaks down these stories. The question is “can we do this too?” And so on until the team feels that they have taken enough work for the sprint.
An abstract quantity used to estimate the time required to complete a task.
It is used for a more accurate estimate of the time it takes to complete a task. Each team member receives a set of cards with different numbers (using Fibonacci numbers, ordinary numbers, degrees of the number 2, etc.). Each specific task is offered for discussion in the team and after the end of this discussion, each participant shows a card with the number of Story Points, necessary according to him for the complete completion of the task. If everyone agrees, this number is saved in the backlog. In case of disagreement, the participant with the largest number and the participant with the least present the arguments for their decisions to the team and proceed to a new vote. The procedure is repeated until there are differences.
This is the sum of all the tasks completed in the sprints at any given time. At the end of the sprint, the increment should be ready in a form suitable for any use.
Reflects ongoing progress during the sprint. The graphic equivalent of the Scrum backlog and available for the Product Owner. It is updated daily immediately after the end of Daily Scrum.
Backlog clearing time for stories (Backlog grooming: storytime):
During the sprint, the team must spend time clarifying the sprint backlog. The existing backlog is evaluated, the acceptance criteria for the individual client tasks are clarified, the big stories are broken down into smaller ones. – Meetings should not be longer than an hour. – It does not include breaking tasks into separate tasks. – The team has the freedom to decide how many meetings are needed in a week.
The most commonly used method is poker planning.
During the sprint, stand-up meetings are held every day.
-At these meetings the list of tasks for the current sprint and their status/backlog / is updated, noting the work done.
– The backlog is a list of – all tasks/functionalities of the project, which are prioritized by the Product Owner. These tasks are discussed by the team and questions are asked to the project manager where there are ambiguities. Once these so-called tasks are clearly and unambiguously outlined, the Development Team determines which of them (according to the priority given by the project manager) can be developed within the sprint. The tasks in the sprint that are waiting to be done are said to be in the sprint backlog.
At stand-up meetings (Daily Scrum), Development team members synchronize what they’ve done from the sprint backlog, and if by chance there are no more tasks to do, then they take a new prioritized task from the product backlog.
These are not meetings for reporting, but for synchronization and revealing potential obstacles in the work of the team.
These meetings last from 5 to 15 minutes and are held daily at a specific time. At the meeting, each member of the team tells three things in a completely informal way:
- what worked the day before,
- what he plans for the coming day
- what problems he has encountered that prevent him from working.
The main attributes of the meeting are:
- The meeting starts just in time.
- The place and time are the same every day.
- The meeting must fit in exactly 15 minutes.
- Maybe everyone, but mainly talk about the main roles in the team.
Updating the Product Backlog
The product backlog is also updated at the meeting, noting the work done.
If any problems are identified, they are solved collectively.
Sprint Review Meeting
The work that has not been done and the work that has not been reviewed. (Reference)
The work done by the clients is presented (a demo is displayed).
The unfinished business is described.
The meeting should take place at 4 o’clock.
All members of the team recall and discuss the last sprint.
Continuous process improvements are being made.
Two main questions are asked – What went well during the sprint? And what can be improved for the next sprint?
The meeting should take place at 3 o’clock.
Scrum allows the organization of self-organizing teams by encouraging all team members to be in the same place and communicate live.
The key principle of Scrum
The key principle of the method is that from the very beginning of the project it is assumed that the requirements cannot be complete and fully understood, innovations and changes in the client’s wishes are expected. The focus is on the team’s ability to deliver quickly and its willingness to respond quickly to unexpected changes.
What is the Kanban method?
The name of the Kanban method comes from the Japanese language and literally means “signal card”. Reference: Kanban vs. Scrum: What are the Differences? pgov.org
This method is a representative of Agile methodologies, based on the gradual, evolutionary change of processes and systems in the organization. Kanban is not only a development method but also a method aimed at improving the activity in the developer’s organization.
This is a method of managing intellectual activity that emphasizes delivery on time, without overloading team members. In this approach, the process – from defining the task to the delivery of the product, is displayed to the participants in it, and at the same time software developers take work tasks from the so-called “queue”.
Kanban uses a system that limits the amount of current work at any point in the workflow. Additional tasks can be undertaken when it is possible to make progress on them. This is an approach that is a basic mechanism for detecting systemic operational problems and stimulating mutual assistance in order to improve the system.
The main Kanban principles
The Kanban method has the following principles:
Start with what you are doing now – there are no specific roles and steps, but start with the roles and processes that are available and stimulate growing, evolutionary changes in the system. Reference: Scrumtime.org
Agree to pursue gradual evolutionary changes – Kanban encourages long, small, and gradual changes in the system. Sudden changes seem more effective, but have a better chance of failure. The organization must agree that sustained, growing, and evolutionary change is the way to go.
Respect current processes, roles, responsibilities, and titles. The organization most likely has elements that work well.
Maintaining them allows us to overcome our initial fears and will allow us to gain wider support.
Leadership at all levels – leadership actions at all levels should be encouraged. Reference: What is Kanban methodology, wikipedia-lab.org
The six main Kanban practices
The Kanban method has six main practices:
Visualize – Visualizing the workflow is key to understanding how the work is going. A popular method is the use of a wall with columns and maps, as the columns are the different states of the work process.
Limit the tasks that are in the process of work. – A system for taking on tasks concerning part or all of the work process must be implemented.
The critical point is that the current work in each of the stages is limited and new tasks are undertaken when there is available capacity in the resource to reach the limit for still unfinished work.
Manage the workflow, this is the only way to assess whether long-term, gradual changes in the system will have a positive or negative effect.
Clarify the requirements – in order to discuss the problems more rationally, empirically, and effectively, you need to correctly and accurately understand how things work and how the work should be done. Thus, consensus on the proposals is more likely.
Use feedback. Improve together, evolve experimentally – Use models and scientific methods. Kanban encourages small, lasting, and evolutionary changes that remain. The method suggests the use of a scientific approach in implementing the changes but does not define a specific approach.
Kanban for problems identification
Kanban is an excellent method for identifying problem areas and promoting improvement. this method sets a work limit and would help in the accumulation of redundant tasks, which would reduce defects and increase productivity. Reference: Comparison between Scrum and Kanban methodologies, kosovatimes.net
The teams decide for themselves how many tasks there should be. Whether the team will choose this method must be decided on the basis of the project it is working on, its competencies, its strengths, and its weaknesses.
After all that has been said so far, it is important to know that there is not only one right approach in project development, it all depends on the work ahead and the teams. No matter which method you are a fan of, you should regularly check your productivity, whether you cope with the tasks, whether there are many or few tasks, whether you manage to achieve accuracy in the amount of work.
Agile is here and it influences our business organizations, even projects, and even teams. Reference: Managing business organizations and adding business value. An Agile Manager’s Guide to the Theory of BVOP.org, policymatters.net, 2020
In my opinion, it is good that teams are encouraged to experiment and go through different methods of work in order to be able to judge who is best for them. No matter which method the teams work by, it is obligatory to regularly check the productivity and whether they cope with their tasks. This in turn allows for corrective action in case of violations of the pre-planned project framework.
It is a misconception of employees that if they choose Scrum or Kanban they will work only on this methodology. Different projects require a different approach, the strengths of the team for one project may be weak for another.
In terms of selection, team leaders need to be guided by the priorities and policies we set for specific projects. It is important for them to know what we put in the foreground – quality, performance, working version in the shortest possible time. This information and the resources of the teams will largely determine the choice of method.
As for my opinion personally, whenever I have the opportunity I would choose Scrum because the short sprints and the real result at the end of each sprint brings a sense of work done and greater satisfaction. The lack of sprints, ie. a foreseeable end at Kanban can make employees feel exhausted and demotivate them.
I hope I have been helpful, I remain available for questions.