Should Your Scrum Master Be Technical?
Prefer to watch this as a video? Click here.
Here’s an issue that’s been playing on my mind a bit recently. I always keep an eye on the agile and scrum related job ads to see what’s out there, and one thing I see time and again is adverts for scrum masters, which then go on to list a large number of technical skills and capabilities as essential criteria for the role. Now on the one hand, you might see this as fair enough. You’ll be scrum mastering a technical team building technical products in one or more technical languages, so why shouldn’t you have the same technical understanding as the rest of the team?
Well, at the risk of slightly playing devil’s advocate, I think there are actually a number of reasons why not. The first is that if you get a technical blocker to the team, and the scrum master is technical, then the temptation can be for the scrum master to get involved and fix the blocker themselves through their technical knowledge. In one sense, this is good, as the scrum master is clearing blockers out of the way of the team, but it misses some wider points.
Clearing blockers out of the way of the team is as much about enabling the team to clear blockers themselves as it is about clearing the blockers for them. It’s like the whole fishing analogy used in poverty. Give someone a fish and they will feed themselves for a day. Teach someone to fish and they will feed themselves for a lifetime. If all the scrum master does is join in with the development team and do technical work to clear blockers, they’re just giving them fish rather than teaching them to fish. They also risk getting caught up in the finer detail, and missing the bigger picture and any potential root cause analysis that could have been done. A root cause analysis that might have stopped similar blockers emerging in future.
Indeed, it is for this reason that I think there’s actually a lot to be said for a scrum master who isn’t in the least bit technical. Without any technical knowledge, there’s no temptation for the team to pull the scrum master into doing their technical work for them, and there’s no temptation on the part of the scrum master to just fix the problem themselves rather than coaching the team into fixing it together. I saw this best in one of the first scrum masters I worked with, who happened to have been trained as an archaeologist, and had never coded in their lives. They’ve gone on to be a hugely successful digital project manager on projects that are household names.
There’s a related problem around this with coaching styles too. Coaching is a very short word for a very complex topic that contains lots of different styles, approaches and schools of thought. The problem is, that if you have a technical scrum master, then they’re more likely to start offering concrete solutions to problems, which immediately shut down some of the coaching styles that can be hugely effective, like counsellor, facilitator and reflective observer. Of course, you could argue if you’re not technical, you shut down some of the other coaching styles, like hands on expert or modeler, but I think this leads us on to another interesting misunderstanding within agile.
People often say agile needs servant leadership, but very few people actually understand what that means. As a result, they conflate it with things like scrum masters clearing blockers, and so see scrum masters getting involved in technical delivery work as acceptable. However, servant leadership is actually much more about the personal growth and development of those you are serving, helping them to do more and become more. So the more you do their difficult work for them, the less you’re actually helping them to grow.
This leads us on to a problem I like to call the 20 legged horse. A horse with four legs will run faster than a horse with three legs, and a lot faster than a horse with two legs. So surely, if you keep adding legs to a horse, they’ll run even faster and be even better for your purposes. The vikings certainly thought so. In their mythology they had a horse called Sleipnir which was ‘the best of horses’ and had eight legs.
The only problem was that Sleipnir was mythological, and I think very often the scrum masters people are advertising for are mythological too. You want a scrum master with technical qualifications, able to code in a certain set of languages, ideally with experience in a certain industry too. At the same time, you want them to be an expert in all of the soft skills scrum masters require, like communication, conflict resolution, facilitation and coaching. In essence, you want a horse with 20 legs.
Sure, it’d be great if such a person could be found, but how realistic are they? Besides, don’t you run into a problem with such people, that unless they’re an exceptional polymath or have decades of experience in different fields, that they’re actually a ‘jack of all trades, master of none’? If you want a hugely diverse range of skills, you’re going to have to start prioritising some skills over others.
Of course, in saying all of this, we mustn’t ignore the fact that there are undeniably various scenarios where a developer can turn into a scrum master, or for a developer in a team to play the scrum master role. Similarly, a scrum master should never be overly precious about things they do and don’t do. If coding is essential to keeping the value being delivered, then coding is what’s needed. That’s all fine, and in some cases that’ll be exactly what the situation requires. But if that’s a regular situation, then advertise for a developer with scrum master abilities, not the other way round, and be aware of what you might be losing in soft skills, servant leadership and team growth benefits as a result.
If you’re looking for someone who can develop, and lead, and coach, and serve, and facilitate, and communicate, at all different levels of the organisation, then chances are you’re looking for someone who doesn’t exist, and closing yourself off from the sort of people your situation might actually require. So write down what your actual broad user needs are for the scrum master, not the specific technical skills and experience that might indicate their deeper abilities. Then prioritise them, share this prioritised list openly, and invite people to let you know how they’d propose to meet those user needs for you.