Do Scrum Masters have to be technical?
That’s a question that I get all the time.
Some people believe the answer is an absolute “YES!”.
Not only that, but there is a belief that Scrum Masters can ONLY do their job if they come from a development background or if they have a degree in computer science.
I respectfully disagree!
Scrum Masters don’t have to be ex-developers.
BUT
They have to have enough understanding of the technical work the developers do to be able to ask relevant questions and coach the team.
Watch the video or keep reading…
Scrum Masters – is it a technical role or a non-technical role?
A great question I’d like to address in this video.
More specifically, I want to talk about the technical skills and knowledge Scrum Masters need.
But first, let me highlight the fact that I am an example of a successful Scrum Master who comes from non-technical background.
I’ve never been a developer or a tester. I actually switched to the Scrum Master role from a Content Manager role.
When I introduce myself to the teams I let them know that my only thing I can develop is basic HTML for my website.
But I also let them know that I have a good knowledge of the software development lifecycle and will be able to understand some of their technical talk and ask them some pointed questions about their work.
And this is how you should look at the role of the Scrum Master.
You might not need to know how to do the job, but you need to understand it nonetheless.
Change Management
We can say that implementing Scrum into a company is really about managing change.
Agile transformation requires individuals to change how they work, how they measure success, how they communicate, and more. It’s a big change!
And change management is an enabling framework for managing the people side of change. Prepare, support and equip individuals to drive change success.
Scrum Masters work with team members, managers, executives to help them navigate the Agile changes.
It’s about working with people NOT working with code.
How does development background or computer science degree help with that?
It doesn’t!
Having a developer background might actually hurt you!
Wait, what?
Yes, you heard that right.
A Scrum Master needs to stay unbiased. You have to let the team to self-manage and own their processes.
If you have your head in the game, you might have difficulty disconnecting from your personal opinions about how to do the work and might impact the teams decisions in the wrong way.
Your role is to ask questions and direct the conversations, not to give out solutions!
And now when all the techies have their blood boiling….
…let me talk about what technical knowledge Scrum Masters actually NEED to be successful.
Btw, I share what a Scrum Master does from day one and how to start in this role in my Scrum Master Startup Guide. Check it out if you need an in-depth practical guide for this job
Now…
Technical knowledge Scrum Masters need
As I mentioned at the beginning of the video, you don’t have to be a developer, but you need to have enough of the understanding of the development work to be able to coach your team.
What would that knowledge include?
Here are a few things I think you need to know:
- Basic tech terminology
- Development environments
- Testing processes
- Deployment processes
- Coding practices & standards
- Technical debt
I will give you a very brief explanation of each of these and how you can use this knowledge, but I encourage you to look deeper into each of these.
Basic tech terminology
There are a few things that I often find myself referring to and that I hear from the teams.
I can’t say that I have a list of these, but here are a few that come to mind:
- Pull request,
- Merge conflict,
- Rollback,
- Pipeline,
- Branch,
- API,
- Production,
- UAT,
- Feature toggles.
There’s more, of course.
I was actually adding new items in this list as I was writing the rest of the script for this video.
What other terms would you recommend looking into? Share in the comments 👇
Development environments
You’ll often hear your teams talking about this.
Especially, when they need to set up a new environment for a new product, for example.
Think of it as a space to work in. You don’t want to make changes to the product that is being currently used by customers.
So you make the changes and work in other spaces, you test your work, before giving it into the hands of the users.
You will hear of a dev environment, a QA environment, often a UAT environment, and production, of course.
Sometimes, staging environment, that is used in website building.
Or maybe pre-alpha, alpha, beta stages in game development. Not exactly environments, but still relevant.
Understanding how a feature goes from one environment to the other is definitely needed.
Testing processes
QA, or testing, is a whole separate field that requires specific knowledge and skills.
You need to be familiar with testing types and have an overall understanding of why they are needed.
Good product development requires testing and you need to be able to coach your team on why it’s important and how it might affect the product quality.
Some examples are: regression testing, unit tests, integration testing, performance testing, user acceptance testing, and more.
Deployment processes
This really comes back to some of the terminology I mentioned before as well as development environments.
Deployment process flow is usually similar from one product to the other, but your team will have their own nuances associated with it.
Think of steps like code developed, code tested locally, code tested in QA, code integrated, etc.
Also look into concepts around continuous deployment, continuous integration, continuous delivery.
Coding practices & standards
Ok, I know this might seem a bit too specific. But it’s an important part of the coaching that a Scrum Master can provide to the team.
You don’t have to be a DevOps expert to understand some good practices your team should employ.
For example, proper code commenting, code reviews, pair programming, clean code, refactoring, and more.
Technical debt
That’s a big one and it might be a bit daunting at first.
In short, tech debt is the deferred work for the product, often the result of decisions made by the developers to trade quality for speed.
There are lots of ways how tech debt may appear.
For example: non-resolved defects, lack of automation, high code complexity, lack of unit tests, hard coded variables, lack of documentation, old software versions used, no knowledge transfer.
These are just a few examples.
What other types of tech debt have you seen? Share in the comments 👇
Using your technical knowledge
Ok, you know all of those fancy words. What now? How do you coach your team with this knowledge?
Let me give you an example of Scrum Master coaching that is not actually technical at all even if we are talking about technical knowledge.
Quite a few teams I worked with had a huge risk factor associated with technical debt in the product.
Since I know this often is the case, I usually ask questions associated with it when I conduct my observations and assessments.
As the voice of the team I need to be able to bring attention of the stakeholders and the Product Owner who might not understand the complexity of the developers’ work.
I don’t need to know what this tech debt is in details and how it might effect the product – the developers know this already.
But I need to think about this topic when I conduct my assessments and create improvement plans.
I am also often there to help developers document the tech debt in such a way that it can be understood by non technical people by asking them customer-focused questions.
How do you learn these?
Ok, of course, your question by now should be: How do I actually learn all this stuff?
Isn’t it exactly what they teach you in those computer science classes? So in the end I need a degree after all?
Well, yes and no.
You can definitely attend some classes to speed up your learning.
For example, I took an online Introduction to Computer Science class with Harvard edX.
But by that time I already had a good understanding of all of the terms.
I believe that the best way to learn that stuff is through your teams working with them.
First, listen in carefully to what developers talk about. Create a mind map for yourself of what their process looks like – visualization can be very helpful.
Then, don’t be afraid to ask lots of questions. Ask the team members to explain how they work and what kind of challenges they face. Ask why certain things are done a certain way. And when the team says that something is too complex, ask for clarification to understand it better.
That’s the way I learned about it and that’s what I recommend you do too.
In the end, I’d like to say, you don’t have to be a development expert, but you need to have an appreciation for the work developers do.
I am always fascinated and impressed by the work that Scrum teams do. They understand such complex concepts that take years to master. Their work is creative and exciting. And they are truly motivated by and love what they do.
Appreciate their work, and they will appreciate yours.
