“There is something you should understand about the way I work. When you need me but do not want me, then I must stay. When you want me but no longer need me, then I have to go. It’s rather sad, really, but there it is.” ~ Nanny McPhee
The same is kind of true of good ScrumMasters: a good ScrumMaster will be quite prominent when a team first starts, but hardly noticed when the team is working well.
This is quite different from the Scrum that I first started using in the mid-00s. Back then it was encouraged to have one of the team fill the role. So the devs used to take turns at being ScrumMaster, spending a proportion of their time as facilitator, deflector and problem-solver. But now it seems to be the common to hire a person whose sole role is ScrumMaster. They are experienced in using Scrum and often fill the role of coach at the same time.
It’s a fine line. I appreciate that the more time the team spends on organisation, the less time they can code, test, do analysis, etc. But if the team pushes as much as possible on to the ScrumMaster then he/she becomes a skivvy which the team relies upon. Reliance also means introducing a single point of failure; neither of which a Scrum team wants to have. A ScrumMaster performing a role that affects production is a dangerous one.
The line between ScrumMaster and coach is also a blurry one: a retrospective can be facilitated by anyone and moves the team towards self-organisation; but, for example, running a productive retrospective with well-constructed action points is a skill that few have.
Each team is different and needs different kinds of help. Will any of them ever move beyond needing coaching? No, because a different perspective and new ideas are always beneficial for self-improvement. But every team should be aiming to remove reliance on their ScrumMaster for anything that affects the day-to-day running of the team.
Pingback: Self Managing Teams – Zoë's ScrumMastery