Evolution of roles
Archived from the Cranked Alliance website.
When we documented Cranked, we included just two roles:
That’s it. Just the two.
This isn’t actually very controversial; it is simply the next step in an evolution of roles – as shown in the diagram in this article (you can click through to a larger version). The essence of the diagram is that in traditional software development there were a lot of roles. In Scrum, there were three and now we have two.
This is inspired by Extreme Programming and in particular, Kent Beck’s statement:
Business people make business decisions and technical people make technical decisions.
The obvious omission in Cranked when compared to Scrum is that there is no Scrum Master role. There are some good reasons for this. Firstly, the technical team must solve problems for themselves – they are all responsible for removing blockages and sometimes, mobbing the problem is the best way to get a result. The temptation to shovel problems to a Scrum Master to unblock is replaced with the self-empowerment of knowing that you are in charge of your own destiny. No room for learned-helplessness here. Secondly, a good Scrum Master actually eliminates their role over time – so having a permanent role titled “Scrum Master” creates a natural conflict of interest as to be great you must make yourself unemployed.
There are other important differences other than the lack of a Scrum Master. The technical team is cross-functional (very much as a Scrum team should be), but the job role and ideally the job title is “Technical Team Member”. Each individual may bring discreet skills to the team, but the endgame is to share those skills with other members of the technical team. The team must build, verify and release their software – no hand-offs, no “chucking it over the wall”.
And lastly… there is one more logical step that could be taken to reduce the roles even more. We will enjoy hearing about anyone who has done this. For now though, we have found two clearly defined roles to be just right.