Multiple Product Owners
I often hear a lot of criticism from agile aficionados around the role of the Product Owner and their dislike for the role. By design, there are a few critical elements to the role, and I want to discuss one of them. I intend to post more on other aspects of the role, so this is not the only one.
In my early career working as a consultant, programmer and architect I often had different customer staff members approach me to do work. As with normal business, they all believed their work was the most important thing to be done. It was an emotional roller coaster trying to appease everyone and work 10 things at the same time. I faced tons of assertiveness and power playing when I said my plate was full forcing me to give in, but only forced into another corner because of not working on something I had said I would do. Far too many bad memories for me. When I first saw how Scrum deals with it, it resonated with me on many levels
In Scrum, there is the concept of a single Product Owner. The Product Owners prime accountability is to maximize value for the product; that is get the best bang-for-buck. For this to happen the Product Owner needs to understand the business strategy and drivers and represent the business. Most developers in teams don’t get to see that context and are normally not invited to those business strategic meetings. An ideal product owner should be someone that is a product manager, thus they can make those “maximizing” decisions as they sit more on the business side.
The problem is when the developers make these decisions of what is valuable for the business, is that technical people are telling business what is important to them. This feels wrong, as a programmer, I hate it when a non-technical person tries to tell me how to code, however, the reverse is true. It is not the accountability of developers to tell the business what is important for them. The business should be specifying what is important to them.
The problem arises that the business has multiple stakeholders. If all of them are telling the team what is important and there are contradictions, who makes those choices on what to focus on. What are the criteria to figure out who’s work is more important, especially if one is not privy to the strategy of the business? I would find it weird if developers were part of those business meetings as it would mean they are in meetings all day and never have time to build the product. Should a developer team face this dilemma, what do they choose?
Recommended by LinkedIn
Having a single product owner allows this individual to represent the value. They can deal with all the conversations with stakeholders and negotiate consensus. They can ask hard questions on value and ROI. They bring focus to work and highlight the importance of it.
Now please, realize that Scrum is a team sport, and any Product Owner should be collaborating with other stakeholders and the team. They can collaboratively agree on the value and the order of work. However, as a backstop, especially if there is disagreement is the PO makes the call. The only time I have ever witnessed lots of disagreement is in a very dysfunctional organization, so it is rare. It is also totally alright for the Product Owner to delegate, but he/she/they will always remain accountable.
One does not need to be a Product Owner that does this in isolation, and others must be involved. However, there is someone that is focusing on the value for the business. It is not putting the burden on the developers, but it may involve them; thus, freeing time for developers to focus on building the product. It also defines a communication channel for work and makes it a lot less stressful for all parties.
Multiple people telling developers what to do will result in a lot of frustration for everyone. The risk is asking developers to make decisions on what is most valuable for business! It is a decision that a business person should be making, not the developers.
- Just Saying
Improving the world by improving the people in it
3yI don't have a problem with multiple POs, I have a problem with multiple people all making different demands upon me without a shared agreement between them. In those situations, I've advised they first all get themselves together and discuss their requirements without me, then only come to see me when each one of them can repeat the same agreed requirements that the others can - I won't stand there listening to them arguing over conflicting requirements. But this *is* the point of the PO - that they can mediate between stakeholders and provide a single voice that speaks a single requirement to the developers. The bit about techies not making business decisions rings very true to me, also. I've cautioned business people that what may seem perfectly obvious legal compliance to them doesn't guarantee developers are aware of such policies, and if they do not specify it as part of the requirements then they shouldn't complain when it's missing in the final results. I've also made it clear to developers that they should seek positive and negative test cases from the business so that they can prove not only their product works as intended for those permitted, but that also those disqualified should be prevented accordingly. It's interesting how much developers suddenly learn about compliance and legislation in those discussions that they'd been oblivious to (and business people quickly understand how unchecked input, buffer overflow and SQL injection attacks can cost dear). I'll also state that the only time I have witnessed lots of disagreement with the PO is when the PO didn't live up to their expectations - were too busy with other things to be an effective PO yet still blamed the developers for faults arising from their own incompetence - coupled with a spineless SM that was expected to "manage" developers for the PO and did very little to establish Scrum theory/practise, simply deployed Scrum terminology and "facilitated Scrum ceremonies" (which meant he attended but did little else). No wonder the devs were frustrated and demoralised.
CRM ERP AI Transformational Delivery Leader | Business Transformation | Copilot | Microsoft Power Platform | 10 X Dynamics and Azure MVP | Chief Technology Officer
3yMultiple Product Owners can be successful by properly leveraging sprints, iterations and releases to satisfy one at a time.
Thought Provoker / COO - AI / Edge Computing
3yThis one brings an interesting statement to the table: When we're in a situation where there's business alignment, i.e. stakeholders have agreed on priority, and there's no backlog, i.e. developers actually have slack capacity, then what problem does a Product Owner solve? The reason why I'm asking: is Scrum maybe solving the wrong problem here, i.e. trying to fix a symptom rather than the root cause?