Scrum. Love it or hate it. There doesn’t appear to be much in between. I like the framework, although I don’t think it is perfect. At the same time, I understand the developers who hate it from the bottom of their hearts. Strangely enough though, they have different problems with Scrum than I have. And zooming in, their problems often are not about Scrum in the first place. They shed light on how Scrum can be misapplied in many ways.
Today I will list the 5 most forgotten, misunderstood or misapplied parts of the Scrum Guide. I will also tell how they are misapplied and their actual intention.
1. Scrum’s focus is on creating valuable products
Scrum is not a delivery framework. Sure, Scrum Teams create value by delivering product increments regularly. The ultimate purpose of Scrum however is to maximize the value of the product. This is why Scrum has:
A Product Owner - Accountable for maximizing the value of the product;
A Product Backlog - An ordered list of what is needed to improve the product;
A Product Goal - A future state of the product.
Interestingly, SAFe also claims to include Scrum. However, SAFe has Team Backlogs instead of Product Backlogs and no Product Goal. So, even SAFe misunderstands Scrum. Like many organizations do, to the detriment of the developers.
2. The Scrum Values are crucial
“Successful use of Scrum depends on people becoming more proficient in living five values: Commitment, Focus, Openness, Respect, and Courage” - Scrum Guide 2020
This isn’t a hollow claim. To be successful with Scrum, teams can’t function in organizations that favour a top-down approach, have a hierarchical structure, favour politics and are geared towards individualism. These organizations blame the bringer of bad news and don’t see the benefit of creative teamwork.
Scrum can only work in an environment of trust. Because only when people trust each other, will they be able to be transparent. To discuss unexpected setbacks, have healthy conflicts and access the potential of everyone to optimize collaboration.
Embracing the Scrum Values can help build trust. Having and showing respect, committing to the team goals, being open about the challenges, showing courage to work on difficult issues, and focusing on their mutual goals.
3. The Sprint Goal is the Sprint commitment, not the selected items
Many Developers believe they need to commit to completing and delivering all items they selected to work on during the Sprint Planning. This is why developers often work overtime to “make” the Sprint. But it is not true. Developers commit to achieving the Sprint Goal.
The consequence of committing to the Sprint Goal is that the Sprint Backlog with the selected Product Backlog Items is adaptable. Whenever Developers think they can optimize the chances of achieving the Sprint Goal differently, they can add, remove or reprioritise items as they see fit.
4. Developers own the Sprint Backlog
The Developers determine how they do the work to achieve the Sprint Goal. They own the Sprint Backlog. The Product Owner, Scrum Master or anyone outside the team has no business changing the Sprint Backlog, by adding items or changing their plans. They may offer their insights and make recommendations. But the Developers decide. And as they are self-managing, their decisions should be respected.
One caveat: Developers can’t make changes that would endanger the chances of achieving the Sprint Goal.
5. Delivering multiple Increments per Sprint
I have seen people hate Scrum because they claim teams can only deliver a software Increment at the end of the Sprint, after approval at the Sprint Review. If this is why they hate the framework, then it is unjustified. Scrum allows for multiple deliveries per Sprint. If a team can deliver multiple times per day, great!
It is a common misunderstanding to think that Sprint exists to create an Increment of a product to be released at the end of the Sprint. But Sprints are learning loops, they do not determine the release frequency.
The Sprint starts with defining a Sprint Goal, like: “We wish to show our product is technically possible”. The Sprint ends in a Sprint Review with the stakeholders to inspect the outcome of the Sprint, like “We will show that our product is technically possible and also discuss stakeholders feedback and other learnings”.
Sprints exist because teams work in a complex environment and can’t predict what will happen, so they need to take small steps, verify the steps and then take these learnings to the next Sprint.
Many more misapplications
I could go on and on. Virtually every line of the Scrum Guide has been misunderstood over the years. But I think I discussed 5 that are particularly painful. I find it mindboggling how many people haven’t read it while still deciding to use it.
Why is this the case? Why is Scrum so misunderstood? Over the years I have come to the following conclusions:
Scrum is by far not the only approach that is misunderstood or misapplied.
We saw a bandwagon effect where organizations started to work with Scrum “because everyone does it”. This is not only a bad reason but also an indicator that these organizations didn’t read the fine print.
The Scrum Guide is geared towards the role of the Scrum Team but largely ignores the role of leadership and the stakeholders. I think this is a mistake because leadership and stakeholders are crucial for the success of any Scrum Team.
Scrum requires a learning culture. Many organizations don’t have this learning culture and don’t want to change.
Scrum started as a framework for products but then focused more on software development. This focus on one aspect of what makes a product experience ignores how important the other parts are and how they need to be in the loop.
Previous versions of the Scrum Guide highlighted practices that have now fallen out of grace. Examples are burndown charts, which focus on finishing items in a predictable way and the three questions during the Daily Scrum that did not help to make this event engaging.
What do you think? Do you have other examples of misunderstandings? Do you agree these haven’t served Scrum well? Leave your remarks in the comments!
I see No. 3 often the other way around: Teams without a sprint goal or a dummyn sprint goal, trying to deliver all the stories. No changes in the sprint allowed.
I honestly think that this has to do with team maturity. I chaos, delivering all the stories is a first step. When the team can achieve that, a better way to work is with sprint goals and adaptable stories in the sprint.