I recently reflected on SCRUM and the role of the ScrumMaster. We know that a ScrumMaster should act as a servant-leader; she should provide guidance but not decisions, removing impediments yet empowering the team: in a word, the ScrumMaster should act as a facilitator within the team, shielding the team from the outside world, ensuring that the team follows SCRUM best practices.
We are also told that a SCRUM team should not elect a technical lead, since everyone in the team (with the exception of the ScrumMaster and Product Owner) should have the same responsibilites.
First, I think that no matter what SCRUM says, in any team at least one technical leader is destined to emerge; this happened in every single team I worked in. There is always someone who naturally takes the technical leadership and to whom team members look up to for decisions; I think it is right that this person(s) shoudl lead the team. This cleary contradicts what SCRUM tells us and therefore I simply believe that in this respect SCRUM has got it all wrong.
Secondly I think that, with the exception of teams approaching Agile and SCRUM for the first time and which would benefit from a ScrumMaster / Agile coach, the figure of ScrumMaster is unnecessary; I believe that experienced Agile teams know very well how to use Agile (SCRUM) tools and don't need a facilitator to tell them what to do. Sprints, TDD, pair programming, retrospectives, team responsibility, etc. are all normal capabilities of an experienced Agile team.
What is a servant-leader anyway? Look but don't touch? Touch but don't taste? Taste but don't swallow? No, I think that the old nice concept of team lead / technical lead still holds true for most of the situations I worked with and that this represents a natural evolution of any team.
We should delegate to the team the role of self-organising Sprints, removing impediments (more of a lean approach if you wish), grooming the burnup or burndown, run retrospectives, etc. I think the concept of a ScrumMaster goes very much in the direction of a Marketing campaign, where the typical consultant was suddendly able to re-sell herself as ScrumMaster, as an Agile coach, as a facilitator.
Software engineering doesn't need grey figures, which are there but whose presence can't be felt, who take responsibility for only part of what the team delivers (e.g. the observation of SCRUM practices, the removal of impediments, etc). We need people who can act throughout the whole project lifecycle, who can take decisions front-to-back, who can take the responsibility of driving the team towards a clear direction even when the team thinks the direction should be another...We need leaders, not marketing campaigns and labels.