Can The Scrum Master and Product Owner Be The Same Person?

I recently asked my LinkedIn connections if the Product Owner (PO) and Scrum Master (SM) can be the same person. To say it caused a debate is an understatement – I’m still getting messages now. The conversation that ensued showed some awesome ways of thinking when it comes to the Scrum framework and Agile methodologies.

I asked the question because – as practitioners – our role is to challenge convention. We iterate ways of working to deliver incremental increases in design quality. While I anticipated the response, it was the reasoning that brought the conversation to life.

The Role Of A Scrum Master vs Product Owner

Before we go any further, it’s important to be clear about the roles and responsibilities of the SM and PO. Doing this helps understand if it is possible for one person to fill both positions. According to Scrum Guide:

Product Owner

The PO is key to maximising value of the product created by the Development Team. They are responsible for managing Product Backlog including:

• Clearly defining Product Backlog items;
• Prioritising the Product Backlog to achieve the goals/mission;
• Maximising the value of work undertaken by Development Team;
• Ensuring clarity of Product Backlog;
• Defining requirements within the Product Backlog for the Development Team.

The key takeaway is responsibility. The PO is crucial to leading on these tasks and must oversee the prioritisation of the Product Backlog in a balanced position between the customer and development team.

Scrum Master

The SM sits in a central position between three competing priorities – supporting the PO, supporting the Development Team, and supporting the Organisation. SM’s implement, promote and support Scrum, to maximise value. They do this by:

• Working with the PO to clarify goals, scope and product domain while managing the Product Backlog and understanding future product requirements;
• Coaching the development team to self-organise, promote cross-functionality, facilitate Scrum events, and removing interference from the development process;
• Leading on the adoption and implementation of Scrum, creating frameworks to enhance productivity, and collaborating with other Scrum Masters in the organisation.

Within each of these abbreviated points are a much-wider range of responsibilities, one of which is knowledge – and practice – of agility. Key to everything that SM’s oversee, is the ability to iterate and improve development on a continual basis.

The Scrum Master and Product Owner Should Not Be The Same

On paper it’s clear to see how the roles are structured – and assigned – to provide separation. But the practicality of combining such roles was argued on a sliding scale. Some saying it could be – in the right circumstances – to others who responded with a downright – No!

The separate roles – and responsibilities – create an inherent tension between the two. The PO is responsible for prioritising work and directs teams to focus on completing sprint goals. The SM facilitates self-organisation within the team and protects them from interference.

If the SM and PO were the same person, it’s likely the PO role would dominate. The PO represents the interests of the customer whereby the SM represents the team. The separation offers a pragmatic argument between client expectation vs technical feasibility.

The reality is that the PO shouldn’t be involved (or care) how it is done. The PO should focus on what is done and why. The SM and their team are responsible for how things are done. Interference with this might lead to compromise (with catastrophic results for the product).

A PO sees a finished end-product, not the steps involved. They may not have oversight or familiarity of technologies to understand constraints. Combining the SM and PO biases the task and prevents independent, subjective mediation at times of divergence.

One argument is that Product Ownership is becoming diminished with a focus on backlog management. Its true position is understanding markets, testing, growth, profitability and the lifecycle. It’s unlikely you’ll get someone skilled enough to own both a PO and SM role.

Furthermore, the PO assumes many responsibilities. They are often supported by other stakeholders to develop the stories and customer journey. The added responsibility of running the Development Team can overwhelm staff and cause significant stress.

Since a Product Owner is expected to spend the majority of their time with the customer, it would be very difficult for them to devote the necessary amount of time to their team as a Scrum Master.

Finally, the SM role is vital when teams are working as part of an agile release train (ART). The SM coordinates across teams to ensure the critical success of each sprint, something PO’s are likely incapable of doing and inexperienced of managing on a large-scale.

An Argument For Combining The Roles

Despite some of the arguments, there were still situations whereby a combined role was seen to have its merits. Primarily, this focused on the skills and experience of the person involved and the size of the project, not a sweeping assumption it could be done all the time.

In a mature team, with a PO who understood enough of the Scrum framework/Agile principles, the balance of knowledge and experience could make it viable. The ideal scenario for this to occur would be when the PO has access to an Agile Coach for support.

For organisations in the early stage of agile adoption, a dedicated Scrum Master – who can coach and lead – can create a culture where the team doesn’t learn to rely on one person. This makes the adoption of a combined role more pragmatic in the future.

In small to medium sized projects, the Product Owner can hold the Scrum Master role as well. As things scale, and more coordination is required between teams, you need to separate the roles on a capacity basis.

Different Perspectives On Scrum Frameworks

For the purists out there, it’s best to give them the answer they so longingly wanted to read from the beginning: If you are utilising Scrum Framework/Rules then the answer is: No, they cannot be combined and it’s not open for discussion.

If you change the framework structure, it isn’t Scrum. The rules and processes that define the framework don’t allow for the changing of roles and processes.

But I purposefully asked an open question in my original post. Once Scrum Master is mentioned, the assumption is we’re talking Scrum convention. Over the years, I’ve seen many teams start with Scrum but evolve away from the process due to its constraints.

Yet the job titles of SM and PO remain in the new approach. On paper, yes the SM role should only fit within Scrum but job titles shouldn’t be specific to frameworks. If we do that then we’re too rigid within a broader Agile methodology.

Instead of thinking: “Are we doing Scrum?” A better question is: “Are we being effective?” Individual and team reflection is intrinsic to Scrum, but it is also critical for any business or lifecycle process when you transition from being directed to being autonomous in delivery.

And context is key when we are looking at whether or not the Scrum Master and Product Owner can be the same person. Does capacity allow it? Does the person have the skills required? Will they be able to do justice to both the roles?

You should ask questions to decide whether or not they can be the same. Sometimes the decision is made for you – and you have to combine the role – but you need to be aware of the distinct skills required and how conflict presents itself and biases the situation.

If we consider the definitions, an SM provides vision and purpose, teaching and coaching. This means you have a ‘Leader’ Manager. If you have a PO and SM combined, it’s more likely you have an ‘Administrative’ Manager which prevents growth at personal and team levels.

As the old adage goes – Can a developer test their own code? Yes. Should they? Probably not. Combining roles has plenty of risk, especially in the SM/PO realm. The most significant? Losing the client because the product wasn’t developed on time or according to need.

In an ideal situation, the PO should have the skills to be a good SM, and vice versa, but the dynamic changes if one person attempts to do both jobs. In high-performance Scum Teams there’s a healthy tension between roles that results in clearly-defined end-user products.

Conclusion

As Agile practitioners we should be open-minded about how topics like this can be viewed in a rigid manner. Everything we do is about trying, learning and improving. Agile shouldn’t be dictated or driven by external opinions, rather experimented and learned.

If something improves product quality, meets customer expectations, and delivers high-performing teams, we should adopt that approach. If that means it doesn’t fit inside the label of ‘Scrum’ anymore, so be it.

We need to look past job titles and focus on agility. If we focus on creating processes that enable positive development, the purview of an agile team is to determine whether they experiment with a combined role or keep the two separate.

Personally, I don’t believe the relentless pursuit of customer value is always aligned with supporting ways of working and self organisation so – in my view – it would always be a conflict of interest to combine the two – but that’s just me.

There are exceptions to the norm, and one person could do both roles, but bear in mind that many teams split these jobs out for good reason. Combining the posts might be necessary short-term but – in reality – may not be sustainable for long periods of time.

Don’t burden one exceptional person to do two jobs below-standard. Find people willing to step-up and grow into new roles. Placing trust in your team is a great way to show leadership and you might be surprised by what they are capable of.