contact@lookforwardconsulting.com
|
01-858-349-5525Class Registration
Combining Scrum Roles
Comments : 5
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.
I agree these roles are very separate, but I disagree with your reasoning. A PO and/or SM need not be a full-time job. This depends on the context.
My main objection to combining them is the resultant loss of the creative tension that these opposing roles generate. The PO has a business-health focus, the SM a team-health focus. Both can’t be satisfied fully all the time, and the dialogs created by the tension will surface the organizational dysfunction. If the SM is the PO which end of the rope will be let go first? You guessed it 🙂
It is not clear to me where I lost you in my reasoning since I agree with everything in your comment. It seems like we used different reasoning to reach the same conclusion or is there something more here?
Your focus in this piece was the amount of work each (role) has to do. I claim that isn’t the only, or the best reason to keep roles separate. The resulting loss of creative tension when roles are combined is the reason to keep roles separate. I don’t see that mentioned in the post.
OIC now – in my mind I make that distinction and you are right that it is not in this posting…and I think I just made that distinction in the last post on Scrum roles. Thank you for adding that texture and I completely agree with you.
I went back and read the previous post. Yes, the idea of tension is very clearly expressed there. Thanks. And I guess I need to pay closer attention to your blog 😉