The main misconceptions about SCRUM

SCRUM? What is SCRUM?

For the first time, the SCRUM approach (eng. Scrum “scramble around the ball”) was described by Hirotaka Takeuchi and Ikujiro Nonaka, who noticed that small teams (5–9 people), staffed by diversified specialists, gave the best results. The most complete description of SCRUM was first introduced in his book by Jeff Sutherland. The book is called - SCRUM. Jeff began his career as a military pilot, during the Vietnam War, made more than a hundred sorties. Then Jeff was engaged in science, but the world will remember him as one of the founders of SCRUM. The book begins with a real story from the life of the FBI, who spent millions of dollars on the development of an automated system designed to search and track criminals. The problem was that when the project was due to expire, the contractors showed the FBI a completely inactive product. This meant only one thing - American taxpayers spent millions in vain. The situation seemed hopeless until the FBI leadership turned to the then-emerging project management method SCRUM. This method is described in accessible language in the aforementioned book, which, by the way, is translated into Russian. The article further discusses the main misconceptions and myths that can scare off top managers who have decided to implement SCRUM in their projects.

1. Total control that kills creativity

In SCRUM, how to achieve a business goal is decided by the project team, not the management. This method motivates and stimulates creativity, as opposed to classical management, where employees are delegated to perform specific low-level actions, and those in turn often do not even understand why this is and how it will affect the project as a whole. Thus, in SCRUM, the management does not control the actions of the project team, and that, in turn, reports only on the results at the end of each sprint (a predetermined period of time, for example, 2 weeks). Transparency exists only among members of the project team. What is it manifested in? First of all, the daily stand-up rallies, at which every member of the project team tells what he did yesterday, what he will do today, what problems he has. This practice is not intended to control the amount of work performed by each employee. Stand-up rallies are designed to help each team member to remove obstacles in their work and devote colleagues into their plans, so that everyone understands where the project is moving today and realize its role in product development. For the same purpose, by the way, is a common SCRUM board with stickers that everyone can see, and openspaces that destroy obstacles to the free communication of team members.

2. SCRUM deprives the rights of the most experienced engineers, because they obey the decision of the team

SCRUM creates an environment in which authority and not titles and positions, but skills and experience. A striking example of the reverse situation is the hierarchy of the military, where power is based on position and rank. A captain can be much more talented and erudite than a colonel. Despite this, the captain must strictly obey. Such a rigid structure is ideal for extreme conditions, such as hostilities, where decisions must be made quickly, and their discussion leads to a delay that leads to the death of people. SCRUM will not cancel titles. Each employee has his position in accordance with his experience and competence matrix. However, in the process of discussing a decision, the dominant factor is a clear and reasonable position, supported by the personal experience of the employee in the area under discussion, and not his title. So, contrary to the myth, SCRUM gives power to precisely those team members who articulate sound ideas. And as you know - who clearly thinks, that clearly articulates.
')

3. SCRUM focuses on short-term business values, not on long-term project development.

This problem is really relevant. Fortunately, the question “What to do?” Has answers. We should start with the fact that if a project is not long-lasting, with a duration of no more than six months, then this problem most likely will not emerge. Another thing, when software develops 2-3 years or more. There are many articles in which the authors pour out their pain regarding such projects. The army of junas and midles (sinera, as is known, are expensive and few) confidently commit their work to master, and the customer sprint after sprint reaps the brilliant results of SCRUM. But bad luck, after 5-10 sprints, adding new features becomes problematic, and the further, the more difficult. Therefore, SCRUM is good, but you need to think about strategy and architecture. To prevent such a situation is possible. First, the project should have at least 1-2 as many experienced engineers as possible, who will pass all commits to the repository through themselves during code review. Secondly, to devote a lot of time to learning (at least 3 hours per week) of junior and middle engineers of software architecture, design patterns and how it is superimposed on an existing project. Such classes should be accompanied by practice and minimal homework for better learning. Practical assignments can be embedded in the backlog of project sprints. This does not greatly affect the profitability of the project, but it will accelerate the growth of employees and prevent potential problems with the software architecture. Conducting periodic meetup-s will allow project teams to learn from each other, which does not harm the quality of the software produced.

4. SCRUM does not allow engineers to develop

SCRUM assumes that all decisions regarding how to achieve business goals are delegated to the team. The product owner decides what to do, and the team decides how. From this it follows that the team must be competent enough to make effective decisions. Thus, the cornerstone of the SCRUM methodology is learning. That is why in all major banks and IT outsourcers so much attention is paid to the development: training, seminars, courses. Professional growth of employees is an integral part of SCRUM. Due to the fact that the SCRUM teams are relatively small, the team members have to master the whole stack of technologies within the project they are working on. At the end of the project, the engineer gets new skills, which increases its value in the labor market.

Subtotal

SCRUM, like any other project management method, has its own characteristics and roughness, which must be known and taken into account. Despite this, he gives the best result among the currently known methods.

1. Jeff Sutherland // SCRUM 2017.