A common question across multiple forums is about the acceptability of combining the ScrumMaster and the Product Owner role. While most Agilists believe that these roles are like oil and water, there are situations where combining them might be inevitable.
Mike Cohn, quoted an interesting example from Harvard Business Review where Professor Hayagreeva Rao asked his students to define the job profile of a pirate ship captain. The resulting job profile had 2 major areas of responsibilities
- Star tasks–the strategic work of deciding which ships to attack, commanding the crew during battle, negotiating with other captains, and so on
- Guardian tasks–the operational work of distributing their pirate booty, settling conflict, punishing crew members, and organizing care for the wounded
According to professor Rao, it is very difficult for an individual to possess the ability to handle both the responsibilities. Star tasks involve risk taking and entrepreneurship, whereas guardian tasks involve consistency. Mike suggested that the ScrumMaster is responsible for performing the guardian tasks and the Product Owner performs the star tasks. Both the tasks are important and hence need undivided focus and attention.
Boris Gloger, listed down a series of reasons to suggest that ScrumMaster cannot be the product owner, some of them include,
- The ScrumMaster will not be able to tell himself that he does a lousy job as a Product Owner.
- The Product Owner would get no help from the ScrumMaster against the development team.
- The ScrumMaster and the Product Owner role will conflict at the idea that the team shall come up with their own technical solutions.
- The ScrumMaster would now be involved in the outcome. He would get all blame from Management in case of failure.
- Who will do the validation of the product in the Review? The ScrumMaster\Product Owner would not be independent anymore.
- The Product Owner as ScrumMaster would accept flaws in quality, because he suddenly has the power.
Ben Johnson & Geoff Watts and suggested that, in practical situations, there are several scenarios where a Scrum team member wears two hats. The most common being ScrumMaster and developer and the less common being Product Owner and Developer. The third combination, that of a ScrumMaster and a Product Owner has explicitly high potential for conflicts of interest. According too them,
This has even more explicit potential for a conflict of interests but depending on which of those hats is the more dominant we can see very different outcomes. For example, if the ScrumMaster assumes the role of Product Owner because there is nobody standing out as a real alternative from the business side, this can lead to real business priorities suffering at the expense of more technology‐focused indulgences.
However, there are examples of situations and circumstances where both the roles are combined.
Richard Lawrence quoted the Chief Engineer role in the Toyota product Development system where it is a combination of ScrumMaster and Product Owner roles. Richard suggested,
I have to wonder: Toyota is one of the best product development organizations in the world. Are Toyota’s CEs a special breed, immune to the conflicts of software teams? Do the rest of us need distinct roles to balance our selfish interests?At the very least, if we find that the interests of our POs, SMs, and teams seem to be fundamentally in conflict, we should ask why. Shouldn’t we all have the same goal: Producing valuable software now and in the future?
Likewise, on a similar discussion, previously on InfoQ, Jason Little suggested that in certain situations like having a small team, some of the Product Owner duties would fall into the ScrumMaster's lap and the team would have to live with it. Kevin E. Schlabach suggested that this arrangement should not be permanent however, it can continue for a short period of time, say one year. Ben Johnson & Geoff Watts suggested that a combination of ScrumMaster and Product Owner could work if the Product Owner is mindful of the Scrum process at all times.
Thus, there is a general consensus that Scrum does not have a ProductMaster role. There could be situations where the roles of a ScrumMaster and the Product Owner are combined for some time, however, this arrangement should be temporary and should be rectified at the first possible opportunity.
Community comments
Astounded!
by Chris Matts,
Re: Astounded!
by Vikas Hazrati,
Re: Astounded!
by Chris Matts,
Scrum is about common sense...
by Peter Stevens,
Re: Scrum is about common sense...
by Peter Stevens,
Flawed analogy
by Joe Moore,
Re: Flawed analogy
by Vikas Hazrati,
Astounded!
by Chris Matts,
Your message is awaiting moderation. Thank you for participating in the discussion.
I had to check the date to make sure this was not an April Fools post.
I had not realised that there was so much conflict on Scrum teams. That Scrum was so negative and based on a blame culture. I do not believe Scrum is like that and I do not believe it is necessary to set it up in such a manner.
If the Scrum Master and Product Owner ( Lets call them the project manager and business analyst / business investors ) are not fully alligned you have a problem. If the whole team is not fully alligned you have a problem. If you have so much conflict and lack of allignment with business objectives, then you need some conflict resolutions skills rather than split the role.
The level of quality of the application is not an IT decision, it is a business investment decision. If you are worried that the Scrum Master will focus on techy stuff instead of business priorities, then sack them now! Do not hire someone else to remind them to do their job properly.
Whether you have a seperate PM and BA or a single person doing both roles is all about context. Sometimes it makes sense to split the role. Other times it makes sense to combine the role. It depends on the individuals and the CONTEXT.
I encounter the "You can't be artistic AND a scientist" once when I was at University. It said more about the person who thought that than the many people out there who can perform both roles at the same time.
Let me check which calendar I'm using. Perhaps it is April Fool after all.
As a final thought...... context, context, context, Context!
Flawed analogy
by Joe Moore,
Your message is awaiting moderation. Thank you for participating in the discussion.
Guardian tasks are done by the First Mate and Quartermaster, not the Captain.
Re: Flawed analogy
by Vikas Hazrati,
Your message is awaiting moderation. Thank you for participating in the discussion.
True and I guess that is exactly the point. The captain and Quartermaster are different people and have different roles
Re: Astounded!
by Vikas Hazrati,
Your message is awaiting moderation. Thank you for participating in the discussion.
Chris I am trying to understand your comment. I guess you mean that depending on the context and the individual, a person could be playing both the roles. If you notice professor Rao suggested that it is "very difficult" not impossible for the same person to be in both the roles. Some people 'can' where as majority of the people who 'believe that they can' cannot.
Re: Astounded!
by Chris Matts,
Your message is awaiting moderation. Thank you for participating in the discussion.
Vikas
Scrum identifies two roles. People are now making the statement that it is better to have two different people performing these two roles. It is all down to context. The individuals involved and demands of the project.
Most people find it hard to be a star gazer and a guardian. Most IT people I know are not "most people". Most IT people I know are highly intelligent and are able to flip between strategic and tactical very easily. I know many people who can easily take on both roles. When RAO was making his statement, was he considering the highly able individuals hired in IT or was he talking about the general masses?
What really bothered me was the idea that there is meant to be conflict between the Scrum Master and the Product Owner. I think it is wrong to build this conflict into a process. There should be no conflict. The idea that the Product Owner focuses on business value and the Scrum Master is focusing on software quality is just plain wrong, and is not what happens on projects I've worked on.
The Scrum Master and Product Owner should have a common goal..... Delivering value to the business. Sometimes that involves improving the quality of the code sometimes it involves going as fast as possible and the code quality may suffer. If your Scrum Master cannot accept that, then sack them.
Chris
P.S. Just look at these statements that you found to justify splitting the role...
* The ScrumMaster will not be able to tell himself that he does a lousy job as a Product Owner. <- Conflict and blame culture.
* The Product Owner would get no help from the ScrumMaster against the development team. <- Conflict - Team and SM
* The ScrumMaster and the Product Owner role will conflict at the idea that the team shall come up with their own technical solutions. <- conflict
* The ScrumMaster would now be involved in the outcome. He would get all blame from Management in case of failure. <- Blame culture assumed. Conflict between project and management.
* Who will do the validation of the product in the Review? The ScrumMaster\Product Owner would not be independent anymore. <- The business users? Independent testers.
* The Product Owner as ScrumMaster would accept flaws in quality, because he suddenly has the power. <- Power corrupts and absolute power corrupts absolutely! Why would they accept flaws in quality?
Its all about conflict, blame and negatives.
Scrum is about common sense...
by Peter Stevens,
Your message is awaiting moderation. Thank you for participating in the discussion.
in organizations where common sense doesn't seem to apply. In government, we have separation of powers to ensure that one branch does not become too powerful or that government as a whole not become too powerful over the people. Governments have separation of powers are susceptible to imbalances and dysfunction (even those that do have checks and balances are sometimes challenged!). The temptations of power overcome the principles of common sense.
Companies generally do not have a concept of separation of powers; they have management hierarchies. Some companies are either small enough or sensible enough to ensure that common sense prevails, communication happens and information flows (as I understand it, Toyota has a strong 'bad news first' culture). Such companies do not need the separation of powers and can relax those rules of Scrum.
For the remaining companies, the ones who need Scrum, the rules of Scrum exist to help companies overcome their own dysfunction. Separation of powers is an established practice for dealing with potential power struggles. That is implemented by the three roles of Scrum: Product Owner (Voice of Customer), Team (Voice of the Doers), and ScrumMaster (Voice of Common Sense).
Re: Scrum is about common sense...
by Peter Stevens,
Your message is awaiting moderation. Thank you for participating in the discussion.
that last message was a bit garbled (dangerous to comment too early in the morning. Let's try again:
Scrum is about common sense... in organizations where common sense doesn't seem to apply. In government, we have separation of powers to ensure that one branch does not become too powerful over the others or that government as a whole not become too powerful over the people. Governments without separation of powers are particularly susceptible to imbalances and dysfunction (even those that do have checks and balances are sometimes challenged!). The temptations of power overcome the principles of common sense.
Companies generally do not have a concept of separation of powers; they have management hierarchies. Some companies are either small enough or sensible enough to ensure that common sense prevails, communication happens and information flows. For example (as I understand it), Toyota has a strong 'bad news first' culture). Such companies do not need the separation of powers and can relax those rules of Scrum.
For the remaining companies, the ones who need Scrum, the rules of Scrum exist to help companies overcome their own dysfunction. Separation of powers is an established practice for dealing with potential power struggles. That is implemented by the three roles of Scrum: Product Owner (Voice of Customer), Team (Voice of the Doers), and ScrumMaster (Voice of Common Sense). So Scrum does not cause the dysfunction, but helps companies address and correct their dysfunction.