This chapter is from the book
This chapter is from the book
This chapter is from the book
Scaling the Product Owner Role
Before I describe product ownership practices for large Scrum projects, here's a general warning: Avoid large projects. Start small and quickly develop a product with the minimum functionality, as discussed in Chapter 2. If you have to employ a large project, scale slowly and grow the project organically by adding one team at a time. Starting with too many people causes products to be overly complex, making future product updates time-consuming and expensive.6
The Chief Product Owner
Large Scrum projects consist of many small teams. Each team needs a product owner, but one product owner can look after only a limited number of teams. How many teams a single product owner can support without being overworked or neglecting some responsibilities depends on a number of factors. These include the product's newness, its complexity, and the domain knowledge of the teams. My experience suggests that a product owner usually cannot look after more than two teams in a sustainable manner. Consequently, when more than two teams are required, several product owners have to collaborate. This seems to create a dilemma: The product owner is one person, but we require several product owners on a large Scrum project. The solution is to put one person in charge of creating and implementing the product vision. In doing so, we introduce a hierarchy of collaborating product owners with an overall or chief product owner at the top—similar to chefs in a restaurant working together with one cook as the chef de cuisine, the head chef.7
The chief product owner guides the other product owners. This individual ensures that needs and requirements are consistently communicated to the various teams, and that the project-wide progress is optimized. This includes facilitating collaborative decision making as well as having the final say if no consensus can be reached. If the project grows organically by starting off with one team, the very first product owner typically becomes the chief product owner.
Product Owner Hierarchies
Product owner hierarchies vary from a small team of product owners with a chief product owner to a complex structure with several levels of collaborating product owners. Let's have a look at the two options, starting with the simpler one.
The project organization depicted in Figure 1.2 consists of three teams and three product owners. Each product owner looks after one team. The product owners form a product owner team with product owner B acting as the chief product owner. Even though there is a chief product owner, the product owner hierarchy is flat. Here is an example of how the project organization can be applied: A client of mine employs a product owner team responsible for a web portal and its applications. Four product owners and a chief product owner collaborate closely. Each product owner looks after an individual application. The chief product owner is in charge of the entire product, comprising all applications and the portal.
)
Figure 1.2 Simple product owner hierarchy
Figure 1.3 shows another option suitable for larger Scrum projects, which is based on Schwaber (2007, 70–73).
)
Figure 1.3 Complex product owner hierarchy
The project organization partially depicted in Figure 1.3 consists of four layers and nine product owners.8 Each product owner guides and assists lower-level colleagues. The top-level product owner is the chief product owner in charge of the entire development effort and is responsible for the product's success. The product owners now form a rather extensive hierarchy.
Note that a complex product owner hierarchy introduces a certain specialization of the individual product owner jobs. The chief product owner leads the overall development effort, coordinating with customers and other stakeholders. The lower-level product owners are more focused on their features or subsystems and work closely with the development teams. Schwaber (2007, 72) notes:
- The Product Owner plans, composes, distributes, and tracks work from his or her level down.... The higher the level is, the harder the Product Owner's ... job is. The responsibility of Product-level jobs usually requires someone with Vice President-level or Director-level title and authority.
Choosing the Right Product Owners
Finding the right person to fill the product owner role is challenging enough when only one product owner is needed. How do we choose the right product owners on large projects? Understanding the different ways we can structure the teams on a large project helps answer the question. There are two ways to organize teams that are creating product increments: as feature teams or as component teams (Pichler 2008, Larman and Vodde 2009). A feature team implements a cohesive set of requirements, such as one or more themes or features. The result is an executable vertical slice that cuts across major parts of the software architecture. A component team creates a component or subsystem.
Both team setups are orthogonal: Feature teams are organized around product backlog items, component teams around the software architecture. Both have advantages and disadvantages. Component teams, for instance, ensure architectural integrity and reuse. Unfortunately, they often cannot consume product backlog items expressed as user stories or use cases but instead require detailed technical requirements. In addition, they have to integrate their work results to create a product increment. Both properties create overhead. Feature teams, on the other hand, can usually work in parallel. They encounter fewer integration issues and can consume the requirements stated in the product backlog. Ensuring architectural integrity and reuse can be a challenge, though. As a rule of thumb, organizations should employ feature teams whenever possible and use component teams only if they must.
Since the product owner of a component team has to help translate product backlog items into technical requirements, the best individual to serve in that role is usually an architect or a senior developer rather than a product manager. If a project consists of three feature teams and one component team, for instance, it is likely to require three product managers and one architect to fill the product owner roles—assuming that one of the product owners is the chief product owner.