Monday, 1 December 2014

Scrum issue #17: The Product owner is too powerful


‘… and the story is a must for the next Sprint. George is the most suitable person to do it as he has the knowledge and the expertise, and no, there is no time to train other team-members in the meantime… now let me tell you what the best tech approach would be and the dependencies you would be dealing with… then you need to talk to Jane from the team in Australia to confirm… and don’t forget the tests you need to run… and the documentation expected…’ – you immediately recognise the almighty Product owner (PO). He is there to conquer, dominate and rule the world and nobody would dare to oppose him.

I worked with many POs and still can’t decide which the worst scenario is. A guy who totally does not care about the backlog, the sprint items and deliverables, the one who let everything to be decided by the team OR the dominant old-school micromanagement type of person who doesn’t let any of his powers easily.

The dominant PO would have any of those characteristics:
  • High-level manager
  • A person who hire / fire or promote (decide the fate of) team members
  • A person who’s been with the company for a decade (at least) and knows the system/the project and the co-workers better than the entire team
  • A business person who doesn’t care about Sprints, Scrum or any other fancy words. He has his due dates and scope negotiated with the client and everybody must comply with his plan
  • A person who love talking for hours and nobody could even get the chance to say anything
  • A person who is always in charge – he starts and finishes the meeting and talks 90% of the time
  • A person who doesn’t listen or quickly ignores any remarks or attempts for such
  • An old-school micro-management freak. He can’t sleep well if he has not personally assigned the daily tasks to each particular team member
  • A person who always changes the agreed meeting time, clearly communicating who the boss is and that the whole team should comply with his schedule
  • A person who expects little discussion and more action. A person who would never ask for anybody’s opinion
  • A person who would always show-off and point how much better he is than anybody else

You would be really unlucky if you have a Product owner with all the characteristics mentioned above but even some of them could be a problem for succeeding in Agile/Scrum. In result to the described PO behaviour using Agile might turn into a horrible experience and miserable situation for everybody, expressed in:
  • The team show zero initiative
  • No self-management/organisation at all
  • Everybody waiting for the boss to assign tasks
  • Little to no interest in Daily Scrum, Planning, Grooming – the PO will take care of the planning anyway
  • The Review feels like ‘school exam’. The Retrospective is just ‘PO bashing everybody’ fest
  • No team proactiveness and no engagement at work
  • Little to no attempt to even discuss the items expected in the next delivery
  • Permanent inability to complete all the Sprint items for each Sprint
  • Insufficient quality for the delivered items
  • Overall team unhappiness

Although exaggerated above, as a Scrum Master you MUST act when you are dealing with a Product owner close to any of the described traits. You definitely would like to have some private time with him and depending on the case prepare for regular coaching sessions if needed. The PO should constantly be reminded/trained in the following Agile principles:
  • The role of the PO is to organise the backlog – ‘what, when and why’… It’s up to the team to decide ‘how and how much’ / absolutely no micromanagement is allowed. It’s up to the team to organise how to do a specific story and what the specific tasks are going to be
  • Discussion means that the team and the PO should talk evenly (or close to) – 50/50. If you feel like talking too much – stop, and ask what the team opinion is and how they see the story
  • You can’t simply put items from the Product backlog into the Sprint backlog under any circumstances! It’s up to the team to decide if a story fits into the Sprint and what is doable and what is not (negotiate deliverables and acceptance criteria – No item is meant to be static in Agile)
  • Back-off and empower the team – let them take the space. The team will not show proactivness and engagement if you hold the full power… What’s even worse – they would not be interested in delivering quality items
  • Show interest in what the team-members are saying – help them improve their ideas, don’t reject or seize them
  • Don’t correct the team even if they are wrong (well, don’t let them ruin the system though) – you could flag the issue but don’t impose your way
  • Treat the team with respect and equality. Let them organise themselves, respect their will and even vision. The main benefit of Agile is that nobody needs to manage the experts – they should be led and supported, but in end it’s up to them to propose, implement and deliver the best solutions (that’s why you hire experts, right?)
  • Engage the team in the long-term planning and how they see the future of the product developed
  • Get feedback from the team. The retrospective is not meant to improve the team work only. It is meant to improve the Product owner and the Scrum master work as well
  • Ask for team support as much as possible. Even with items primarily meant to be PO responsibility – like backlog prioritisation for example

There are many benefits in having self-organised and managed team. The productivity will increase, the items committed to - will be items delivered, the quality will be improved, better solutions will be implemented and the team will be motivated, working with fun and fulfilment. Stripping off some of the PO powers is usually just a little sacrifice for the greater good.

No comments:

Post a Comment