Responsibility for correcting the situation when the team fails several sprints in a row
Hello colleagues,
Let's imagine a situation where the Team fails to reach the Sprint Goals seven times in a row.
Who is responsible to change the situation?
1) Product Owner
2) Scrum Master
3) Developers
4) The Scrum Team
What do we have?
First: PO
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
So PO could ask the Developers about a reason of fails.
Second: SM
The Scrum Master is accountable for the Scrum Team’s effectiveness.
Scrum Masters are true leaders who serve the Scrum Team to be better in continuous learning process.
Coaching the team members in self-management and cross-functionality.
Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done.
Causing the removal of impediments to the Scrum Team’s progress.
Third: Developers
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
Adapting their plan each day toward the Sprint Goal.
And: The Scrum Team
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.
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.
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.
So... According to these statements SM, PO and Devs are responsible for the value at the end of a Sprint. It means - The whole Scrum Team. Yes. And It's my vision.
I know "the right" answer: Developers.
But I don't think so. Why they are scapegoats?
Let's see how it could be.
1) PO should ask the Team after the first, second (especially after the third fail) on the Retrospective: "Why do you fail? how can I help you?"
- because environments are not stable. Dear SM, could we ask you to do something, may be ask an organization to change the hardware please?
2) SM should ask the Team: "Guys may be I'm mistaken, but I see what we didn't reach the Goal. Am I right?"
- Yes, because PO changes stories during the Sprint
"What should we do to do not repeat this case again?"
3) Devs don't see the problem because nobody helps them to point on it.
- Really? PO says what it's okay. Nobody (from business) cares about the value.
After that SM goes to PO clarify the question privately.
The next chains of issue solving could be here:
SM rises this topic on the Retro -> Devs create an action item to solve it
PO rises this topic on the Retro -> Devs create an action item to solve it
Devs rise this topic on the Retro -> Devs+PO create an action item to solve it and ask SM to assist
...other scenarios
But any way SM should help the team to better through training, couching and mentoring.
...and Whole Scrum Team takes part in the issue solving: SM as the Team helper to be effective, PO as the value controller, Devs as the implementers.
From my point of view: Bad Scrum Master - who do nothing because "developers are responsible...". (especially several sprints in a row).
What are your thoughts on this?
The entire Scrum Team is responsible. This statement comes from the Scrum Guides section that describes Sprint Planning, in the first subsection.
The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.
If the entire Scrum Team collaborates to define the goal, then the whole team has responsibility for accomplishing that goal. As your example shows, there can be any number of reasons or excuses made for why it is not being accomplished. But in the end, it is up to the entire team to adapt their behaviors in order for the goals to be met.
Scrum does not have a "single wring-able neck" premise. The team works together on everything. Sure there are some specific responsibilities called out in the Scrum Guide but those are not duties. Responsibilities are designated to help provide some accountability for the team.
I know "the right" answer: Developers.
But I don't think so. Why they are scapegoats?
Because it's the right answer to a narrower question: who is accountable for creating a Done increment?
Scapegoating may follow from an inductive fallacy, i.e. the assumption that Developers, who are accountable for Done, must therefore be uniquely accountable for achieving the Sprint Goal. These two commitments, of course, are not the same thing.
I know "the right" answer: Developers.
But I don't think so. Why they are scapegoats?
From my point of view: Bad Scrum Master
Why any single person who taken Scrum Master accountability is scapegoat after 7 sprints of failure from your point of view ?. Even in the case that person was not available for 3 to 4 sprints or didn't even train and coach the team work in Scrum framework(as you mentioned "Who do nothing"), Will the team and stakeholders wait to fail till 7 sprints to finger point 1 person ? I see this as a hypothetical situation because there should have been improvements identified by all for their way of working in sprints at the earliest unless everyone in the program totally misunderstood the need for Scrum.
If there is an issue that causes the Sprint Goal is not or will not be met and someone can do something for the Sprint Goal to be met, the issue should be raised as soon as possible by the Developers. This does not need to be during the Retrospective. The Developers should notice the Sprint Goal will not be met before the end of the Sprint.
Of course, it should be talked about in every Retrospective. The Developers should raise it as an issue. If they don't feel it needs to be raised, or if they feel they can't, that in itself is an issue to talk about.
So, PO and SM are not accountable? Yes they are, they need to set up a culture of collaboration, Respect, Openness and Courage, so the Developers (can) talk and raise issues.
Thank you Daniel Wilhite, Ian Mitchell, Balaji Dhamodaran and Mario De Caerlé for your feedback, your minds.
Thanks for this great solution!