I’m coaching and mentoring a woman who is beginning her journey as a Scrum Master. She has a very non-technical background and at lunch yesterday asked me if I thought that a Scrum Master needed to be a Technical Scrum Master (especially since she knows I have a very deep technical background). Bob Galen wrote about this exact thing earlier on this blog, but let me explain my thinking. And while my answer may not surprise you (the tl;dr version is “no”), the whys may. So let me explain.
Technical Scrum Master – A History
At the risk of sounding pretentious, let me give a brief history of technical Scrum Masters. Much of what organizations think Scrum Masters do is based on their experience of Project Management. When they hear that a Scrum Master is responsible for the process, for helping the team meet their commitments, and for communicating out impediments, their minds pretty immediately go to “project manager”. And that’s a serious problem for real Scrum Masters.
In one of my previous lives (I think I’m on #12 if anyone’s counting) I was a Project Manager for interactive television applications. In that role, I had to have a technical understanding of the thing being built. I had to create the schedule (usually in GANTT form), work with the teams to break down milestones and deliverables and the individual tasks. I oftentimes checked my team members on their estimates and their breakdowns. “Does this work account for X?” “Are you sure it’s going to take you 3 days?” That kind of thing. Not that all Project Managers did the same thing, but I think it made me a better PM. Most importantly, it’s what was expected that this person would do – and why they hired me over other people.
Because of this history, most organizations that (un)intentionally (and, most importantly, incorrectly) equate a Scrum Master to a Project Manager are likely to consider them a Technical Scrum Master.
The Scrum Master Role
In response to her question, I asked her: “What does a Scrum Master really do?” Her answer was spot-on and discussed all the main points. Coaching the team to improve. Facilitating ceremonies. Resolving and escalating impediments. Acting as guardian and enforcer of the process. Et cetera.
But nothing that equated to knowing “a tech stack” or “design patterns”. The reason, of course, is that Scrum Masters are just what she enumerated (and what’s listed in the ). The focus is on the Scrum Master as a coach, as an expert on Scrum, and as the “grease for the skids”, but nothing about technical prowess. And there’s a good reason. Technical Scrum Masters can be dangerous.
Dangers of Being a Technical Scrum Master
The main issue with having a technical Scrum Master (or looking only to hire them) is that it sometimes creates “Scrum Master as Expert” kind of problems. You want your Scrum Master to be an expert on Scrum (or at least “very knowledgeable”). But an expert on technology? That opens up a can of worms that is probably better left unopened (unlike the one to the right).
When a Scrum Master is technical, they can influence the team in a lot of ways. They may act as a technical subject matter expert (SME) and try to drive solutions. They may question the team on their estimates. They may push a particular technology (because that’s what they know). They may even – horror of horrors – try to tell the team how to break down stories into tasks. They may tell the Product Owner how to prioritize the work. In essence, they can try to “manage the project” the team is developing.
Management and teams both need to understand what a Scrum Master should be doing and when a technical Scrum Master is overstepping their bounds. It’s okay for someone to be technical and a Scrum Master. It may not be okay to be a technical Scrum Master.
How Technical Skill Can Matter
My coachee pointed out that I have been a Scrum Master and I do have a technical background (I’ve been writing code, in one form or another, for over 35 years). So yes – I do have technical skills. Are they necessarily relevant? No. Should they be? Absolutely not.
When I coach, my role is to help the team be successful. Not tell them how to do the work. Not provide solutions. Not question their decisions. Having a technical background gave me a little authority and knowledge so I could call “BS” and get the team talking when something outrageous happened. Or when someone claimed something couldn’t be done. But I never allowed myself to jump in and try to solve the team’s problems or tell them how to do things. (I tried, at least) Whenever I had difficult technical conversations – almost without fail – they were related to how someone was doing work as it related to agile, not on technical merits. I could personally question the wisdom of something they were doing, but they were the team and they were the experts, not me. Did it take a lot of restraint? Absolutely!
One of the best facilitators I’ve worked with – a great coach named Dan – used to clearly delineate when he was facilitating and when he was participating. I took that example to heart. I tried to keep out of technical conversations, but if I ever got into a deep technical conversation with someone, I was very clear about taking off my Coach HatTM before having them. And I put the HatTM back on when we were done.
Closing Thoughts
One of the challenges that we face when we talk about agile adoption or transformation is that some of the new roles don’t fit nicely into our old paradigms. Project Managers “manage projects” that usually requires some level of technical understanding of the product we’re building. Scrum Masters, on the other hand, are coaches, facilitators, and empowerers. These skills are soft skills, not technical ones.
Agile adoption and/or transformation engenders a whole boatload of changes to organizations. Managers who don’t direct the work of their teams. Teams that aren’t assigned to projects but vice-versa. Business and teams working together daily. Cats and dogs living together! Okay, probably not that last one, but most definitely: Scrum Masters who aren’t Project Managers.
Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)
Bill.