10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Can Product Owner and Scrum Master be Combined?
Posted by Mark Levison on Dec 11, 2008
Many short staffed teams or small organizations consider combining the role of Scrum Master (SM) and Product Owner (PO) into one person. Is it advisable? Have other people done it? What are the options?
According to Mike Cohn, author of Agile Estimating and Planning, the Scrum Master is:
...responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster protects the team by making sure they do not overcommit themselves to what they can achieve during a sprint. The ScrumMaster facilitates the daily scrum and becomes responsible for removing any obstacles that are brought up by the team during those meetings. The ScrumMaster role is typically filled by a project manager or a technical team leader but can be anyone.
In addition, the Scrum Master owns quality on behalf of the team.
Whereas the Product Owner is:
... (typically someone from a Marketing role or a key user in internal development) prioritizes the Product Backlog. The Scrum Team looks at the prioritized Product Backlog and slices off the top priority items and commits to completing them during a sprint. These items become the Sprint Backlog. In return for their commitment to completing the selected tasks (which, by definition, are the most important to the product owner), the product owner commits that he or she will not throw new requirements at the team during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint. Once the team starts on a sprint it remains maniacally focused on the goal of that sprint.
As Matt Gelbwaks pointed out, the Product owner is responsible for concepts and ideas (i.e. the backlog), while Scrum Master is responsible for execution and quality, so the Product Owner wants more features while Scrum Master is focusing on getting it done. Tomek Wlodarek explains that the different points of view are only half the problem. The other half is the time commitment: "In a corporate environment what I learnt is that a SM is a full time job for a team as big as 5-6 people. ... the PO role for that team turned out to be 60% - 100% job."
Dan Rawsthorne, Coach with Danube Technologies, wrote:
I've done it, back in the day before I knew any better. ... I combined the PO, SM, and Lead Designer roles. In order to keep my team self-organized, I used to have skits in front of them: "on this hand... on the other hand... what should I do?" It worked out, but was very difficult, and I never want to do it again, and I don't want anybody else to try it either.
Tom Mellor has also seen it work once, noting that it took a rather unique individual who is coaching full time now.
Steve Eichert, had the most optimistic answer saying "Assuming a single person is able to fill both of these roles by not mixing and matching it seems feasible that they could be done by a single person if absolutely required.". However, even he recommends keeping them separate.
Finally Ken Schwaber noted (in a CSM class) that experienced Scrum Master could pinch hit for the Product Owner until a proper one has been identified and trained.
- This article is part of a featured topic series on Agile Techniques and also Agile
- See more Agile Techniques content at: http://www.infoq.com/agile_techniques
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Transforming Software Delivery: An IBM Rational Case Study
Agile Development: A Manager's Roadmap for Success
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Can Versus Should
by
Lukas Bradley
Posted
Re: Can Versus Should
by
Mark Levison
Posted
PO's by the dozen
by
Will Read
Posted
Re: PO's by the dozen
by
Mark Levison
Posted
in certain situations, yes
by
Jason Little
Posted
Re: in certain situations, yes
by
Mark Levison
Posted
Unless your Steve Jobs...
by
Mike Bria
Posted
Re: Unless your Steve Jobs...
by
Mark Levison
Posted
Devil's Advocate...
by
Kevin E. Schlabach
Posted
Re: Devil's Advocate...
by
Mike Bria
Posted
Re: Devil's Advocate...
by
Matt (AgileMan) Holmes
Posted
Scrum Master should not "own quality"
by
Lasse Koskela
Posted
Re: Scrum Master should not
by
Mark Levison
Posted
Don't Use Scrum If You Do Not Have The People
by
Sebastian Kübeck
Posted
Re: Don't Use Scrum If You Do Not Have The People
by
Mark Levison
Posted
Too Much Time, Yes, Opposed Interests, Hopefully No
by
Richard Lawrence
Posted
Re: Too Much Time, Yes, Opposed Interests, Hopefully No
by
Mark Levison
Posted
Product Owner role trivialized
by
Ken Schwaber
Posted
-
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'd certainly never agree to work in an environment like that, again... and I wouldn't recommend it for anyone else, either! -
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
18 comments
Watch Thread Reply