The Agile Coach on Pitfalls of Product Ownership

I’ve seen many great Product Owners in my Agile experiences. And here’s what makes them so…

They’re available.
They enjoy collaborating with the team.
They have a clear picture of what’s important to the customer.
They have good rapport with stakeholders.
They’re solid negotiators.
They have a willingness to own and groom the Product Backlog.
They understand the collaborative partnership with the Scrum team.
And they remain engaged and asks questions throughout the project.

In short, they’re committed.

But let’s be honest… not all Product Owners are great. So let’s talk about some of the pitfalls of Product Ownership and what we can do about them.

I’ve seen Product Owners who so badly want to please their boss on some side job that they don’t tell him that their Scrum team is counting on them.

The fact is, that Scrum project their team is working on is likely part of a larger program. And that program is part of a portfolio, which ultimately makes the overall strategic vision of the company a reality. Ironic, isn’t it? Talk with your boss about that side job and it’s importance in relation to the Scrum project. There are always other options. Your Scrum team needs you in order to be successful.

I’ve seen Executives that don’t fully understand the Product Owner role, so they don’t understand what the big deal is.

Clearly an opportunity for Agile Coaching or a quick ‘Agile for Executives’ training session here. A staff meeting on the topic wouldn’t hurt either in order to set expectations.

I’ve seen Product Owners that haven’t been trained on their new roles in Scrum, therefore not able to fully understand the expectations and the resulting consequences if they’re not engaged and available every step along the way. They somehow get thrown into the new role based on their business knowledge alone.

Yet another opportunity for the Agile Coach/Trainer. We might want to look at how we spin up new Scrum Project Teams at the PMO level as well.

Sadly, I’ve also seen several instances where trained Product Owners either partially or fully ignore their new role.

If this is the case, there are several options.

One is to explore the root cause. Ask the 5 Why’s… Why are they not available to the team? Because they’re overwhelmed with other work. Why are they overwhelmed? Because their boss is giving them too much to do? Why is their boss giving them too much to do? Because the Portfolio Management Office is cramming too much through the Project pipe. Why are they cramming too much through the pipe? Because they don’t realize you can’t do the work. Oh… You get the picture.

A second option is for them to assign a Product Owner Proxy, who can speak for and make all decisions on their behalf. In this case, make sure the Product Owner fully understands this Proxy role, because the same thing can happen if they don’t. Misunderstandings, disagreements, re-work, bugs, finger pointing, schedule risks, etc. Not to mention the Proxy can end up feeling unappreciated, dejected, and lose respect for the Product Owner and from the team.

A third option is to simply stop the project and wait for them to be available. Make it clear to them why you’re doing so. If you choose to move forward without their input, be sure to identify and communicate the risk; mainly building something that either won’t be used, or is going in the wrong direction.

A fourth option is to simply tell them that they’re not cutting the mustard as a Product Owner and you’d like to have someone who can commit to the team. These are difficult conversations for sure, but sometimes necessary.

And what about the Scrum Master? I’ve seen these folks end up taking on a heavier load due to decreased Product Owner involvement as well. Many times they end up making decisions that should be made by the Product Owner. Sometimes they make the right call and help to move the project forward, other times they don’t, and end up getting burned. This is another case where a Proxy should be selected. But reality has shown me that the Scrum Master often gets this thrown on top of their already heavy workload.

And the Scrum Team Members; how do they know they’re building the right thing? They may have to start making assumptions on what to build next, or what the acceptance criteria is for a certain story. What if they’re wrong? Finger pointing, re-work, bugs, schedule risk, dependencies on other projects or releases, etc.

If you’re a Product Owner on a Scrum project, are you fully committed? Do you understand your new role and the expectations? If you can’t be fully committed, what are you doing about it?