Is it a good idea to appoint one of the scrum team member or scrum master as Product Owner?

Question

Lately we had a project, in which client was busy touring. As usual scrum team was formed, management decided to appoint our analyst as Product owner since Client won’t be able to participate actively. Analyst was the one who worked closely with client for requirement analysis and specification drafting.

Client doesn’t have the time to review first two releases. Everything went smoothly until, client saw third release; he wasn’t satisfied with some functionalities, and those was introduced by make shift Product Owner (our analyst).

We were told to wait till design team finished mock-up of all pages and client checked each one and approved to continue working. Scrum team is there, but no sprints – we finished work almost like classic waterfall method.

Is it a good idea to appoint scrum team member or master as product owner? Do we need to follow scrum in the absence of client/product owner participation?

Answer 1

It was only a few weeks ago that Mike Cohn wrote about combining scrum master and product owner roles on his blog. I don't think I can put it any better than he did, but my short summary of his post is this:

• it's a bad idea
• SM and PO perform very different kinds of tasks ("star tasks" and "guardian tasks" in Cohn's words)
• the person combining the two roles is unlikely to be a good fit for all tasks involved in both roles
• the team may be hurt by the combined SM/PO neglecting the tasks they are not the best at.

I think there is nothing wrong per se with taking any member of a scrum team and moving him/her to Product Owner. But you have to realize that it's like a promotion or an internal transfer; it creates a hole in the team and the hole needs to be filled. Maybe the team can "self-reorganize" to fill the hole; maybe it needs to hire a new employee to fill the vacant position.

Answer 2

Your process seems fine to me. You did not describe it in details, but a least, roles are respected (this is important).

However, with the few details I have, I can see some problem at the product owner level.

He/she should ensure that the customer is properly notified of the progress. Looks like he is doing "waterfall" externally with the customer and "scrum" internally with you.

Result: waterfall wins since customer is king. Even if in this case, the customer has his responsability...

Your current team (including Scrum Master), should focus on delivering the sprint backlog. However the product owner (analyst) should ensure that what is in his/her backlog reflects what the customer want. She/he should also ensure that the communication is good and that the customer participate.

Possible solution: send your product owner (analyst) to a Scrum Product Owner course, or make him/her read (and understand) this book: Agile Product Management with Scrum.

Answer 3

Scrum works best with a real client in place. There are a couple real challenges in dealing with clients who aren't used to iterative product design.

• The blank sheet syndrome
• Scared client syndrome

Design stages with a blank sheet tend to go pie in the sky really quickly, and typically go into great depth on a couple side issues and not enough depth on the core functionality needed. You really need a straw man for the client to pick apart for the design meetings to go successfully. By focusing on just one aspect at a time, you are helping your client learn iterative design.

Scared clients (like you had with your experience) don't realize that agile projects anticipate a certain (controlled) amount of rework as part of the process. What they have a hard time grasping is that as the product development moves forward, there will be fewer "Oh my god" moments. More importantly, the part most clients have a hard time with is that the "Oh my god" moments don't require butt-loads of money to fix because of the short time between review/planning cycles.

Managing client expectations is very difficult. Its a fine balance of customer education, placating, and even learning to say "no". The client can't always come weekly or biweekly. Sometimes they can only come once a month. That's OK. As long as you show them what you did to address their concerns the previous month, then focus on this month's work, it will go a long way to making the project go more smoothly. Bottom line is, in the customer's absence you do have someone who can make reasonable recommendations for some questions. It does need to be someone familiar with the goals the client is trying to achieve.

Answer 4

Ideally the product owner has some level of authority and knowledge about the project. This same thing could have happened if the client assigned a lower-level employee who was then over-ruled at a later phase requiring you to nearly start over.

Answer 5

Thanks for your post. I realize it's old, but I think you've raised a great case and here are my $.02:

Problem 1: appointing the analyst as PO in your case seriously short-circuits the scrum framework. Why? Because only the PO can make value judgements, ROI assessments, prioritization and decisive choices that flow from the business, not from technology, not even from familiarity with the product. I'm sure your sr. analyst did a fantastic job mimicking the PO, but ultimately had to guess the wants, values, choices that would come from your PO. ref http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/. Unless your analyst was granted POA from the client (unlikely), they would not be in a position to accept or reject anything at sprint review.

Could this approach possibly work? Yes but there would need to be a total transfer of responsibilities while your client was out. Your client's boss would need to agree to the surrogate, and that no reasonable decisions made would be reversed. Sound likely? More likely that you'd get a temporary PO from your client's organization (which is certainly not without its downside!) But if your sr. analyst worked with the temporary PO, any incorrect decisions would come from the business, thus keeping your team roles clean.

Problem 2: "client doesn't have time to review". Big problem (and one that I ran into recently too). PO must be present to accept the product. No one else can 'sign the check'. PO absence means dissatisfaction happens later, potentially more rework, and loss of trust. More fundamentally I'm sensing the client is not actively engaged in your project: no time for the daily standup, no time to answer questions, etc.

Problem 3: "we were told to wait till design team finished mock-up". And now are off scrum completely. The folks doing the mock-up should be part of your cross-functional team. I can't tell if this is caused by lack of management understanding of scrum or a shock reaction to your third release.

Question: Where was your scrum master in all of this? The SM would ordinarily recognize the danger of the role conflict and PO lack of participation, both obstacles / dangers to be addressed.