Thoughts on the 2020 Scrum Guide – Part 2: The Scrum Team

Last time I examined changes to the 2020 Scrum Guide in the areas of Scrum definition, theory, and values. This time, I’m taking on the new, and in many ways improved, definition of the Scrum Team.

Definition of the Scrum Team

The 2017 Scrum Guide defined a Scrum Team as self-organizing, cross-functional, and consisting of a Product Owner, Scrum Master, and Development Team. The first major change here is the removal of the term “Development Team” and its replacement with the designation “Developers.” The 2020 definition of the Scrum Team appears on page 5 and is worth quoting here:

“The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.”

There is a lot going on in just these few words. First, the much-needed clarification that Developers do not form a sub-team within the larger Scrum Team. The concept of a Development Team within a Scrum Team created no end of confusion and I am glad to see that awkward usage replaced with the much more straightforward designation of “Developers” as members of a Scrum Team.

The authors also clarify that a Scrum Team consists of exactly one Scrum Master, exactly one Product Owner, and the aforementioned Developers. They then go on to muddy the waters around the Product Owner, but more on that later. Importantly, the 2020 definition of a Scrum Team specifically rules out sub-teams and hierarchies within a Scrum Team. The relationship between members of a Scrum Team is strictly peer-to-peer, even though each of the “roles” (oh boy, this is a problem, but again more on this later), has its own areas of accountability.

Finally, the new definition makes it crystal clear what the purpose of a Scrum Team is: a cohesive set of professionals focused on delivering a clear objective, in this case an artifact new to Scrum, the Product Goal. More on the Product Goal when I get to artifacts in a later post.

From Self-organizing to Self-managing

Although it may not seem significant at first glance, this is a major change in the definition of the Scrum Team. The old definition of a Scrum Team as self-organizing gave the Team the authority to decide how to do the work and who would do the work without external interference. The new definition enhances the autonomy and authority of the Scrum Team by designating the Team as self-managing, rather than self-organizing. So what does self-managing mean? Just this, the Scrum team decides internally not only who and how, but also what to work on. This means that the Scrum Team has complete authority over what they collectively choose to deliver each Sprint in order to achieve the Product Goal in the best way possible.

Scrum Team Accountability

The rest of this section in the 2020 Scrum Guide (again, on page 5) describes in more detail the size of the Scrum Team – 10 or fewer people with a bias toward smaller Teams to enhance communication and productivity. If a Scrum Team becomes too large, whether exceeding the limit of 10 or not, the 2020 Scrum Guide recommends reorganizing into multiple smaller, cohesive Scrum Teams that share the same Product Goal, Product Backlog, and – here’s the big problem – Product Owner. I’ll dive into why having multiple Scrum Teams sharing the same Product Owner is a fraught proposition when I cover the Product Owner in a later post. For now, be aware that this is a significant source of major dysfunction in organizations using Scrum, so until we can dive into this topic in more detail, suffice it to say I recommend that you avoid sharing an individual Product Owner across multiple Scrum Teams at all cost.

Okay, back to the accountability of the Scrum Team. The Scrum Team is accountable for all product-related activities, including collaborating with stakeholders, validating that what was built was the right thing, ongoing operations and maintenance of the product, experimentation, R & D, and all other aspects of product development, delivery, maintenance, and enhancement. The organization is obligated to provide the Scrum Team with full authority to manage their work, including working at a sustainable pace to enhance focus and consistency.

Not only is the Scrum Team accountable for the long-term development, delivery, and health of the product, the Team is also accountable for creating a valuable, useful product increment every Sprint. This combination of long-term and short-term accountability helps the Team stay focused on the big picture while not losing sight of the details.

These are excellent clarifications of the product-level accountabilities of a Scrum Team and will, I hope, end forever the notion that a Scrum Team is only dedicated to a technological component layer or development of new features only. This new emphasis on end-to-end product accountability is a breath of fresh air in the Scrum Guide and removes several areas of significant potential dysfunction from the conversation about Scrum.

That’s all for this time. Next up, describing the specific accountabilities within a Scrum Team: Scrum Master, Product Owner, and Developers.