My issues with Accountabilities
One of the misconceptions is that Scrum is soft. Scrum Teams can’t make promises ‘because the product environment is complex’. When Scrum Teams don’t deliver, they give the same excuse. No one can say anything about it because the team is self-managing. Outsiders aren’t allowed to intervene. This faulty perception of Scrum must sting the creators of the framework.
Scrum isn’t like this. Instead, Scrum requires relentless commitment. Without this commitment from the Scrum Team and its stakeholders, Scrum isn’t effective.
I assume this is why they decided to be clearer in the new Scrum Guide by adding Commitments and Accountabilities. I like the emphasis on the two, but I don’t like how they implemented Accountabilities. Scrum Master, Developers and Product Owners all have their own accountabilities. But what about the Scrum Team? Shouldn’t the team be the prime focus? Are the accountabilities an incentive for silos within the Scrum Team?
There’s so much to unpack here. Let’s get right to it.
The Scrum Guide emphasises on the team
To most of us, it is clear that Scrum always has been about cross-functional and self-organising teams. In complex environments, teams need to have autonomy and all the skills required to create valuable products. There needs to be purpose, mastery and autonomy (Daniel Pink — Intrinsic motivation). This is inhibited when someone is limiting the team, telling them what to do.
The new version of the Scrum Guide has many updates on this front. Almost all these updates are effective in underlining the importance of the team. The list of changes is impressive. I will first show how the Scrum Guide increases the focus on the team. Then I will address the issues I have with the individual accountabilities.
From self-organizing to self-managing
Scrum Teams are now self-managing, determining who does what, when and how. The previous Scrum Guide said self-organizing, determining how to do the work.
Scrum Teams always determined what, when and how. But The Scrum Guide did not state this clearly when defining self-organisation. The new Scrum Guide fixes this ambiguity.
Shared responsibility
I like the following addition to the Scrum Guide:
“The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.” — Scrum Guide ‘20
Product Owner, Developers and Scrum Master all are responsible for all things to create valuable products. Sure, the Product Owner may be the person who is most in contact with the stakeholders. The Developer may be the person who builds new functionality. The Scrum Master may be focusing on the effective use of the Scrum framework. But everyone is part of a cross-functional team and it’s the result that matters — to everyone.
Shared accountability
The Scrum Team has shared accountability:
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. — Scrum Guide ‘20
This is again a clear message that Scrum is about teamwork and shared accountability. It’s another addition I like. For Scrum to work, the team needs to create an Increment at least once every Sprint. Without it, there’s no inspection and adaptation.
No more Development Team
The new Scrum Guide dropped the name Development Team. There’s no longer a team within a team. Only one team remains: the Scrum Team. The renaming of the Development Team to Developers will not change a lot to their daily routine. The Developers still create Increments. They still own the Sprint Backlog and the Daily Scrum.
The name change is an example of an improvement caused by removing something. In this case, they removed the team within a team.
Definition of Done (DoD)
In the previous version of the Scrum Guide, the Development Team defines the DoD. In the new Scrum Guide, the entire Scrum Team defines the DoD.
With this change, the Scrum Guide underlines that the whole team is accountable for creating Increments of quality.
My problem with individual accountabilities
I summarised how the new Scrum Guide puts the spotlight on teamwork and team responsibility.
This is why the individual accountabilities are at odds with the emphasis on the team. On top of that, I have issues with the term accountability. To clarify what I mean, I will now address all the accountabilities.
Definition of “accountable”
According to the Cambridge dictionary, accountable is:
“Someone who is accountable is completely responsible for what they do and must be able to give a satisfactory reason for it”.
Keeping in mind how the Scrum Guide emphasises the team, let’s address Developers, Product Owner and Scrum Master.
Developers
The Developers are accountable for four things:
Creating a plan for the Sprint.
Adhering to the Definition of Done.
Inspecting and adapting daily to meet the Sprint Goal.
Holding each other accountable to be true professionals.
The first three are ways for the Developers to address their accountability for building “a valuable, useful Increment every Sprint.” — Scrum Guide 2020.
Being true professionals and holding each other responsible for it applies to the complete Scrum Team. I don’t understand why the Product Owner and Scrum Master aren’t part of this. This is why I see this as accountability for the complete team. The fact that the Scrum Guide doesn’t make this call, may trigger silo-thinking.
Product Owner
The Scrum Guide mentions two accountabilities for the Product Owner:
Maximizing the value of the product that is created by the team.
Effective Product Backlog management.
I see these as ways for the Product Owner to address the accountability for building “a valuable, useful Increment every Sprint.” — Scrum Guide 2020.
To avoid silo-thinking, the Scrum Team accountability could be rephrased to creating a useful Increment of the highest possible value every Sprint. With that, the complete team is accountable and the Product Owner has the role to see to it.
Scrum Master
Then we have the Scrum Master. The Scrum Guide mentions two accountabilities:
Establishing Scrum according to the Scrum Guide.
Effectiveness of the Scrum Team.
Now consider the following:
The position of the ScrumMaster, having only indirect influence.
The Scrum Guide puts emphasis on the Scrum Team.
I argue every member of the Scrum Team should be able to explain what they did as a team to establish Scrum and be effective.
Sure, the Scrum Master is the one with the prime focus on this. But in the end, it is the Scrum Team who inspects itself and adapts to improve on these two aspects.
Accountability inflation
The good old Scrum Roles don’t exist anymore. Or rather, they have been renamed to Accountabilities. The new names point to the fact that Product Owner, Developers and Scrum Master all have their own accountabilities.
The Scrum Guide clarifies the importance of commitment and focus. Without it, Scrum isn’t effective. But I believe the accountabilities don’t help establish this.
They are an incentive for silo-thinking. The Scrum Guide highlights the Scrum Team and their shared accountability to build valuable Increments every Sprint. For this reason, I believe it is undesirable to have accountabilities on the level of Developers, Product Owner and Scrum Master.
We shouldn’t get rid of the accountabilities altogether. The Scrum Team could have the following accountabilities:
Create a useful Increment of the highest possible value every Sprint.
Holding each other accountable to be true professionals.
Establishing Scrum according to the Scrum Guide.
Being effective as a Scrum Team.
The remaining accountabilities are better served as ways for the different roles (Developers, Product Owner and Scrum Master) to work towards the accountabilities. It is far-fetched to call them accountabilities in the first place.
The Scrum Guide suffers from accountability inflation. It turns activities into accountabilities when renaming the roles to accountabilities.
Calling roles accountabilities is an attempt to clarify Scrum is serious business. It was an unnecessary move. The new Scrum Guide already clarified commitment and focus. Clarity on accountability is a great addition. But the current solution helps to create silo-thinking. This can never be the intent.