Can Product Owner and Scrum Master be Combined?

Just because you can do something doesn't mean you should. I strongly feel these two roles should be separated. Too often in my experience these roles are combined (whether in an Agile process or not), and one or both functions suffers.

Furthermore, I feel as if the two ideals presented (quality and concept) do clash at times, and it takes two representative positions to champion each.

If a small team can't afford both, I can understand the need to combine the roles. It should be noted this action creates great risk to the project as a whole, in my humble opinion.

Coming from an organization of 25 and a development team of 6 we had one person who played both parts of SM and PO. He was SM first and PO only because we had a half dozen people from sales, to customer support, to marketing, to technology with strong opinions about what was high priority, and so our SM because the defacto PO as well.

It worked better than those six people trying to go directly to a team of 6, but I would also agree that something was lost. As Dan Rawsthorne points out, the two positions are designed to oppose each other. The struggle between the two, assuming it remains a productive struggle, results in the right features being done on a schedule that is realistic for the team. Combining the two roles into one person seems like it would create enough internal struggle that it becomes easy to resort to apathy or just burn out.

Obviously it's best to have a dedicated product owner as there is much more to product management as a whole than what the scope of the product owner is by definition.

In smaller organizations you might not have much of a choice but to have them as one role or at least have some PO duties fall into the SM's lap. I think it is possible with smaller teams but I do agree a PO role should be 100% of 1 person's time.

Sure, in the rarest corners of the earth exist a human in a situation who can effectively set the strategy & creative direction whilst still having active, tangible involvement in driving the day-to-day execution activities...but good luck finding that.

In all but the rarest situations, having a single person fill both these roles is as destined for problems as having your offensive coordinator be your quarterback.

Hell, even if ya got a Steve Jobs situation, both roles simply take too much hands-on time (to do well) to be handled by a single chap, as Wlodarek astutely notes.

I think they should be separate roles... but...

You create a start-up... you hire 5 great agile developers. You run...

Guess what, you are probably the CEO, PO, and SCM all at once until that situation grows a bit.

My point? In small enough environments, it can be a practical solution for a short window of time (1 year).

Okay, in a company small enough with a product embryonic enough where "everyone is everyone", it may work. Still prolly a risky endeavor.

We tried the combined PO/SM role in our organization and got just about exactly the results that you'd expect:

• - those stretched-thin individuals focused more on their PO duties than their SM ones, to the detriment of the development teams who needed coaching
• - whenever schedule pressures were brought to bear by our executives, owners or customers, the PO/SMs would transfer those demands directly onto the teams, rather than either shielding them or working to arrive at reasonable trade-offs
• - an "us vs them" divide opened up because the development teams felt betrayed by being told one thing (that the SM was there to help and protect them, as well as hold them accountable) and then shown something entirely different (pressure to commit to unachievable deliverables and then blame when failure ensued)

I disagree with the notion that the Scrum Master "owns quality on behalf of the team." Okay, the main disagreement might be due to wording of "owning" quality - maybe the intent here was to say that the Scrum Master is responsible for pointing out if the team is cutting too many corners. In any case, I believe it should not be the Scrum Master who is responsible for the quality of the code the team produces. People should eat their own dog food, not their neighbor's.

It is necessary to have a minimum number of people around to establish Scrum. I don't think that it makes any sense to combine the role of the scrum master and product owner as you do not combine the role of speaker and prime minister in any parliament. You could do that for a short initial period until the product owner is trained to do her job. In very small teams, you can implement the Tracer Bullet process (from Andy Hunt and Dave Thomas) described in "Ship It!".

Ok we're in agreement, responsible would have been a better choice of words on my part. Nonetheless the key here is that there is a tension between the role of Scrum Master and Product Owner.

Sebastian agreed - but at the end of the day, it may not be Scrum but the issue would still rear its ugly head in agile process.

I think we're in agreement here. The key point is to understand the risk and compromise involved. At least if you go in with your eyes open and question yourself constantly then you will know when you've found some rocky shoals.

Will - was there a medium/long term plan to separate the roles?

Aside from all the other issues I would eventually expect the PO/SM to burn out. There is just too much work.

Among other things you can't afford to lose that person and the workload will eventually take a toll on their health (look at Jobs).

Thanks for consolidating these quotes and links in one place, Mark.

As a practical matter, both the SM and PO roles may be too time-consuming to combine. But the claim that I often hear that the SM and PO interests are opposed and that the dialectical struggle between them produces better software worries me. If the SM and PO don't have the same interests, that to me is a sign of a deeper problem, and better software would result from aligning those interests. I posted on this a few weeks ago here: www.richardlawrence.info/2008/11/26/are-the-pro....

I agree with the point, but I think the tension happens in real life. Product Owners are human and some will want more features in trade for quality. Sometimes they won't even realize that's what they're asking for.

All too often, the product managers are opting out of being Product Owner, and letting the analyst be a "proxy." Of course, since most of the descriptions of the Product Owner have him/her as an appendage to the Scrum Team. All he/she has to do is write user stories and play planning poker, with INVEST.
This delegation of product owner responsibilities continues to deep divide between development and its customers. I'm going to try to remedy it with a new product owner course that purely focuses on a Product Manager being agile. He/she can be using Scrum or any iterative incremental techniques, but the point is to be agile, value driven, and opportunistic - not to sit around and write user stories.
Ken Schwaber