I’m on a journey to go through the complete Scrum Guide (2020 version) and turn it inside out. Hoping to find a satisfying answer to the question: “Does Scrum make sense?”
I started with “Purpose of Scrum” and “Empiricism”. I came to the conclusion that the premise of Scrum is sound. Then I looked into the Scrum Values, which can indeed bring the pillars of empiricism to life.
Then I discussed the Scrum Team. And I wondered how often is it that a Scrum Team and its stakeholders work in an environment where all Scrum Values can be upheld, the team has no hierarchies and everyone understands the Scrum theory well enough to make effective use of the framework.
Last week I addressed the Developers, who should own the What, How, and When to achieve a Sprint Goal.
Today I will continue my journey with the next chapter of the Scrum Guide, about the Product Owner.
Product value maximizer
I have to admit, I immediately grapple with the first sentence of the Product Owner section:
“The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.” — Scrum Guide 2020
At first glance it makes sense. The name says it all: Product OWNER. This person ultimately decides what the Scrum Team needs to do to maximize the value of the product.
But there’s a catch. it says “[…] resulting from the work of the Scrum Team”. Could there be work on the product outside of the Scrum Team? If that is the case, does this mean that the Product Owner doesn’t own that piece of the product? What if 90% of the product isn’t for the Scrum Team? Does the name actually hold up to reality?
The Scrum Guide is intentionally focusing on one aspect of how a Product Owner does their job. And that is to maximize value in a complex environment. Scrum doesn’t discuss which Product Management practices or tools to use. I have no issues with that. I want to see the Scrum Guide focus on the essence of the learning loops of Scrum. Not on best practices that may not be applicable to all environments.
Product Backlog Manager
I argued that the Product Owner may not own the entire product, but merely the part that’s for their Scrum Team(s). But they DO own the Product Backlog. This means that the Product Owner:
Determines the Product Goal, which is the desired future state of the product.
Creates and communicates the Product Backlog Items (PBIs).
Orders the PBIs.
Ensures transparency of the Product Backlog.
Given that the Product Owner is accountable to maximize the value of the product (the part they control), it makes sense to me they own the Product Goal and the path to this Product Goal (the Product Backlog).
I do find it interesting that the 2020 version of the Scrum Guide introduced the notion that people outside of the Scrum Team can also do the above things, although the Product Owner remains accountable. It makes sense. It allows others to contribute to generating the Product Goal and ideas to achieve that goal. You want to engage with your stakeholders and this is a way to make that easier.
One person
The Scrum Guide says the Product Owner is one person and everybody should respect their decisions. This was established years ago to protect the team and to avoid them being pushed around by several people with conflicting priorities and agendas.
I’m wondering if this (still) holds up all the time. I have seen teams deviate from this practice of one Product Owner with great results. Here are two examples.
3 Product Owners have 10 Scrum Teams
The 3 Product Owners work together to maximize the value of one product, using one Product Backlog. The 3 Product Owners share the accountability for the product. They all have their strengths and insights and complement each other. Together they create the Product Goal, manage the Product Backlog, and work with 3 or 4 teams every Sprint.
They do everything according to the Scrum Guide. The only deviation is that they are more than one person. This setup has been very effective for a product of my current company, Worldline.
A Scrum Team sharing Product Owner accountabilities
The Scrum Team creates the Product Goal together, manages the Product Backlog, and works with the stakeholders. The Product Owner accountability is absorbed by the Scrum Team.
I know one team within my company that works this way. They create the Product Goal together and have a weekly alignment on the Product Backlog where all unclarities are removed. This team does everything by the book (too), except for having a sole Product Owner.
I argue these two situations show a great way to work with Scrum without that one Product Owner. In the first example, the 3 Product Owners can together shield the teams, if needed. In the second example, the team can and should be empowered to shield themselves. I fail to see why this wouldn’t be Scrum, although the Scrum Guide states that this is the case:
“While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety […]” — Scrum Guide 2020
I consider the Product Owner accountability to be too prescriptive. There are great other ways to fill in the Product Owner accountability without exactly following the Scrum Guide.
Sprint Planning and execution
The main role of the Product Owner at the Sprint Planning is to ensure the Scrum Team is in a good shape to work on something meaningful in the current Sprint. The Product Owner should be able to propose a potential Sprint Goal that realistically can be achieved with a selection of Product Backlog Items. The entire Scrum Team crafts the definite Sprint Goal.
The Product Owner does not tell the Developers how to achieve this Sprint Goal. The Developers know best. And during the Sprint, they have the freedom to deviate from the plan to maximize the chances to meet the Sprint Goal. The Product Owner is kept in the loop.
It is logical when the Product Owner leads the Scrum Team by setting the Product Goal and proposing the Sprint Goal for the next Sprint. As it is logical that the Developers are best equipped to find the best way to achieve the Sprint Goal.
Not without issues
I like most of what the Scrum Guide says about the Product Owner. I particularly like the emphasis on outcome-oriented goals, like the Product Goal and Sprint Goal.
However, I do have issues with how a Product Owner is stated to be only accountable for the Scrum Team-related work. At first glance, this makes sense. As were are talking about Scrum. But when a large part or even the majority of the work on a product is done by others than by the Scrum Team, what is left of the Product Owner? Isn’t the name very deceptive in these cases?
Also, why should a Product Owner always be one person? What is the problem with having a Product Owner team or a Scrum Team that absorbed the accountabilities of the Product Owner and thus having no one who wears that hat?
These days, Agile and Scrum are the norms. So are self-managing teams. I’m not implying that these concepts are perfectly executed everywhere (far from it!), but people know what they entail.
Many organizations may not need that ONE Product Owner, that single wringable neck. Sure, it remains important to reduce complexity, have transparency, and keep the focus. But I don’t see any reason why a Product Owner committee couldn’t achieve this as well as one Product Owner, especially when they are committed to strengthening these. Also, having one Product Owner means having a possible bottleneck. You may want to avoid this too.
I feel Scrum is rather rigid in how it defines the Product Owner accountability. It very much is rooted in the past while modern alternatives may work just as well with Scrum. For me, the Product Owner accountability is too prescriptive.
"But when a large part or even the majority of the work on a product is done by others than by the Scrum Team, what is left of the Product Owner?"
Nothing.
My company has been doing agile for almost 3 years. I am not impressed, to put it nicely. The team compositions are roughly: 1 Scrum Master, 1 PO, 3-4 developers, 3-4 Business people.
When they transitioned to Agile, they took the company SME's and they turned them into "Proxy Product Owners." Our customer does not provide their own product owners; we took our company experts, essentially flushed their decades of knowledge down the toilet and put them into a permanent quasi-retirement state. We don't do system specialization or SME's anymore, because apparently newbies with literally zero knowledge of a system can architect new development in the same amount of time and at the same quality as the SME with decades of experience. Apparently, filling our new PO role is more important than having people that actually understand the system actually designing the system.
Whatever our ex-SME's do now as PO's is beyond my, and everyone else's understanding. When I asked "Now that you won't be a SME, what will you be doing?" I was told "Integrating with the team." When I asked the Scrum Master what they do I was told "Read the job description." The job description is a list of vague, near-meaningless terms, with literally nothing concrete listed, other than "Lead the Backlog Meeting." When I told him that I had read the job description already and it was so vague that I had no idea what it was talking about, the Scrum Master was not able to provide any additional details. Nobody can.
In my experience, the PO is responsible for nothing. The PO is accountable for nothing. The PO does almost nothing.
Is the project late? Well, it's not the PO's fault, he doesn't do any work on it, it's the teams fault.
Are the requirements a mess? Well, it's not the PO's fault, the developers and business people iron those out.
Do we need to meet with the customer to resolve something? Well, the PO only half understands the issues, and the business people and developers can communicate the problems better, because they actually do the work; so the PO can go twiddle his thumbs in the corner somewhere.
Is it time to cram to meet deadlines? The PO is long gone... because what the hell is he going to do anyways?
My company took the people with the most experience and stuck them in a worthless role, to do nothing and paid them like they are frikin Atlas, carrying the entire world on their shoulders. Why? To check some ridiculous "Agile" checkbox. The "Agile" manual says we should do this PO thing, so we're going to do the PO thing, end of story.