I recently came across an article that caught my attention. Here’s Why Many Developers Hate Scrum, or Why Many Devs Hate Scrum, makes an analysis of the work in Scrum, indicating, mainly, an increase in load for developers, due to the needs created by the use of the Scrum framework. As interesting as I found the article, and it really is interesting, I noticed several points of disagreement, or that deserved an explanation, which ended up leading me to also make a similar analysis. There is no intention to negatively criticize its author, nor his opinion, not least because it was thanks to it that I developed this, let’s say, complementary analysis. I believe that another look at the problem presented can help Devs who are experiencing this dilemma.
I think that some Devs really have the vision aligned with what was expressed by Willem-Jan Ageling, the author, in his article, and, therefore, I decided to debate a little more the topics listed by him. I understand that some people can really find in these topics reasons to “hate” Scrum, but I believe that another view on such reasons can turn this hate into love.
The analysis by Willem-Jan , focuses on new responsibilities faced by dev’s when working using Scrum. Better then, take a look at these “new” responsibilities, dissecting the problem to understand it better.
- At the Sprint Planning — Determining a Sprint Goal, in cooperation with the Product Owner. The Development Team needs to assess if they can meet the Sprint Goal as this drives the Sprint
Are there traditional, or non-agile, teams where the manager does not ask about deadlines, or what can be done until a certain delivery date? Honestly, I never saw that happen. Quite the opposite. I have always witnessed this questioning being asked repeatedly, even generating heated discussions, and stealing time, and often tranquility, from the team. This issue can never be abandoned, as there is no way that an organization, which establishes goals and objectives, works with KPI and OKR, does not have any idea of when it will arrive where. In fact, I think that Scrum helps the team a lot in this sense, defining a specific moment for such discussion, in a way limiting it, and preventing it from stealing more time from the team.
- At the Sprint Planning — Creating a Sprint Backlog. This entails selecting the Product Backlog Items that help meeting the Sprint Goal and to create a plan to deliver them.
In reality, I understand that the Dev Team only helps the PO, or clarifies its doubts, so that it selects the stories to be contemplated. It is the responsibility of the PO to define a goal with the team and define what can be done to achieve that goal. Although the assessment is up to them, he is the utmost interested and the one who provides the guidance. Regarding the necessary plan, I believe that there are two aspects. The first is that this practice of planning what will be done in the short term is extremely productive. In general, it avoids hacking. Or do we not know devs who, upon hearing the first news about a customer need, already want to sit down and go out programming? This small planning, significantly helps to avoid the mole effect and promotes collaboration and coordination between team members, under the risk of not doing so, generating rework and having a lot of coordination difficulties. In other words, in my view, such a responsibility has always existed. Only, some people, or teams, forget their need and end up paying a high price later.
- During the Sprint — Ensuring the Product Backlog Items meet the Definition of “Done” and acceptance criteria.
Could the team work differently? This seems to me to be inherent to dev’s work. Otherwise, the dev forgot to be working to satisfy the needs of some client, to be a dilletante.
- During the Sprint — Making sure the Sprint Backlog always shows the current state of the progress on the Product Backlog Items and the plan for the Sprint.
This responsibility does not seem like extra work, but only a matter of discipline, attention to the framework and use of an appropriate tool. The daily meeting, already built in Scrum and that should not be abandoned, has as part of its scope the presentation of did/will do/problems. This, in itself, allows for an update of the work situation. If, in addition, the team uses a monitoring tool, as Scrumhalf, where the tasks worked are updated by the dev himself and automatically generate information, such as the Burndown chart, transparency and visibility are guaranteed, without any extra effort.
- At the Daily Scrum — Daily assessing the progress towards the Sprint Goal. This includes updating the plan as reflected in the Sprint Backlog.
Really, the Daily Scrum is something that takes time from the team. However, this time, which must be very short, around 15 minutes or less, would be much longer if the project had a formal manager and the team members had to make their progress reports for him. Additionally, it is essential to remember that the Daily Meeting is what enables the team’s self-organization, reducing traditional friction with management, and increasing job satisfaction.
- At the Sprint Review — Discussing the Sprint Goal and how they managed to reach it.
This is really not a common thing outside of Scrum. However, in addition to the fact that this discussion should not take too long, it should be remembered that, among other reasons, this discussion promotes transparency and ends up avoiding, or replacing, the constant discussions and debates of the Dev team with management, when using non-agile management.
- At the Sprint Review — Showing what they created and answering questions.
I’ve never seen this left out either. Dev Team can’t just code and forget. Unless there are other members to demonstrate the implemented features, note any bugs, etc. The advantage in Scrum is that since it is done in an organized way, faster, and with the participation of the entire team, it allows everyone to stay up to date, reducing interruptions of work in subsequent tasks.
- At the Sprint Review — Taking part in the discussion of what to do next.
Although I have always promoted this type of discussion in the projects I participated in, especially in the ones I managed, before agility, I recognize that the Dev Team is often left out of it. However, as a result, it is normal for the team to waste a lot of time later, complaining and discussing why something is being done. That is, the process of thinking about what should, or should not, be done is effectively carried out. The big difference here is that he will be able to express his thoughts and listen to that of the other companions. And, it must be remembered, responsibility, like mostly in Scrum, is collective, of the Dev Team, not individual.
- At the Sprint Retrospective — Inspecting how the Sprint went and create an improvement plan.
This one is really different. Kaizen, or continuous improvement, is something Scrum takes very seriously. It takes a little time from the team, but it brings enormous benefits, including allowing more and more the dev’s to focus on their main activity over time, since the “process” itself is working well. It is up to the Scrum Master to make this ceremony productive and enjoyable. Its results, which in a non-agile way should also be reached by good management, will always be implemented in the same way, regardless of the management model. I mean by that, if something needs to be changed, revised, it will have to be. And someone will have to do the job.
- Creating and maintaining the Definition of Done.
Truth. Now the team must worry about that. But let’s see. The definition of done, at least in the developer’s mind, already exists. Otherwise, how would he finish working on something? The difference here is that now the team must create a shared definition, which is understood by everyone. And, in fact, what initially may seem heavy, after agreement avoids a series of conflicts, is easy to maintain, and can, for example, be seem as a by-product, when necessary, of the Retrospective.
- Learning, exploring, and embodying the Scrum Values of Courage, Commitment, Focus, Openness, and Respect.
This only occurs, or at least in a striking way, when transitioning from a non-agile method to Scrum. It is, at that moment of the transition, an important cultural change. But after some time working this way, it starts to flow in the vein of the agilists and it becomes no burden. After all, isn’t life more beautiful like that?
To summarize, we set up the table below. In this table, we represent each of the responsibilities, in the same order as the text, and we try to indicate the need for their adoption in any project, regardless of the management model used. On its side, we try to demonstrate the impact if it is neglected. In Scrum, we try to show the main form of Scrum in dealing with the responsibility and, finally, we indicating if a tool can significantly facilitate the work of the team, if it adheres to Scrum. This table is empirical, without scientific rigor, being only the result of what we observed throughout the projects that we participated, directly or indirectly. The only purpose of this table is to compile the data, from our perspective, related to such an extensive list, synthesizing it, albeit superficially, to allow for a global view on the part of the reader.
Well, we tried above to complement the analysis made by our colleague Willem, to who we thank, aiming to give the Devs, or any element of a Scrum team, another perspective on their “new” responsibilities. The use of additional elements in the team, to take care of certain aspects show here, or the redistribution of some activities, can undoubtedly help, relieving some work, as pointed out by Willem. Evidently, discounting the communicational aspect made clear by Fred Brooks, in his seminal book The Mythical Man-Month, more people usually help to lighten the burden.
In conclusion, I think the main point is that Scrum actually fixes and organizes a number of things that in reality are already done in other ways in non-Scrum activities, and when it adds something extra, it is because it really is necessary and brings great benefits to the team. Can you think outside of the box and see these aspects in a positive way too?
*This is a Google Translation of the original article
