Should A Scrum Master Be Technical?

Wouldn't that be a temptation for the Scrum Master to be ...less of a Scrum Master ? I mean, if the Dev Team feel he's more like an inspector of their work (you talk about evaluation), and in return they'll be more likely to expect assignments from him/her?

There is a user on this forum who constantly answers OP questions by another question, thus inviting for autonomous, creative thinking. I have found many times that although I was not an expert on many topics, asking questions and understanding principles allowed me to actually guide my interlocutor into finding solutions and gain a better understanding of why they were doing certain things. And if it doesn't lead to the "best" solution necessarily, it might still be the most "fruitful" in terms of what one gains in accountability, autonomy and critical thinking. 

PS: I don't work as a Scrum Master (yet?)

Are you familiar with the Agile Coaching Competency Framework? I believe that it applies to the Scrum Master role - the Scrum Master role is agile coaching in the context of the Scrum framework, with particular rules and responsibilities around the role.

I'm mainly looking at the types of mastery that an agile coach - or a Scrum Master - may need to use. Technical Mastery is simply one. A single person may not embody all of these forms of mastery, or may have different levels of depth. Depending on the needs of the team and the organization, you may want different sets of skills for the Scrum Master to have in order to help coach and facilitate the team. In some cases, having excellent technical skills may be extremely useful. In other cases, a different set of skills may be necessary.

Thank you Thomas - no I have only focused on the core Scrum - if I may call it that way.

Thanks !

I see the argument for the Technical Scrum Master as counter productive to the real goal of the Scrum Master role.  You are describing what I know as a technical lead. In the Scrum Guide the Scrum Master role is well defined. (https://scrumguides.org/scrum-guide.html#team-sm).  The entire focus is on how the team functions as a self-organized unit while understanding and appreciating the Scrum Framework. If the Scrum Master focused on your list I do not believe that it would provide the benefit that is described in the Scrum Guide. 

You are describing a very command/control individual and that is not a Scrum Master. 

Should a Scrum Master be Technical?

In some situations it can be advantageous for a Scrum Master to also be a Development Team member.

• Force the team to adopt and use a particular technology
• Try to handle the project that the team is working on

What impact would this behavior have on self-organization?

Thanks Daniel for your valuable comments

As your teams implement Scrum, they are going to continuously change how they work and what they work on. They are going to collide with how the others in organizations work from time to time. Hence, it is imperative for Scrum Master to understand other aspects of business, from finance to HR, from marketing to sales, from budgeting to resource allocation, in detail, such a way that the Scrum Master can understand emerging impediments in a timely manner. It is a big ask. As Daniel suggested, technical Scrum Master can be counter-productive if the SM has to spend an extended period as a dev. There is a real possibility of getting blind-sided about the other factors and repetitive emergence of the same types of impediments.

I'm not going to say as a blanket answer that a TSM is worse than a pure SM. To me, the SM is 4 dimensional skillset (teach, mentor, coach, servant leader). I will say there is an impact or effect on the SM to feel the pressure to blur the lines a little bit.

Sometimes this pressure is earned from the company expectation for this SM to improve delivery of the team by way of utilizing their technical experience ... essentially having the SM manage the output or step on the toes of the PO a little bit. It's a disservice to the effectiveness of the SM and the growth of the whole Scrum Team for the immediate lack of trust and interest in the skillset of the team improving.

That said, the is positive usage of the experience by way of knowing what questions to ask the team and sharing experience by way of stories of things that worked well and didn't, and what was learned. The team would then determine what to do with that information in mind, but in no way will the SM force the team to do/be a certain way because of the technical background. 

In my opinion - A technical SM may prove to be beneficial in cases, where the team members are relatively new, and if that technology/platform is the SM's forte - as long as he/she doesn't end up controlling

• how the team works
• who does what
• undermine the team's development effort and be unreasonable
• etc etc

Also, a Scrum Master with sufficient and updated technical knowhow can challenge some of the solutions, which may end up for good.

If (s)he understands that there is a pretty solid line - and doesn't cross over, a TSM may not be that bad after all.

I recently heard somebody ask the same question in the context of a UI UX designer. That is, should a UI UX designer be a former software engineer? 

It depends on the situation. I don't think it should be a job requirement. One Scrum Master who stands out in my mind admitted to have failed at writing code, excelled at managing projects and transitioned to becoming a Scrum Master. He was a rockstar and got the team motivated, kept them happy and cleared impediments. 

I can only say from my past experience that a lot of companies have a rather different understanding of what it means to be a Scrum Master. I have often seen that it is not only desired but required to be a coder or at least people should have a lot of technical expertise.

I do think that this does not work well for the role as it was already stated before in this thread that a technical Scrum Master might influence the team to solve challenges a certain way. Yet for me a Scrum Master should always be a coach, mentor, facilitator and more often the one people can talk to (Listener).

Yet as for now and I can speak only for Germany regarding this matter, many companies even change the title of Scrum Master to Delivery Lead and this does not help.

I can only hope that this situation will change over time but for now it seems to me that there are as many definitions to the role of Scrum Master as there are open positions listed.

I remember a conversation between stakeholders, the Product Owner and Developers at Sprint Review. Stakeholders gave feedback and were requesting a feature that Developers then claimed was "impossible".

I was the Scrum Master, and had some technical knowledge. My response was something like:

"No, it's not impossible. You just mean 'it's very difficult and complex'. How about we talk about options instead of just rejecting the idea?"

I found it useful on this occasion to have enough technical knowledge to call the team out. It wouldn't stop, though, a great Scrum Master from recognising stonewalling behaviour and to support the conversation to instead talk things through.

In some sample cases it is an advantage when you have a technical background:

• In an agile transformation many team members need somebody who can answer technical questions as they were used to ask their previous team lead
• you can ask (better) questions to guide the teams as you know what they are talking about in detail
• If you want to improve the companies processes to certain topics (e.g. leverage the code coverage, build infrastructure) - it is way easier if you can guide the team members.

Risks are similiar

• in an agile transformation the team members just ask you and do not get self organized
• you provide always answers instead of asking questions
• you ask questions in a too specific direction (the direction you have in mind)

You see the benefits and risks are very close together. I have technical background and try to ask as much as possible.

For sure, technical tooling know how is always recommanded.

I was the Scrum Master, and had some technical knowledge. My response was something like:

"No, it's not impossible. You just mean 'it's very difficult and complex'. How about we talk about options instead of just rejecting the idea?"

How did the team react to that? Did they hate you afterwards?

As per my personal experience goes, lots of scrum guide statements are highly misused. This is one of them. 

We have a situation where all the team members are junior developers and they don't realize how to be operationally efficient.

But the SM in our team is totally jerk and I realize they are using such statements to totally avoid learning technical stuff (they use language tactics to avoid asking technical stuff) and upskilling, which is very much the need in the team.

Scrum guide does not says being SM whether they actively should upskill themselves or not or they just have to use this argument to avoid technical stuff at all cost. 

The difference is stark & latter dosen't work in practice.  

Scrum guide does not says being SM whether they actively should upskill themselves or not or they just have to use this argument to avoid technical stuff at all cost. 

In the guide you can see how SM is accountable to serve the team, PO, and organisation. Whatever skills to fulfil these accountabilities is required for SM. 

We have a situation where all the team members are junior developers and they don't realize how to be operationally efficient.

Did your team retrospect to find out if this a problem and tried to find a solution ? 

Scrum guide does not says being SM whether they actively should upskill themselves or not or they just have to use this argument to avoid technical stuff at all cost.

I once heard on a podcast a Scrum Master at -I think it was- Nestlé, where the scrum team makes new products (for example a new yoghurt). How do you see the Scrum guide describing that Scrum Master to be technical, or upskill themselves? Should this SM know how to make or market a new yoghurt? That is why the Scrum Guide does not talk about the technical skills of the Scrum Master, it is very complex if you take into account that they may not all be in software development.

Why would a Scrum Master's input be welcomed? 'The one's who do the work...'

What value would a Scrum Master's technical ability be worth after one-year of not being a developer, after two-years?

At best a former experience as a developer may ease a Scrum Master's reading of body language, jargon, empathy, as they have been there as well as reading between the lines. Though, a (successful) Scrum Master will learn this as they mature in their role and gain experience and as they further their education, yes?

I know of organizations that follow the Scrum framework for non-software development areas.  The Scrum Guide 

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

No where in the Scrum Guide state that is for software development.  One company where I worked used it for their recruiting team, trade show event team, software development, C-staff initiatives, and more.  Any type of discipline can have complex problems.  

So in the cases I mentioned above what benefit would a Technical Scrum Master provide to the recruiting team if that team was also responsible for recruiting Sales, Marketing, Accounting, Executives, Customer Service? 

Does a Scrum Master need to be technical?  Only to the point of being able to use the technology necessary to do their job.

Also a Scrum Master is a human being with his strengths and weaknesses. One might have sound technical skills and excel with those in his role, another one might have "no clue" - and excel as well. I'd suggest having also a read of https://www.scrum.org/resources/blog/2-best-scrum-masters-i-ever-worked-master-coaching-and-facilitation that deals exactly with this topic.

And: a Scrum Master should not "try to handle services" (at least not in his accountability as a Scrum Master - maybe he can also act as Developer in the Scrum Team and do so in that accountability), "force the team" or "handle the project".

Scrum guide does not seem to prohibit a single person working as both Scrum Master and developer. So if SM is technical is capable he might be able to work as a Developer in Scrum Team, But I would say conflicts of interest can occur especially with some of the SM responsibilities.

From my personal experience a Scrum Master with technical knowledge would always be beneficial to the Team as long as the Scrum Values are followed. Abiding by the concept of being a facilitator, a SM can always provide assistance when reached out by the Scrum Team.

I would not agree to the fact that if a SM is technical then he is going to boss the Team regarding the technology. He can still boss the Team even if he isn't a technical, that has more to do with kind of person rather than the role.