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.