What makes Scrum Scrum?
Can the Product Owner role really be dropped?
My reflections on Mike Cohn’s new article
--
This is a response to Mike Cohn’s article Is it time to do away with Scrum’s Product Owner role? It doesn’t require you to read Mike’s article first.
Three weeks after discussing the mandatory nature of the Sprint Review, Mike Cohn has dropped another bomb: he questions if the Product Owner role is still required. The responsibilities could be shared by the Development Team instead. As with the Sprint Review discussion, he is not the first to bring this up. But Mike is a big name in Scrum and this is why this has more impact than if people from outside the world of Scrum state it.
Mike has the following reasons to bring this up:
- Nothing in the role prevents it from being a shared responsibility for a team;
- Great Agile teams share their responsibilities (like coding, testing). This could also be true for product decisions;
- Self-organising teams choose their own best way with architectural choices. The same can apply to product decisions;
- A team always knows more than a dedicated Product Owner alone.
Product Owner responsibilities blending with Development Team
It’s not that the work of a Product Owner would become obsolete. On the contrary, it remains important. Mike however suggests that the Development Team could have this responsibility. It’s just the same as having the responsibility to do the architecture, build the increment, test the increment — having truly cross-functional teams.
A cross-functional team shouldn’t be confused with ‘everyone does everything’. While this is a possible way to work as a team, it doesn’t need to be that way and it often isn’t like this. Often you have people that are (more) specialised in building while others are (more) specialised in testing. Mike argues that you could have someone (or more people) in the team who are mainly specialised in product management, leading/guiding the team. She/He/They should however understand that the whole team can and should chip in when it comes to product decisions.
Possible issues
Mike states some prerequisites (thank you Sjoerd Nijland for phrasing them) that basically touch upon the maturity of a team:
- Development Team members need to depart from their specialist centered accountability and embrace full product accountability. No more “I am just a designer so I only design”.
- Development Team members need to have ownership — no more “tell me exactly what to work on”.
- Development Team members should ‘’bring their whole heart and passion”.
- There should be no more single person level decisions. There’s not only no Product Owner to be the sole person making product decisions. This also applies to designer, tester, architect, engineer. “The single wringable neck” will go out the window.” — Mike Cohn
I feel that these are always prerequisites for a well functioning Development Team, regardless if the Product Owner responsibilities are moved to the team or not. However I do acknowledge that these important factors are often absent, which makes teams less effective. Having the Product Owner responsibilities carried over to such a team only would make this worse, because not only the ‘how’ will be worked on in a sub-optimal way, it would now also apply for the ‘what’.
There is a similar issue if the Development Team isn’t truly self-organising. In order to make it work it is crucial that the Development Team determines the order of the Product Backlog, chooses the Sprint Goal and determines what items they will pick up in a Sprint.
What makes Scrum Scrum?
Some people may think that by removing the Product Owner Scrum actually stops to be Scrum. But the Product Owner wasn’t always part of Scrum. The role was introduced to solve the problem that many people were addressing the Scrum Team with requests. Someone had to bring order to this, hence the Product Owner was introduced.
Scrum at its core is:
“… a framework for developing, delivering, and sustaining complex products.” — Scrum Guide 2017
Scrum uses empiricism — transparency, inspection, adaptation — to address complex products. The work is accomplished by self-organising, cross-functional teams.
Scrum as a framework to address complex products, using empiricism, done by self-organising and cross-functional teams has always been what Scrum is about.
The introduction of the Product Owner was a solution to a problem. When a certain problem doesn’t exist anymore the reason for a Product Owner could also disappear.
It is only fitting that Scrum has adapted too, for example:
- Scrum initially didn’t have a Scrum Master, a Sprint Retrospective, a Product Owner, a Definition of “Done”;
- Scrum dropped the requirement for the three questions during the Daily Scrum, Scrum dropped the word “grooming”;
- The Scrum Master changed from team leader to coach.
And Scrum will continue to adapt as the world continues to change.
One product with multiple teams
I believe there a catch. It appears that the argument to do away with Scrum’s Product Owner role is based upon the idea that there’s a one-to-one relationship between Product Owner and Development Team. However this is not true:
“Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.” — Scrum Guide 2017
There’s a one-to-one relationship between Product Backlog and Product Owner. Hence there’s a one-to-many relationship between Product Owner and Development Team.
Who is responsible for this Product Backlog when there’s no Product Owner anymore? All the Development Teams together? Is this feasible? I’d argue that in these cases you can’t have the ordering of the Backlog Items done by the Development Teams.
Conclusion — intriguing idea but there are issues
Mike Cohn’s idea to do away with the Product Owner role is intriguing. I believe there are great benefits of having the responsibilities of the Product Owner shared by the Development Team, having product management expertise within the Development Team.
I always like it when a Product Owner collaborates with the Development Team in such a way the she/he essentially is part of this team. I also saw how Product Owners that were detached from the teams weren’t as successful as those who were part of the teams.
I do however also see issues with this approach, especially in environments where Scrum isn’t fully understood or where teams aren’t truly self-organising and cross-functional. Adding Product Owner responsibilities to a Development Team already struggling to become self-organising will only make things worse.
Another issue I see is in case of multiple teams working from one Product Backlog, a practice that — I believe — is an important nuance in Scrum. I don’t see multiple Development Teams being responsible for this one Product Backlog. Mike states that nothing in the Product Owner role prevents it from being a shared responsibility for a team. I argue that the fact that a Product Owner can work with multiple teams does prevent it.
I am curious if this idea from Mike is more than an idea. Perhaps it is a sign of what is to come. After all: the Scrum Guide user voice page is closed while “new Scrum Guide is under development”. But this idea really has to be worked out properly.
Thank you Maarten Dalmijn and Marty de Jonge for your feedback.
