Comprehensive software reviews to make better IT decisions
Understanding Scrum: Why Do Product Owners Have Three Ears?
Agile systems delivery (implemented through Scrum) is quickly becoming an accepted norm in IT. But using Scrum successfully in any organization requires a deep understanding of how it works and why. For example, many of our members don’t realize that successfully using Scrum requires them to select a Product Owner who has three ears.
Scrum is currently the most widely adopted process for implementing Agile in an organization. But simply adopting Scrum practices without a good understanding of why and how it works often leads to the failure of Agile Transformations or perhaps just a veneer of new practices that hide the fact that, under the covers, nothing substantial has changed in the organization. And let’s be clear, becoming Agile requires change that many organizations are not fully aware of, or in some circumstances, even willing to accommodate.
Among the mistakes that first-time Agile adopters make is to not fully appreciate the critical role played by the Product Owner (PO) in Scrum, nor the fundamental changes the organization will need to make in support of the PO role. Both mistakes will reduce an organization’s chances of successfully adopting Agile and achieving its promised benefits.
Successfully executing an Agile Transformation can yield significant benefits to an organization when given the conditions it needs to fully take root. Among those conditions is a full and proper appreciation of the Product Owner role and how critical it is to Scrum.
The success of any project (whether running Agile, Waterfall, or any approach you care to mention) always hinges on achieving a proper and healthy balance among the myriad of powerful and competing needs and constraints it faces. These needs/constraints always originate from one of three different sources:
- The Organization
- The Stakeholders
- The Project Team
Any large and important project is apt to go sideways whenever one or more of these sources is consistently given less weight than the others over the course of the project.
Organizational needs/constraints represent what is most important to the organization overall, and typically revolve around things like cost, schedule, return on investment, time to market, risk mitigation, leveraging opportunities, creating synergies, conforming to policies and regulations, etc.
Stakeholder needs/constraints represent what is most important to those who will be using the system and typically revolve around delivery of value, ease of use, better outcomes, making their jobs easier and more efficient, getting what they ask for, etc.
Project team needs/constraints represent what is most important to those who are tasked with delivering the system and cover a broad range that includes tools, skills, capabilities, technology limitations, capacity limits, adequate testing, architectural considerations, sustainable workload, clear direction and requirements, opportunities to innovate, getting sufficient input and feedback, support for clearing roadblocks, dependencies on other teams, etc.
Not surprisingly, all three of these sources will passionately and forcefully express their needs/constraints, which will often be in conflict with the others’. In Scrum, the PO is the individual tasked with listening to the cacophony of requests coming from the organization, stakeholders, and project team, making sense of it all, and judiciously distilling them down to make the best (balanced) decisions throughout the life of the project. It is a near super-human undertaking, which is why all good Product Owners must have three “ears,” one for each source.
Our Take
Proper organizational understanding and support of the PO role is critical to the success of Scrum. If we were to try and succinctly “define” the Product Owner in a way that adequately conveys its importance and describes the kind of organizational change required to support the PO role, it would look something like:
“The Product Owner is a project team member (typically also a stakeholder) who has been empowered by both the organization and stakeholders to act on their behalf and to guide the project direction with a single voice (supported by appropriate consultations with the organization and stakeholders). The Product Owner must be someone with deep understanding of the project deliverable (they are often considered to be a subject matter expert in an area related to the project deliverable) and ideally is both well-known and respected by both the organization and stakeholders. During the course of the project, requirements clarification, prioritization, and scope changes are ultimately decided by the Product Owner, who must perform the important balancing act required by the project to adequately reflect the needs and constraints of the organization, its stakeholders, and the project team.
The Product Owner role can only be successful in an organization that has established a trusting and supportive culture. Great trust must be placed in the Product Owner to adequately balance competing needs in a way which leads to good outcomes for the organization. This trust must come with some authority to make important project decisions, and the organization must also support the Product Owner in addressing risks and roadblocks outside the control of the project team.
The Product Owner is first among equals when it comes to ultimate ownership of success for the project (along with the project team itself). Because of this, any project of any significance will require the full-time effort of the Product Owner (don't shortchange yourself by under investing in a willing, able, and available Product Owner).”
Typical mistakes made by organizations starting out with Scrum include:
- Assigning a project manager as the Product Owner: The two roles are related but very different and mixing them up will impact the project negatively.
- Allowing the role of the Product Owner to be hijacked by a project steering committee: It’s easy to fall into the trap of believing that the critical arbitration and compromise that needs to take place because of the many competing needs and constrains of a project cannot possibly be achieved by a single individual, and so must be the purview of a committee. But this one, seemingly clear and simple, decision is actually the death knell of many projects. The Product Owner role exists to avoid the delays and diluted thinking that committees often represent.
- Failing to assign a full-time Product Owner to an important project: A Scrum project that lacks a willing, able, and available Product Owner is unlikely to be successful (about one-third of respondents to The State of Agile Report site Product Owner availability as a challenge). If for some reason it is truly impossible to find a sufficiently available Product Owner, a proxy for the role must be assigned to the project team, and clear guidance established about the range of scope and prioritization decisions that can be made by the proxy without consultation with the PO/stakeholders (and even then, it is important that the PO/stakeholders prioritize their time to work through issues/questions raised by the proxy).
Establishing effective Product Owners is a necessary and critical ingredient for any organization’s successful adoption of Scrum. Make sure your organization understands this and adjusts its processes and thinking to support the Product Owner role.
(An organization’s move to Agile can be more effective when it is supported by the adoption of tools that align to Agile’s “different way of working.” Agile Product Owners can benefit from the use of product road mapping tools like Aha!, ProductPlan, and Productboard.)