*Blog post was originally posted on Scrum.org
The Scrum Guide is quite clear on one important thing: for one product there is only one Product Owner and only one Product Backlog:
“[The Product Backlog] is the single source of requirements for any changes to be made to the product.”
“The Product Owner is the sole person responsible for managing the Product Backlog.”
“The Product Owner is one person, not a committee.”
With such an easy formula where “1 Product = 1 Product Owner = 1 Product Backlog” it is only fitting to add a little extension to it by saying “1 Product = 1 Team”. This usually comes from the understanding that a team is formed based on the product they are working on. In this case, if people are working on the same product, they have to be part of the same team.
So is it a myth or a fact?
To get a better view of the situation, let’s look at some real-life examples of this assumption takes into action in organizations.
The case of over-populated cross-functional teams
Scrum thrives on cross-functional teams, meaning that the team “has all competencies needed to accomplish the work without depending on others not part of the team”. That is simple enough.
However, when put into practice in big organizations it often means jumbling together people from all around the company to work on a product as a single team. This often results in huge teams of 20+ people who only interact once during the day – at their Daily Scrum.
That Daily Scrum usually becomes one of the most painful events and follows one of two patterns: it takes unnecessarily long time, or it goes fast and produces no useful information. After this unpleasant experience the team members go back to their usual desk situated on a different floor, or even in a different building.
This clearly does not help increase collaboration between team members, because the more people you add to the group, the more coordination challenges you’ll encounter. It also becomes much more difficult for each team member to know who is working on what and how it relates to their own work.
It can get extreme when you have some new people “join” your team for a week or just a couple of days to help with something small. But since it’s still in the same product, they have to be part of the team, right?
The case of inexistent Sprint Goals
I often hear Scrum Masters say that it is extremely difficult to create a good cohesive Sprint Goal for their team because each of the team members works on a different thing. Logically, the goal becomes to complete each individual task.
It leads to people owning one single user story, or a set of very specific user stories. And once they finish those, they usually need to find some extra work that was not planned for at all. Most of the time, because each person owns their own list of tasks, it’s impossible to collaborate on those together.
By that time, the Sprint Goal is not longer used by the team anyway. But we know that in Scrum Sprint Goals are not optional (this myth has been busted a long time ago) – every Scrum team has to have a Sprint Goal every single Sprint.
The big question is: how come we have to have cohesive Sprint Goals but we can never come up with a single one? That must be a hint to a bigger challenge.
The case of lack of commitment
When there are many different products being built and a variety of projects underway, people are often assigned on several teams (or more specifically, projects).
A very real example of this is when someone (let’s call him John) from a different department joins your team to help you work on some new features. John, however, can’t be with your team all the time, because he has his departmental work to worry about.
It’s clear that John’s primary focus will always be the departmental work because this is where his individual goals are set and performance is evaluated. It means that his commitment to your Scrum Team will be at a minimum, so is his commitment to your product’s success.
Myth or fact?
I think you might have guessed it by now. The assumption that if you work on the same product you are a team is a myth.
As Patrick Lencioni said in his book Overcoming the Five Dysfunctions of a Team:
”Sometimes a team improvement effort is doomed from the start because the group going through it isn’t really a team at all… You see, a team is a relatively small number of people that shares common goals as well as rewards and responsibilities for achieving them.”
When we look at this it becomes clear that a common goal is a must to be a team. While not everyone might associate themselves with a team goal right away, there has to be one. And it has to be clear and understood by everyone.
Is there one feature that unites your team that everyone is working on? Are there specific product metrics that your team is working on improving? Is your team responsible for a certain customer?
Think about what creates cohesion for your team to be called a team. If you don’t have any at all, then you might reconsider your team’s composition. Most likely you have several smaller teams responsible for different parts of your product.
Another dimension to your team definition
Obviously, a common goal is the first thing that defines your team. But there are more factors that impact your team boundaries.
One of the models that I find extremely useful introduces a new axis called “Need each other” to the notion of a team (for more details see the article by Stefan Lindbohm and Viktor Cessan “The First Question To Ask When Building Teams – Is This Really A Team?“). What it means is that it recognizes, that you might have common goals as a group of people, but if you don’t need each other to achieve them, then you are just a pseudo-team.
This also works well within the context of cross-functionality – while you are not dependent on external sources, you might be dependent on the team itself. This “dependency” (or better, this need for each other) can be manifested through the distributed knowledge and skills, or personal and emotional connections (when people just click, if you will). If you absolutely don’t need your teammates, then you might as well work alone to achieve the same result.
In the case I described earlier with people coming together to work on something for a short period of time, we have a temporary alliance. People do not really share common goals, especially if they work for different departments, but they need each other to complete something. It is temporary.
The new people might be working on the same product as your Scrum Team, but they are more like your customers than your teammates.
And the last case where everyone just works on their own thing, when they cannot for the life of them to come up with a single cohesive Sprint Goal – they are just co-workers. They don’t need each other and they don’t have common goals. Putting them all of a single Scrum Team will make it more difficult for them to succeed.
One product – many teams
All the cases described above show how people working on the same product can be a team or can be not a team.
I believe that Scrum is successful when you work with an actual team – that is where you will be able to harness the power of teamwork and self-organization. Bundling people together because of some externally defined factors is not good enough.
Whether you are a Scrum Master, a manager, or a team member, look at the people you work with and think about how you are a team and how you are not a team. By recognizing your current state you will be able to make the necessary changes to the overall organizational structures for a more successful Scrum implementation.