What to do with a Product Owner who is not able to understand the role

Question

I am a ScrumMaster for a team of developers and QA's with a Product Owner.

I have tried unsuccessfully for the last year to get the PO to understand what the role of the PO entails and he just does not seem to get it. He tries my suggestions for a few weeks and then he slips into his old mode of working especially when deadlines loom:

• Micromanages team members
• Manages the team
• Attempts to plan the teams day, during standups
• Leers at them when they are sitting in a group chatting and asks why they are not working
• Constantly asks for updates
• Attempts to design the solution
• Relentless in his pursuit of understanding the solution design at a low level
• Dominates almost every team meeting and ceremony including technical solution design meetings even though they clearly don't have solution design experience or development experience
• Is constantly involved in team management related work e.g. resourcing of the team etc
• Does not write/is not able to write user stories and acceptance criteria at a level of detail for the team to design and code effectively
• Spends more time on the first points than actually doing requirements elicitation

What have the team said:

• They have raised the need for acceptance criteria and scenarios on numerous occasions
• They have said that the requirements are not clear and do not provide enough to 'go on'
• They have said they do feel 'managed' by the PO (during 1on1's with me)

My question is where should I go from here. I am at the end of my tether.

I was thinking my next step should be to talk to his manager and explain that I think he would make a very good traditional manager or project manager but I cannot see any qualities useful for a Product Owner.

Answer 1

There are a few areas I would want to dig further into.

First: Why does the team tolerate this from the PO. The PO, SM, and Team should all have about equal authority on the scrum team, though in different areas. I assume there are some other factors at play that grant the PO more authority.

I often look at the Scrum Team like a game of tug of war. As long as the roles are pulling about the same, there's a natural tension and we all have fun. If any of the roles are too strong or too weak, everyone falls over.

Second: What are the pressures on the PO? We all have expectations on us at work, but the if the company is expecting X scope by Y delivery date and making the PO responsible for that, you have a situation that is impossible for the PO to deliver on and unhealthy for the whole Scrum team. In most teams I work with, we identify the purpose of the team and the measures of success. As soon as the we see the measure is "get work done" we know that we have a problem. Measures should be focused on profitability, cost reduction, user satisfaction, etc. Then the PO's job is to maximize those with whatever work the team can get done. Usually in situations like you describe, the asks on the PO by others in the company are the wrong expectation.

My suspicion would be that you have an alignment and balance problem and that the practices problem is secondary, especially since you say the PO tries suggestions and then falls back to old habits under pressure.

Answer 2

An answer here really depends on how enabled the team is to utilize Scrum.

I see a few things here that may be worth unpacking with your PO:

the Daily Scrum is for the Development team to replan their day in an effort to meet a sprint goal. If the PO is being disruptive, they should not be in attendance as this distracts from the purpose of the Daily Scrum. An effort to coach the PO on the utility of the Daily Scrum should be taken.

the PO is responsible for maximizing/optimizing the value of delivered work, NOT the implementation of said work. Development Teams are structured and empowered by the organization to organize and manage their own work. Again, this sounds like a coaching opportunity with your PO.

the PO should be available to provide clarity into work items. If they are unable to do so, the Scrum Master should coach them on how to become better at this. If things do not improve, external training opportunities should be discussed.

All in all, this sounds like a conversation that needs to be had during a sprint retrospective, not 1-on-1 where transparency is limited. Coaching the team to embody the Scrum Values during this event, specifically Openness and Courage, is easier said than done, but essential to unroot causality and promote transparency both internally and externally to the team. Tough conversations move a team forward.

If a plan for remedy stems from this open conversation, and no progress is made, then it makes sense to escalate beyond the team. Removing impediments to the team's progress and helping organizational stakeholders understand and enact Scrum and empirical product development are key elements of being a Scrum Master. Tough task, but an essential part of the role.

Answer 3

The answers above are all valid. I'd just like to mention that the only "weapon" a team can use is a carefully tracked and categorized waste log. Track wait, re-work, debt servicing, overdesign etc and report the time (i.e money) wasted due to insufficient process. Then suggest action points. That is the only way I found really working when common sense arguments didn't. Work is work, so tracking the time spent on work is pointless. Track the time spent on blockers. Check https://dzone.com/articles/90-sprints-for-capital-markets-part-4-of-4 (disclaimer - I'm the author)