I was checking my Twitter account yesterday and saw that Mike Cohn had posted a piece about roles.  Mike compared scrum’s product owner and scrum master roles saying that one is more suitable to guardian tasks and the other to star tasks.  According to Rao, who carried out research recently, most people are good at one sort of task or the other, rarely is anyone good at both.

1. Being a product owner and a scrum master are very involved roles.  As Mike points out in the comments, they need care and attention to be done properly, so a multi-task may be acceptable but certainly not desirable.


2. Establishing one person in one or more serious roles places a lot of power in that one person’s hands.  As new information or ideas, ‘foreign elements’, enter a work eco-system, the most powerful people will strongly resist; they have an emotional reason to maintain the status quo.  Any threats to existing power structures are dealt with firmly and often viscously.  ^{Don't take my word for it!  The other day, see references, I saw a good introduction to Satir's model.  But Kotter's Leading Change offers something too.} Power structures must remain flexible and this can be achieved by rotating roles, keeping them separate, focusing on reflection, so retrospectives are important, and there must be career paths and rewards for company instead of personal growth.  ^{Misaligned goals are known as 'perverse'.  Rao touch on this too, 'such as hiring the wrong people for the wrong reasons or creating perverse incentives'.  I would recomend reading this paper and then Mike's.} It’s not easy to keep power structures flexible.

Finally, roles can be dangerous.  Roles are a form of stereotyping, if a product owner is a ‘risk taker’ because Rao and Cohn say so, then a person, like a typecast actor, may never rotate out of their job; what people think of them may keep them trapped.  As we’ve seen above, people staying in a role for too long will create an attachment to a power structure.  This won’t do when things need to change.  So, although people are attracted to jobs/tasks they do well, there is a business case that they should be rotated every now and then.  (And, of course, rotation requires retraining or coaching, so it’s not the soft option, which is often why we don’t take it.  That’s a mistake.)

I had a client once who did a workshop that stereotyped each employee according to a specific profile (green, red, blue).  After the workshop the colours were used as excuses for what was inexcusable behaviour.  ‘Oh, don’t mind so-and-so, he’s so red’.  ‘Well, did you expect him to communicate well, he’s green’.  The good engineer and manager seek to rise above their nature, so, yes, I do expect ‘green’ people to communicate well in spite of any natural deficiencies.  This is the danger of roles, of the super programmer, the genius quant, the pit-bull manager.

In summary, use roles to help design your team (or pirate ship) and your responsibilities (and heed Rao's advice, link below).  But, go deeper, and approach roles mindfully: they can, and will, be misused as tools of apology and coercion.

Thanks to Mike Cohn for bringing this study to the community’s attention.

References
Cohn, M (2010) 'Avast Combining the ScrumMaster and Product Owner, Matey!'.  Mountain Goat Software.  Available at: http://blog.mountaingoatsoftware.com/avast-combining-the-scrummaster-and-product-owner-matey/.

Rao, Hayagreeva (2010) 'Column: What 17th-Century Pirates Can Teach Us About Job Design'.  Harvard Business Review.  Available from: http://hbr.org/2010/10/column-what-17th-century-pirates-can-teach-us-about-job-design/ar/1.

Smith, Steven (2010) 'The Satir Change Model'.  Steven Smith.  Available from: http://stevenmsmith.com/ar-satir-change-model/.

Add comment