Overruling the Product Owner?
What if stakeholders insist on overruling the Product Owner because they bring the funding? Making Your Scrum Work #21.
Join the DZone community and get the full member experience.Join For Free
There are plenty of failure possibilities with Scrum. Since Scrum is an intentionally incomplete framework with a reasonable yet short “manual,” this effect should not surprise anyone. For example, what if the stakeholders (who bring the budget that is funding your Scrum team) insist on calling the shots by overruling the Product Owner’s prerogative to define the composition and the ordering the Product Backlog? What if your stakeholders suffer from the “my budget, my feature” syndrome?
Join me and delve into the effects of overruling the Product Owner in less than 140 seconds.
The Scrum Guide on the Product Owner
Let’s refresh our memories regarding the job of the Product Owner:
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals...For Product Owners to succeed, the entire organization must respect their decisions...The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.
The key to understanding today’s overruling the Product Owner anti-pattern is the last sentence: “Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.” It is the prerogative of the Product Owner to define the composition and the ordering of the Product Backlog. No one has the right to interfere with that competence.
Stakeholders may lobby for a change of the Product Backlog, pitching their needs in a general competition for the capacity of the Scrum team. However, pulling rank or—here—pointing at bringing the budget derails the whole Scrum process and is hence counter-productive.
Overruling the Product Owner
The organization nominally adapts Agile practices but sticks with the traditional ways of figuring out what is worth building:
- Pitch an idea to the management
- Get a budget
- Treat the product people as an internal agency to deliver what you want—it is your budget, isn’t it?
Think “Agile PMO,” metered funding, contract negotiations, and “servant-leadership” by status reports. (Concerning the Manifesto of Agile Software Development, we are back to square one.) Typically, this results in misalignment of efforts at an organizational level and stimulates local optimization initiatives within functional silos.
Break up functional silos, consider practices like Beyond Budgeting, create empowered product teams tasked with autonomously solving customer problems, and link bonuses strictly to the organization’s overall progress during the agile transformation. Embracing business agility as an organization does not work while trying to preserve organizational structures from the 1920s.
Given the responsibilities of the Product Owner, stakeholders may lobby for a change of the Product Backlog. However, pointing at bringing the budget to the party as a stakeholder and demanding the right to determine what will be built derails the whole Scrum process. Furthermore, it is counter-productive for an organization’s aspiration to become agile.
Have you been overruled as a Product Owner? How did you deal with that? Please share your learnings with us in the comments.
Published at DZone with permission of Stefan Wolpers, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.