As a Certified Scrum Coach (CSC), I belong to a CSC/Certified Scrum Trainer discussion group. The folks on this list are a relatively small group of coaches and trainers that are one of the driving forces behind Scrum.
They are thought leaders, evangelists, and practitioners. It’s an incredible group and I’m humbled to be a part of it.
As you can imagine, there’s always discussion and debate going on about the nuances of Scrum, Agile, and the associated practices. Sometimes it gets quite heated. I won’t share the specifics, but I do want to focus in on a thread that seems to come up quite often. The question:
Is the Product Owner a part of the Scrum Team?
It sounds like a simple question, one with a clear answer. However, it seems that it causes a nearly 50/50 rift in the above community. Now to be fair, the entire community doesn’t always “weigh-in”, so it’s hard to get an accurate assessment. But it certainly feels like a 50/50 split. And I find it somewhat confusing that such a small, but important point can have such ambiguity.
Before I weigh-in with my own opinions, I’d like to gather a few from well-respected resources.
A Few Opinions
From the Agile Atlas, I captured the following:
Scrum is a team process. The Scrum Team includes three roles, the Product Owner, the ScrumMaster, and the members of the Development Team. The Product Owner has responsibility for deciding what work will be done. The ScrumMaster acts as a servant leader, helping the team and the organization make the best use of Scrum. The Development Team builds the product incrementally, in a series of short time periods called Sprints. A Sprint is a fixed time period, from one to four weeks, with a preference toward shorter intervals. In each Sprint the Scrum Team will build and deliver a Product Increment. Each increment is a recognizable, visibly improved, operating subset of the product, meeting understood acceptance criteria and built to a level of quality called the Definition of Done.
And from the Scrum Guide , the following surrounds the definition of the Scrum Team:
In both cases, the distinction is for the Product Owner role to part of the overall Scrum Team. I didn’t say the “Development Team”, but the overall Scrum Team.
So, Why Exclude Them?
In the discussions I’ve seen surrounding whether the Product Owner is on the team have circled the following four major points:
- They’re not part of the team, so they don’t talk at the daily stand-up.
- They can’t attend the teams retrospective. This is one point that gets the most traction. The logic goes that they can skew the discussions in the retrospective to be too business-centric or results focused. Rather than internally towards the teams’ improvement.
- They’re too busy to engage with the team as a “team member”.
- Their role is simply too different; that is they don’t contribute work to the sprint.
All of them concern me, but the second point most of all.
I clearly ‘get’ that the Product Owner role is separate from the Development Team in Scrum. I think that distinction is healthy and balanced. However, I don’t think the Product Owner (nor the Scrum Master) should be excluded from participating in any of the teams Scrum ceremonies or activities. Nor should they be precluded from speaking.
From my perspective, they’re a member of the team with equal footing in all areas as long as we support the inherent fundamentals of each role – role and responsibilities.
Why do I want the Product Owner ‘in’ the team?
So you might be asking, why do I feel so strongly about this point? It originates with the notion of agile being a “team sport” and the self-directed team aspects of creating high-performance teams. I think ‘teaming’ is a central component of the success potential. Here’s a short-list of reasons why I want the Product Owner to be “on the team”:
- So they have some skin in the game
- So they’re accountable for the teams’ success or failure
- So they learn with the team
- So they begin to understand the teams’ strengths and weaknesses (including their own)
- So they attend ALL of the ceremonies and fully engage (as all team members should)
- So they make themselves “available” for the team when they are needed
- So they try to “sit with” the team
- So they occasionally try and do some work within their team, for example, feature testing
- So they invest in continuous team improvement; which includes: sharing the competitive/business landscape with their team – domain knowledge
- So they celebrate success with the team
And I don’t intend this list to be exhaustive; as I’m sure I missed things. But surely you get a sense for the ‘why’ behind my concern and argument.
Can a Product Owner become too involved in the development process and create churn? Perhaps. Can they share business pressure with the team and push them to deliver too quickly? Sure. Can they become separated from the team due to job time constraints and appear to be disinterested? Absolutely.
Can the Scrum Master operate poorly? Can the Development Team operate poorly? A clear yes to both. But excluding them from the team is only one possible ‘solution’ for these challenges. I’d rather look at root cause and fix them than exclude folks from the team who are creating ‘churn’ or are operating poorly within their roles. But that’s just me.
Like I said, approximately 50% of the CST’s seem to want the Product Owner outside of the team. So, you’re not necessarily wrong if this is your model or posture.
However, I’ve just got a different view. AND, in my agile experience this model has always led to better results. When I refer to a “Scrum Team”, I personally like them to be “composed of”: a Scrum Master, a Product Owner, and a cross-functional team of “developers” who are sufficiently skilled to deliver on their Product Backlog and meet their Definition of Done. This to me is a TEAM, and anything that undermines that notion is something that creates a lesser result.
Thanks for listening,
Powered by Facebook Comments