“Proxy Product Owner”, in this onshore/offshore agile world is a secret sauce to address the gap between the business and the development team. A proxy product owner is co-located with the development team while the product owner with all the business knowledge sits miles away. There is so much that can be done as a proxy and also there is an option to only stick to the mechanics. When I say mechanics I mean only restricting to writing stories in the backlog, planning etc. Proxy can become a note taker from the PO or choose to rather “mirror” the PO to begin with and then further develop into a “thought partner”. If a proxy doesn’t attain the “thought partnership” then, like today, the role will indeed be debated.
Ask these questions to yourself and if the answer is “No” for any of these then may be the role might lose it’s charm…
Q1 Do you ensure that the development team is happy?
Proxy should ensure that the development team is happy, a happy team is productive and will work for good and the good will automatically make the client happy. Proxy is just at the right place to do that.
Q2 Do you constantly measure and try to improve?
Let me explain with the help of an example. Track velocity and risk for a release and this would give you enough to understand what went wrong and will help you give a better shot next time. Unless you measure and analyse you live in a false world. Also when you measure then you are better equipped to resolve a problem.
Also have retrospectives and work on the action items religiously. If all your projects have the same issues then may be the problem is “you” than anything else.
Q3. Do your stakeholders always trust your product decisions?
If they don’t trust your decisions then you are not needed. Who needs just another layer in decision making?
Q4. Are you always in the main scene? Do you always have a pulse of what’s happening with the team?
Proxy constantly gives the direction to the development team, if you are side tracked then the team probably is not moving in the right direction.
Q5 Do you sometimes feel like you don’t have the right tools to solve a user challenge/team challenge/opportunity?
You need to gear up and experiment. You work with best of the technologists and if you are not tech/tool savvy then they probably won’t like you. Also it is a win-win. Ultimately tools will ease your life too.
Q6 Does team always have and respect Definition of Done (DoD)?
It is very important to have a DoD that is mutually agreed by you and the team. If it is agreed it will most likely be respected.
Q7 Do you ensure that backlog items estimates are created collaboratively by the people who will do the work?
Estimates should always be given by the person who would work on it else it’s unfair.
Q8 Are the top items in backlog small enough to fit in a sprint?
Proxy should focus on making requirements uncomplicated and that can be done by slicing and dicing the problem. The better you are at that, the simpler the problem will become. Small is usually simple and big is usually complex. If you give themes to the team then you are not needed, PO is more than enough.
Q9 Do you engage end user in every sprint for the feedback?
If you don’t then team indeed will work on changes later. Essence of agile is taking customer feedback as soon as possible.
Q10 Do you think before you say a “No” even when you are sure that it is not a “Yes”?
Last but not the least…don’t be a “Yes” man/woman. Team should mutually agree to a “Yes”. Also you need to put extra effort to ensure that every “Yes” is what the customer needs else you would build another software that is not adopted.
Let’s together work hard to make this role as a much needed role than a role that is debated on…
Look forward to hearing your comments…
These are only my thoughts, who am I? a proxy…