“You can roll out Scrum with one of your teams,” my manager said. My eyes widened, and I felt happy. After months of persistence and nagging to convince her allowing one of my teams to adopt Scrum, I finally received the go-ahead.
“But, there is one important condition,” she continued, “You can’t hire a Scrum Master or appoint anyone the role of Scrum Master. We want our developers to code. Being a Scrum Master would be too distracting for them. I don’t believe in Scrum yet. I’m sure as hell not going to allocate any budget to hire a Scrum Master until you prove it works.”
My initial happiness was replaced with disappointment. I did my best to not show it. For a split second, I thought about telling my manager that having a Scrum Master was essential for Scrum to work. But I decided it was better to remain silent. Being able to adopt an impaired version of Scrum was already a big win, and I was not willing to risk that.
You now know the story how I ended up in the unenvious position of being a Product Owner and Scrum Master at the same time, for the same Scrum Teams.
Was this exactly what I wanted? No. But sometimes you gotta make it work.
I have the questionable experience of having performed the dual role of Product Owner and Scrum Master for many years. I want to preface my experience by saying: I don’t recommend anyone to perform these two roles at the same time.
Especially with multiple teams, it is the definition of insanity. You will never have sufficient time to perform both roles with success and to your own satisfaction.
Whatever doesn’t kill you makes you stronger… or so they say.
Many believe the dual role setup would never be effective. The main reasoning supporting this belief surprised me. It wasn’t a lack of knowledge or lack of time to do both roles. The biggest critics maintained Product Owners and Scrum Masters must be structural, opposing forces for Scrum to be successful
The belief underpinning these viewpoints is that doing Scrum and delivering value are diametrically opposing goals. The Product Owner monomaniacally focuses on delivering value, and the Scrum Master cares about Scrum and the team.
By putting both roles in a single person, you will be missing out on essential and fruitful friction between these roles. The expectation was also that the Development Team would end up being miserable, as there would be no one that can keep the pushy Product Owner in check.
This necessary systemic conflict between roles is absolutely untrue. And to me, this indicates a poor understanding of Scrum. But I’m glad I juggled both roles for a while, as I can now share a unique perspective on the amount of conflict between the two roles.
Let’s grab the Scrum Guide to refresh our memories on the Product Owner role, Scrum Master role, and Scrum framework.
The primary duty of the Product Owner:
“The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” — Scrum Guide, Nov 2017
The main responsibility of the Scrum Master:
“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide” — Scrum Guide, Nov 2017
Here’s the definition of Scrum:
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. — Scrum Guide, Nov 2017
The Scrum Master promotes and supports Scrum, to deliver on the promise of delivering products of the highest possible value. The Product Owner is responsible for maximizing the value of the product.
When reading these sentences, does it seem like the Scrum Master and Product Owner should be, by definition, at odds with each other?
The Product Owner, Scrum Master, and Development Team all share the same goal of delivering products of the highest possible value. Even though they play different roles, the ultimate goal is the same.
Delivering products of the highest possible value is the purpose of Scrum. If there ever is a conflict between following Scrum by the book or delivering value, then delivering value should win.
I agree with the sentiment that constructive friction is necessary to deliver the best results. But this creative tension applies for each member of the Scrum Team, regardless of the role. This does not translate to a compulsory unavoidable conflict between the Product Owner and Scrum Master.
No, the roles don’t have a conflict of interest. But when you wear two hats you can’t always act the right way to do justice to both roles. These are moments when normally there would be some friction between the Product Owner and Scrum Master. Friction is something else than having structural conflict by design.
Scrum exists to serve the delivery of value. Both Product Owners and Scrum Masters have this same interest in mind. The roles have quite a significant overlap in skills and capabilities, but there are also significant differences.
Similarities between Product Owners and Scrum Masters
Product Owners and Scrum Masters are both servant leaders who need to influence without authority to nudge the team in the right direction. Usually, nobody in the Scrum Team reports to either the Product Owner or Scrum Master. The Scrum Master is an expert in Scrum and teaching others about Scrum. The Product Owner is a Product Management specialist with a deep understanding of the business.
Both the Scrum Master and Product Owner role require strong soft skills: persuasion, situational leadership, ability to listen, and communicating at all levels in the organization. If someone is interested in switching between roles, from a soft skills perspective the two roles don’t have significant differences.
Both the Product Owner and the Scrum Master should always care about the team. An unhappy team will never give their best performance, which will have a negative impact on value. There is zero incentive for me to push a team over the edge in either role. I adopt the servant leader stance in both roles, asking for their opinion, and trying to involve them as much as possible in decision-making.
Differences between Product Owners and Scrum Masters
Stakeholder management is a particular type of influencing that Scrum Masters usually don’t have a lot of experience with. Influencing stakeholders is not something that comes naturally to most people. Mastering the art of saying “No” while everybody remains happy is not an easy feat. Only through years of practice can you perfect the dark art pleasing people while not doing what they want.
The Scrum Master role requires way more patience than the Product Owner role. A Product Owner wants to move quickly and deliver results. As a Scrum Master, if you want to transform an organization or a team, forget about moving fast.
Scrum Masters need to take it one step at a time, meet the team where they are, and help them take the next best possible step. Likely they’ll fail, and you’ll need to pick them up so they can try again.
Making progress with your team as a Scrum Master resembles emptying a bottle a of ketchup: at times a lot comes out, and sometimes little to nothing. Not everyone has enough patience to deal with this.
To me, this is actually the biggest reason it is hard to find a person who is equally adept at being a Product Owner and a Scrum Master. It’s hard to find someone equally comfortable with switching between the patient and results-oriented stances.
In the role of Product Owner I sometimes have to make a final call the team doesn’t agree with. But then I’ll discuss it together and explain why I’m making the decision. There still might be disagreement, but I will then try to get the team to disagree and commit. In the Scrum Master role, I try to grant them more trust so they can make their own mistakes and lean from them.
Mike Cohn wrote a great article where he says Batman would be the perfect Scrum Master. The relationship between Product Owner and Scrum Master should be like Batman and Robin: both working together as a strong team towards the same goals.
The Scrum Master role has Scrum in mind, and Scrum focuses on delivering value. The Product Owner and Scrum Master need to have a close relationship together if you want to get the most out of your team. There should be no opposing goals, as Scrum exists to serve the delivery of value. We’re all on the same team, and it doesn’t help if we’re each going in a different direction.
As a Product Owner, you should always keep the team in mind. Bullying your team only gets you somewhere in the short-term, and becomes destructive quickly. As a Product Owner, you should help your Scrum Team understand the customers and the business as much as possible. This empowers your team to come up with solutions that are better than what you can devise on your own.
Scrum should rarely be the main topic of conversation. We should spend most of our time talking about the following question: how can we make sure we’re delivering value to our customers and the business?
This question is especially important because Scrum is a process framework. What the Scrum framework doesn’t provide — what you need to add yourself — plays a crucial role in Scrum’s ability to help deliver products of the highest possible value.
What Scrum doesn’t tell and leaves up to the Scrum Team to figure out, that’s where the magic happens to deliver valuable products.
Special thanks to Todd Lankford for all the excellent suggestions.