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.

PO Anti Patterns

Thanks!
About Me

Comments

Post a Comment

Popular posts from this blog

Who Moved My HR?

Image
There was a time when Human Resource Development(HRD) was important and respected function in all organizations. In recent time it has been observed that organizations are reducing the focus on HRD or treating it as a secondary function.  The use of technology has brought about a revolution in the routine activities of HR. This is mainly triggered by the flourishing IT industry since last 20 years. With primary focus being the development and deliveries of the technical solutions, HR function has been silently subdued by interesting hierarchies in these IT organizations.  Firstly HR function has been split into many sub functions like Recruitment Management, Resource Allocation, Training, Appraisals and these functions directly started working with executives and managers in the company. There were certain reasons for that like project managers having the insight to details about required skills on particular project. Although it started like that eventually HR fun
Read more

Passwords Passwords

Image
  Humans never had more secrets throughout their evolution than they are having now and Passwords/PINs are the reasons.  From internet banking to phone password, we are carrying these secrets with us. Even one password theft can be detrimental.  There used to be the time when they said, never write down your passwords, memorize them and destroy. This was possible when there used to be hardly couple of passwords, your computer login and your email login. Now that everyone on an average has about 30-40 passwords to be remembered and used, it is no more possible to follow that safety tip. And not just passwords but variety of user names too. I am very sure that everyone of us now keep the backup of passwords in one form or other. Just that you should not keep the passwords backed up on your laptop, phone or other digital device. There are two risks in doing so: Hacker Attack: Any device that connects to internet has probability of hacking attack, howsoever precautionary measures you tak
Read more

Agile [Story Point Estimation]

What Is It After All? Like any other estimation techniques, story points estimates are also about time i.e. the time efforts involved in doing something(a story). Everyone likes certainty and predictability and hence want to know when something will be done\delivered. When estimating, we need to consider all  the factors which directly or indirectly influence the efforts involved. C omplexity  is the base factor although other factors like  risk ,  uncertainty  etc. also adds to time efforts.  Each of these factors can affect in one or more phases of delivering a story. For example: A story may be  simple  to implement however  complex  to test or vice-versa Uncertainty  for example comes in during integration testing where your team's work gets integrated into say other teams work. Both teams are confident about their deliveries, however, that anxiousness creeps in, will it work flawlessly? Will we have some rework to do? Example of  risk  could a change required in a lega
Read more