This chapter is from the book
This chapter is from the book
This chapter is from the book
Common Mistakes
Applying the product owner role means entering new territory for many organizations. And the path to effective product ownership is littered with pitfalls and traps. This section will help you avoid some of the most common mistakes.
The Underpowered Product Owner
A project with an underpowered product owner is much like a car with an underpowered engine: The car runs, but it struggles when the going gets tough. An underpowered product owner lacks empowerment. There may be several causes: The product owner does not have enough management attention; the sponsorship comes from the wrong level or the wrong person; management does not fully trust the product owner or finds it difficult to delegate decision-making authority. As a consequence, the product owner struggles to do an effective job, for instance, to align the Scrum team, stakeholders, and customers or to exclude requirements from the release. A product owner of a new-product development project I worked with, for instance, had to consult his boss, the head of the line of business, for every major decision. Not surprisingly, this caused delays and eroded the team's confidence in the product owner. Ensure that the product owner is fully empowered and receives support and trust from the right person.
The Overworked Product Owner
Being overworked is not just unhealthy and unsustainable on a personal level; overworked product owners quickly become bottlenecks and limit the project's progress. Symptoms of an overworked product owner include neglecting product backlog grooming, missing sprint planning or review meetings, and not being available for questions or giving answers only after a long delay. Overworked product owners are at odds with the Agile Manifesto's concept of sustainable pace. "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely" (Beck et al. 2001).
There are two main causes of product owner overburden: not enough time to perform the role and not enough support from the team. Availability tends to be an issue when the product owner role is just one of many jobs competing for time and attention or when the product owner looks after too many products or teams. Not enough support from the team is rooted in a wrong understanding of product ownership: Even though there is one product owner, most of the product owner work is carried out collaboratively. The team and ScrumMaster must support the product owner.
To avoid an overworked product owner, try the following: First, free the individual from all other responsibilities. Start with the assumption that being a product owner is a full-time job, and that one product owner can look after only one product and one team. Second, ensure that the team makes time in every sprint to collaborate with the product owner. Scrum allocates up to 10% of the team's capacity in every sprint for supporting the product owner (Schwaber 2007). Not only does collaboration spread the work across many shoulders; it also leverages the team's collective knowledge and creativity.
The Partial Product Owner
Some organizations split the product owner role and distribute its duties across several people, for instance, by employing a product manager and a "product owner." The product manager takes care of the product marketing and product management aspects, owns the vision, is outward-facing, and keeps in touch with the market. The "product owner" is inward-facing, drives the sprints, and works with the team. In these cases, the so-called product owner is little more than a product backlog item writer. This approach reinforces old barriers, blurs responsibility and authority, and causes handoffs, delays, and other waste.
Instead of splitting the product owner role, organizations should face the challenge of applying the role properly. One person should be in charge of the strategic and the tactical product management aspects. This may well require organizational changes, including adapting job roles and career paths and developing individuals to take on a rich set of responsibilities, as discussed in Chapter 6.
The Distant Product Owner
A distant product owner works separately from the team. Distance may evoke images of a globalized world with the product owner on one continent and the team on another. But distance comes in many forms and degrees. It starts with working on the same site in different rooms, and it ends with product owner and team being separated across continents and time zones (Simons 2004). I have found recurring issues with distant product owners, including mistrust, miscommunication, misalignment, and slow progress. There is a reason: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation" (Beck et al. 2001).
Avoid distant product owners by colocating all Scrum team members. As mentioned earlier, mobile.de experienced a significant productivity and morale increase after colocating its product owner, ScrumMaster, and team. If colocation is not an option, the product owner should spend as much time as possible in the same room as the rest of the Scrum team. Remote product owners should be on-site at least for the sprint planning, the review, and the retrospective meetings. Moving from a distant to a colocated product owner often takes time. It may require hiring and training a local product owner. In some cases, it may also require rethinking the company's product strategy, including where the company develops its products.
The Proxy Product Owner
A proxy product owner is a person acting as a placeholder for the actual product owner. I have found proxy product owners used to compensate for overworked, partial, and distant product owners. At a client of mine, the vice president of product management was asked to take on the product owner role for a business-critical product. Even though he was ideally suited for the job, he struggled to spend enough time with the team. The business analyst on the team consequently stood in as a proxy product owner when the real product owner could not be there. The proxy did most of the product owner work without being empowered. The actual product owner ultimately decided about product backlog prioritization, release planning, and whether to accept or reject work results. What followed was an increase in conflicts and miscommunication, a slowdown in decision making, and a decrease in productivity and morale.
Using a proxy product owner is an attempt to superficially treat a systemic issue. Rather than employing a quick fix, organizations should address the underlying issues. This might require freeing up the product owner from other obligations; colocating the product owner, ScrumMaster, and team; or even finding a new product owner.
The Product Owner Committee
A product owner committee is a group of product owners without anyone in charge of the overall product. There is no one person guiding the group, helping to create a common goal, and facilitating decision making. A product owner committee is in danger of getting caught in endless meetings with conflicting interests and politics—something also referred to as "death by committee." No real progress is achieved; people stop collaborating and start fighting each other. Always ensure that there is one person in charge of the product, an overall or chief product owner who guides the other product owners and facilitates decision making, including product backlog prioritization and release planning.