the hype has already passed anyway
“Forbid me, I'm stuck on the same thing! Forbid me, The buzz is already gone anyway!”
I.F. Letov “Obsession”
The trend in project management over the past two decades has been the transition to SCRUM processes. Since 2020, the number of people who began to actively criticize the so-called “pure” SCRUM has increased. Now, under pressure from circumstances, some companies are actively abandoning this methodology, since SCRUM, which was improved in theory, in practice has turned into a kind of cult in many companies that does not affect efficiency or even reduces it.
In the world of victorious agile, SCRUM, as one of the most popular methodologies, seemed to have every chance of becoming an industry standard. However, due to its inherent shortcomings, it has become something between a religion for those involved in project management and air for selling agile coaches. Moreover, today strict adherence to the principles of SCRUM often becomes a marker of professional unsuitability for people who were careless enough to degenerate from full-fledged project methodologists and managers into fanatically obsessed with rituals scrum masters (I am not talking about all of them, but about many).
What's wrong with SCRUM?
First, let's go over what's generally wrong with what should lead to the fastest possible appearance useful features increments of business value, a series of continuous product releases and flexible management of customer or user desires.
1. Dependence of the project, team and efficiency on the skills of the Scrum Master
Most of us are used to the fact that the success of a product under development depends, first of all, on the qualifications of programmers, sometimes on the professionalism of PMs, and the meticulousness of analysts. In the classic approach to SCRUM, there is a scrum master or someone performing his role. Additional risks arise with this role. They are actualized if the scrum master religiously follows everything written in the SCRUM guide, blindly believes in efficiency due to the purity of rituals, while imposing work organization principles that are clearly inappropriate for the project. Up to 40% of working time is spent on chatting during dailies, groomings, and retrospectives.
Meetings almost always drag on, and the team wastes time on repeated and useless discussions of tasks that are clear to everyone except the Scrum Master. POs and PMs are particularly tense, as they strive to formulate user stories where there is no need for them, endlessly decompose epics, etc. in order to comply with methodological dogmas. Anyone who has participated in a team with such evangelists understands what I am talking about. SCRUM requires a high degree of self-organization and discipline, which is not always possible in real conditions. The best Scrum Master is the one who can modify the methodology to suit both the project conditions and the team's specifics (I have even met such people… twice in my life).
2. Difficulties with adaptation
SCRUM cannot always be adapted to all types of projects. First of all, we are talking about situations where it would be most reasonable to solve everything in one iteration, and an attempt to decompose will not lead to the emergence of business value.
This, for example, concerns the development and training of neural networks. When it comes to preparing ML, with the development of the model itself, collecting data, and then training. Also any projects where the results of tasks are difficult or impossible to obtain with parallel development.
In the first case, it makes sense to use KANBAN or extreme programming. In the second case, good old Waterfall. No one produces a car by creating and delivering individual parts to the customer or buyer; the end result is important. Attempts to allocate individual increments in such projects are guaranteed to complicate the development process, leading either to huge sprints or to the fact that the final goals of the iteration are never achieved.
3. Non-agile methodology
In practice, SCRUM does not welcome changes to tasks during a sprint. Any scrum master will say that this is acceptable, but such changes will require additional costs in the form of assessment, planning, and decomposition. It reaches the point of absurdity when, in order to add a simple and intuitive feature, for every “unlikely fire case”, new analysis artifacts are created, meetings are held to assess the task, etc.
As a result, planning changes, previously created tasks are re-evaluated, which takes many times more time for individual specialists or the entire team. Due to such problems, both PMs and Scrum Masters avoid including new tasks in the sprint in every possible way and try to plan, often urgent and high-priority tasks, for the next one. Almost inevitably, this leads to delays and a decrease in the quality of the product. If we continue the analogy with production, this is the situation when adding a label above the button requires the approval of 10 people and changing 5 stages of the process. Redundancy encourages not to change plans immediately, but to wait for the next iteration.
4. High training and implementation costs
SCRUM can be effective for some projects (despite everything described above and what I will write further), but successful implementation requires long and expensive preparation and training of the team. Implementation is especially painful in companies that have not used Agile methodologies before, but at the whim of the manager, who has listened to promises air sellers courses on SCRUM, decided to “increase efficiency”.
Moreover, there is no talk of efficiency when “pure SCRUM without additives” is imposed during training, changes to which are “like death”, and deviation from standard methods is as likely as changes in the classical Chinese tea ceremony. The result is a well-fed air seller, a dissatisfied team, missed deadlines, zero efficiency gains.
5. Dependence on frequent feedback
SCRUM requires constant feedback. On the one hand, this is a strong point of the methodology, in practice, it makes customers, PO and/or users as irresponsible as possible to the requirements for business value. They just know that tomorrow they can demand a new feature, form, button, and they actively use it.
Frequent feedback from the customer or product owner allows for a large number of changes to the requirements, but not the features in the product, the requirements are fixed, but then the bureaucratic hell of the methodology delays the delivery of value for months.
The other side of the coin is that not all customers are ready for this level of interaction. In Russian realities, they often prefer to see the finished product as a whole, rather than in parts, which makes the use of SCRUM completely pointless.
“No Need for a Violinist” or What’s Wrong with a Scrum Master
The feedback I receive from colleagues about Scrum Masters reminds me of the good old Soviet film “Kin-dza-dza”, where the phrase “a violinist is not needed” was regularly heard. Rare exceptions concerned very experienced specialists in companies that started with SCRUM processes from the start, the product PandaDoc and the outsourcing giant EPAM.
There, experts spoke of the Scrum Master role as useful and increasing efficiency, but even there, the Scrum Master is not perceived as something sacred and inviolable. However, if we look at medium and small teams, we can find that this role is not only useless, but almost always harmful. Let's figure out why.
Scrum Master is an unnecessary intermediary
In small and medium teams, where all participants in the process are closely connected and interact with each other regularly, the Scrum Master becomes redundant. Imagine that you are in the kitchen, where you are cooking dinner with friends. Everyone knows what to do, and then a person appears and starts giving out instructions on what order to chop vegetables in, when to put the pot on the stove, and how much salt to add. As a result, everyone only gets annoyed, and the cooking process becomes difficult and slow. This is exactly the kind of “kitchen boss” the Scrum Master becomes.
Money for the process
Hiring a Scrum Master requires additional costs, which can be significant for small and medium-sized companies. This money could be spent on something more useful, such as buying new equipment or training employees. It’s like hiring a personal trainer for your cat – there are costs, but no benefits.
Scrum Master and Micromanagement
A Scrum Master can easily turn into a micromanager, and this is harmful not only for small and medium-sized teams, but also for large companies. A full-fledged specialist is quite capable of working effectively without constant supervision, “the ceremonial magic of grooming and retrospectives.”
Micromanagement by a Scrum Master often demotivates employees and reduces productivity, and if the team has a PM role and the latter is prone to “harassing control,” then the project participants are sent to another mandatory meeting with a patient who needs to undergo a colonoscopy. You don’t need to teach a fish to swim, it knows how to do it.
Scrum Master and Bureaucracy
The Scrum Master almost always burdens the development process with bureaucracy of dubious value. Agile is chosen where flexibility and speed are important. The work of the Scrum Master often leads to the fact that mandatory meetings and ceremonies slow down the work, and also add bureaucratic descriptive work.
A good figurative comparison would be an attempt to organize a family picnic in a corporate planner. A large number of formalities that lose their meaning in a living process turn development into a fairly routine process, in which its participants inevitably lose enthusiasm.
The non-viability of abstract task assessment
Another Achilles heel of SCRUM is the estimation of labor costs. Such estimation is one of the key practices. In theory, it should help the team better plan and manage their time. In practice, abstract units, firstly, are difficult to use for those who are accustomed to estimating work by time, and secondly, they poorly correlate with other processes in IT companies.
For example, a customer of an outsourcing company usually asks to estimate the time frame, similarly, in product teams it is important to understand, When new features will become available to users. Story points can help at an early stage to compare the complexity of tasks with the time it takes to implement them, but, as a rule, this concerns relatively simple tasks that can be correctly estimated even without story points.
Poker SCRUM does not solve the problem at all and turns the evaluation process into fortune telling on tea leaves. Management tries to understate the deadlines for the fastest delivery of value. Developers regularly increase the deadlines, trying to predict how much testing will take. As a result, both of them tie story points to time in their heads. Efficiency decreases or, at least, does not grow, the process becomes more complicated, SCRUM evangelists applaud standing.
So, to summarize, we get the following evaluation problems (sometimes not obvious in a cursory approach to choosing a methodology, but obvious in practice):
1. Subjectivity is equivalent to assessing a boa constrictor in parrots, when one participant in the assessment imagines a huge cockatoo, and the second a small budgie, while the units of measurement of parrots also remain an abstract entity. In practice, this leads to the fact that identical assessments of the task may ultimately turn out to be fundamentally different. Using the “fibe” (Fibonacci sequence) does not improve the situation in practice.
2. Problems with team motivation
Abstract estimates almost always have a negative impact on team motivation if there is no common agreement on how many hours (days, years) are included in a conditional story point. A feeling of uncertainty and unpredictability is created.
5. Difficulty explaining to customers
Explaining to customers, especially those not connected with the industry and unfamiliar with SCRUM, what story points are and “what to eat them with” is extremely difficult. Abstract estimates, especially in Russian realities, always cause bewilderment and mistrust. You might as well say that the project will be ready in “a few bananas”.
What is useful in SCRUM?
Despite all of the above, SCRUM in its modified form is viable and useful. Its main advantage is the combination of iterative and incremental approaches.
1. Sprints: Continuous Improvement
The iterative approach in SCRUM, the use of sprints allows you to conveniently decompose the work. “Cutting a cake into pieces is easier than eating it whole.” Retrospectives, where sprints are analyzed, really allow you to improve processes and the development product itself. This way, you can more easily adapt to changes and avoid large-scale errors. At the same time, it is important to modify canonical processes in such a way as not to get all the problems described above.
2. Incremental Approach: Adding Value Gradually
The incremental approach in SCRUM assumes that each iteration ends with the delivery of value. In many (but not all) projects, this allows you to demonstrate results and receive feedback from customers and/or users. Problems only arise when the increment by definition cannot fit into a pre-defined sprint, and the SCRUM master is not ready or does not want to go beyond the process.
3. Adaptability
In ideal conditions, SCRUM allows teams to quickly adapt to changing requirements and conditions, and to make changes in each subsequent sprint. The problem is that, on the one hand, changes may need to be made in an already planned sprint, which is not kosher. Secondly, the process can turn into an endless one, and some feature will forever migrate from sprint to sprint, acquiring new requirements, without getting into the release.
4. Transparency
SCRUM does provide a high degree of process transparency. Daily reports, sprint reviews and retrospectives allow all project participants to be aware of the current state of affairs and progress. As I wrote above, they are not always necessary and useful, often the team can see everything well.
When can SCRUM be useful?
1. Large projects
In large projects that require coordination of multiple tasks and participants, SCRUM helps structure the work and ensure regular delivery of value.
2. Projects with uniform and (or) typical tasks of limited duration
If most tasks in a project take approximately the same amount of time, SCRUM allows you to effectively plan and manage resources. This helps avoid overloads and downtime, ensuring an even distribution of work (naturally, we are talking about ideal or almost ideal conditions).
3. Creating value over equal periods of time
SCRUM allows the team to regularly deliver value to the customer, which is especially important in projects that require frequent feedback (when it can be obtained without dancing with a tambourine) and the ability to make changes (if the level of bureaucracy of the Scrum Master and PM is close to 100lv and making changes does not require 100500 artifacts with a comparable number of approvals for each).
Risks of abandoning SCRUM where the process has been successfully built
When companies decide to move away from SCRUM after teams have already adapted to the methodology and built processes, they also face a number of challenges:
1. Loss of structure and clarity
SCRUM provides a clear structure and clarity in the distribution of roles and responsibilities. When teams are accustomed to this structure, abandoning it can lead to chaos and confusion. The orchestra loses its conductor – the musicians may know their parts, but without coordination the result will be extremely problematic.
2. Decreased motivation and productivity
Teams accustomed to regular sprints and retrospectives can lose motivation and productivity without these elements. Feedback really helps teams stay on track and continually improve. Think of it as turning off the traffic lights and removing the road signs on a busy highway.
3. Deterioration of communication
SCRUM often helps improve communication within the team and with external stakeholders. This is especially critical in large projects where it is important for everyone involved to be aware of the current state of affairs.
4. Problems with adaptation to changes
SCRUM allows teams to be flexible and adapt quickly to changes. Rejecting this methodology can make it difficult to adapt to new requirements and conditions.
If you criticize, make suggestions
The risks described above show that a complete rejection of scrum processes is not rational and it is logical to offer an alternative that preserves its advantages and eliminates its disadvantages. Conventionally, such a methodology can be called PostSCRUM. Let's consider what properties such a methodology should have.
Focus on the result, not the process
One of the drawbacks of SCRUM is its excessive focus on process, which can distract the team from doing real work. The new methodology should be outcome-oriented rather than process-oriented, so that the team can focus on achieving goals rather than performing rituals.
Minimizing bureaucracy
SCRUM can add unnecessary bureaucracy to the development process. The new methodology should minimize bureaucracy and formalities so that the team can work more efficiently and quickly.
Support for long-term planning
SCRUM focuses on short-term goals and iterations, which can make long-term planning difficult. A new methodology should support both short-term and long-term goals so that the team can effectively plan and forecast. The hybrid SCRUMBAN methodology has this property to some extent.
In conclusion
Now we can state that in development practice SCRUM has become a parody of itself, especially if the methodology is used in its canonically pure “halal” unmodified form. At the same time, its features have contributed to the emergence of a huge number of teams fixed on SCRUM processes, air sellers principles of the “correct” approach to project management, ceremonially fixed scrum masters. I predict that the active use of SCRUM in the world has become one of the reasons for the catastrophic statistics of the success of agile projects (the study showed that agile projects have a 268% higher failure rate) https://johnfarrier.com/agile-failure-what-drives-268-higher-failure-rates/.
It is clear that despite all its theoretical advantages, SCRUM has failed in practice and requires significant modification to become effective.
