Why most Product Owners in Scrum are destined to fail
Simple to understand, difficult to master
The introduction of Scrum within a company can go wrong in many different ways. Maarten Dalmijn showed us how Scrum Masters are destined to fail. I see similar issues with the Product Owner role. These issues can be so big that they jeopardise the adoption of Scrum and the success of the Scrum Team.
The Product Owner role is not something you simply do. Often someone accepts the challenge to be a Product Owner of a Scrum Team without any preparation. It may sound nice to be called “Product Owner”. But — for starters — the role title is very deceptive.
Suppose that you know everything you should know about a product and that you have the authority to determine the vision of the product. And that you — on top of that — also can determine the order of the items for the product. These are big “ifs”. But let’s assume this is the case. This is not enough to avoid failure.
A Product Owner must know her/his place in Scrum
There are a few anti-patterns that are constantly popping up with Product Owners new to Scrum. Here are two very common ones.
“I own the product, so I call shots”
Product Owners often believe that they have full control over the team. They determine what is put on the Sprint Backlog and think they can expect no less than all items finished at the end of the Sprint. They basically hijack the team. These people were used to treat the team like this before. Becoming a Product Owner reinforces their belief that this way of working is the norm: after all they are the Product Owner!
There are reasons to call a Product Owner a Product Owner. The most important reason appears to be to establish that the Product Owner is responsible for maximizing the value of the product. But Scrum comes with certain rules that impact how the Product Owner is to approach the Development Team:
“They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality” — Scrum Guide 2017
The Development Team determines “how” to build the stuff because they self-organise.
“The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.” — Scrum Guide 2017
This is a tough one for many Product Owners. The Development Team — not the Product Owner — determines what can be picked up in the Sprint. Sure, the Product Owner determines the order of the items. But the Development Team determines what can and what can’t be done.
During the Sprint:
“Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.” — Scrum Guide 2017
Again: it’s not the Product Owner calling the shots. When more is learned it’s up to the Product Owner AND Development Team to determine what now.
And finally:
“The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.” — Scrum Guide 2017
The Product Owner is not in a position to tell the Development Team what to do. Or rather: the Product Owner doesn’t have the authority over the Development Team to determine what needs to be done. A failure to address these anti-patterns from the Product Owner will disrupt the team. The Product Owner will fail to effectively fulfill her/his role.
“You are self-organising. See you at the review!”
Another anti-pattern: the Product Owners thinking they have no real role in Scrum except for ordering the Product Backlog and making sure the team is picking up the right items. Product Owners that do this forget about many things, like:
“Ensuring the Development Team understands items in the Product Backlog to the level needed.” — Scrum Guide 2017
To do this a Product Owner needs to be available for the other members of the Scrum Team.
I already mentioned the following piece:
“Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.” — Scrum Guide 2017
Besides clarifying that the Product Owner doesn’t tell the team what needs to be done, it also says that a Product Owner should be available for the team.
A Product Owner who thinks that her/his presence isn’t required during Sprint is also setting up the team for failure.
Start to understand Scrum
It is pivotal for a Product Owner to understand Scrum. She/he doesn’t have to be at the same level of understanding as a Scrum Master, but there are certain things that absolutely need to be established:
- The Product Owner doesn’t own the Scrum Team’s agenda
- The Product Owner is an integral part of the Scrum Team
- The Product Owner should seek advise from the Scrum Master
Without this the Product Owner is destined to fail, dragging the whole Scrum Team into the pit.
My twitter profile is https://twitter.com/WJAgeling
Thank you Maarten Dalmijn, Max Heiliger, Paddy Corry and Sjoerd Nijland for your review!
