Can the Scrum Master also be the Product Owner?

If you’ve experimented with scrum, you’re likely familiar with the Scrum Master and Product Owner roles. But just in case you’re not, here’s a quick breakdown: The Scrum Master is responsible for ensuring that the team follows the Scrum process, while the Product Owner ensures that the team spends time building things that bring the most value to the organization. These roles sound so deceivingly simple that sometimes a single person will try tackling both.

This can happen in a ground-up implementation of scrum when a Product Owner is never officially assigned to the team, leaving the Scrum Master to fill these responsibilities. It can also happen when the team’s Scrum Master is also an individual contributor, and simply too overwhelmed to focus on the scrum process. In these cases the Product Owner may try to step up to lead the process, in addition to their own responsibilities.Regardless of the reason, when a team attempts to combine all responsibilities into a single role, it almost never ends well. Let’s look at some of the ways this can go awry, and how to fix it.

Scenario 1: Scrum Master acts as Product Owner

Most commonly, when these roles are combined, it results in the Scrum Master also wearing the hat of Product Owner. While it sounds logical, the Scrum Master may not have access to the customers to gather valuable feedback. Without actionable feedback, the team simply breaks an un-validated product down into smaller and smaller pieces delivering each incrementally. While incremental delivery is an improvement over a single large delivery, the reality is that it’s really just a more efficient way to deliver the wrong product.

When the Scrum Master acts as Product Owner, it’s easy to miss out on a coherent vision for the team, resulting in the delivery of low-value work. This can happen when the Scrum Master, lacking customer access or a true vision for the product, simply stacks the backlog with the items they find most interesting or familiar. This results in the team dusting the app by making minor enhancements to existing features or cleaning up low-priority bugs, but not accomplishing any meaningful work. In this case, low-value shouldn’t be confused with low-quality: While the team may be producing high-quality work, it doesn’t mean it’s making a meaningful impact on the product.

Scenario 2: Product Owner acts as Scrum Master

Product Ownership is a full-time job. This means that it’s easy for responsibilities outside of this role to slip. When the Product Owner acts as a Scrum Master we usually see the less tangible pieces of the scrum process slowly start to wane. Retrospectives are often the first casualty, as their outcomes can (incorrectly) seem less relevant to a busy Product Owner. While the Product Owner may not officially cancel a Retrospective, they may view it as most relevant to the development team and, therefore, leave the scheduling to them. These meetings appear unimportant to the organization and eventually die out.

Alternatively, the symptom may not be as blatant as a missed meeting. In some cases, regular meetings will still occur but you’ll start to notice that their focus subtly changes. For instance, daily standups still occur but rather than acting as a chance for the team to plan their work for the day, they slowly morph into a status meeting in which each team member reports their progress to the Product Owner. Likewise, sprint-planning meetings will still occur, but rather than the team arriving at estimates and a sprint plan together, they may find themselves bullied into uncomfortable commitments as the result of  an overzealous Product Owner.

How to fix it

Both Scrum Master and Product Owner, for the most part, are full-time jobs. When the same person attempts to fill both roles disaster almost always ensues. In the cases where the Scrum Master is filling the Product Owner’s responsibilities, the simplest solution can be to free the individual of their Scrum Master responsibilities, allowing them to focus on the Product Owner role entirely. Many Scrum Masters eventually gravitate toward the Product Owner role and, as of late, this has become a very popular career progression for those with a taste for Product Management.

Keep in mind, however, that your team still needs a Scrum Master. This is your opportunity to identify a team member who’s up for the challenge, and coach them into their new role. If successful, you’ll have a new, dedicated Scrum Master, brought up from within the team, and a new dedicated Product Owner with a background in the scrum process. That’s a pretty big win.

In situations where the Product Owner acts as Scrum Master, the solution is to find a new Scrum Master who can dedicate time to the role. Not only does this free the Product Owner from managing the Scrum process, but it also helps create healthy tension between Scrum Masters and Product Owners. Ideally, the Scrum Master and Product Owner act as opposing forces. While the Product Owner represents the interest of the customers, the Scrum Master represents the interests of the team. When a single person tries to fill both roles, this healthy tension is lost and the fulcrum inevitably tips too far in one direction.

This is often seen when the Product Owner attempts both roles, as the fulcrum may tip toward bigger feature sets and a rush to market, which not only sacrifices the team’s investment in quality, but can also take a toll on their overall well-being. Freeing the Product Owner to focus entirely on product ownership, while allowing a completely different individual to focus on the scrum process, helps restore balance and better serves the end result.

Takeaway

There are exceptions to every rule, and it is possible for one person to serve both roles successfully. Just keep in mind that this isn’t the norm, nor should it be a long-term solution. To give your organization the best chance for success when using scrum, allow two distinct individuals to serve these roles. Even if you’re struggling to find those with the right aptitude, you’ll be better off with two people who have a passion to grow into their respective roles, rather than one exceptional individual struggling to balance both.

Want to learn more about how agile really works? Check out Jeremy’s course, Agile in the Real World, for concrete strategies on making the best agile techniques work for your team.