Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
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.
Learning to be a Good Product Owner: Foundation Skills
Technical Debt and Design Death
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:
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.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
17 comments
Watch Thread Reply