When most members of the agile community write and talk about Scrum, they often like to stick to the ideal scenarios.
In these ideal scenarios, Product Owners tend to be fully empowered, Scrum Masters are capable of helping the team remove every impediment, and Developers are knowledgeable, disciplined, and willing to develop the product by following all of the best practices for how that should be done.
As you and I know well, that’s just theory. In practice, even the most experienced people and Scrum Teams come across bottlenecks, impediments, and constraints that are hard (and sometimes impossible) to resolve. And one of them is when there simply isn’t an option to have a dedicated person for the Scrum Master accountability.
Which leads some agilists to ask…
Can the Product Owner in a Scrum Team also be the Scrum Master?
The official Scrum Guide doesn’t explicitly rule out the possibility of the same person fulfilling the Scrum Master and Product Owner accountabilities. However, these two accountabilities are best fulfilled by two persons with different focus and skill sets.
Here’s what the 2020 Scrum Guide says about the accountabilities in a Scrum Team: “The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies.”
As you can see, though the Scrum Guide doesn’t explicitly rule out that possibility, it doesn’t necessarily call it out as acceptable either. Scrum, as its founders Jeff Sutherland and Ken Schwaber often say, is an intentionally lightweight and purposefully incomplete framework.
If you’re faced with this dilemma, it’s best to make your own conclusion based on the context of your organization, team, and the individuals in it.
My two cents?
It’s not really a good idea for the same person to have the Product Owner and Scrum Master accountabilities.
Just like any government needs to have separation of powers between its legislative, judicial, and executive branches to function democratically, a Scrum Team needs separation of accountabilities between the Product Owner, Scrum Master, and Developers to be cross-functional and self-organizing.
As the official Scrum Guide says, the Product Owner is “accountable for maximizing the value of the product resulting from the work of the Scrum Team.” The Product Owner does this by setting the Product and Sprint Goals, as well as ordering the items on the Product and Sprint Backlogs.
As Agile Coach and author Geoff Watts says in his book “Product Mastery: From Good to Great Product Ownership,” the high-performing Product Owner is DRIVEN. They are Decisive, Ruthless, Informed, Versatile, Empowering, and Negotiable.
The Scrum Master, on the other hand, “is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.”
As Watts says in his second book, “Scrum Mastery: From Good to Great Servant-Leadership,” the high-performing Scrum Master is RETRAINED. They are Resourceful, Enabling, Tactful, Respected, Alternative, Inspiring, Nurturing, Empathetic, and Disruptive.
More often than not, the DRIVEN Product Owner and the RETRAINED Scrum Master aspire, communicate, and collaborate to achieve different outcomes. A healthy conflict between the two persons in that role is beneficial to any Scrum Team at an early Tuckman stage.
When a Product Owner becomes the Scrum Master (and vise-versa), the separation of accountabilities in a Scrum Team is essentially destroyed.
These two accountabilities are so different in their essence, that it’s really hard for a single person to be DRIVEN and RETRAINED at the same time—especially if they lack a theoretical understanding of and the practical experience in one of them.
Correct me in the comments below if I’m wrong and you came to read this post for a different reason, but I’m guessing that this doesn’t really solve your problem. In fact, you probably came here because your organization or team has some constraint that prevents it from hiring a dedicated Scrum Master.
What to Do When You Can’t Hire a Scrum Master
Here’s your options if, for one reason or another, your organization or Scrum Team can’t get a dedicated person for the Scrum Master accountability.
Identify the Leader Among the Developers
Most Scrum Teams have Developers of various seniority. Usually, the most senior Developer on the team plays, in one way or another, formally or informally, the role of Technical Lead for the product.
In most cases, that person will have the most experience with servant-leadership. He or she is already teaching, coaching, mentoring, and unblocking the less experienced team members, albeit focused more on technology and less on process.
Whether you’re a stakeholder (for example, a sponsor, leader, or customer/user) or member of the agile team, identifying that person will be easy and usually happens pretty fast. Make it your top priority to have a conversation with them about the need for someone to take the Scrum Master accountability—and why they are the first person to ask about it.
If you can’t immediately name that person, this means that they’re probably not a member of the team.
What should you do in that case?
Look for Interest from Less Experienced Developers
Don’t rush to name the Product Owner as Scrum Master. Instead, think about a less experienced Developer in the team who has the trust of his or her fellow team members, and who has demonstrated servant-leadership abilities before.
If you do decide to go for this option and agree with a Junior or Mid-level Developer to also become the Scrum Master, keep in mind that training and coaching are essential to their success with that accountability.
Getting that person a seat at a Certified Scrum Master (CSM) training and giving them access to an Agile Coach should be the bare minimum that your organization does to help set them up for success.
Consider Scrum Mastery on Rotation
If no one in the team is willing to take on the Scrum Master accountability, consider rotation. Every team member (Product Owner and Developers) gets to become the Scrum Master hat for one sprint, then rotates with another member of the Scrum Team.
Rotation can be highly helpful in my experience. When every member of the team acts as the Scrum Master alongside their other accountabilities for one sprint, by the time the whole team has rotated, almost everyone will have a better understanding and greater appreciation of the challenges of scrum-mastery and servant-leadership as a whole.
Rotation can also help a Developer from the Scrum Team to uncover a “hidden passion” for servant-leadership (I’ve seen that happen more than once).
If none of the three options above are, for a reason irrelevant to this post, feasible for your organization and Scrum Team, only then should you consider having the Product Owner also take on the Scrum Master accountability. As I mentioned a while ago, the potential for conflict of interest and human error is simply too big to keep this option on top of your list.
What to Do if You’re the Product Owner and Scrum Master
Okay, you got the picture. It’s not a good idea for the same person to be the Product Owner and Scrum Master in a Scrum Team.
What if, nevertheless, you are that person?
Acknowledge the situation. There’s no need to get frustrated, worried, or panicked. But you absolutely must acknowledge to yourself that you are in a complicated situation and you should be aware, conscious, and mindful.
Determine your weaker accountability. The chances are high that you’re as good at one of your accountabilities as you’d like to think. Which one is it? Are you a better Product Owner than you are a Scrum Master? Or is it the other way round?
Understand the differences between the two. Product Owners are decisive. Scrum Masters are supportive. Product Owners drive the product and maximize its value with the Increment(s) shipped in every Sprint. Scrum Masters help the team grow healthier and ship better Increment(s) in a more sustainable way.
Identify the mindsets and behaviors that can cause harm. Now that you need to balance, what mindsets and behaviors will cause more harm than good for you, the Scrum Team, and the product? What should you be extra-attentive to not do (or keep doing) to prevent yourself from abusing the power of the two accountabilities? Make a list. Keep it in your eyesight every day.
Be honest to others and stay open to feedback. When you collaborate with the Developers in the team and communicate with your stakeholders, start off your sentences with, “Putting my Scrum Master accountability on, here’s what I think about this…” to help them perceive you as objective and unbiased. Stay open to feedback in the Retrospectives; even if it’s hard to hear.
Think in dual terms. It will help you to consider the two sides of the same coin when you’re making decisions or talking to others. You’re there to maximize the value of the product that the team is building as a Product Owner. But you’re also tasked to help the team establish Scrum as described in the Scrum Guide, causing the removal of impediments to their progress and helping them—and yourself—to achieve a sustainable pace of delivery.
The Bottom Line
The official Scrum Guide doesn’t explicitly rule out the possibility of one person having the Product Owner and Scrum Master accountabilities. It doesn’t necessarily call it out as possible or endorse it, either.
As many things in agile and Scrum, it’s best to use the Scrum Guide and posts like this one as a compass that helps you find your own way. Even if you are in uncharted territory, you always have options—as long as you keep your eyes open for the best way forward.
