Should the Product Owner Also Be the ScrumMaster?

Kulbhushan Sharma asks about having a single person fulfill the role of both ScrumMaster and Product Owner:

The Scrum Guide states that a person can be "Team Member" and "Scrum Master", or a "Team Member" and "Product Owner" but emphatically rules out "Scrum Master" and "Product Owner" roles by one person.

I understand that all these "role combinations" lead to one person being split between two sets of duties that are required to be performed. But why does only the "SM & PO" combination find particular mention as not acceptable?

[...] is [combining the roles] worth a try, especially in a team which does not have the luxury of specialists in each role?

"Carlton" writes a strong opinion in support of having a dedicated Product Owner:

The way I teach Scrum is that the PO is responsible for the business outcomes and the SM is responsible to ensure the process is implemented correctly and improves the flow of value. These responsibilities require very different skill sets and it is rare that all are in one person or that one person wants to learn them all. When the two are combined, one is responsible for doing the work of two people in an 8 hour day—which is then a violation of the Agile principle of sustainable pace.

[...]

It is not a luxury to ask the business to provide a representative that can make day-to-day decisions about the business priorities, is engaged with the Team and has access to important stakeholders. That is actually considered a success factor for delivering a valuable product on-time and within budget. I find if the business cannot identify a person—in Scrum they are called a Product Owner—then perhaps the project does not make business sense and should be deprioritized?

And Roy Morien adds his support:

I agree entirely with the sentiment that if the project is not important enough to have a user representative, then it is not important enough to even do.

In my prototyping days I had the experience of presenting a well developed (as in containing a lot of apparently required features) to a user, for whom the system was supposed be developed, and asking him to spend some time checking it out. He promptly informed me that it wasn't his job to check if my system was correct or not, and refused to do it. I did no further work on the project until he did give me the requested feedback, which he never did. The project slid below the waves without a murmur, and nobody missed it. I think this demonstrates the correlation between user involvement and project necessity.

Bachan Anand sees a difference in the authority wielded by the two roles:

I have found it is hard to facilitate (SM) when you are the person also responsible for priorities (Product Owner). Even if you are good at it, team members may think about your question/request as a ScrumMaster as an order/direction as a Product Owner.

Mike Cohn uses the analogy of captaining a pirate ship to explain why having one person handle both roles might not be a good idea:

In a recent issue of the Harvard Business Review (October 2010), Professor Hayagreeva Rao wrote 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:

1. star tasks—the strategic work of deciding which ships to attack, commanding the crew during battle, negotiating with other captains, and so on
2. guardian tasks—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.

[...]

So what does the decidedly non-collaborative, non-agile environment of a pirate ship have to do with whether a ScrumMaster and product owner can be combined? Well, it turns out that the product owner is largely performing star tasks and the ScrumMaster is largely performing guardian tasks. And so, for the same reason that pirate ships had separate individuals as captain and quartermaster general, our agile software development projects should have separate ScrumMasters and product owners.