As we know, SCRUM and KANBAN are the project management methods for the development of certain products or services. They belong to a large number of representatives of the Agile methodology. Such methods are very flexible and iterative, their capabilities can be used by employees from any sphere, but most of all they are suitable for the purposes of IT.
Often people use symbiosis of these methods, and, of course, only the best practices of KANBAN and/or SCRUM.
SCRUM and KANBAN combine the basic principles of an Agile manifest:
- A group of people is above all things, above any process or complex of tools. People who are constantly working together on the same task have significant potential for ultimate success. A team is one whole core, which means that all specialists are responsible for a positive and negative result. The fundamental principle is equal interaction among colleagues and collective discussion of tasks and contradictions;
- The developed web product is more important than any detailed documentation or specification. Both in SCRUM, and KANBAN, there’s focus on a significant reduction in workflow and increasing communication among colleagues within one team, as well as constant discussing of the current project. The visualization of development process is extremely important. For such purposes, you can use simple boards with cards, either of which contains a specific task or assignment;
- Customer interaction is above the agreement negotiation process. The basis of success is constant communication with the client and the well-known feedback. Such a strategy allows us understanding fully what the client needs as a result;
- Continued readiness to respond quickly to incoming changes, even if they are contrary to the plan that was established previously. This principle is necessary in order to respond immediately to feedback and improve the created product.
Despite the fact that these two methodologies have a lot in common, they have a number of differences, which we will consider in detail below.
Team composition
A project team that works on SCRUM technology is universal by its members.
It includes a large number of various specialists who can easily solve any problem on a particular project. Traditionally, 5-8 people are enough.
If the number of specialists increases, the result is less obvious. Therefore, SCRUM-group employees do not have a clearly defined competence. For example, QA can easily help the designer in drawing up the main page layout, and the marketing analyst can help programmer or project manager (and alternately, of course).
On the other hand, KANBAN involves balancing of different specialists in the team.
Several single-discipline groups can work simultaneously on the task solving.
For example, first the tasks are solved by the analytics department, then by the designers, and only then the developers can work on it. Moreover, it is not forbidden to organize universal teams.
Strict roles
SCRUM-team requires more different resources than KANBAN-team. You need additional roles to manage properly all aspects of development: so-called Scrum master and Product owner.
Scrum master is a manager. But he does not control, and, moreover, doesn’t give instructions left and right.
His tasks include the organization of thematic meetings, solving of everyday problems, the motivation of the team, tracking the tasks status, checking for compliance of all the team actions for scram-approach. Also, the Scrum master does the same work as other team members.
The product owner is in direct communication with the customer, connects the client’s will with the team capabilities, monitors the development of the project, and despite all this, he/she isn’t a formal boss.
The product owner is responsible for setting priorities within the team.
Moreover, he/she meets with all the achieved results of work.
In the case of the Kanban community, such resources are not relevant because the development process has a linear construction and is very simple in the final execution.
The project team doesn’t need a manager and a product owner. The group is one strong unit.
The planning process
In both methodologies Scrum and Kanban, the project is divided into 10 or even 100 small subtasks of a different nature. All future tasks on the project are added in the final list – backlog.
Each task has its own priority and relevance.
The only difference is that all priorities are set by the project owner in Scrum, and by the project team in Kanban.
Period
When using the Scrum methodology, the project team divides the working time into equal parts – sprints, the duration of which does not exceed 4 weeks, but the shorter the sprint is, the easier it is to make changes and additions to it. Deadlines are mandatory with such a methodology.
Any sprint consists of 4 mutually complementary stages:
- The planning process. The project team analyzes the total number of scheduled tasks and ranks them in chronological order by solving the priority. The team selects only those tasks for the sprint that will be fulfilled, in their opinion;
- Performance. All members of the project team work simultaneously: the programmer writes code, the tester creates a test suite for it, and the technical writer writes technical documentation;
- Release. By the time a new version or product is released, it should be as efficient as possible, useful for the end user, and more advanced than it was before the sprint was created;
- Retrospective. All project team members take part in the discussion of the sprint. Together they analyze possible ways to improve the quality of work, and what can be done faster and better in the future.
Scrum approach is not flexible since you can’t add new tasks to the sprint that has been already started. Even the most urgent and important feedback will be implemented in another sprint after the previous ones will be completed.
At the end of the stage, all unfinished tasks are returned to the backlog. And at the planning stage of the next sprint, the need and time for their completion are determined.
Also, you should note that if you use Scrum, it is necessary to find some time for regular meetings, where you will plan all future sprints and resolve organizational issues.
If we talk about Kanban, it is not particularly necessary to hold regular meetings with discussions. Their frequency can vary from one week to a month.
In the case of Kanban, any project can be divided into specific stages of the planned tasks solving, for example: “Need to be done”, “Under test”, “Completed”. Such stages can last in different ways.
New tasks or improvements can be made at any time. If the team gets a priority task, the project group will not wait for the start of a new sprint but will proceed with the assigned task.
From all mentioned above, we can assume that it is more difficult to control the time frame required for developing a web product and to make predictions about the completion of the started module in Kanban than in Scrum methodology.
Board
In order to visualize maximally the nature of these two methodologies, people often use physical or electronic boards, for example, Jira or Trello. With their help, you can make the workflow more open and understandable to all members of the project team.
Moreover, you may schedule tasks and set current priorities.
Such a board is divided into several columns that display different stages of tasks completing: Test, Done, Review, or to do. The number of columns can vary significantly, depending on the scale and objectives of each specific project. But in general, the fewer columns you have, the better it is.
The current priority is detailed, and deadlines are put down Inside each created card. As the tasks are completed, the cards are moved on the board, this allows the project team observing the progress of the tasks and seeing where certain difficulties and troubles arise.
In this case, the difference of the methods lies in the fact that such a board is always completed in the case of the Kanban methodology. With the Scrum approach, the board is cleared when it is time to perform a new iteration.
Performance indicators
If one follows the Scrum methodology, there’s measuring of all the assigned tasks that must be completed in one sprint.
By dividing the total weight of the current tasks into potential performance for 1 sprint, the project team receives an estimated time to complete the project. Productivity growth is the most important indicator of the project team in the case of the Scrum methodology.
If we talk about Kanban, the average time for completing one task is measured on the board. This time is the most intelligible benchmark for the potential effectiveness of the project team.
Team members do not concentrate on a specific task but make sure that the average completion rate is minimal.
Peculiarities of implementation
It is really easy to turn to Agile through Kanban exactly. This is because such a methodology has very few restrictions, but there is no need to form universal teams on the project, and you can keep dividing into functional departments.
You can use Scrum when you are confident in the knowledge about methodologies flexibilities.
How to achieve this?
- Find a getkanban board game and try to play it with your colleagues;
- If you like the game, take any current project and divide its tasks into small components. It is very convenient when all tasks take approximately the same time for their completing. Prioritize execution;
- Think about the stages that these tasks should go through. For example, this may be the following logic: Plan-Execution-Done;
- Think about the logical limitations of task status;
- Hold an initial meeting. Discuss with your colleagues how you will organize your work. What is the time for release exactly, and when will the next meeting be;
- Move a couple of tasks from the backlog to the “Plan” status and start working;
- Watch cards move among columns when the task has changed from one status to another;
- Keep tracking the time spent on assigned tasks performing. When you add a new card to the board, write the start time of work on it, and the end time when you remove it from the board;
- Conduct experiments with restrictions on working with cards so that the average time to complete a task will steadily decrease;
- Hold special meetings where each member of the project team can express his/her opinion regarding the work on the current project: he/she has the opportunity to say what went according to the plan and what could be improved next time.
The experience of many successful web companies today proves that it is very difficult to implement quickly Scrum or Kanban technology.
If the team is used to work constantly on a cascade structure, it will be very difficult to move to the flexible methodology. But the main thing is not to give up, and things will work out.
Actually, it doesn’t matter what you choose, because for both Scrum and Kanban any interaction within the team is more important than productive and sought-after practice.
Leave A Comment