Agile [Proxy Product Owner]

The Proxy Product Owner

A proxy product owner is a person acting as a place holder for the actual product owner . I have found proxy product owners used to compensate for overworked, partial, and distant product owners. In an organization, the vice president of product management was asked to take on the product owner role for a business-critical product. Even though he was ideally suited for the job, he struggled to spend enough time with the team. The business analyst on the team consequently stood in as a proxy product owner when the real product owner could not be there. The proxy did most of the product owner work without being empowered. The actual product owner ultimately decided about product backlog prioritization, release planning, and whether to accept or reject work results. What followed was an increase in conflicts and miscommunication, a slowdown in decision making, and a decrease in productivity and morale.

Using a proxy product owner is an attempt to superficially treat a systemic issue. Rather than employing a quick fix, organizations should address the underlying issues. This might require freeing up the product owner from other obligations; co-locating the product owner, Scrum Master, and team; or even finding a new product owner. Unless the proxy is truly empowered to make binding decisions on behalf of the Product Owner, this approach would lead to troubles. More often than not, the proxy is just NOT the single wring-able neck. You can hold them accountable, but unless they get to really decide what happens with the product, accountability is going to break down… they will defer and refer to the real owner every time.

This is also a big risk to the team as it may lead to some miscommunication. There could be instances where-in PO proxy may not be aware of big picture and hence unable to answer team questions with authority.

Backlog grooming or refinement session can address this. Scrum teams must have this meeting as part of their scrum ceremonies.  In this session, entire team, product owner and proxy product owner come together to discuss new and upcoming requirements of product backlog.  This gives offshore team to hear and connect with actual product owner directly. The outcome of these meetings is, a well-groomed( i.e. crystal clear DOD), sufficient, prioritized product backlog ready to be consumed by scrum\agile team, making PO’s presence optional during a running Sprint.  It is PO’s choice to connect with team in between if s\he has liberty of time. Or else s\he can directly appear for Sprint demo and acceptance of the Sprint.

Two anti-patterns to watch for…..
  •  Making under-powered,  incompetent, indecisive person as PO Proxy for offshore team. This will create more confusion, conflicts and miscommunication. This eventually leads to slowdown in decision making and a decrease in productivity and morale. Watch-out for this pattern.  Just calling business analyst as Proxy product owner is not a solution. Proxy PO is given free hands to make decisions.

  • Second anti-pattern which is observed is supplementing low bandwidth busy Product Owner with a so called Proxy PO to help him. This is solving a wrong problem. You need to balance actual product owner time at the first place.

Concluding thoughts…
It is favourable to have a proxy PO for addressing vast time zone differences, however it is of utmost important that PPO has the same capability, vision and authority as PO. No need to say that PPO comes from the same organization as PO. Additionally,  having a business person on offshore side, helps in building big picture, domain expertise, alignment towards business vision and also makes wonders to offshore team confidence and morale. Offshore teams work as business partner rather than implementation partner.

A very good link below about PO anti-patterns in turn emphasizing the criticality of the role.


Popular posts from this blog

Indian IT Industry - A Long Due Course Correction

Who Moved My HR?