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.

Thoughts on the 2020 Scrum Guide – Part 1: Definition, Theory, Values

With the release of a newly revised Scrum Guide ( I’d like to identify some of the key changes since the last release in 2017 and offer my thoughts on the changes that strike me as significant. Rather than writing the whole thing up in one probably quite long post, I decided to break it up into as many separate posts as needed to cover each thematic area in smaller, more easily digestible bites.

I’ve organized this journey through the 2020 Scrum Guide chronologically, covering topics in the order in which they appear in the new Guide. Fortunately, the Scrum Guide is organized thematically in general, which makes a chronological approach both convenient and effective. So, without further ado, here we go….

Scrum Definition and Theory

These introductory sections have not changed substantially in the new Guide, but there are some differences and clarifications of note. First off, the definition of Scrum on page 3 dives right into the major responsibilities of the Scrum Master in fostering an organizational environment in which the Scrum Team can successfully deliver value while collaborating with stakeholders to inspect and adapt every Sprint. This does not represent a substantive change from the previous Scrum Guide, but does state very clearly that the Scrum Master is a critical player in the organization’s success. I think (here’s my first interpretation) that placing the Scrum Master right up front as one of the keys to success using Scrum is both appropriate and clears up any confusion around the necessity of having a full-time, dedicated Scrum Master to serve each Scrum Team.

The Scrum Definition section wraps up with this extremely meaningful statement: “Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.” This means that everything within the organization is subject to change and improvement, management structures included. This refreshingly powerful statement makes clear that it’s not just the people doing the work who may need to change, management also must be accountable for improvement and change.

The brief section on Scrum Theory on page 3 now calls out that Scrum is based not only in Empirical Process Control and its three pillars of Transparency, Inspection, and Adaptation, but also Lean thinking with its emphasis on reducing waste and focusing on essentials. This is an important acknowledgement of the importance of Lean thinking in Scrum. Lean thinking was always implicit in Scrum practices, but not called out explicitly in the Scrum Guide. The remainder of this section describes how Scrum applies Transparency, Inspection, and Adaptation to enable Lean thinking.

Scrum Values

As with the 2017 edition, the 2020 Scrum Guide specifically calls out the five Scrum Values: Commitment, Focus, Openness, Respect, and Courage. The definitions of the Scrum Values now focus more on how individuals come together as a team to achieve shared goals and build trust. I am especially gratified to see the emphasis on building trust both within the Scrum Team and between the Scrum Team and its stakeholders. I have long advocated that trust is critical to success so this is, in my opinion, an excellent addition to the formal philosophy and practice of Scrum.

That’s it for this installment. Next time we will examine the substantial changes to the definition of the Scrum Team and its players.