At some point, you've probably wondered, can the product owner and the Scrum Master be the same person? Banish that thought!
You wouldn't be the first person to try combining the Scrum Master role with the product owner role. People ask me every day if they can combine the roles of product and ScrumMaster and give both sets of responsibilities to a single person.
In general, trying to fill these two roles with one person is a very bad idea. Different individuals should fill these two roles. To see why, let's look back in history at the job of being a pirate ship captain.
The Pirates Knew: Different Skills Require Different People
Professor Hayagreeva Rao wrote in Harvard Business Review about the results of asking his MBA students to design the job of a 17th century pirate ship captain. His MBA students designed a job that lumped together two areas of responsibility:
- Star tasks: These are the strategic work of deciding which ships to attack, commanding the crew during battle, negotiating with other captains, and so on
- Guardian tasks: These are the operational work of distributing their pirate booty, settling conflict, punishing crew members, and organizing care for the wounded
The problem with this job description is that it mixes star and guardian tasks. As Professor Rao points out, there are very few individuals who excel at both types of task.
Star tasks require risk-taking and entrepreneurship, whereas guardian tasks require conscientiousness and consistency. A pirate captain good at identifying ships to attack and at leading his crew into battle would likely be bored by the administrative minutiae of the guardian tasks.
To make matters worse, Professor Rao asserts that people tend to spend most of their effort on the tasks they are good at (and presumably enjoy). My experience certainly bears this out. That means it is even harder to succeed when mixing roles that require different skills.
Pirates solved the problem by having two leaders on each ship: a captain responsible for the star tasks and a quartermaster general responsible for the guardian tasks.
4 Reasons Scrum Masters Should Not Also Be Product Owners
So what does the decidedly non-collaborative, non-agile environment of a pirate ship have to do with Scrum? Just as pirate ships had separate individuals as captain and quartermaster general, agile projects should have separate Scrum Masters and product owners. Let's look at four reasons why the product owner and Scrum Master should not be the same person.
1. Scrum Masters and Product Owners Perform Different Tasks
First, the roles of product owner and ScrumMaster have very different responsibilities (accountabilities), and therefore require very different skills. Product owners perform the star tasks of establishing a vision for a product, defining the best outcomes the product can create for its users, and defining the features that will get it there. Scrum Masters perform the guardian tasks of protecting a team from distractions and improving collaboration and focus.
That is, while a product owner is determining what to build, the ScrumMaster is helping the team work together so they can.
In many ways, this can be thought of as similar to the idea that a team’s programmer and tester should be separate. Sure, a good programmer can test and a good tester can program. But, separating those roles is usually a good idea.
2. Each Role Is a Full-Time Job on Its Own
Second, it is quite likely that being either ScrumMaster or product owner requires full- or near full-time attention. Putting one person in both roles at the same time will almost certainly shortchange one of the two.
3. Product Owners and Scrum Masters Tend to Have Different Personalities
Third, there is some overlap in the skills and personality traits that make good product owners and ScrumMasters. However, the roles are different, and it is extremely unlikely that someone will be able to excel at both, especially at the same time.
4. A Natural Tension Exists Between Product Owner and Scrum Master roles
Finally, a natural tension should exist between the product owner and Scrum Master roles. Although each is undeniably committed to the success of the product or system being developed, product owners naturally want more, more, more.
ScrumMasters, on the other hand, are more attuned to the issues that can arise from a team under undue pressure to deliver more, more, more.
When a balance exists between the roles, a product owner is free to follow their natural tendency to ask for more, safe with the assurance that the ScrumMaster will prevent pushing too hard.
Are There Ever Exceptions?
As with any rule, there are times when one person can act as a Scrum Master and product owner at the same time. I’ve encountered situations in which the ScrumMaster and product owner were the same person, and where I felt that was appropriate. Some of these have included small organizations that could not afford the luxury of dedicated or separate individuals.
Other situations were small teams who had started in the pursuit of a technical product owner’s vision. On such small teams, any one personality can have an outsized effect on the team, regardless of any formal role played by the person.
Other exceptions have been ScrumMasters involved in contract development. It is common on such a project for the “true product owner” to exist within the client asking for the software to be built. Unfortunately, it is also common for such true product owners not to want to be deeply involved in the project at the level a Scrum team needs. It is in these cases that a good ScrumMaster often steps up and into the role as a proxy for that true product owner.
And in a few special instances, I've seen someone fill both roles successfully, against all odds. Each has been an exceptional person, perhaps the Blackbeards of Scrum. However, in each case, my reaction was to think how much better the person could have done if enabled to work in only one of the roles.
So, sure there are exceptions—just like there are to any rule. However, none of those exceptions should exist for the long term. And anyone in both roles simultaneously should be aware of the challenges the dual role presents. And also should consider what they might lose in trying to fill both roles.
