Short answer: yes, and a lot of working scrum masters came in that way.
Long answer is more useful, because “yes” on its own gets people to spend money on a certification and then wonder why nothing happens.
What the role actually requires
A scrum master does not write code, does not review code, and does not make technical decisions. Those belong to the team.
What the role requires is that you can run a room, remove obstacles, hold a process when it is inconvenient, and tell somebody senior an uncomfortable truth early.
None of that is technical. All of it is hard, and most of it is learnable only by doing it.
What the technical gap actually costs you
Here is the part the encouraging articles skip. There is a real cost and pretending otherwise sets people up to be blindsided.
- You cannot always tell whether an estimate is honest. When a developer says a story is eight points and another says three, a technical scrum master can sometimes hear who is right. You cannot, so you have to get there by asking questions instead, which is slower and occasionally you will be managed.
- Some blockers are technical and you will not understand them. The correct response is “I do not know, who does” and then going to get that person. The wrong response is nodding. Engineers spot the nodding immediately and you will not get a second impression.
- You have to earn credibility that a technical hire is given. Usually within a fortnight, usually by removing one thing that had been annoying everybody for months.
None of these are fatal. All of them are easier if you have decided in advance to be straightforward about what you do not know.
What you do need
Not the ability to code. The vocabulary to follow the conversation.
You should be comfortable with roughly this much, and it is a few evenings of reading rather than a course:
- What a deployment is, what an environment is, and why there are several
- Why a thing that works on one machine might not work on another
- What an API is, well enough to understand that one team waiting on another team’s API is a dependency and not an excuse
- What technical debt means, and why the team keeps raising it
- What a pull request and a code review are, well enough to know why a story sits in review for two days
That is enough to run the meeting, ask the next question, and know when to bring somebody else in.
What employers actually mean by “two years experience”
They are not counting. They are trying not to hire somebody who has read about it and never done it under pressure.
What they want to know is whether you have ever had something blocked and got it unblocked by talking to people who did not report to you. Whether you have delivered bad news early with a number attached. Whether you have watched a plan fail and changed how the team worked afterwards.
You can have done all three in a hospital, a school or a shop.
The order that works
- Decide it is actually this role and not business analyst or product owner, because the three get applied for interchangeably and it shows
- Build a delivery project so you have something specific to answer from, with a sprint that missed for a boring reason
- Learn the five bits of vocabulary above, which is a week of evenings
- Get certified, CSM or PSM, after the project rather than before
- Rewrite the CV in delivery language, with the project above employment
- Apply in volume. This is the step people skip. Twelve applications is not a sample
Where a non-technical background is an advantage
Two places, and they are worth naming in an interview.
The first is that you cannot solve the problem yourself, so you do not. A scrum master who used to be an engineer spends the first year fighting the urge to fix things, and some never stop, which quietly removes the team’s ownership.
The second is that if you came from nursing, teaching, law or retail, you have spent years translating between people who do not speak each other’s language. That is most of the job, and it is much harder to learn than the vocabulary.
The honest expectation
It takes longer than the course sellers say and it is more achievable than the forums say.
Expect several months of applications. Expect your first role to be at a smaller organisation or inside a company you already work for, because internal moves are much easier than external ones and most people underrate that route.
And expect to be asked, in the first interview, how you will cope without a technical background. Have the answer ready. The good answer is not a denial. It is that you know precisely where the gap is, you have decided how to handle it, and you will say “I do not know, who does” rather than pretend.
The gap is not knowledge
It is that every interview question assumes you have a project to answer from. The Portfolio Project Kit is a complete agile delivery project you import into your own Jira in one click, with full acceptance criteria, three sprints and one documented impediment. It is a practice project and you say so every time you present it. See the Portfolio Project Kit, $49
Not sure which of the four you are aiming at?
The Role Fit Diagnostic is sixteen statements. You tick the ones that are true of you now, count your ticks by letter, and read the page for whichever role you already work like. Ten pages, printable, free, about six minutes.