During the early part of 2023 I was fortunate enough to take a break and do some travelling. This was a great opportunity to catchup on some reading and do some reflection. Funny how things always seem to connect.
Sadly, at our first port of call in the Bahamas, although we docked as planned, we weren’t permitted to disembark due to a handful of cases of the dreaded Norovirus onboard. We still had a good day, the weather was excellent and we wanted for nothing in terms of service but we were only able to gaze out from the deck and enjoy the weather from there. To be fair the port area wasn’t exactly picturesque but I spent the day ‘catching some rays’ and contemplating the Scrum Master role.
So here’s the first question: is a bad scrum master better than no scrum master at all?
Firstly, it is necessary for me to provide a definition of ‘bad’ scrum master. This is obviously subjective as there are so many opinions and grey areas around this topic that I am certainly not trying to provide an exact definition but I hope to provide a little context of what I mean.
In Scrum terms, the Scrum Master is potential the most transient of the roles, by which I mean that to create value we will always need someone to identify the value (the Scrum Product Owner or a hands-on customer) and someone to create a solution (the development team). The Scrum Master is there to ‘facilitate’ the relationship between the developers and the end user (whether that is via a Product Owner or not). In the hypothetical perfect world, the relationship between user and developer is so trusted and so rich in communication that even an experienced Scrum Master can add little to the mix.
At this point I should clarify that I see a massive difference between a ‘bad’ scrum master and an inexperienced one. Lack of experience or knowledge is not a crime but perhaps this gives me my first ‘bad‘ characteristic – over confidence or lack of humility.
The most dangerous scenario for lack of humility is the misinterpretation of the role. Classic examples of this are “scrum master is the new name for project manager or technical delivery manager” or “reporting to the scrum master at daily standup”. In this case, I would tentatively suggest that the team would indeed be better off without a scrum master of this type.
We know that the root cause of these issues is lack of training or subsequent coaching but both of these services require the recipient to want to learn. No business would ever consider letting loose an untrained operative with a highly valuable and complicated piece of equipment and yet many are happy to hand over ‘control’ (yes that’s irony) of a team to an untrained scrum master. There are few more valuable and expensive assets to most businesses than their teams of people, yet this crazy behaviour happens regularly.
“So what has this got to do with infections?” I hear you ask.
One of this articles that got me thinking along these lines was another old essay from Tobias Mayer, where he proposed that the role of the scrum master was to ‘infect’ the team with agility. The traditional role of the Scrum Master has been corrupted within so many poor applications of agility that maybe it is time to revisit, rename or even remove the role and start again. Tobias promotes the possibility of an “agile influencer”, free to move around the teams and organisation without line management or reporting responsibility beyond directly to the CEO.
The other major inspiration for my thinking popped up in the inbox this week from Mike Cohn, where he considered 6 attributes of a scrum master. We already mentioned humility but Mike’s list also included
– responsible
– collaborative
– committed
– influential
– knowledgeable
For me most of these are pretty obvious. Certainly commitment and collaboration are such fundamental characteristics for anyone working successfully in an agile environment that there can be no argument. Some of the others are worth further discussion. Everyone needs to be clear on the scope of Scrum Master’s responsibility and this is where the most troublesome one for me coincides. It is often said that “a little knowledge is a dangerous thing”. I would say that too much knowledge especially of a technical or product nature is potentially dangerous too.
I am most uncomfortable with Mike’s comment that “knowledgeable Scrum Masters understand enough about key technical issues to be able to explain the problem to others in the organization when necessary.” I just don’t see this as part of the SM role at all. Technical discussions need to take place with the people doing the work, the developers. The SM should be ensuring that those discussions happen, facilitating if necessary, to ensure the conversation remains focused and productive. If they have the discussion themselves they are getting involved in the solution and potentially become an unnecessary step of any knowledge transfer process or in the worst case, a single point of failure.
In my experience, technical knowledge represents a significant risk for a Scrum Master. If a Scrum Master is distracted by the technical discussion taking place they may well miss some of the human interactions or any tensions that are occurring. The responsibility of the Scrum Master is the effectiveness of the team. It is my belief that the role is heavily human focused and they must always ensure that any technical distraction does not prevent them from meeting that responsibility.
Anyway, I digress.
A Scrum Master needs to be infectious. Not with something unpleasant that will prevent the team from collaborating face to face but with the essence of agility. Demonstrating the key behaviours, and finding ways to encourage others to do the same, is the main objective. When everyone in the team is fully infected to the point that the symptoms start to spread to others both within and external to the team the SM can take their virus and move on, perhaps occasionally revisiting to ensure that the ‘disease’ is still rampant and reinfecting as necessary.
Infection is best done with frequent close contact. In the best scenarios the recipient is not even aware that the infection has taken place, until they step back and realise ,that their symptoms (ways of working) have changed. Many will be scared of being infected as the fear of the unknown can be strong. They may resist and this is why subconscious infection is the holy grail for the SM.
So Scrum Masters, immerse yourself and go forth and infect! Whatever your experience level, don’t try to tell the team what to do. Share anything you learn or observe and work with the team to experiment, learn and advance your experience together – that’s collaboration and that’s your responsibility. Be committed to the task, don’t let any technical knowledge you have distract you and always remain humble about your own impact. Finally, always endeavour to be a good example and influence on the behaviours of the team.
Image by brgfx on Freepik