Here’s Why Many Developers Hate Scrum

And?what?you can learn from this

Scrum is a disruptive framework. Complex environments need a different approach to building products, taking small steps and inspecting and adapting regularly. 36 years after its inception, it still causes confusion and frustration. Many have written books and articles to explain Scrum where they focus on how the framework works, the roles and the Scrum Values.

This information hasn’t convinced all developers. Some see Scrum as a burden and “just want to code”. In this article, I am going to show you why they have a point and what you can learn from their issues.

“Just let me code!” — A common response of a developer to the burdens of Scrum

Scrum comes with a lot of new responsibilities

Many embrace Scrum because it empowers the people who create the product. The Developers manage their capacity and control how it builds an Increment. The team also determines when Product Backlog Items are “Done”.?In Scrum, no one can tell them to cut corners on quality.

But with?autonomy?comes responsibility.?In Scrum, developer responsibility comes in spades. Look at the?list of responsibilities for the developers beyond building the product:

• At the Sprint Planning — Determining a Sprint Goal, in collaboration with the Product Owner.?The developers need to assess if they can meet the Sprint Goal as this drives the Sprint;
• At the Sprint Planning — Creating a Sprint Backlog.?Selecting the Product Backlog Items that help meet the Sprint Goal and creating a plan to deliver them.
• During the Sprint — Ensuring the Product Backlog Items meet the Definition of “Done” and acceptance criteria.
• 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.
• At the Daily Scrum — Assessing the progress towards the Sprint Goal. This includes updating the plan as reflected in the Sprint Backlog.
• At the Sprint Review — Discussing the Sprint Goal and how they managed to reach it.
• At the Sprint Review — Showing what they created and answering questions.
• At the Sprint Review — Taking part in the discussion of what to do next.
• At the Sprint Retrospective — Inspect how the Sprint went?and?create an improvement plan.
• Creating and maintaining the Definition of “Done”.
• Learning, exploring, and embodying the Scrum Values of Courage, Commitment, Focus, Openness, and Respect.

This is a long list.

Autonomy has its flipside. It comes with responsibilities, and responsibilities come with a price.

New responsibilities cost time

For many that used to work in a traditional project-managed environment, these are new responsibilities. It is extra work on top of building valuable products.?Work that used to be part of the Project Manager function is now for them.?If this isn’t recognized, then this work will eat away time from actually building the product.

It is truly painful for developers that have worked with Scrum for years but never realised the extent of their new responsibilities straining them.

Worst off are the developers that know about the work that comes with self-management, but don’t see ways to alleviate their pain due to expectations from outside the team.

Developers need to adapt to the responsibilities that come with Scrum.

Here is the solution

When teams realize the impact of the responsibilities of being a self-managing Scrum Team, the path is clear for a solution.?The developers should either get the additional capacity to do this work?OR they should reduce their expectations of what they can deliver.

It would be logical to go for the first option though. Someone —like a Project Manager?— used to do the work that now is part of the developers' responsibilities. There used to be capacity for this. Hence the logical solution is to move this capacity to the developers, adding someone to the team.

There are several ways to add capacity to the developers:

• The team gets one more person who can help build the product. The whole team divides the extra work between them.
• If no one currently is capable of doing this type of work, someone with specific skills can join the team. Until now, they didn’t have all skills to do the work in a Sprint.?Planning and admin are work too. If a project manager used to do this work, perhaps she/he can continue to do so as part of the developers.
• The Scrum Master could step in. However, it is important to separate the true Scrum Master role from this work that involves a lot of planning and administration. This is why I don’t like this solution. Many already confuse a Scrum Master with an admin.
• A Product Owner could do the work. But there’s a catch here too.?The Product Owner should not limit the developers from self-managing.?When a Product Owner isn’t part of the developers, the autonomy of the developers can be under pressure with this solution.

Whatever choice the team makes, it should be clear that the person doing this Scrum-related additional work is equal to the rest of the Scrum Team (Product Owner, Scrum Master, Developers). She or he also does work that helps to create valuable products.

If there is no way to add capacity to the team, then the only logical solution is to?expect less from them and plan less.?Some managers might consider this somehow strange. But the work also existed when Scrum was not around, although it wasn’t with the team. And with moving the responsibility there should also be a change in capacity.

Scrum does come with additional investment and responsibilities

When teams work with the Scrum framework, they need to self-manage.?Self-management comes with responsibilities. If Scrum Teams fail to embrace these responsibilities — ignoring them or doing them half-heartedly —, Scrum will not be effective for them.

The same is true when Scrum Teams are forced to do this work on top of building products without the additional capacity to do it properly. This is not sustainable and will lead to disgruntled colleagues who despise Scrum and “just want to code”.

A self-managing Scrum Team needs to?commit to Scrum to make it work.?Responsibilities that used to be outside of the team, are for the team now.?With additional responsibilities, leading to additional work, there should be additional capacity.?There are several ways to add additional capacity to the team. The work needed to function as a self-managing Scrum Team is just as valuable as building the product. It is an essential piece of the Scrum puzzle to create high-value products.