The main idea of the Scrum framework is to organize the development process for faster execution of work at various stages of the project life cycle. But does this approach always push developers towards the right behaviors? Many users who joined the discussion of the above questionon Stack Overflow, have experienced similar things where developers cut corners, place too much emphasis on the high scores assigned to their tickets, or even pretend to be high-performing employees in front of managers. How can these dangers be avoided? The question in question has moved from workplace.stackexchange.com to softwareengineering.stackexchange.com . This suggests that programmers view the considerations surrounding Scrum and its effectiveness as something serious enough to go beyond managing the software development cycle. They feel the impact of this project management method on the overall work environment.
Is Scrum the cause of bad development practices, or is it just an excuse for this problem?
Much controversy has sparked speculation about the impact of Scrum on teams and individual developers, and the limitations it places on those who use it. While many blame Scrum for team failures, others believe that this is an attribution error and that the roots of the problems in development teams go much deeper.
Scrum advocates see bad management as the root of the trouble. Here's what user Llewellyn says, summing up: “Management, in fact, ignores the developers. There are fixed deadlines to be met in order to achieve predetermined results. The work is done not by a team focused on achieving the same goal, but by a group of people in which everyone only cares about themselves. Planning ahead and thinking outside the box is discouraged. In such conditions, the programmer, as a result, succumbs to circumstances and finds salvation in the simple execution of the tasks assigned to him. I have worked in such conditions. But don't blame Scrum for that. "
User DJClayworth expressed the sentiment of many comments, saying that programmers who think they are under pressure will perform poorly with any development management methodology.
The opposite opinion on this issue was best expressed by user Martin Maat , who drew the attention of the audience to the fact that the very fact that so many people feel the need to speak out on this issue speaks for the frustration that Scrum causes them.
What are the common troubles with using Scrum?
Some common Scrum pitfalls have surfaced in the comments, which appear either due to the framework being misused or because they are, in fact, inherent Scrum problems. Here are nearly a dozen problems of this kind that have caught our attention.
▍1. Daily meetings are for managers
The first criticism of Scrum is related to the fact that during daily meetings (stand-ups) unwanted tendencies arise. One of the arguments in favor of this idea is that stand-ups can degrade to the state of events, the participants of which only do what they say about their productivity. Especially if managers are present at such events. Therefore, the user Matthew Gaiser (he already wrote for us, but we stumbled upon his commentary) called stand-up events that are aimed at informing managers about the current situation ( update management). He believes that developer presentations at such events only encourage managers to observe what they are working on, but it is not useful. This is even more true for distributed teams, when each of the team members works in their own mode.
▍2. Completing tasks plays a major role
Another idea that came up in the comments is that any development methodology that divides large tasks into smaller tasks and monitors the progress of those tasks leads, whether intentionally or not, to new approaches to evaluating work. If you just start applying some metrics, it will affect the behavior of people whose activities are assessed in accordance with these metrics.
Many commentators say this means that developers can “cut corners” to complete what needed to be done in the current sprint. The problem pointed out by user Gaiserand other users, is that a separate ticket that is being worked on, and which, during the sprint, is transferred to the category of "ready", this is a "black box". Whatever is inside this "black box", it will not affect the result of evaluating the speed of work. User Gaiser writes that the poor-quality implementation that went through the QA department and the perfectly tested and engineered implementation are no different from each other. As a result, it turns out that accounting for the number of closed tickets is an unreliable indicator of labor productivity.
▍3. Extremely productive developers who don't work as a team
Another thread discussed the tension between great solo programmers and great teams. When everyone follows the Scrum methodology, some developers can be extremely productive, but then the "team" can be forgotten. User Gaiser says that without the right incentives, self-organization is an unattainable goal: “Team members will solve problems as they see fit, or as directed. If it doesn't build the team, there will be a lot left over and the team members will simply move forward in disarray. "
He continues: "Moreover, allowing each developer to choose their own methods for solving problems, it means more difficult to debug the code."
▍4. Difficult tasks are postponed for later
Gaiser, in the same vein, continues to criticize the illusion of productivity. He says that when applying Scrum, the main focus is on getting the ticket to the "Ready" state. Thinking deeply about the task at the same time does not seem particularly productive. Therefore, developers may tend to take on easy tasks and avoid more complex ones. Here, again, the words of the user Gaiser: "Scrum encourages developers to take on easy tasks that take a little time to solve, which allows developers to show consistently high performance." As a result, it turns out that daily task choices and daily work reports are pushing the choice of tasks that take one day to complete.
▍5. Product features are more important than code quality
All the same Gaiser believes that the use of the Scrum framework leads to a drop in product quality: “How good a developer is is usually determined by his ability to develop reliable code. Scrum, unless the product owner understands programming and reviews the code, seriously devalues this characteristic of projects. " He emphasizes here that the "readiness" of a ticket is often determined not after checking the quality of the code, but only after the corresponding feature has been implemented.
▍6. Lack of time to discuss work issues with colleagues
If the speed of development is the only indicator of the team's effectiveness, it means that the team members no longer have time to discuss some issues with each other, to get the opinion of others, or to test their ideas for someone talking about them. And that's exactly what makes a team a team. Here, again, the words of user Gaiser: “Great developers often consult with other developers and look for alternatives to their opinions. But such classes take up the time it takes to close tickets, and this slows down the development speed. "
▍7. Recently identified bugs have to wait their turn
Another bad Scrum behavior is that "bugs are found after the sprint and are considered new tasks." This can push developers to release low-quality code, since additional tasks cannot be included in the current sprint.
▍8. Ticket Driven Architecture
The ticket system is not only based on what tasks developers choose for themselves. User Gaiser also says that using Scrum, inadvertently, leads to a confusing project architecture, as developers work on tickets in the order they appear and independently of each other. As a result, "architecture quickly becomes a reflection of tickets."
▍9. A development management methodology that affects absolutely everything
Reading the discussion, you can pay attention to the comments, the authors of which note that the root of all problems lies in the lack of strict adherence to the Scrum rules. However, perhaps the strongest anti-Scrum claim from Gaiser is that the framework takes over everything else. This can destroy a strong team. "[Scrum] distorts and breaks any other development management mechanisms, this framework becomes an all-encompassing phenomenon in which nothing but performing rituals is done uniformly, and performing these rituals creates the illusion of success."
We have discussed a fairly long list of problems that may be caused by the use of Scrum, and, perhaps, only become more noticeable due to the use of this framework. But in the discussion we are researching, you can find just as many ideas regarding how developers can live in peace and harmony by following the Scrum rules .
How to get the most out of Scrum?
Many of the responses to Gaiser's comments, which received many positive ratings, were that what he was talking about was not Scrum. Here is what user Stephen Byrne wrote about this: “I think this is a good answer with some valuable insights, but I have to agree with many other commenters that what is described here is definitely not Scrum, although and is viewed under the guise of Scrum. " But many either openly hated Scrum, or agreed with the Gaiser user that if something went wrong when using Scrum, it means that this framework is simply not being used correctly.
How to use Scrum correctly?
▍1. Daily meetings are not the same as picking up new tickets every day
Many people said that daily meetings force developers to close tickets every day. But, as noted by DJClayworth , you can't do without prioritizing tasks either. And if the priorities are not set naturally, then this task should be taken over by the Scrum Master: “We need to prioritize tasks within the sprints, larger tasks need to be given higher priority, so someone has to take on difficult tasks on the first day of the sprint. In any case, if by the second day no one has taken on a large and complex task, the Scrum Master should say something like: “I see no one has taken on the task of compressing the database. And this is a big task. If we are going to complete the sprint, we need to start working on this task now. "
▍2. ,
All tasks solved in the sprint should be broken down into small parts. This is undeniable. But the Scrum framework is not saying that developers should be obsessed with metrics that indicate results. Scrum does not suggest pitting developers against each other. The Gaiser user proposes to completely abandon the consideration of the points of individual programmers. He also points out that many managers may need to re-learn Scrum's rules: “Tell managers that the moment they praise developers or give them a promotion based on closed tickets becomes the moment they radically change the behavior of the team. ".
User DJClayworthagrees that deliberately ignoring the metrics associated with individual tickets should be part of the task of a good Scrum Master: “Attention should be focused on ensuring that the team achieves its goals as a team. The Scrum Master should stick to this line of behavior and avoid any discussion or metrics based on how many user stories each member of the team has promoted. "
▍3. You need to take small steps towards big goals, but with this approach you shouldn't forget about these goals.
Here's another idea for breaking large problems into small pieces: "If you are working on a small piece of a puzzle, this does not mean that you need to forget about the whole puzzle."
User Llewellyn points out that using Scrum is no excuse to completely ignore the principles of quality software development: “You have to have a good idea of where the project is going. This knowledge can be used to plan the architecture of the project, engaging in planning even within the current sprint. "
Scrum does not free programmers from the need to do their job, investing all their knowledge and all their experience in it. Therefore, Llewellyn's call goes to the programmers who are among the readers of the comments: “You were in the meeting, you can look at the backlog, you know what the overall vision of the project is in the organization. You strive to avoid having to spend long periods of time on something from the distant future. But there is nothing wrong with laying the foundation for an extensible, modular system that will be suitable for solving current problems and will allow you to create additional opportunities already planned without problems in the future. "
▍4. It is necessary to decide on what "Done" means
One of the topics raised in the discussion we were discussing concerned the Definition of Done (DoD) criteria, and how defining these criteria helps individual programmers adhere to certain quality standards and stay on top of what is expected of them. The most pressing question here was who was developing these criteria and when. When it comes to “ when, ” it was usually either about developing criteria as quickly as possible, or about how they should be developed during sprint planning.
The answer to the question of who produces DoD was written by user SpoonerNZ in the form of an answer to another questionon the Software Engineering website. “The readiness criteria are created by the team, but this process may require the presence of a Scrum Master. This is necessary in order to set restrictions regarding quality, in the event that the team does not have clear development standards. For example, a team might not want to mess with code reviews or unit tests, which will result in all of these being added to the DoD by the ScrumMaster in order to ensure high quality development. In an ideal situation, the team, having understood the strengths of what is being offered, will gladly accept it, but the real world is not always ideal. "
Who should work while adhering to the DoD? A natural (and challenging) goal is to ensure that the provisions outlined in the DoD are applied in one team, and that they are supported by all members of that team. But there are good reasons to extend DoD's influence across multiple teams. Or even the entire organization. Here is what the user Alan Larimer writes about it: “The lack of a universally recognized DoD definition for a product negatively impacts the quality and transparency of work results. The organizational level of the DoD should be minimal, technical, and sometimes organization-specific, which can provide a universal application of preparedness criteria. The organization can propose standards for coding. An organization may require automated assembly creation, giving the resources to create and maintain assemblies for each product. Any part of the DoD, whether created by an organization or by an individual developer, has to bring something of value to the readiness criteria. "
▍5. Managers must play the role of silent observers
While what is in the heading of this section is already enshrined in the official Scrum manual, analysis of the discussion shows that this rule is, unfortunately, often violated in daily meetings attended by managers. Because of this, programmers feel the need to explain why ticket jobs are taking longer than planned. If there are only programmers attending the meeting, there is little need for such explanations. Here's what the Scrum manual says about it: “Daily Scrum is an internal meeting of the development team. If someone else is present at it, the Scrum Master makes sure that they do not interfere with the meeting. "
▍6. People should be more important than processes
For guidance on how to apply Scrum rules, read the words written by user Frank Hopkins to remind you of one classic principle: "People are more important than processes." Here he added the following: "A good team must define its processes, rigidly defined processes do not contribute to the formation of a good team."
Another user, meriton , pointed out that the use of Scrum depends on individual programmers: “Scrum does not stipulate that developers work independently of each other. Scrum provides that the development team is self-organizing, that is, that the team makes decisions about how its members interact. "
User nvoigt notesthat teams in Scrum self-organize due to the fact that they come to the project with a defined mission: “The Scrum framework is based on the fact that you are a team. It doesn't matter in the team whether the ticket was closed yesterday by a specific programmer. Anyone who works in a team understands the goal (ie DoD) and strives to achieve it along with the rest of the team. "
▍7. Build teams to work like Scrum, but don't expect Scrum to create a team
User nvoigtapplied a sports metaphor: “Imagine 11 people received a printed soccer manual. They were told that they needed to practice in Conference Room # 5 every day, at about 10 am, for 15 minutes. Do you think the result will be a good football team? What if these 11 people were good, professional footballers? Wouldn't the command work anyway? Yes, it wouldn’t. It's just that football teams are not created that way. Like any team sport, Scrum needs those who use this framework to be a team. If it's just a group of people, each of whom just wants to earn points for themselves by showing how many points in the user story they have covered, or how many goals they achieved, then this group will always lose to a team whose members play together, and not next to each other. friend,or against each other. "
Outcome
The nvoigt user is willing to admit that Scrum "is not suitable for absolutely all people or teams." And, as the community's interest in the issue we are discussing here has shown, applying a set of rules that Scrum might push to develop can lead to a work environment that is far from what it would like to build.
We would like to summarize the result of this material with the words of the user Seth R... He says there is no need to expect miracles from the rituals of agile methodologies. Too much is wanted by those who seek with their help, as if by magic, to correct the shortcomings of the development team. This is how he sees the situation: “It's all about speeding up feedback. As a result, the team has the opportunity to self-review and make decisions about how to work to achieve the best results. Scrum won't help you create a better product, but if you get serious about self-testing, it can help you build a better team. This, in turn, leads to the development of a better product. "
Many people compare this framework to democracy. So maybe Scrum is the worst form of development management, apart from everyone else?
Or maybe it is, as the official guide says , a framework that is easy to understand but difficult to master perfectly.
How would you answer the question in the title of this article?
