Why Are These 6 Things Not Allowed In Scrum?
The most recent version of the Scrum Guide has the definition of Scrum. The guide even says you don’t do Scrum if you only implement parts of it.
” The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.” — Scrum Guide 2020
I understand they bring it like this. Many people have altered things from Scrum to only invalidate the effectiveness of their Scrum adoption. But there’s another side of this coin. The Scrum Guide has certain rules you can deviate from without impacting the essence of Scrum. I believe the essence is:
- Deliver value every Sprint;
- Decide within the team;
- Inspect and adapt each step of the way.
In this article, I will discuss 6 things that are totally ok to deviate from without impacting the essence of Scrum but aren’t ok according to the new Scrum Guide.
There should be one Scrum Master
“The Scrum Team consists of one Scrum Master …” — Scrum Guide 2020
This line did not exist before. Previous versions of the Scrum Guide did not specifically say a team should have only one Scrum Master. I argue that it would work perfectly well if two people would share the Scrum Master responsibilities. As an example, one could focus on the team and the other could focus on the organisation. Together they can perfectly meet the accountabilities and fulfil all responsibilities. Who would argue the team doesn’t do Scrum?
But I can take it even a step further. Why should teams have a designated Scrum Master at all? What if the entire team shares the accountabilities and responsibilities? I’d argue that would be perfect. Teams would show they’d be perfectly self-managing. They would show their maturity in working with Scrum.
But it is not Scrum according to the Scrum Guide.
There should be one Product Owner
Since the Product Owner came into existence, Scrum has always said there should only be one. There should be one set of vocal cords and everyone should respect the decisions of the Product Owner.
The rule was introduced to move away from the bad practice of having multiple people fighting for the services of a team without any clear direction. This was a common practice when the Product Owner was introduced twenty plus years ago. It is still happening a lot today. The rule of one Product Owner per product — and as a result per team — is a logical one.
But it doesn’t apply to all product teams. I know a team with two people as Product Owner. Together, they share the accountability to maximize the value of their product. They ensure they are in sync all the time and everyone is ok with this.
According to the Scrum Guide, they don’t do Scrum.
I also have seen a team without a designated Product Owner. Together they did everything a Scrum Product Owner would do, but then as a team. They didn’t call themselves a Scrum Team. But apart from the absence of the Product Owner, they followed all the rules of the Scrum Guide.
Having a Product Owner is a great practice with Scrum. But why is it mandatory?
You need to have Daily Scrums
Teams may not need to have a daily event to inspect their progress towards the Sprint Goal. Here’s an example of when a team works in one-day Sprints.
A Sprint is a calendar month or less. The Scrum Guide doesn’t mention a minimum length. Theoretically, a Sprint could be one day. You could start the day with a planning session, setting a goal. Throughout the day, the team could work towards creating an Increment to meet the goal. The day ends with a Sprint Review and a Sprint Retrospective.
This could work in a highly complex environment to manage uncertainties and risks on a daily basis. Teams that work in one-day Sprints may not need a Daily Scrum. But the Scrum framework itself brings limitations as it is immutable. A team that’s doesn’t have Daily Scrums doesn’t do Scrum.
Daily Scrums need to be 15 minutes max
Daily Scrums are events to replan your work to optimize the chances of meeting your Sprint Goal. The Scrum Guide says they should be 15 minutes or less. This is an incentive to keep the discussion focused. It again is a great recommendation. Many teams will profit from a focused and short Daily Scrum.
But what if a team is happy to have a 30-minute daily planning session? We could argue they aren’t efficient this way. But who are we to judge? Doesn’t Scrum include self-management, allowing teams to determine how they create their Increments?
If a team has a perfect session taking 30 minutes, why isn’t this Scrum?
The Sprint Retrospective concludes the Sprint
“The Sprint Retrospective concludes the Sprint.” — Scrum Guide 2020
Scrum has never been clearer than in the current version of the Scrum Guide: a team ends the Sprint with a Sprint Retrospective. What if a team decides to end every day of the Sprint with a short retro? They could daily discuss what went well and what they could improve. They wouldn’t wait for the end of the Sprint to discuss possible improvements. This is a great practice. There’s also the option to do continuous retrospectives.
I agree that it is important to reflect on what happened during the Sprint. I also believe the best place to have a one-off Sprint Retrospective is after the Sprint Review and before the Sprint Planning.
But why are other options not Scrum? If you do daily retrospectives, isn’t this embracing the idea of empiricism — inspection and adaptation?
The Product Backlog
A Product Backlog helps to have an ordered list of things to do to meet the Product Goal. It is a means to an end. It is a helpful way to bring transparency, commitment and focus.
But teams may work in an environment so complex, they don’t exactly know how they will achieve the goal until they work on it. They only have a Product Goal. At the Sprint Planning, such teams define a Sprint Goal and create a plan to meet this Sprint Goal. They work from goal to goal and only determine how to reach the goal during the Sprint.
Apart from the Product Backlog, they tick all the boxes of Scrum. According to the Scrum Guide, they do not Scrum.
The 6 examples I mentioned here are not applicable to most of the Scrum Teams. The majority of the teams are totally covered with the Scrum Guide. It is great in describing best practices to work with the Scrum framework.
But some teams don’t fit the picture the Scrum Guide describes. But they do fully align with the essence of Scrum. They work with goals and in Sprints. They embrace empiricism.
I argue that the six topics I addressed don’t touch the essence of Scrum. They are only practices that help to get to the essence. They could be redundant for some teams.
Scrum is about empiricism, not about following the Scrum Guide meticulously. By focusing on doing everything according to the book, many went astray and forgot about what it REALLY is about: transparency, inspection and adaptation.
This is why I advocate for returning to the heart of Scrum. Let’s divide the Scrum Guide into the essence and practices that have proven to work for many situations, but aren’t applicable for everyone.