SCRUM MYTHS
Scrum Myth #1 The PO Is Not Part Of The Team
Do you invite the PO to your team Retrospectives?
Do you invite the PO to your team Retrospectives? Recently I faced a situation where the PO was explicitly uninvited. No hard feelings, they understood. My suspicion is that they were actually relieved. One meeting less, right?
I was stunned. How do you intend to improve anything if an important piece of the puzzle is missing?
Then I realized that many people still keep the mentality of the Product Owner being “outside” of the team. I thought I’ll write and make a video about this topic because apparently the advantages of having just one team are not fully recognized or internalized.
What is your experience? I asked this question on LinkedIn and got some interesting responses. Follow me on LinkedIn and let’s bust the myths together!
Scrum Myth #1
Today we will debunk Scrum Myth #1 — that the Product Owner is not part of the team.
First, we will go through the anti-patterns, then I will explain why teamwork is king not only because Scrum Guide and the Scrum community say so but because that’s the most effective way of working. Especially in software development.
The Antipatterns
There are so many variations to this myth. Let’s start with the juicy pieces, the antipatterns that perpetuate the strange division of what we, the Agile people, would like to see as a cohesive team.
- The PO has a goal assigned and is tasked to make the team fulfill that goal. The team has no say in it and has no idea why the goal matters.
- The PO tells what the team will do and how they will implement it.
- Only the PO talks to the stakeholders, designers included.
- The PO is responsible for bringing perfectly written stories to the team for refinement.
- The PO is only involving the lead developers in story refinement.
- The PO is considered a manager, at a higher level than the rest of the team members.
All in all, POs end up being perceived as “them, the business people”. And as an inevitable result of all the aforementioned:
- The PO is excluded from team retrospectives.
All those anti-patterns lead to a big division between what is considered the product domain and the development team. We get different variations of Devs vs PO, or even Devs and SM vs PO.
Reasons for the exclusion
A colleague of mine explained this exclusion in the following manner:
Teamwork is King
Let’s see why I consider that this division is unhealthy for everyone — the people, the business, and the customers.
First of all, teamwork is king.
Especially in creative work as Jurgen Appelo, the author of Management 3.0, puts it “Many people work nowadays in the creative economy and they collaborate in networks, not hierarchies.”
Ask anyone who worked with multiple teams in their career which teams are the most successful and happy — the groups of people working on the same project or in the same room or cohesive teams sharing a goal and actively collaborating to achieve it?
Google’s researchers from Project Aristotle who conducted research to discover the secrets of effective teams at Google, define a team as follows:
“Teams are highly interdependent — they plan work, solve problems, make decisions, and review progress in service of a specific project. Team members need one another to get work done.”
Anyone who worked in software development will understand the “need one another” part. You need someone to review your code, test your implementation, to rubber-duck a solution. Two heads are better than one. You think about development and that’s even more true with people who come from different domains and have different perspectives. A developer needs to partner with the PO to understand the context and the business better so they can make more informed decisions.
As Agile Coaches, Scrum Masters, and any Leaders we should be coaching the team for collaboration.
Scrum is based upon a team
“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.”
Scrum Guide, 2020
This also illustrates how important teamwork is. What’s more, the Scrum founders underline that there is no room for hierarchies in the team. Each team member is just as equal. Egalitarianism!
Separation issues
Secondly, I want to draw your attention to a problem with separating the team. If there is no common goal, what usually happens is that people start pushing in opposite directions. PO pushes for more features faster, and the development team for code quality and techy improvements. If they don’t share a common purpose, their pursuits might get misaligned which only means that conflicts are just around the corner.
I hate my job
We all know what it feels like to go to a job we don’t like and deal with people who annoy us. Our motivation is close to zero, we hate Mondays and get the Sunday Scaries. This is no good for us, other people, or for the business.
We sometimes forget how essential it is to have fun in what we do and with the people we work with. Our job does not consist of repetitive tasks, it’s a constant mental activity with a high dose of creativity. We need to have fun and get on well with each other to drive great results for the company.
So do invite the Product Owner to the Retro. Improve together and learn from each other!
