Software Development Industry News

Industry News

Why agile teams need to share the product owner role

Why agile teams need to share the product owner role

TechBeacon Wednesday, 11 January 2017

Within many agile teams, the PO (product owner) is solely responsible for the definition, interpretation, and prioritization of requirements. While these areas are clearly ruled by the PO, making them the unique province of the PO is fundamentally at odds with healthy agile team practices such as cross-functional teaming and collaborative swarming.

Building a special box around the PO into which others should not venture is both unnecessary and unhealthy. Those attempts seem like wish fulfillment for technophiles, since this separation of duties might insulate the development team from many of the people-centered duties of software development, which are notoriously challenging.

Instead of using the PO as a boundary and buffer, agile teams benefit from sharing elements of the PO role with the designated PO, who should retain final say over what work needs to be done and whether or not it has been successful. Here's why.

The PO is the chief steward of business value

On an agile team, the PO is principally responsible for representing business needs and ensuring that the team delivers business value. The PO develops the product backlog and prioritizes backlog items. In planning sessions, the PO ensures that the most important items are worked first, and helps to define acceptance criteria for those items.

Once the team is done working on the items, the PO verifies that the acceptance criteria have been met. Overall, the PO ensures that the team is working on the right features and producing valuable outcomes.

The PO is not a black box 

On many teams, however, the PO role as implemented in an exaggerated fashion. Since the PO is responsible for requirements and prioritization, the team treats the PO as a living specification document. The requirements are whatever the PO says that they are, and any questions about the requirements are resolved by asking the PO.

If there are confusions that need to be sorted out or priorities that need to be de-conflicted, those activities are thought to be squarely in the the PO's domain, and the team waits while the PO goes to figure things out. The messiest and most difficult aspect of software development—nailing down the requirements—is left in the hands of a single individual. The team treats that individual as an abstraction layer for a variety of requirements management activities, such as education, research, strategic planning, and stakeholder negotiation.

The isolated PO role is wish fulfillment

The tendency for agile teams to share all roles except product ownership likely derives in part from the interests and proclivities of the development team. By which I mean: The great fantasy of many software developers is to deal with code instead of people. While both present interesting challenges, machines are much more tractable than their owners.

When developers can't deal with technology alone, they might like to deal with other technical people to whom they can easily relate. Failing that, they would prefer to deal with a limited number of non-technical people who are well known to them. The PO role, as some teams define it, sounds suspiciously like wish fulfillment related to this fantasy. It gives technical people license to hide the messy, human-centric work they often don't, like behind a particular well-known person with whom they are comfortable. And it allows them to instead focus on the kinds of work they prefer to do.

In some contexts, this is reasonable. However, since the PO role is almost always a proxy for many other people's requirements, it is a fallible (albeit useful) layer of abstraction. The PO can be wrong, and sometimes the task of requirements engineering is too large for a single mind to handle.

Sharing the PO role

Development teams can help carry the burden of the PO in several ways, including:

Knowing the business

Development teams should understand the business considerations driving the software, and know why certain features are valuable. This will help them to ask better questions and make appropriate implementation decisions for low-level details that aren't covered by the stated requirements.

Knowing the stakeholders

Development teams should know who the application stakeholders are and how to get information from them. Routing every question of fact or intent through the PO will create an artificial and pointless bottleneck, particularly in cases where the PO functions as a proxy for others. Teams must learn how to get behind the PO when additional details or clarifications are needed. At the same time, they must keep the PO in the loop on any such efforts, so that the PO retains the ability to make informed and comprehensive judgments.

Challenging requirements

The PO is fallible, as are the stakeholders the PO represents. Requirements will sometimes be wrongly prioritized, missed, and misconstrued. The development team must use their business and technical knowledge to challenge requirements that seem misguided, supply new requirements for consideration, and argue for compromises motivated by implementation concerns.

Understanding project economics

The development team should understand the basis for prioritizing certain work. They must grasp ROI, payback periods, rates of return, and the time value of money. They should also understand the balance between time to market and technical debt. This knowledge will inform their engineering practices and drive them to decompose epics and user stories in ways that deliver the highest value elements first.   

Think inside the "box"

By venturing inside of the PO box and sharing some of the traditional PO duties, an agile team will become more informed, efficient, and fault-tolerant. The considerations that drive them to share technical tasks are equally applicable to the human-centric side of their work.