Now we’re getting into some of the more significant changes introduced in the 2020 Scrum Guide.
Accountabilities Instead of Roles
This seems like a strange usage of terminology to me, having “accountabilities” instead of “roles.” The accountabilities are labeled much like the former Scrum Roles: Scrum Master, Product Owner, and Developers (in place of Development Team), yet the use of the term accountabilities seems to imply that which person holds which accountability at any given moment is subject to change. I’m not sure that was the intent here, but it does open up a host of potential issues when organizations start thinking people can seamlessly shift from one accountability to another within a Scrum Team. I think everyone would be better served to continue to think in terms of roles and the associated accountabilities on a Scrum Team. The more stability in who does what – or who has which set of accountabilities to use the current terminology – the better both for the Scrum Team and for the organization.
Of the three accountabilities, this is the one that saw the most significant changes in the 2020 Scrum Guide. The Product Owner is accountable for maximizing the business value of the Scrum Team’s work and for effectively managing the Product Backlog, the latter consisting of (this appears on page 5):
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;
- Ordering Product Backlog items; and,
- Ensuring that the Product Backlog is transparent, visible and understood.
Okay, all good so far. Unfortunately, the Product Owner may do this work personally or delegate it to others, all the while remaining accountable for the results. I would never advocate for a Product Owner to do everything all the time, but delegating significant parts of the Product Owner’s work can very easily devolve into the dreaded “proxy Product Owner” situation in which accountability breaks down and decision making authority is diluted. In my view, the Product Owner should be doing most of this work, with perhaps the exception of creating Product Backlog Items, which can clearly be the result of input from many different quarters.
Sharing One Product Owner Across Multiple Scrum Teams
I mentioned in Part 2 of this series that I would be returning to this topic so here we are. Just by way of a refresher, the 2020 Scrum Guide states the following on page 5:
If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.
Sharing the Product Goal and Product Backlog across multiple Scrum Teams makes perfect sense. However, where I disagree strongly is with the assertion that the Product Owner is tightly coupled to the product and only loosely coupled to any particular Scrum Team (to use an object-oriented programming metaphor). In my view this is a significant problem. In fact, in my experience this type of Product Owner overloading is among the most common single points of failure in Scrum implementations. A much better approach is to ensure that each Scrum Team has a fully formed Product Owner and, in a multiple-Team setting, there is a Chief Product Owner who takes on the strategic view of the product. Following the 2020 Scrum Guide on this point leads directly to the emergence of proxy Product Owners on each Scrum Team, that is, an individual who has neither the accountability nor the authority to fulfill the Product Owner role yet is expected to do the same work. Nothing good can come of this so my advice is to avoid using this approach at all costs. Follow the one Product Owner-per-Team with a Chief Product Owner model instead.
Developers (Instead of Development Team)
This is a refreshing simplification. Instead of a team-within-a-team, we now have Developers as a constituent part of the Scrum Team, tying in with the new emphasis on the entire Scrum Team being accountable for creating a valuable, useful product increment every Sprint (page 5).
The accountabilities of the Developers have also been distilled down to planning each Sprint by creating a Sprint Backlog, building quality into the product by adhering to the Definition of Done, adapting their plan each day to take into account that reality really doesn’t care about our plans, and engaging in mutual accountability.
The number of Developers on a Scrum Team is no longer specified, but implied by the overall limit of 10 members of each Scrum Team, which translates into no more than eight Developers, with a conscious bias toward smaller Team sizes to enhance responsiveness and reduce decision-making overhead.
The Scrum Master accountabilities have also been distilled down and simplified, though not as dramatically as those of the Developers. The Scrum Master is accountable for “establishing Scrum as defined in the Scrum Guide” (page 6). That is much more forceful language than previously used. The Scrum Master is also now charged with being a “true leader” instead of specifically calling out the practice of servant-leadership as in the 2017 edition. The only issue I have with this formulation is the lack of a clear definition of “true leader.” You will need to explore the nature and practice of leadership to be able to answer this call adequately.
Otherwise, the Scrum Master is charged with being of service to the Product Owner, Developers, and organization much as before with just a couple of notable revisions. First, the Scrum Master is accountable for ensuring that the Scrum Events are positive, productive, and do not exceed the timebox. This is much more forceful than the 2017 version which simply stated that the Scrum Master should facilitate the Scrum Events if needed or requested.
Two final clarifications of the Scrum Master accountabilities: First, Scrum Masters are now required to ensure that impediments to the Scrum Team’s progress are removed, rather than laying it all on the Scrum Master to remove all such impediments, which was never organizationally realistic and in many ways contradictory with the Scrum Master’s defined role in the organization, i.e., not having management authority.
The second clarification of note covers helping the Product Owner engage in effective stakeholder collaboration as needed or requested and helping break down barriers between stakeholders and the Scrum Team. These are common-sense changes that provide additional clarity and support for the Scrum Master’s daily work.
That’s it for this installment. I hope you find these observations relevant and helpful in your Scrum practice.
Next up, a review of the revised definitions of the Scrum Events.