Scrum is a project management framework that seeks to optimize the interests of customers and developers. This approach has produced some unintended consequences among developers, including increased levels of stress and disengagement.

Although teams can mitigate these adverse effects with careful execution, before adoption, teams should properly understand how Scrum fits them.

This article will explore the good, bad, and ugly of Scrum!

We will cover:

• Why Scrum works for some teams and not for others
• The good: Scrum gives developers autonomy
• The bad: Scrum comes with additional responsibilities 
• The ugly: Scrum can be relentless
• Conclusion 

Why does Scrum work for some teams and not for others?

Scrum is not a silver bullet. The Scrum framework is not something one will implement and expect everything to be amazing. It’s a framework that one has to adapt for their particular organization, their particular management style, their particular team, and their particular culture.

The good: Scrum gives developers autonomy

Daniel Pink’s book Drive shows that one of the fundamental features that drive intrinsic motivation is autonomy. And we discussed in our article 4 Things Engineering Managers of Effective Team do how in building and maintaining motivation, developers need to have the ability to make decisions on what tasks they prioritize, in what order, and in what manner. 

Scrum gives developers that full autonomy in their:

• Task: The developers decide how many backlog items they want to forecast for a Sprint. The 2017 Scrum Guide^TM clearly states, “The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.“.

• Time: Allowing the developers to decide the Sprint length that best suits them in collaboration with the Scrum team and stakeholders. When multiple teams are working on the same project, developers can align the Sprint length across teams based on team agreement—giving them control over their time-box!

• Technique: In achieving engineering excellence, many good engineering practices can be adopted by teams — like Test-Driven Development, Pair Programming, etc. While all these practices have their merits, we wrote in our article What Makes Engineering Teams Go Off The Best Engineering Practices on how engineering practices are contextual. 

In Scrum, the Development teams are meant to be self-organizing. 2017 Scrum Guide^TM says this about the Development teams: “They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality“.    

When developers have autonomy over their tasks, time, and technique, their ability to build awesome products and solve complex problems for the organization will greatly improve. 

The bad: Scrum comes with additional responsibilities

With autonomy comes additional responsibilities. In Scrum, developers don’t just “write code” – they are expected to take responsibility for planning, estimating, and managing their work. These new responsibilities bring additional time costs.

New responsibilities Scrum brings to developers

• Attend daily scrum meetings and report on the day’s planned tasks.
• Assure the product owner and Scrum master that the assigned work is being completed according to the plan.
• Give the product owner feedback on the creation of user stories.
• Provide estimates on user stories approved by the product owner.
• Agree on the length of the Sprint with the other Scrum team members.
• Develop the Sprint backlog and the Sprint burndown chart.
• Create the deliverables.
• Submit change requests, if any.
• Participate in prioritized product backlog review meetings.
• Identify any improvement opportunities from the current Sprint and agree on any changes for the next Sprint.

The 2017 Scrum Guide^TM clearly states:

“Lightweight“

“Simple to understand.”

“Difficult to master.”

Though simple to understand, it is difficult to master. And that fact can be seen as developers require deep knowledge and understanding of Scrum to carry out the additional responsibility Scrum brings effectively for any software project.

The ugly: Scrum can be relentless

The developers just finished a Sprint, and it went so well. They met the Sprint Goal, and everyone is really happy! Now it’s time to start a new one. And then, once that one is done, there will be another Sprint Goal! The cycle continues on and on…

Developers have complained that the cycle wears them down. With the additional responsibilities, developers will have more to do that they can handle within a sprint if not managed right. 

“We do Scrum, but Scrum wears us down; we don’t get any respite.” This shouldn’t be the case, and it comes down to sustainable pace and doing Scrum right. 

Few issues that may bring about the relentlessness of Scrum

• Ramming a Sprint full of work to meet up deadlines. Too many items selected in the Sprint backlog will probably lead to burnout along with a drop in quality.

• Adding new items to the Sprint Backlog mid-Sprint without considering the impact on the items already on the Sprint backlog.

• Having too many meetings. If the development team is doing Scrum events alongside other meetings, it isn’t going to lead to the benefits of Scrum.

• Having too many big items added to the Sprint backlog. With these big items in the sprint backlog, the chances are high that towards the end of the Sprint, stress levels will increase in the quest to meet the “Definition of Done.”

All the above issues are anti-patterns. They ignore one or more essential aspects of Scrum, starting with how many items are added to the Sprint Backlog:

“Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.” – The 2020 Scrum Guide^TM

This is essential: the development team needs to properly plan and estimate how many items can meet the “Definition of Done” based on their empiricism. 

Some of the issues are because the development team ignores Scrum’s advice on the size of items to be added to the sprint backlog:

“For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. Decomposing Product Backlog items often do this into smaller work items of one day or less.” – The 2020 Scrum Guide^TM.

The cycle will continue leading to disgruntled developers. Unless the development team in itself use Scrum events like Sprint Retrospective to identify and solve the problem fulfilling the purpose of the Retrospective — which is to plan ways to increase quality and effectiveness of the team:

“The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.” – The 2020 Scrum Guide^TM.

Conclusion

This article covered how the autonomy (good of Scrum) Scrum gives developers can lead to bad and ugly effects. There are many other aspects of Scrum —if not done right — can lead to adverse effects. 

The 2020 Scrum Guide^TM clearly states:

“The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.” 

Getting the best out of Scrum requires adaptation to the particular organization, team, and culture.