Scrum Master: technical or not?
… The best option is not to be alone.
This is a classic question:
Do you have to have a technical background to be a Scrum Master? To be a good one?
The question is interesting as technical and non-technical Scrum Masters tend to have different skill sets to do the same job.
What if we took a simplistic view?
Let’s say that a technical Scrum Master is better than a non-technical Scrum Master since, well, she is technical. Meaning she has one more thing that doesn’t have the non-technical Scrum Master.
Right?
How being a technical Scrum Master can backfire
Is having a tech background really an edge for the Scrum Master?
The big problem with having a technical background — and most often than not, enjoying technical stuff — is that you want to dive in. You want to take part in all those awesome discussions that the development team has. You want to be part of it. You want to find the perfect solution to the problem at hand.
Maybe even, you’ll think that you know better than the development team!
If that’s what you’re doing, well: you’re doing it wrong.
All this is the dev team’s job. The Scrum Master is not a developer. He’s not even part of the development team!
It’s not up to the Scrum Master to find solutions; it’s up to him to guide the dev team to a solution through managing the environment of the team.
So… It might not be that good an idea to be a technical Scrum Master. You end up involving yourself in topics where you should not.
Facilitating is easy for the non-technical Scrum Master
Enter the non-technical Scrum Master: sure enough, there will be no involvement into technical topics.
This makes it easy for the non-technical Scrum Master to be a great facilitator, focusing on words, tones, stances and interactions (and clock) instead of the actual discussion.
Indeed the basics of facilitation is not to get involved into the discussion. Facilitation becomes hard the moment you’re part of the discussion.
So basically it’s easier not to suck at the Scrum Master role when you are not technical.
But how about being an awesome Scrum Master? Isn’t a technical background useful sometimes?
A real-life example: story splitting
What about story splitting?
Let’s say that the team doesn’t want to split the stories anymore. More precisely, they don’t see how they could split in smaller stories.
Yet you think that they should have smaller stories: given the current size of the stories, they will only have a handful of them in the coming iteration.
This doesn’t require any technical background.
The team got that Scrum requires smaller stories. But they don’t feel obligated to do it. Indeed you were thinking in terms of process, not actual outcomes. You were simply following guidelines. Guidelines can be worked-around if they don’t make sense to your current context. Agile and stuff, remember?
So you’re up to explain them why smaller stories are better, reducing risk, giving earlier feedback, minimizing the amount of rework, maximizing the amount of finished work. It’s not about following guidelines, it’s useful — in their context, too!
This doesn’t really require any technical background, yet you might be more convincing if you actually experienced what development is.
Hurrah! The team bought your idea of splitting stories. Yet we’re back to the starting point: they don’t know how to do it. Sure they could split in technical items. But they really don’t see how to split in smaller items that are business-oriented.
So you explain them why it is important to have as much as possible backlog items bringing actual value to the table. Sometimes we can do technical items… But that should be avoided most of the time. So you ask them: “How one can be sure the item is “DONE” if no-one can see it from the outside?” You talk about value, about testing, about having feedback and avoiding the tunnel effect.
Again, this doesn’t really require any technical background, but it can be hard to be convincing if you haven’t lived it by yourself. Let’s say that you draw from all those years shared with development teams.
You totally won this one. They agree with you: these stories must be smaller, and the resulting stories must not be technical, each bringing value. But… They still don’t know how to do it. They keep looking at the big stories and they simply don’t see how they could split them in smaller, non-technical stories.
Fair enough, let’s just show them! You take the first big story and start pondering… “Which pattern could we use to split this story?”
Hopefully you reach a printed copy of the “How to Split a User Story” poster, or you find it online. You also remember great videos about the topic.
You end up trying several patterns. Most doesn’t work — indeed this story is not easy to split. But you finally find a pattern that looks promising.
You suggest a tentative split to the team. They start refining your proposal. The story is split.
The team actually learned how to split stories. They are now able to do it by themselves on the other big stories.
What happened? You actually did the work of story splitting for the team. You had to; learning always start with a good example. Hopefully, you had some understanding of the story itself in order to successfully split it.
Could you have done it without any technical background? I’m not sure. If not a technical background from your past, that may be some technical background that you grew during your years as a Scrum Master in company of technical people working on technical projects.
Sometimes, a technical background is required
Coaching the team with the story splitting skill is not happening everyday in a Scrum Master’s life. Yet, it definitely happens at some point in time.
This requires some level of technical background from the Scrum Master, no matter how she earned it.
Does that mean that having no technical background makes it easier not to suck at the Scrum Master role but also makes it harder to be a great Scrum master?
You’re not alone
The best solution, actually, is neither to be technical or non-technical.
The best solution is to form a team with your fellow Scrum Masters.
Everyone has its own feats and struggles; chances are that your Scrum Master friends facilitating other teams could complement you.
If you are totally lacking any technical background, why not calling to the rescue another Scrum Master to coach the team with story splitting?
If your technical background tends to impede your facilitation skills, why not calling to the rescue another Scrum Master to help you facilitate a tricky situation?
This is a true story
Take for instance my good friend Alexandre Quach and I.
During the time we spent together we were an awesome team of Scrum Masters, bringing more value to our teams than we could bring individually.
Indeed while I had a greater focus on processes and technical excellence, Alexandre was a master in personal development and team dynamics.
Our respective skill sets made us complement each other.
Liked this article? Show it!
Please clap 👏 and share the article! It is because of you that I put my heart and soul into writing.
And follow me on my blog to be notified when I publish new articles!
Thank you so much!
