Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In this series of posts we - your ‘mythbusters’ Christiaan Verwijs & Barry Overeem - will address the most common myths and misunderstandings. PS: The great visuals are by Thea Schukken.
Myth 6: The Product Owner is a Proxy for Stakeholders
Today we bust the myth that the Product Owner acts as the proxy for stakeholders. More plainly put, this is an interpretation of Scrum where the Product Owner is supposedly the only person who talks with stakeholders (e.g. customers and users) on behalf of the entire Scrum Team.
We’ve seen quite a few Scrum Teams that express this belief through the following behaviors:
- Whenever a question about a feature pops up, the Development Team asks the Product Owner to go and clarify it with stakeholders. We once spent time with a team that literally spent an hour debating an unclear requirement that only required a 1-minute phone call with a stakeholder to clarify;
- Whenever a stakeholder expresses new ideas to members of the Development Team, they are referred to the Product Owner without taking note themselves;
- The Product Owner is (solely) expected to identify and clarify work on the Product Backlog on behalf of the Scrum Team.
Busting the Myth
The Scrum Guide states that the Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. This work is made transparent on the Product Backlog, and is managed by the Product Owner. In order to determine what work is valuable and in what order, the input of stakeholders is obviously needed. However, nowhere in the Scrum Guide is it stated that the Product Owner is the sole person responsible for communicating with stakeholders.
This interpretation of Scrum actually runs counter to what we’re trying to achieve. Scrum is built on the experience that product development is a very complex affair. Discovering what is needed, and how to best implement it, requires the Scrum Team to work closely with customers, users, and other stakeholders.
Scrum is a process of ‘collaborative discovery’
Starting only with a rough outline of a treasure map, the Scrum Team goes on a journey with stakeholders to identify where the treasure is actually buried. This collaborative principle is echoed in the third line of the Agile Manifesto: “Customer collaboration over contract negotiation”.
When only the Product Owner communicates with stakeholders, the following impediments to Agility are likely to arise:
- Stakeholders will not feel heard when the Development Team keeps referring them to the Product Owner to discuss new ideas. By turning Scrum into a bureaucracy, the Scrum Team becomes less responsive to what users need;
- The emergence of new insights, new ideas, and valuable opportunities will be stifled;
- The agility of the Scrum Team diminishes as the Product Owner becomes a bottleneck in clarifying requirements with stakeholders;
- The Development Team will not build the kind of deep understanding of what their users need, resulting in products that are difficult to understand, hard to use and don’t address the actual needs.
So treating the Product Owner as a proxy for stakeholders it not conductive of Agility. But how is the role of the Product Owner intended?
Proxy or Facilitator?
Instead of framing the Product Owner as a proxy for stakeholders, we prefer to explain the Product Owner as the person responsible for including the voice of stakeholders in this process of ‘collaborative discovery’. How this is done is up to the Product Owner and the Scrum Team, and depends on the availability of stakeholders and the nature of the product under development. But we’ve seen the following things work well:
- The Product Owner invites stakeholders to attend the Sprint Review, which is a minimal opportunity during Scrum where input from stakeholders is gathered;
- The Product Owner organizes workshops where he/she, stakeholders and members of the Development Team identify and clarify upcoming, valuable work for the product;
- The Product Owner creates opportunities and platforms where the Development Team can work with stakeholders to test assumptions or clarify needs;
- The Product Owner organizes tours or events to help the Development Team to get to know the people that are using the product;
The Product Owner is responsible for including the voice of the stakeholders in the process of 'collaborative discovery'
Instead of creating walls around the Development Team, the Product Owner should bridge the organizational gap that often exists between developers and stakeholders (users in particular). In any case, this should be done in ways that are respectful of the focus that the Development Team needs during a Sprint.
We would like to emphasize strongly that the Product Owner remains responsible for what goes on the Product Backlog, and in what order. In every sense of the word, the product is still owned by the Product Owner. But not in bureaucratic, traditional manner where everything has to go through the Product Owner.
Tips
- If you’re the Scrum Master, support your Product Owner by offering formats or approaches to help bridge the gap between development and stakeholders;
- The Liberating Structure ‘25/10 Crowd Sourcing’ is a great way to rapidly identify high-value features with stakeholders and the Development Team. Other Liberating Structures that are very useful here are Wise Crowds and Celebrity Interview;
- Organize sessions where stakeholders and members of the Development Team work together to create ‘Empathy Maps’, ‘Design the Box’ or perform ‘Magic Estimation’;
- Create personas that are based on actual stakeholders and associate them with PBI’s on the Product Backlog. Whenever questions arise during work, the Development Team knows who to contact for further clarification or to validate assumptions;
Closing
In this post, we busted the myth that the Product Owner is a proxy for stakeholders. The bottom-line is that Scrum Teams become significantly less Agile when only the Product Owner communicates with stakeholders. Instead of framing the Product Owner as a proxy, we instead prefer to explain the Product Owner as the person responsible for including stakeholders in the conversation. We offered a few concrete tips on how to do this.
What do you think about this myth? Do you agree? What are your 'lessons learned'?
Want to separate Scrum from the myths? Join our Professional Scrum Master or Scrum Master Advanced courses (in Dutch or English). We guarantee a unique, eye-opening experience that is 100% free of PowerPoint, highly interactive and serious-but-fun. Check out our public courses (Dutch) or contact us for in-house or English courses.
