Scrum Master as a Non Developer

Every coin has 2 faces.

Your question remind me of a friend of mine, very good as a developper. After several months, his Scrum Team was still totally not knowing about his technical skills. When he said "I understand everything you talk about", the Dev Team members were all surprised.

How can you see your non-technical background as a huge strength for you, as a Scrum Master ?

Olivier Ledru I am not sure I understood what you meant in the end.

"How can you see your non-technical background as a huge strength for you, as a Scrum Master ?''

So a non technical person can hardly be a successful scrum master?

So the challenge I face is to understand the technicalities of the project thus being unable to participate actively and get the overall grasp of the project.

Is improving your own understanding of project technicalities the best thing you can do to help? Doesn’t the Development Team already have sufficient technical competency?

Might it be better instead to establish transparency over the work which is going on with its dependencies and assumptions, and to explore how Scrum may be better interpreted and applied?

I agree with Ian, do not worry about technical things, important thing for you is the processes and where there can or be bottlenecks from your perspective. I as a former developer and current scrum master do not give any technical input  as i would have to step out of my role.

Giving a technical input is a different thing. But my worry is about understanding the technicalities and thus not being able to handle the team because of it because I just dont know the project at higher level. (like the view from the top of the hill). Just wanted to know if I am alone or there are people with non technical background and yet good scrum masters.

I come from a management background and have very limited technical experience, but still receive the feedback that other people experience me as a good Scrum Master (not to boast about myself, but to provide you a little peer experience). It's not that I don't want to know about the technicalities, but I do think there are several benefits of staying clear from the technical part. I've seen quite a lot of really good dev-turned-SM's that looked more like a glorified team leader rather than Scrum Master. Not having technical knowledge leads to creative thinking if there is an impediment. Whether it's external knowledge or having training, we as a Scrum Master can enable and support their decision and help them identify potential bottlenecks, but providing them a solution from a technical perspective will limit empiricism.

Thanks @Sander Dur . That helped. 

+1 Sander Dur. I currently serve as Scrum Master on a team I developed with for a long time. It can really be a handicap for the team, because they tend to fall into the 'you decide' trap, whenever I voice an opinion on technical stuff. It's hard to stay out of tech discussions, but I work hard at it. 

There’s an old Scrum Master saying that once you know what your team is actually building, it’s probably time to move on.

I wouldn’t interpret that too literally, but it is true that a detachment from technical detail can be a healthy thing. Often the perceived details are a treatment of why agile practice “won’t work in this case” because the organizational context is “special”. It’s important not to get lost in the weeds.

I'm at the opposite side from Olivier's friend. I come as a scrum master from several years of technical work, and most of the members of the dev teams know me and my skills, so it is common for me to be included by them in some interactions not directly related to the scrum master's role.

It is tempting to give away technical opinions and judgements, specially when you know about it deeply. I just don't. If I want to create a sense of work ownership among them, as a scrum master I must stay off of their way of solving things. I've found myself judging what I heard from a technical point of view, thinking "They're going for solution A, but the correct one is B" to end up afterwards very surprised at how wrong I really was, and viceversa. So you never know. Maybe technical assistance is needed when the case is something special or the team is totally hindered, but for the most part of it, they have to try on their own.

What to do when I am asked for my technical opinion? I find useful to say "Let me see if I've got it correctly" And I simply go over their plan all the neutral I can. Being neutral is quite important here. Sometimes they just start discussing again and sometimes by simply listening the same thing with other words is enough to make them considering other alternatives. Sometimes they just need to hear it aloud to became confident. The key to me is to keep things moving, and if they are feeling confident, then so am I. If not, let's find why. 

Once I was questioned "Ey Juan, I remember you were working on this same thing once in project A, how should we proceed?" and, out of the 'trap', I honestly gave away what I did, but also strongly remarked: "But this worked for that time and those given conditions. Can you tell me 100% sure that these are the same conditions for what we have in our hands here and now?" (They are usually not)

I feel empty inside as a non technical person and yet the scrum master. 

I sometimes feel too full as a technical person and yet the scrum master :) Your duty is to pay attention to the interactions and processes, not the technical work. I believe anyone can perform well as a SM if the role is well understood regardless the background, and ey, we all come from some kind of background, and different backgrounds have different pros and cons. Figure out which ones work for the team and which don't, then adapt.

Hope this helps.  

I was a developer MANY years ago, then moved into a QA role, then management.  But when I participate with my teams, I intentionally avoid getting involved in the technical discussions unless they ask me for an opinion.  As Scrum Master, my job is to help them come together as a group of individuals instead of a bunch of individuals in a group.  Instead of being involved in the technical discussion, I provide a better service to the team by observing their interactions, preventing 1 or 2 people from dominating the conversations, helping to ensure that everyone on board with decisions.  So while I understand the technical, I try to avoid it. 

I'm a bit jealous of your position. Since you will have a hard time understanding the conversation, you won't be tempted to be pulled into it and can spend your time observing and coaching as a good Scrum Master should.

This is really helpful information for me as I'm planning on getting out of 20 years of corporate and academic training and moving to a scrum master role after I pass the PSM I this spring. I don't come from a technical background and was worried not understanding the technical side would hinder my abilities but I have often been at companies where I find myself asking questions and making comments about very technical products that I don't understand that still further the project or at least inspiration of the developer. I just had never thought of being a scrum master in such a sense. Tomorrow I'm going to read the Scrum Guide for the first time. cheers!

Actually the less technical Scrum master is, the better. Scrum masters actual job is not teaching developers to develop, but to ensure good communication and team spirit within the framework of the methodology. As such Scrum master should actively discourage use of complex, technical language at any of the Scrum meetings, would it be sprint planning, daily scrum, review or retro. For the sake of team work, better communication with each other and with stakeholder developers should learn to exchange all information in a manner which would be easy to understand for a grandmother of 10 year sold.

This means all information-user stories, backlogs, what they say on the daily scrum meetings, or other ceremonies. So Scrum master should never hesitate to say "I don't understand you, please explain in simple language" when developer starts using to much tech lingo. And demand simplification of the language until the concept will become clear to himself-and eventually for everyone else.