At the March meeting for the Agile Nashville User Group, we had a lively discussion around whether or not the Product Owner was a member of the Scrum team. This stemmed from a comment about the Product Owner not attending the sprint retrospective since it was primarily only for the team. There were several people on both sides of the issue, each very passionate about their respective stance, so in this article, I thought I would throw in my own two cents worth.
Following "The Rules"
Several people pointed to the “Scrum Guide,” as it clearly states that the "Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master." This is pretty definitive, but still some people pressed the opposite view. There were references made to other organizations such as the International Consortium for Agile, Scaled Agile Academy and the Project Management Institute and their reference materials, which were not as clear cut.
I found this very timely since I had just come back from the Mile High Agile conference where Mike Cohn of Mountain Goat Software had given the keynote, which contained some guidance around just following "the rules."
Mike cautioned that agile practitioners sometimes get too caught up in prescribed rules to the point where they start to blindly follow them. While most attendees involved in the discussion were open to idea of the Product Owner not being on the Scrum team and not attending the sprint retrospective, many seemed to get stuck on what the rules were from the Scrum Guide.
Another interesting thing that coincided with Mike's keynote was the idea of confirmation bias, where we tend to search for or interpret information in a way that confirms our preconceptions.
One of the user group members brought in some research material on this subject at our next meeting. In this material, it outlined what most of the major agile/Scrum organizations stated in regards to the Product Owner being on the Scrum team and attending retrospectives.
The document was well referenced and contained multiple viewpoints, but the section that most aligned with the author's own view was the most robust and annotated. When people with the opposite viewpoint reviewed the content, they tended to focus on the sections that leaned towards their own opinion.
Back to the Basics
When I was asked by several of the group members what I thought, I used the age-old coaching trick of answering a question with a question: "Why do you think the authors of the Scrum Guide clearly state that the Product Owner is a member of the Scrum team, and if it is so definitively stated, why are we still debating it?"
Agile Values and Principles
Now I don't do this just to be a jerk (that is a side benefit), but rather to get people thinking beyond the rule and more about why the rule is there in the first place.
When I train Scrum teams, almost one-fourth of my class is spent on the values and principles from the Agile Manifesto. Often, this is a quick reference slide in some of the training I've seen; but to me, it is at the core of what we adopt in agile – and more importantly, why we adopt it.
Teams definitely should adopt a set of mechanics and rules as part of their process, but these can evolve and change over time where the underlying values and principles remain fairly immutable.
So, let's look at the first part of my question about why Jeff Sutherland and Ken Schwaber decided to state that the Product Owner is part of the Scrum team.
When I look at one of the first principles in the Agile Manifesto, I think what applies is the following: "Business people and developers must work together daily throughout the project."
The Product Owner's job is to maximize the value of the product as the primary representative of the business stakeholders and end users. So if we consider the Product Owner to be one of the "business people," then we want them to work daily with the developers.
In Scrum, developers are part of the Scrum team, so we are saying that we want to have the Product Owner working together daily with the Scrum team. To me, that sounds like they are part of the team.
For another example, take the following principle: "The best architectures, requirements and designs emerge from self-organizing teams."
As the owner of the product backlog, the Product Owner is primarily responsible for the requirements of the product. The developers are primarily responsible for the architecture and design of the product.
As the principle states, we believe that the best way to create these is to have a self-organizing team. Once again, the implication is that the Product Owner is part of the Scrum team so that they can collaborate on these efforts.
Now take our user group's specific issue around the Product Owner attending the sprint retrospective. This ceremony reflects the principle that "at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
We can infer from the principles above that the Product Owner is indeed supposed to be an integral part of the team. If we also expect that team to regularly reflect and adapt through the Scrum ceremony of the sprint retrospective, then it is easy to conclude that, yes, the Product Owner is meant to participate.
Why is This Still a Debate?
So if you follow my reasoning above and concur that the Product Owner is meant to be a member of the Scrum team and attend sprint retrospectives, why is this still something agile teams are struggling with?
I find that many organizations struggle with the role of Product Owner, period. They often put people in the role who are not truly empowered to act for the business stakeholders. Sometimes they may put an actual business stakeholder in the role, but they will have competing responsibilities that constantly drag them away from the team.
When this happens, the Product Owner role becomes diluted and stops reflecting the agile values and principles it is supposed to embody. They no longer work with the teams on a daily basis or they cannot truly represent the business stakeholders and become a mere order taker.
The more abstracted from the team they become, the less they are collaborating, and the team will struggle to self-organize around efforts such as gathering requirements. While this can happen on any team, it can be more prevalent in larger organizations where the sheer size and number of teams requires more distributed management. This can easily lead to a certain detachment from the Scrum team for the Product Owner.
When the team feels the Product Owner is not fully integrated into their daily process, then it starts to seem reasonable that they would not be involved in the activities to inspect and adapt that process.
In addition to feeling like the Product Owner should not have much influence into their processes, the Scrum team may also feel a lack of trust that would dissuade this as well. When the Product Owner is farther away from the team and does not have a good understanding of what they do, they tend to make more unrealistic or uninformed demands.
This situation can easily cause friction between the two, and if the Scrum team feels like they cannot openly discuss these issues in a retrospective because of the Product Owner’s involvement, we start to lose out one of the best aspects of agile.
So, Are They a Member of the Scrum Team or Not?
In my opinion, there is no debate that in Scrum, the intention is that the Product Owner is an integral part of the Scrum team. If, in your experience, you feel this not to be true, then I ask you to think about what reasons you have for feeling that way.
What factors are leading you to not want your Product Owner to be in your sprint retrospectives? Investigate those reasons and try to fix the underlying issues to get the team to a place where they would feel completely comfortable with and absolutely want the Product Owner there.
Rather than blindly sticking to a rule one way or another, understand the values and principles behind it, and figure out how better to implement them. Rules are meant to bend, evolve and sometimes even break, but the values behind them will rarely fail you.
To learn more from Tommy, check out his online courses on "Scrum Fundamentals" or on "Advanced Scrum: Requirements Management and Quality Assurance."