Combining Scrum Roles

This question started an interesting exchange on the Scrum Development list at yahoo!

The Scrum Guide states that a person can be “Team Member” and “Scrum  Master”, 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 combination” lead to one person being  split between two set of duties that are required to be performed. But  why does only the “SM & PO” combination find particular mention as  not acceptable.

The way I teach the Scrum roles is that the Product Owner is responsible for the business outcomes and the ScrumMaster 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.

IMO, I often see people wanting to combine ScrumMaster with Product Owner or as a Team member, i.e. continue as a contributor.  As a friend of mine pointed out to me, this desire to combine the roles often speaks to hidden assumption\perception that there really is not enough stuff for a fulltime ScrumMaster.  Some people look at the framework and think: “ScrumMaster facilitates some meetings (check), updates Burndown chart (check) and does self-organization (check), not enough here to justify 100% allocation.”

Oh how wrong!  Being a ScrumMaster is a full time job.  First, one has to help the Team become self-organizing.  That is a lot of work, requires close proximity to the Team and many hours of observation.  It is not something you can “phone in“.  Second, as ScrumMaster you are accountable to the stakeholders to improve the flow of value and help remove the organizational waste, i.e. impediments.  A lot of that effort is building relationships with different stakeholders and participating in efforts to remove organizational roadblocks (sometimes called kaizen).  You cannot be writing code, doing design or however you contributed in the past, if your responsible for identifying and removing impediments.