Product Owner is far too involved in granular detail
Evening everyone,
I'm having a bit of an issue with my Product Owner that I haven't been able to resolve.
I believe my team's Product Owner is getting far too involved in the solution of a problem. Their story/acceptance criteria writing has improved dramatically over the past few months, however, they are still reguarly attempting to dictate a solution to the team, rather than presenting them with a problem statement. As a result of this, they end up getting involved in granular level detail and neglecting their other duties as a Product Owner (e.g. the overall product vision). This is starting to have a serious impact on the development team, and they are very quickly losing respect for the PO.
As a Scrum Master, I'm struggling to rein him in. I've mentioned their tendency to solutionise multiple times, but it's not having an affect.
Does anyone have any tips on how I can coach him into letting go of the granular level detail and focusing on the big picture?
Thanks.
PO is responsible for the 'What' and the team for the 'How'.
What is the background of the PO?. Does he come from a Tech or Business background?
Years ago I worked in an Gov organization with a progressive CIO who was keen on introducing new development methodologies, new technologies, different prog languages etc. Being a Gov organization he wasn't able to successfully implement any of these. Too much resistance and constraints. He got frustrated with his own IT department.
One of the business units needed an overhaul of their system and this CIO applied for the position of Director of this business unit. Having the Tech background was seen as very positive. He became the PO... and you can guess what happened. We got the same issue as you have. He was questioning everything, pushing for stuff he had been pushing for as a CIO. He took on the attitude that IT was now a service to him as a customer and he should be calling the shots. The customer is always right attitude. He started pressing for having his own IT department, which he didn't get.
But it didn't mean that he was wrong. He took on the role of a 'Technical Product Owner' which might be a role that can be incorporated in SCRUM alongside the Business Product Owner. Having technical AND business knowledge can be useful.
But at the moment that is not the role of your PO and you should make it clear. His argument can be that he only sees value in the product if it's done his way. That his customer satisfaction is affected by it all.
If he doesn't want to change then it's time to find out what his agenda really is...
In Scrum PO ought to do a mental trade-off: less predictable, but release quality outcomes (increments) vs accuracy (that is often false one).
If PO is unable to do that trade-off, I would try to verify following hypotheses:
- PO sees limited value in the team work (e.g. he doesn't believe that team will come up with better ideas than his own)
- project is not complex (it might be complicated, though), therefore benefits coming from Scrum implementation are limited (is PO able to formulate a Sprint Goal?)
- PO is stressed out in this role (is it new to him?) and he does what he can do best - e.g. giving detailed solutions, and avoids doing what he believes he can't do well, e.g. providing problem description
Those are the matter of SM and applying a coaching process.
Thanks for the replies everyone.
In my opinion, I believe the PO is a bit controlling and obsessive. For example, during this morning's stand-up one of the team mentioned that they were adjusting copy to ensure it was inline and the PO went off on a tangent around copy questioning exactly what they were changing.
The PO comes from a technical background, but has not practised development in a very long time.They have a number of outdated concepts (e.g. obsessing over the "page fold") which is frustrating to the team.
Overall, I think there is a lack of trust. The PO is relatively new to the organisation (about 6 months in) and we expect our to PO to be efficient in analytics, etc. which the PO is not. Honestly, I think the team lacks respect for the PO as they don't believe they are doing their job properly.
Try focusing more on the actual structure and rigor of Scrum Events. For example:
- a Scrum Master should ensure that only the Development Team participate in the Daily Scrum. Why is the PO even there to go off on a tangent?
- ensure that each Sprint Planning session clearly separates the topics of "what" and "how". A clear treatment of "what" should eliminate precocious solutioning regardless of who is involved. Once these are separated you can develop the idea of who really needs to be there to decide "how".
Bear in mind that there is nothing in Scrum to stop a PO from actually being a member of the Development Team, if they think he or she would add value. I suspect your PO may be exhibiting a micromanagement tendency because he is somewhat frustrated at no longer having a technical job. However, if a PO is to succeed as a Dev Team member, then they would need to learn teamwork and to earn the respect of the others. That might be a long journey for him to make in this case, but the journey itself must be made clear if he wishes to participate in the Development Team role.