So, you’re about to start that next (or even first!) Scrum project, and you’ve got everything in place:
✓ A business need
✓ A backlog of items to be developed into a product to solve that business need
✓ A dedicated development team
✓ A dedicated ScrumMaster
? A dedicated business Product Owner – Yeah, about that…
I know, I know… You have the perfect person in mind – let’s call her Susan. Susan would be the ideal product owner because she knows a ton about the business, and she can make decisions without even thinking twice about them. However, Susan is so important and busy in her day job that you can’t afford to spare any of her time as a Product Owner.
You’re definitely not the first to experience this problem. Actually, the lack of availability of the right Product Owner is one of the most commonly recurring issues that I see in Scrum and Agile development.
There are three common Product Owner availability replacement scenarios that I’ve experienced and I’ll try to explain a bit about why they don’t work as well.
You’ve already determined that the potential business ROI far exceeds the cost of a dedicated development team and Scrum Master, so you’ve assigned those roles. The only thing missing is the proper person to help the team identify which items in the backlog are truly going to deliver the most business value.
The bottom line is this: The right Product Owner can mean the difference between a truly successful team and one that struggles to deliver the right product in the right amount of time.
What follows below are three of the most common Product Owner “replacement” or “supplement” scenarios that I see.
Product Owner by Team
“It’s really not so important to have one person doing that, right? Since Susan is so busy, can we split the responsibility between her direct reports and cover it that way?”
The product owner by team concept sounds like a great way to share the burden, but in reality, it rarely works well. The most common scenario is that everyone that makes up the Product Owner “team” tends to have a different sense of what’s the most important, or what would provide the most value. In this case, two things tend to happen – 1) Everyone wants to come to an agreement 2) Those members that feel like they, personally, have the most urgent business-need tend to dominate the discussion, regardless of whether it truly provides the most business value.
The old adage of “too many cooks in the kitchen” comes to mind here. Having the right “chef” who can make the proper business decisions right away causes the least amount of wasted time and effort.
Product Owner’s direct report
aka – “Product owner by proxy” – “Since the team isn’t a good idea, and Susan is too busy, why don’t we use Bill instead? He reports to Susan, and he’s the one that knows the most about the business on her team. If he’s not sure about something, Bill can just meet with Susan to find out what she thinks is important.”
This is a slightly less problematic option than the Product Owner by team, but unfortunately still not ideal. A good product owner is knowledgeable, available and authoritative. Bill might fit the first two criteria quite well, but unfortunately, the bottleneck will still be Susan when a decision needs to be made.
There are many instances where the development team can be blocked by something that can be a quick decision. Having a Product Owner that can be available to make the proper business decisions right away also reduces wasted time. In this case, I would suggest that Bill is formally authorized as the Product Owner and entrusted to make the business decisions. Susan could then still be effective at her normal role, and much less time would be required of her if she assumes the role of Stakeholder.
Scrum Master as Product Owner
“We’ve named Jim as the ScrumMaster, and Jim has so much technical knowledge from his previous roles, he should have no problem prioritizing the work for the team.”
Once again, this sounds like another possible solution to the lack of time Susan has, but one major problem remains. Even though Jim may have a ton of technical knowledge, the biggest missing piece here is the business knowledge.
Even the most technical person can only guess at what will provide true business value. Only a knowledgeable Product Owner can provide the proper business vision and strategy to the team.
So, what’s the lesson here? You’ve made the commitment to assembling the team, in both time and cost. Why wouldn’t you try to increase the amount of overall value delivered while decreasing the amount of time it takes to deliver that value?
In my experience, having a dedicated Product Owner who has the knowledge, authority, and availability is going to provide a much quicker realization of the business value and overall ROI that you’re looking for.
We’d love to work with you to help identify the right product owner and to solve your next SAP problem with a proven Agile approach – please contact us to get started!
If you are interested in viewing similar articles, visit our blog, here.
View our LinkedIn, here.
