Having a proxy PO can create more problems than it solves since one of the primary benefits of a dedicated PO is to shorten the decision-making time for the developers. If the proxy PO is not empowered to make decisions, the role can quickly become a buffer to the real Product Owner. If this occurs, having a proxy PO can quickly become an antipattern. A healthy alternative is to introduce the role of the Chief Product Owner to work with a Product Owner. This is more than a choice of words because both roles are entitled to make decisions in accordance to their Scope.
Responsibilities of the Chief Product Owner
1. Has the same responsibilities of the PO but at scale.
2. Sets a strategic vision for the whole Scrum of Scrum.
3. Creates a single, prioritized backlog for the Product Owner(s) to decompose.
4. Performs release planning for the Scrum of Scrum.
5. Consolidates a minimal and uniform “Definition of Done” that applies to all teams.
6. Resolves dependencies and impediments raised by the teams.
7. Establishes and monitors effectiveness metrics.
8. Leads the MetaScrum event if there is no CCPO to linearly scale the role.
Antipatterns to Avoid
There are three main scenarios where an organization might consider adapting a Proxy PO structure. Let us examine each to consider alternatives that avoid these antipatterns:
1- One Large Product with a Single PO – I’m often asked, “What about the case where we have a very large product and multiple teams where a single Product Owner cannot handle all the work involved?” This is where a network of Product Owners comes in handy. A Proxy PO implies that the person is just holding down the fort for the real PO. Instead, consider making the “would-be” Proxy PO a real team PO and then adding a Chief PO into the mix to work with multiple Team POs. A Chief PO can then work with the local POs to fulfill the responsibilities of the role. One might think, “Isn’t that splitting hairs, isn’t a Proxy PO the same as a Team PO and you just renamed the PO to a Chief Product Owner?” Not at all. The main difference is that the team POs still have autonomy and decision-making ability. They simply work with one another to coordinate the work relating to their joined backlog. This allows for the work to flow without stopping and for the individual scrum teams to make decisions in a shorter time.
2- One PO handling Multiple Products - I often find that a Proxy PO is used when the organization has multiple products and the PO is overwhelmed but the organization does not trust others to take over the role. In this scenario, the organization opts to place a body on the ground who defers all decision making to the real PO who is too busy handling other issues. This stunts the flow of work and frustrates the development team since they now must wait for the information to flow through different people before anything can be done. This can be avoided by establishing empowered PO roles to work with the respective development team and adding a CPO to prioritize the aggregated work.
3- A PO in a different time zone - Nothing slows the decision-making time like time zone differences. Having a PO in a different part of the world than where the teams are located can slow down the start of the process by as much as twelve hours. In this case, it is best to adopt a Chief PO to Team PO structure where the team PO is as close as possible to the development team time zone. Remember that it is critical for the team PO to have decision making power. This means that the person needs to understand the requirements and priorities well. To do this, the Chief PO meets with the team POs daily not to hold a status meeting but to coordinate the priorities and dependencies throughout the network of teams.
A decisive PO who can provide answers to the team quickly is a key element of success in Scrum. In fact, teams that can make decisions quicker have a 25% higher chance of success over those that take longer. Therefore, an empowered Product Owner who is always available to the team is a critical success factor. If your product owner is overwhelmed and it’s time to scale the role, consider introducing a Chief Product Owner as a healthier alternative so your organization can continue to scale toward greater Agility.
