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 build products, taking small steps and inspect and adapt regularly. 34 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 members of Development Teams. 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 Development Team manages its capacity and controls 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, Development Team responsibility comes in spades.
Look at the list of responsibilities for the Development Team beyond building the product:
- 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;
- 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.
- 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 — Daily 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 — Inspecting 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 Development Teams that have worked with Scrum for years but never realised the extent of their new responsibilities straining them.
Worst off are the Development Teams that know about the work that comes with self-organisation, but don’t see ways to alleviate their pain due to expectations from outside the team.
Development Teams 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-organizing Scrum Team, the path is clear for a solution. The Development Team should either get the additional capacity to do this work OR the Development Team 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 Development Team’s responsibilities. There used to be capacity for this. Hence the logical solution is to move this capacity to the Development Team, adding someone to the team.
There are several ways to do add capacity to the Development Team:
- 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 work, someone with the specific skills can join the team. Until now, they didn’t have all skills to do the work in a Sprint. Planning and admin is work too. If a project manager used to do this work, perhaps she/he can continue to do so as part of the Development Team.
- 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 Development Team from self-organising. When a Product Owner isn’t part of the Development Team, the autonomy of the Development Team 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, Development Team). 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-organise. Self-organisation 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-organising 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-organising Scrum Team is just as valuable as building the product. It is an essential piece of the Scrum puzzle to create high-value products.