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 favorable 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.
Thanks!
Comments
Post a Comment