On a regular basis I see comments in forums about how in a mature agile team a Scrum Master is not needed, or how the goal of a Scrum Master is to make themselves redundant.
On some level I agree with both comments, but the thing I am curious about is just what proportion of teams are actually mature?
My experience is anecdotal and is obviously reflective of where I have worked and who I have interacted with, but I have worked on Agile projects at 5 major companies, 3 of whom are top 100 companies and 2 major government departments, these are not obscure backstreet companies these are mainstream and in some cases pioneering tech companies. But if you measure Agile maturity on a scale of 1-5 the best would rate a 2/5. They are certainly improving, they are maturing and I am proud to have been part of that process, but they are all a long way from this fabled maturity.
So you might think that the rest of the industry is better and I have just been unlucky – or maybe I am hired because they need a coach to mature. But again my experience disagrees with this, I do a lot of recruitment: in the last 12 months I have hired 14 developers/testers, and significant numbers at previous clients. I always ask about Scrum to get a feel for their experience and their attitude towards Agile delivery. I must have interviewed hundreds of candidates, and a significant number put that they are certified ScrumMasters on their CV. But overwhelmingly those that claim to come from companies where they are ‘Agile’ or use ‘Scrum’ – demonstrate what I would describe as immature Agile adoption, sometimes just paying lip service to the concept.
So many, and I mean many! Seem to think that a daily Stand-up means they are Agile, I have had some describe how they are very Agile and follow Scrum closely but go on to describe how the plan is made in advance, a lead engineer estimates and the dev manager individually tasks on a daily basis and that testing occurs in the following Sprint to development and bugfixes are dealt with the sprint after. I ask about retrospectives and I’d say that maybe 1 in 20 come from teams that hold any retrospectives and those that do describe quite varied experiences.
So for me that mature team remains a myth, something to aspire to. However, I do notice that over time my role as a an Agile Coach changes drastically, early on a lot of time is spent embedding Scrum Processes, getting the team used to a different way of working, encouraging XP practices, building confidence in the team and showing the value of retrospectives and Agile delivery. As the team evolves less time is spent on these, as a project progresses there are less impediments, but retrospectives become harder: the low hanging fruit has been dealt with and further improvements require greater insight and more skill to draw them out. This is not a bad thing and gives time to start pushing out to the rest of the organisation, or taking on a second or third team.
So do you become redundant? I don’t see it, there will always be some impediments and yes a mature team may learn to solve them by themselves but that is hardly the point, the goal is to allow the dev teams to concentrate on what brings value, and a Scrum Master can deal with many of these problems more efficiently and without distracting the frankly more valuable dev resource.
Also simply by their presence a Scrum Master acts as a counter balance to the Product Owner and the pressure to circumvent the framework. There seems to be a notion that a mature team is a team of highly skilled software developers and testers that are also interested and eager to enforce Agile principles, and again this is something I don’t see, even the mature teams and experienced agile development teams are not enthusiastic about it in the same way a Scrum Master would be. They understand the value and the importance of Agile, they are wholeheartedly behind it, but that is quite different from the enthusiasm and drive a Scrum Master usually has.
If given the option of completing a task or attending a meeting, many developers would drop the scrum framework in a flash (“just this once”) or extend a sprint to complete a story (“just this once”). It is also hard to see fault in yourself, and sometimes it takes an observer to reflect your behaviours back at you in a way to enable you to improve.
Metrics can be useful but they can take time and effort to produce effectively, and yes a developer or product owner could do it, but again this is something that a Scrum Master is likely better at and again the developers’ time is more valuable writing code.
Finally, new projects/product increments start and this creates a flurry of impediments, there will be turnover in the team and new staff will need to be hired and integrated into the team, a team may expand or another team needed and all of this runs far smoother with a Scrum Master. When you scale to having multiple teams working together the need for a Scrum Master becomes even greater.
In my opinion, for a new team on a new project a Scrum Master will be very, very busy, but over time as the teams settle and mature I see no reason why a Scrum Master couldn’t support 2 or 3 or in some cases even 4 development teams – assuming they are all located in the same room.
But the prospect of a team or teams without a Scrum Master at all causes me concern as it exposes them to internal and external pressure to compromise Agile principles. And unless there is an enthusiastic team member you are in danger of regressing and whilst you can certainly manage without a Scrum Master, our goal is not to ‘manage’ or ‘get by’ it is to be high performing and efficient. If the team(s) gets more value from having a Scrum Master than they cost it should not be a difficult choice.
And if you truly want to be Agile, having an expert around to help and to coach would be high on my list of factors that can determine success or failure of a project.
I personally see huge value in having Scrum Masters and Agile Coaches, maybe not 1:1 with teams, but I question your commitment to Agile if you feel you don’t need them at all.
We all still have more to learn, and there are countless opportunities to improve.