One lesson most agile practitioners learn quickly is that it takes a village to own a product. Most agile frameworks present backlog management as a collaboration between an omniscient and omnipotent Product Owner and a team. In theory, this is a beautiful model for realizing the economic benefits of agility. The backlog minimizes coordination delays because it’s the single authoritative source the team pulls work from. The product owner works with the team, adding, deleting, and changing backlog items in response to learning from Agile’s fast feedback cycles. The team is always working on the backlog items that should yield the best economic outcomes.
The reality is that this model does not work for most organizations because the Product Owner role is so demanding that one individual cannot successfully perform it. In a blog post, Lor Steyn described what we ask of the product owner [1]:
- Gather specifications from various stakeholders within the business and build the stories from which the team will work.
- Manage the backlog’s priorities, deciding which features will give the most business value.
- Have excellent communication skills to understand the business users and the development team.
“….so we have a role defined that requires high-level strategic thinking around business value and priorities, with a need for highly detailed thinking on stories, and the ability to understand the highly technical needs of the developers as well as the business needs of the users.”
An early study of the customer role in extreme programming led the researchers to conclude “….customers have a pressured and stressful role, leading to issues of sustainability”[2]
In his book “The Art of Agile Product Ownership,” Alan Kelly suggests “…only superhumans need to apply”[3]. Is it any wonder why product ownership issues often top surveys of problems agile teams experience?
The agile textbook agile image of an omniscient and omnipotent product owner has likely resulted in serious economic damage to many IT organizations because many laid off their business analysts, believing the responsibility for “determining precisely what to build” could be shouldered exclusively by an empowered product owner. Unfortunately, many of these organizations soon learned why the business analyst role was created in the first place.
Most agile frameworks suggest that the team and others assist the product owner. However, they provide little guidance for how the product owner and those other roles interact and collaborate. The Rock Crusher is a flow-based model describing roles, practices, and artifacts and provides guidance for these interactions and collaborations. As we developed the Rock Crusher model, we observed many successful collaborative product ownership patterns, which became the Rock Crusher Village.
The Rock Crusher deconstructs the role of the classical Product Owner into seven constituent roles. Roles are not individuals and only describe a function that must be provided. In a very small system, it is conceivable that an individual could play all roles – the classical product owner. In reality, for any real system, multiple individuals playing multiple roles must collaborate to “…determine precisely what to build”. The notable exception is the Backlog Owner, which is always a single person and not shared among several individuals. Roles are categorized as either accountable, responsible, or supporting.
Accountable Roles
Backlog Owner has the final say on the sequencing /prioritizing of work for a team. The backlog owner has the final say because they are accountable for ensuring the team always works on the most valuable work.
Solution Owner is a customer-facing role that is accountable for which features make into a Solution but does not have the final say on the prioritization of work for an individual team.
The need to distinguish between these two roles is driven by the observation that in many environments, the individual often designated as the Product Owner is only interested in Rocks that are related to a pet Solution and is not interested in or capable of guiding the Team in other Rocks in their backlog. I noted this issue in a previous post Are You Really the Product Owner? Furthermore, the team may be responsible for supporting multiple Solutions. For example, in a project-oriented environment, a team may work on several projects simultaneously. Someone must ensure team member priorities align with strategic enterprise goals.
In many organizations, both roles may be played by one individual. However, our observation was that organizations that clearly distinguished their ownership roles also avoided messy priority ambiguities, prioritization conflicts, and coordination delays.
Responsible Roles
Analyst is an individual responsible for transforming the sometimes competing wants, hopes, interests, and aspirations of the Customer, Stakeholder, Solution Owner, and the contributions of the Subject Matter Expert into a shared clear understanding of precisely what to build. They are responsible for progressively creating a better understanding of precisely what to build – the Solution.
Team members are responsible for collaborating with all roles to decide precisely what to build, and they are accountable for delivering on their commitments to the Backlog Owner.
Supporting Roles
Customer is the receiver or beneficiary of the Solution. May be consulted or informed about decisions on precisely what to build
Stakeholder is any individual who cares about the outcome of the solution and must be consulted about precisely what is being built and may also have decision-making authority in deciding “precisely what to build”. A Customer may also be a Stakeholder if they need to be consulted about decisions on precisely what to build.
Subject Matter Expert (SME) has deep knowledge of the relevant problem domain and/or technology and development practices. SMEs use their knowledge to advise other roles, “deciding precisely what to build”. They are responsible for providing the expertise other roles may need to perform their jobs. For example, a medical doctor may act as a domain expert for an organization creating electronic health records. An architect may be a technical expert in determining a solution’s technical scope and complexity.
The Rock Crusher Canvas is a tool that can help you identify your village and the roles individuals play. The simple truth is that whether you acknowledge it or not, the village is there. Acknowledging its existence and the roles individuals play now opens the opportunity for systematic experimentation and improvement of our practices. Ignoring the village means our success strategy is based on hope and ad hoc heroics.
If you want to learn more about the Rock Crusher, you can order a copy of our book from the IIBA Bookstore.
[1] https://krs.co.za/musings/product-owner-unicorns/
[2] A. Martin, R. Biddle and J. Noble, “The XP customer role in practice: three studies,” Agile Development Conference, Salt Lake City, UT, USA, 2004, pp. 42-54, doi: 10.1109/ADEVC.2004.23.
[3] Kelly, A. (2019). The Art of Agile Product Ownership. Apress