In the latest installment of my blog series on “Anti-patterns that Doom a Product Owner to Fail,” I address the fact that the Product Owner is indeed a member of the Scrum Team.
The Product Owner doesn’t act as part of the team
While Product Owners are leaders and provide the Product Vision for a Scrum Team, they need to remember that they are also a part of the Scrum Team.
Problem
If a Product Owner is detached from the team and only shows up when necessary, the person doesn’t consider him/herself part of the team. Instead of having regular interactions with the team, the Product Owner stays aloof, only communicating with the team when requested.
Solution
Regular communication and collaboration should happen between the rest of the Scrum Team and the Product Owner. As a part of the team, the PO should be actively engaged and available to the team whenever needed.
The Product Owner tries to control the Scrum Team
The opposite of not acting as part of the team is a Product Owner who wants to control everything.
Problem
Rather than being a team member, and a leader who also serves the Scrum Team, the Product Owner thinks that s/he’s in charge. This type of PO will boss people around and dictate the team’s work, rather than enabling self-management.
Solution
The Product Owner is responsible for the Product Backlog and its ordering, but the developers own the Sprint Backlog. They should consider the order of the Product Backlog, which may inform their selections, but they ultimately get to decide what work to do. The PO should be consulted but should not direct the work.
The Product Owner interrupts the Scrum Team during a Sprint
The Product Owner who interrupts the Scrum Team can be his/her own worst enemy.
Problem
If a Product Owner doesn’t have a backbone and can’t learn how to say “no” to demanding stakeholders, chances are your Sprints will be regularly interrupted. When a Sprint starts, the Scrum Team commits to accomplishing their Sprint Goal. As you discover new information during the Sprint, things can change, but adding items mid-stream is a bad idea unless there is a compelling argument to do so.
Solution
Don’t let new requests “jump” into the Sprint in progress. The Product Owner should explain to stakeholders that their items will be evaluated and considered when appropriate. That said, there may be exceptions to this – such as Production Support issues. Production issues can be showstoppers if the Scrum Team also supports their product; in this case, it may make sense to address such an issue immediately. However, this should be a rare exception and not a rule.
The Product Owner doesn’t interact with the Scrum Team
Your Product Owner not only doesn’t act like part of the team, but s/he may avoid contact with the Scrum Team altogether.
Problem
In this case, the Product Owner is more-or-less “Missing in Action,” avoiding the Scrum Team like the plague. Anyone absent, unavailable, or unresponsive won’t be effective. I once experienced this – the Product Owner was an executive who had little interest in my team’s work. As a result, we made our own decisions and drove the direction of the product because our PO would not.
Solution
Give the absent Product Owner the boot – that’s what we did. We searched for an alternate person within the organization who was interested and willing to do the job. I’m not privy to all the behind-the-scenes action to make this happen but suffice it to say that our new Product Owner turned the ship around.
The Product Owner doesn’t trust the Scrum Team
If you don’t relinquish control and trust your team, you’ll never succeed as a Product Owner.
Problem
The Product Owner doesn’t trust the rest of the Scrum Team to do their job. As you probably already know, the absence of trust is one of Patrick Lencioni’s “Five Dysfunctions of a Team.” Trust is the foundation of everything else. Unless the team members are willing to be vulnerable and work together as a team, you will never establish trust.
Trust is earned, not simply given, so earn it:
Solution
- Be vulnerable
- Do what you say you will do
- Work together
- Collaborate
- Communicate – often
- Don’t be afraid to make a mistake, and if you do, own it
- Be transparent
By exhibiting these types of behaviors, trust builds naturally – and once you have it, do everything you can to maintain and continue building on it.
Final Thoughts
Product Owners are absolutely part of the Scrum Team, and they should act like it. While Product Owners are leaders who serve the team, they aren’t “in charge” of the team. The Scrum Team and the Product Owner should work closely together to achieve Product and Sprint Goals. When you achieve your goals and build trust together, you have a solid foundation for a successful Scrum Team.
So what do you think? Have you seen any other problems or anti-patterns between a Product Owner and a Scrum Team that I didn’t cover? I would love to hear about your experiences, so share with me in the comments below!