Toggle Menu

Insights > Agile Transformation > Dear Agile: Can We Have Multiple Product Owners?

Dear Agile: Can We Have Multiple Product Owners?

This post is the latest in Excella’s Dear Agile series of blog posts. Have a question for Dear Agile? Send it to us via our anonymous submission form. DEAR AGILE – I work on a large project … [with] multiple Product Owners who sign off on stories across several different pieces of the application. These […]

By

April 28, 2017

This post is the latest in Excella’s Dear Agile series of blog posts. Have a question for Dear Agile? Send it to us via our anonymous submission form.

DEAR AGILE –

I work on a large project … [with] multiple Product Owners who sign off on stories across several different pieces of the application.

These POs are great individuals but oftentimes they run up against deadlines and are concerned that their requested features won’t make it into a release, particularly when the priorities of other POs may come into conflict. Similarly, we occasionally run into issues where one development team may be swamped for a release while another is [nearly] idle.

Is there a better way to approaching the PO role in large projects where there may be separate backlogs?

-PO’d

 

DEAR PO’d-

Different teams can have different POs if they operate independently. However, when multiple teams work on the same product or for the same customer, or otherwise have interdependencies, you really want “one PO to rule them all”—thus avoiding just the kind of problems you mention.

There’s a reason that Scrum stipulates one Product Owner—there can be only one set of priorities for the team. Otherwise, there are no clear priorities. It’s not the team’s responsibility to decide what is of greatest value; that’s the responsibility of the business/client/customer, represented by the PO. Even with a separate backlog and PO for each team, if there are features that must be coordinated across multiple teams, then we need an Executive PO to arbitrate conflicting priorities. Otherwise, no one speaks with authority for the customer’s best interests overall. Instead, each PO must negotiate with other POs to coordinate a cross-team feature, and the feature’s priority will default to the lowest priority given it across all involved POs.

Balancing the workload across teams for a given release is even more difficult when teams are not “fungible” across items in the backlog(s); that is, Team 1 can only work on “the front end” (or a given application, or certain kinds of backlog items), Team 2 can only work on “the back end,” etc. Cross-team features introduce the possibility of bottlenecks in the workflow. The skills and experience (and/or rigid predilections) of a given team prevents them from picking up work on other applications or architectural elements, similar to the situation of a single team composed of inflexible specialists (“I only do coding;” “I only do testing”). Granted, it’s not trivial for a team (or a person) to be able to smoothly shift from work on one area to collaborating with another team in a different area, but it would certainly be valuable to overcome bottlenecks, wouldn’t it?

Bottom line: when multiple teams (or POs) can’t work smoothly as one team, there are bound to be unfortunate complications.

About the Author

Rich McCabe has been around software since it was in punch cards. Nevertheless, he became a self-proclaimed Agile coach in 2002 and he does that now. Go figure.

You Might Also Like

Agile Transformation

9 Methods to Get More from Your Agile Adoption

Getting started with Agile is straightforward; succeeding with it is challenging. You can’t just introduce...

Agile Transformation

9 Signs You’re Struggling with Agile Adoption

Your team adopted Agile to get better—to accelerate delivery and improve performance—but now that you’ve...

Agile

The Manifesto for Scaling Agility

At Excella, we believe that continuous learning and knowledge-sharing fuels innovative thinking. The company created...