Do Agile teams really need a single Product Owner?

‘Product Owner’ is a defined role in Scrum and is associated with Scrum and other Agile development projects. A team I’ve been working with recently, Team Jaguar, has made me re-evaluate Product Ownership as described in the Agile world. The experience has made me ask ‘do Agile teams really need a single product owner?’

The generally accepted definition of an Agile Product Owner

The clearest definition of a Product Owner I’ve come across is the one in The Scrum Guide, which at the time of writing reads:

"The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.”

The Scrum Guide by Jeff Sutherland and Ken Schwaber, used under CC BY-SA 4.0

Team Jaguar’s situation

The scenario that Team Jaguar faces is not an uncommon one. The team is small and is the only team in this New Zealand government department with any development capability. The government department has a huge number of products which are in the most part point solutions to problems the department has faced in the past. There are also a few larger systems developed externally and then handed over to the team to support, or built internally by the team themselves.

The team’s products are across a variety of business units, and so the team deals with many product owners from these units (obviously not Product Owners by the Scrum definition).

Given government budget and head count constraints, this team is the only team there is and isn’t likely to change in size.

How do we handle the Product Owner role in Team Jaguar’s situation?

There clearly is no single “product” that a Product Owner could be associated with in this context so rather than argue semantics over whether we treat all of the department’s solutions as a single product let’s instead look at why best practice suggests we have a single Product Owner.

Looking again at the Scrum Guide description above and applying a little information from other domains I surmise that the only reasons for having a single Product Owner rather than multiple are as follows:

• The team needs a single ordered list of deliverable work to ensure that we are “maximizing the value of the … work of the Development Team”. This is most easily achieved by having a single individual decide the relative value of work items on the list;
• Teams that have longevity are generally better performing than those that do not. In the context of product delivery, having a consistent single Product Owner means they become a more integrated member of the delivery team so that the team can communicate more efficiently with them and improve overall performance; and,
• Even if multiple Product Owners were associated with the team for a long period of time, thus providing sufficient longevity, having multiple Product Owners still makes the team significantly less flexible with respect to process changes and therefore continuous improvement.

The most optimal solution is obviously to have one individual performing the Product Owner role for the team. However, if these three points are satisfactorily addressed then it doesn’t necessarily need to be this way.

So, let’s look at an alternative that could apply in the context of Team Jaguar.

The team currently has a Manager. The manager has all the roles you’d expect in a traditional organisation like a government department: line management, personal development, work management, stakeholder management, reporting and recruitment.

Looking at the first need, this could be met by the manager assuming that role. In reality the manager is already defining schedules which is effectively prioritising the team’s backlog. It's only prioritised on a first-come-first-served basis but it’s still prioritised. So let’s carry on doing that. The only change being proactive publication of the prioritised list to all stakeholders in the hope that the increased visibility drives a value discussion between the business owners.

The manager is dedicated to the team so the longevity element is dealt with. Since the team has a different product owner on the business side per piece of work this means they have a lot of people to educate but that’s the constraint they’re working within. Because they have so many product owners, they need to be clear about how the process for communicating requirements and getting feedback from these people is going to work. Part of this needs to be a clear understanding of how and when process changes are communicated and incorporated so that the team can still implement continuous improvement. This addresses points two and three. It’s obviously not ideal but it could work.

Agile development purist vs pragmatist

The Scrum purists will obviously argue against this because there is no one Product Owner while the Lean purists will argue that we’re not “optimising the whole” and I completely agree, on both counts. However the whole system in this case that we have any influence over lies within these existing constraints so while this looks like a ridiculous optimisation and would change as soon as we widen the circle of the “system”, it’s still, I believe, the most pragmatic in the circumstances. Hopefully by being more transparent about how the team works with the various product owners and team manager and by highlighting the problems and inefficiencies that this current process causes, the system will extend out to include them. Once that happens we can then look to improve on it but we’re not there on our change curve yet. I’ll let you know how it goes!