Who is on the Team?

If you are our age, you remember the 90’s bulls. Air Jordan, Scottie Pippen and Dennis Rodman.

You probably remember Phil Jackson, the coaching Zen master who pioneered the triangle offence. He is able to make a collection of individuals into a team and give them a purpose greater than their individual ego’s. So loved by his team, that many would rather leave the Bulls than not be coached by him.

Was Phil Jackson part of the team, although he never scored a single point?

"I didn't win without Scottie Pippen, and that's why I consider him my best teammate of all time. He helped me so much in the way I approached the game, in the way I played the game. Whenever they speak Michael Jordan, they should speak Scottie Pippen."

It was Jerry Krause that drafted Scottie Pippen. Jerry Krause was the General manager of the Bulls. If we extend Jordan’s logic, without Krause, there was no winning.

Was Jerry Krause part of the team, although he never scored a single point?

The answer to these questions rests on the definition of the word team and the mental models it evokes.

Creating a shared mental model of the word "Team"?

You can find many definitions of a team in the literature.

For example, Jon. R. Katzenbach the author of book The Wisdom of Teams defines team as:

"A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable."  - Jon. R. Katzenbach

Professor Leigh Thompson of the Kellogg School of Management defines a team as follows

"A team is a group of people who are interdependent with respect to information, resources, knowledge and skills and who seek to combine their efforts to achieve a common goal" - Professor Leigh Thompson

The definition by Peter G. Northouse, a professor emeritus at Western Michigan University provides us with a definition that aligns closely to a team in Scrum.

"A team is a type of organizational group that is composed of members who are interdependent, who share common goals, and who must coordinate their activities to accomplish these goals" - Professor Peter G. Northouse

Although each definition is slightly different, all include a group of people that need each other's skills to accomplish some shared goal. A key point is that team members do not have an individual job to do, but instead are required to work together to produce some value -- like a product.

Renowned researcher J. Richard Hackman said that in a 'a real team' the members have a shared task, the team boundaries clearly state who is inside or outside of the group, it is clear what decisions are and are not for the team to make, and that the group membership is stable. Furthermore, he identified that in a ‘real team’, the team members are collectively accountable for the outcome that is produced.

Back to the Bulls

"You’ve got to have great athletes to win, I don’t care who the coach is. You can’t win without good athletes but you can lose with them. This is where coaching makes the difference." - Legendary coach Lou Holtz

Was Phil Jackson part of the team?

• Are Phil’s skills required during the game? Are his interventions in time-outs, substitutions required for winning the game?
• Is Phil held accountable for winning games?
• Is Phil a stable member of the team?

Who is on the team in Scrum?

"For a Scrum project the Development Team, Product Owners & Scrum Masters are considered as people who are committed to the project while stakeholders, customers and executive management are considered as involved but not committed to the project" - Ken Schwaber - Agile Project Management with SCRUM

The latest revision of the Scrum guide has taken an unambiguous stance on who is on the team: the development team, scrum master, and the product owner. The intention is to remove the "us vs. them" dynamic. The latest change made explicit what was alluded to in the Scrum guide since it was published a decade ago.

In the previous Scrum Guide, it was unclear what the Scrum Team's accountability is. In the new Scrum Guide, there can be no doubt. The Scrum Master, Product Owner, and the Development team are all on the team?

Subjecting the 2020 Scrum Guide to the team acid test

The answers to the question marks are subjective and will largely depend on two factors:

1. Your own experiences with the product owner and scrum master
2. The scale of the organization

Some of the mental models we have observed when reacting to the changes in the new Guide

"If you are not developing the product, you are not in the team."
A Product Owner or Scrum Master that performs a bunch of activities like stakeholder management, impediment removal, or Scrum coaching but has no Sprint Backlog tasks does not directly contribute to developing the Increment. Hence you might believe that they cannot be part of the team.

"The developers are responsible for building it right, while the Product Owner is responsible for identifying the right thing to build."
Suppose your experience with Product Owners is that they are only responsible for identifying what to build to maximize value delivery. In that case, you might believe that they are not part of the development team. From a tension between developers that want to improve quality by refactoring and test automation and the Product Owner that does not care about that, one might conclude that the Product Owner is not part of the team.

"Product Owner and Scrum Master are usually dysfunctional."
Experience with a Product Owner that hands-off requirements to the team or estimates the product backlog items and then disappears into lots of meetings might lead you to believe that the Product Owner cannot be part of the team. The same conclusion could follow from experiencing a Scrum Master that manages the Daily Scrum or always speaks for and represents the team to the outside.

"The development team, the Scrum Master and the Product Owner are responsible for both building the right thing and building it right."
If your experience with Product Owners is that they own the product, are responsible for its success, have the authority to make decisions, and intensively collaborate with the developers. You might consider that the Product Owner is part of the team. When you experience Scrum Masters that do technical coaching, help the developers improve product quality, and regularly pair programs, then you might consider that the Scrum Master is part of the team too.

"There is a difference between the product group and the team"
In the context of large scale product development, the word team is limited to those actually working to produce the Increment. All other roles, such as the Scrum Master, Product owner and management are part of the product group of which the teams are a part.

To be able to have a meaningful dialogue around who is on the team, it's useful to first uncover your own mental model around the word team. These were meant to be a sampling of those gathered during discussions of the new scrum guide as well as our own mental models.

Are the new changes to the Scrum Guide good or bad?

While this sounds well-intentioned on the surface, many claim that eliminating the Development Team role can lead to dangerous unintended consequences. By changing the words in the Scrum guide, will it help eliminate the "us and them" behavior between the Product Owner and Development Team or make things worse?

Some in the Scrum community are so strongly against the proposed changes that there is talk of forking the Scrum guide and ignoring the "Covid" Version.

Some of the concerns:

• "Blurring the boundaries between PO and Team opens the door for the BA-PO"
• The Product Owner micromanages the developers as she is now part of the team.
• The Product Owner is interfering with the developer's daily work even as she does not do active developer work.

In short, the "us and them" behavior will become worse rather than better.

What about Scrum Teams at a large scale?

In the context of large-scale product development with tens of teams working on a single product, how can the Product Owner be part of all teams or even a single team? Can the Product Owner pass the acid test in this context?

On the other hand, some feel strongly in favor of the removal of the Development Team role:

Some of the claimed benefits:

• Every role in the Scrum Team is accountable for delivering a valuable Increment. This not only increases alignment and focus on the product but also likely increases the feeling of product pride.
• No more hand-off of responsibility from the 'business' to 'developers" to deliver a valuable Increment. The Scrum Team is in this together, optimizing the whole Scrum Team instead of roles taken separately.

So What?

The mental model of the authors of the scrum guide was clarified in the current version of the guide: The ScrumMaster, Developers, and Product Owner are all jointly accountable for building the right product and building the product right.

"The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master." - 2020 Scrum Guide

This clarification has highlighted a cognitive dissonance between those who have different mental models on what a team is and who is on the team. Cognitive dissonance is an artifact of scaling any idea as people bring in their mental models under a common umbrella. The Physicist David Bohme, the originator of the idea of Dialogue and discussion, writes:

"Different groups ... are not actually able to listen to each other. As a result, the very attempt to improve communication leads frequently to yet more confusion, and the consequent sense of frustration inclines people ever further toward aggression and violence, rather than toward mutual understanding and trust."

What does this mean for your organization?

As a manager or Scrum Master, you might wonder how these changes are going to impact your organization?

It can impact in one of three ways: positively, negatively or not at all.

For us, we try to elevate the role of the Product Owner from business analyst to an entrepreneur so that they can focus on higher order things like maximizing the impact of the product. For example, we can take this change in the Scrum Guide as an opportunity to have a business analyst who was relabeled to Product Owner during the initial transformation join the developers, therefore creating the space for the entrepreneur Product Owner to emerge.

Similarly, our goal is to elevate the developers from those who "build it right" to those who can co-create with the Product Owner and the customer. This requires additional skills that are conveniently found in the ‘product owners’ that were in the role of business analyst.

We view the changes in the Scrum Guide as an opportunity for the Scrum community to come together through meaningful dialogue rather than get divided. It is also an opportunity for organizations who have adopted scrum to improve the impact they are having with Scrum.

"Talent wins games, but teamwork and intelligence wins championships." - Michael Jordan

Special thanks to the following people for the discussions and comments:

Viktor Grgic, Bas Vodde, Robert Briese, Ran Nyman and Michael James.

About the Authors

Ahmad Fahmy specializes in large-scale product development & organizational design. He has helped multiple large organizations and product companies successfully transition to lean and agile ways of working. With over 20 years of technology experience, his product knowledge and technology background makes him well suited to help organizations transform. His experience and empathy have made him a sought after consultant, trainer, and speaker on the subject of organizational design. You can find more here.

Cesario Ramos works as a senior management consultant on large-scale Agile transformations in the financial and high tech industries. Starting in 2001 with his first Scrum, he steadily expanded his work scope to guide projects, departments, to whole organizations. His international experience, a strong background in technology, and passion for people make him an influential partner in organization design and leading the adoption. Ramos is the author of the books' EMERGENT – Lean & Agile adoption for an innovative workplace' and co-author of 'A Scrum Book'. He regularly speaks at conferences and provides the Certified LeSS courses and Professional Scrum courses from Scrum.org. You can find more here.