June 15, 2019 at 17:37Basic misconceptions about SCRUM
Scrum? Which SCRUM?
First SCRUM approach (Eng. Scrum“Fight around the ball”) was described by Hirotaka Takeuchi and Ikujiro Nonaka, who noticed that small teams (5 - 9 people), staffed by diverse specialists, give better 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 he completed more than one 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 after the project expired, the contractors showed the FBI a completely non-working product. This meant only one thing - American taxpayers have wasted millions. The situation seemed hopeless until the FBI leadership turned to the then-nascent SCRUM project management method. This method is described in accessible language in the aforementioned book, which, incidentally, has been translated into Russian. Further, the article discusses the main misconceptions and myths that can scare away top managers who have decided to implement SCRUM in their projects.
1. Total control that kills creativity
At SCRUM, the project team, not the management, decides how to achieve the business goal. This method motivates and stimulates a creative approach, in contrast to classical management, where employees are delegated the implementation of 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, 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 pre-set period of time, for example, 2 weeks). Transparency exists only among members of the project team. What is it manifested in? First of all, daily stand-up rallies at which each member of the project team tells what he did yesterday, what he will do today, what problems he had. This practice is not intended to control the amount of work performed by each employee. Stand-up rallies are designed to help each member of the team remove obstacles in their work and devote colleagues to their plans so that everyone understands where the project is moving today and is aware of its role in product development. For the same purpose, by the way, a common SCRUM board with stickers, which everyone can see, and open space, which remove the obstacles for free communication between team members, serves.
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 is gained not by titles and positions, but by 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 delay, which leads to the death of people. SCRUM will not cancel titles. Each employee has his own position in accordance with his experience and competency matrix. However, in the process of discussing a solution, the dominant factor is a clear and reasonable position, reinforced by the personal experience of the employee in the area under discussion, and not his title. Contrary to myth, SCRUM gives power to precisely those team members who clearly articulate sound ideas. And as you know - he who thinks clearly, he clearly formulates.
3. SCRUM is aimed at short-term business values, and not at long-term development of the project
This problem is, indeed, relevant. Fortunately, the question “What to do?” Has answers. It should start with the fact that if the project is not long-playing, with a duration of no more than six months, then this problem most likely will not come up. Another thing is when software develops for 2-3 years or more. There are many articles in which authors pour out their pain regarding such projects. The army of June and Middle (synergies, as you know, are expensive and few in number) confidently commits their work to master, and the customer sprint reapes brilliant results for sprint SCRUM. But the problem is that after 5-10 sprints, adding new features becomes problematic, and the farther, the more difficult. Therefore, SCRUM is good, but you need to think about strategy and architecture. A similar situation can be prevented. Firstly, the project should work
4. SCRUM prevents engineers from developing
SCRUM assumes that all decisions regarding the way to achieve business goals are delegated to the team. The product owner decides what needs to be done, and the team decides how. It follows that the team must be competent enough to make effective decisions. Therefore, the cornerstone of the SCRUM methodology is training. That is why in all the largest banks and IT outsourcers so much attention is paid to development: trainings, seminars, courses. The professional growth of employees is an integral part of SCRUM. Due to the fact that SCRUM teams are relatively small, team members have to master the entire technology stack within the project they are working on. At the end of the project, the engineer receives new skills, which increases its value in the labor market.
Subtotal
SCRUM, like any other project management method, has its own characteristics and roughnesses that need to be known and taken into account. Despite this, it gives the best result among the methods known today.
1. Jeff Sutherland // SCRUM 2017.