Roles at Scale: Product Owners, Managers and Teams

With one team, agile roles are fairly simple. Someone owns the product and its priorities, a small team builds it, and someone helps the team and organization improve how they work. Once five, ten or fifty teams contribute to the same product, leaders face design questions that single-team guidance does not answer. Who decides priorities across teams? Who keeps teams integrated? And what happens to the managers who used to assign the work?

The major scaling frameworks answer these questions differently, and each describes its own roles on its own official site. This guide summarizes those descriptions side by side, alongside the role guidance in the U.S. Government Accountability Office's Agile Assessment Guide (GAO-24-105506), so leaders can make deliberate choices rather than accidental ones.

It does not rank the frameworks. It focuses on the role decisions that tend to cause trouble at scale.

Start from the single-team definitions

The Scrum Guide (November 2020) defines three accountabilities: Developers, the Product Owner and the Scrum Master. It describes a Scrum Team as typically 10 or fewer people. It says the Product Owner is "one person, not a committee," and that "For Product Owners to succeed, the entire organization must respect their decisions." When a team grows too large, the guide suggests reorganizing into multiple cohesive Scrum Teams focused on the same product, sharing the same Product Goal, Product Backlog and Product Owner.

GAO's guide adds the consequences of getting product ownership wrong. Without a clearly identified product owner who is the authoritative customer representative, developers may receive conflicting priorities, which can delay high-priority features. If the product owner is not dedicated, developers may make assumptions to keep moving, and significant rework may follow. GAO also says the number of agile teams assigned to one product owner should be limited, so the product owner has time for all of the teams, stakeholders, customers and users they support.

How the frameworks scale product ownership

Each framework structures product ownership differently:

• LeSS (Large-Scale Scrum): the LeSS rules call for one Product Owner and one Product Backlog for the complete shippable product. The Product Owner focuses on prioritization, while clarification happens as much as possible directly between the teams and customers, users and other stakeholders. In very large products, LeSS Huge adds Area Product Owners for requirement areas, with one overall Product Owner responsible for product-wide prioritization.
• Nexus: the Nexus Guide describes a Nexus as a group of approximately three to nine Scrum Teams working on a single product, with a single Product Owner who manages a single Product Backlog.
• Scrum@Scale: the Scrum@Scale Guide describes a Product Owner Team for each Scrum of Scrums, guided by a Chief Product Owner who coordinates priorities. At the top, an Executive MetaScrum is the forum where leaders and stakeholders set strategic priorities with the Chief Product Owners.
• SAFe: Scaled Agile describes the Product Owner as the agile team member primarily responsible for maximizing the value the team delivers by keeping the team backlog aligned with customer and stakeholder needs. Each Product Owner is part of the larger Product Management function.

The practical decision for leaders is how much product ownership can sit with one person and how much must be shared. LeSS and Nexus keep one Product Owner for the whole product, while Scrum@Scale and SAFe add more layers of product roles. GAO accepts either pattern, noting that some organizations use multiple product owners with clear boundaries, while others use a core group of business officials with a single product owner interacting with teams. Regardless of structure, GAO says, the product owner should be empowered and their responsibilities well defined.

Who keeps the teams integrated

Coordinating many teams is a separate job from owning priorities, and the frameworks assign it explicitly:

• Nexus adds a Nexus Integration Team, accountable for ensuring that a done Integrated Increment is produced at least once a Sprint. The Product Owner, a Scrum Master and appropriate members from the Scrum Teams belong to it.
• Scrum@Scale has a Scrum of Scrums Master, accountable for ensuring the scaled events take place and for making impediments, process improvements and progress visible to the organization.
• SAFe defines the Release Train Engineer as a servant leader and coach for the Agile Release Train who facilitates its events and processes and supports teams in delivering value.
• LeSS gives Scrum Masters responsibility for a well-working LeSS adoption, with a focus on the overall organizational system rather than just one team.

Whichever model you use, make one person or group explicitly accountable for integration. GAO's guide treats frequent continuous integration as a critical success factor for large programs, and warns that teams who delay integration until just before release will likely run out of time for testing and fixing defects.

What happens to managers

Agile at scale changes management roles more than any other. LeSS's guidance on the role of the manager states that decisions about what the team works on move to the Product Owner, and decisions about how to work move to the self-managing team. It describes middle managers as capability builders who see the whole, help remove obstacles, teach problem solving and "Go See" the real work. The LeSS rules say managers are optional, and that where they exist, their focus shifts from managing day-to-day product work to improving the product development system.

Scrum@Scale gives senior leaders a defined home. Its Executive Action Team fulfills the Scrum Master accountabilities for the whole agile organization, removes impediments teams cannot remove themselves and, per the guide, the entire Scrum Master organization reports into it.

GAO notes that a large-scale transformation may require reorganization, such as realigning traditional roles with agile roles, for example program manager to product owner, and that organizations will face challenges as they train and "untrain" staff in new roles. Leaders should plan for this openly. People whose authority is changing deserve a clear account of what their new job is, not just what they are no longer allowed to do.

Design teams for stability and completeness

Roles only work if teams are built to deliver. GAO describes agile teams as usually 5 to 9 people and says teams should be cross-functional, so they need not rely on outside teams to complete their work. It also stresses team stability: frequently shifting people within or between teams can undo learning and reduce a team's ability to meet commitments.

GAO adds one public-sector rule of thumb. While agile teams may mix contractor and federal staff, GAO says it is imperative that the product owner be a federal employee, and notes that nothing in its guide suggests a product owner can take actions reserved for contracting officers.

A short role checklist for leaders

1. For each product, can everyone name the one person with final say over priorities?
2. Does that person have the time and authority to do the job, including over stakeholder requests?
3. Is someone explicitly accountable for integrating work across teams every iteration?
4. Have managers been told, specifically, what their new responsibilities are?
5. Are teams stable and cross-functional enough to finish work without hand-offs?

Key takeaways

• The Scrum Guide's "one person, not a committee" principle for the Product Owner is a useful test for any scaled structure: can everyone name who has final say?
• LeSS, Nexus, Scrum@Scale and SAFe each describe different structures for product ownership and integration; choose deliberately and document the choice.
• GAO warns that unclear or part-time product ownership causes conflicting priorities, delays and rework, and says product owners need a limited number of teams.
• Manager roles shift from directing work to building capability and removing impediments; plan the transition openly.
• Stable, cross-functional teams are the foundation every role structure depends on.

Sources

• Ken Schwaber and Jeff Sutherland, The Scrum Guide (November 2020)
• The LeSS Company, LeSS Rules
• The LeSS Company, Role of Manager
• Scrum.org, Online Nexus Guide (January 2021)
• Jeff Sutherland and Scrum Inc., The Scrum@Scale Guide, Version 2.1 (February 2022)
• Scaled Agile, Inc., Release Train Engineer
• Scaled Agile, Inc., Product Owner
• U.S. Government Accountability Office, GAO Agile Assessment Guide: Best Practices for Adoption and Implementation, GAO-24-105506 (November 28, 2023; reissued with revisions December 15, 2023)