“Can the Scrum Master also be the Product Owner?”
This is a common question in my Professional Scrum classes. The topic of combining Scrum roles often comes up early when we are still learning the basics of the Scrum framework. It comes up because people are already wearing two hats or are being told that they will be.
The short answer is: Scrum does not have a rule against fulfilling multiple roles. This is left up to you to decide what is best in your context.
The longer discussion involves answering the question: Should you and can you combine these roles?
There are 4 questions I suggest to help people have a conversation to explore this topic in their own context.
First, let’s get clear on the accountabilities.
Specific skills and knowledge are required to fulfill both of these roles. Do they have the skills and knowledge? Do they have experience in both areas? Will they be supported in fulfilling both roles?
And do they have the time? In my experience, this is often a huge challenge. There is a lot that goes into understanding and growing product value, from getting to know stakeholder needs and markets to measuring product value.
There is also a lot that goes into helping a team grow a strong identity and effectively leverage and improve their processes, tools, and interactions.
When someone is expected to split their time, that leads to the next discussion.
While all of the Scrum values are equally important, focus and respect are the ones I see get challenged the most when someone is asked to fulfill multiple roles (especially when those roles can conflict at times).
People can find ways to schedule their days, delegate effectively, and pass on more knowledge and empowerment to others to create more focus for themselves. But the topic does need to be addressed openly. These things take time to unfold effectively and will evolve as the team, the product, and the organization change.
And what happens when there are critical issues to be addressed that impact both accountabilities? For example, there is an urgent impediment preventing the Developers from achieving the Sprint Goal. And there is an urgent decision to make that impacts product value. Often, people have a preference in which role they are more skilled or more comfortable. This will often drive how they prioritize where they focus. It is important to have awareness to this bias so that people can make better choices when put in difficult situations.
Also, it is important to ensure that all Scrum roles are equally respected. If the organization treats Product Owners as “order takers,” then that will likely affect how focus is split and what activities are prioritized. The same is true if the organization treats Scrum Masters as “team admins” or “event facilitators.”
The Product Owner and the Scrum Master is the role combination I have the strongest opinion about. It’s the one I warn most strongly against. There is an inherent tension between the role of the Product Owner (owns value) and the role of the Developers (own quality). The Scrum Master looks after the overall health of the team and the empirical process.
If the Scrum Master is also the Product Owner, what happens when this tension becomes unhealthy?
Who protects the Scrum Team? Who protects the health of the empirical process? Who helps the Product Owner understand how to better collaborate with the Developers? Who helps the Developers understand how to better collaborate with the Product Owner?
These complexities can be addressed, but only if there is enough trust to ensure transparency to these issues.
Is there trust between the person and the organization? Is there trust between the person and the Developers? Can we enter into healthy conflict?
The discussions of these 3 questions ultimately help us answer the next question.
If it is simply to save money and/or because one role is not viewed as equal in importance, this is pointing you towards the underlying problems to address. Hopefully, the discussions leading up to this have helped you clarify misunderstandings and create alignment on what is important to the product and the organization.
If you have uncovered other reasons that feel valid and important, then perhaps combining the roles does make sense in your context and is worth trying. Be sure to frequently discuss how this is working. Sprint Retrospectives are a great opportunity for a full Scrum Team discussion. Be sure to also engage with stakeholders and managers to get their perspectives.
So beyond the exploration offered above, what is my advice?
When I get towards the end of class, I ask students how they feel about this question now. And most of them agree that in their situation it is likely to create (or already causing) problems. My advice is to do what you can to set individuals and Scrum Teams up for success.
AGILE SOCKS is a registered trademark of Agile Socks LLC. Other marks used herein are the property of their respective owners. For more information see Trademark Notice in Terms & Conditions.