In the first part I gave a short answer to this question. I have also wrote here and here about the nature of the Scrum Master.
Now I’ll try to give the long answer:
A person asking this question lives in a certain context. In that context, certain events pop up, events that trigger this kind of question. Different answers might appear, answers that are based on premises. Sometimes, those premises are not made explicit, because not everything which is implicit can be made explicit.
For me, this question activated multiple dimensions in my mind: Scrum, Scrum Master, XP, XP Coach, technical background meaning, agile coach meaning, team maturity, processes/management, complexity, utopia/ideal. So:
– Scrum Master, as it is defined in the Scrum guide(1), doesn’t have any activities regarding technical stuff that need to be made. The SM has to take care of how Scrum is applied, and make sure it is made according to the Scrum guide, so no technical background is being mentioned;
– Scrum wants to be a more general purpose framework for developing (complex) products. For example, regarding software products, Scrum does not address anything regarding technical aspects nor does it prohibit any such aspects – actually it borrowed a lot from XP;
– XP(Extreme Programming) came with the idea of a coach(2) first, even before the scrum master was defined(*). XP was designed especially for software development work. It contains specific technical activities connected in a special way. It’s not like one chooses a technical activity at the expense of another one;
– A coach in XP had to defend the process, but the process is quite different: the coach must help the team maintain the disciplines(pair programming, refactoring, metaphor, continuous integration…). This position would be a rotating one meaning that the coach needs to be someone who knows how to apply what he defends, not just by using words/encouragement/…;
– XP has the same non-technical “protocol” as Scrum;
– Maturity of the team: This is an important detail. Reality seems to give us lots of surprises, challenging ones. This means that an immature team can pose difficult challenges. If the team is mature enough then SM/Agile Coach is no longer needed or is only partially needed, so in the rest of the time, he/she can help other projects or do actual work in the same project;
– Agile Coach: This is, for me, a very abused title. I’m sure that there are damn good agile coaches out there, but most of the time, I only see fake/charlatans/unprepared/naive agile coaches. When I read Agile Coach, I thought of XP, because this role is explicitly mentioned there. Now I know that not everyone can be like the agile signatory guys, or like the grandfather of agile Jerry Weinberg, or like Allen Holub, or like Jim Coplien, … but they do raise the bar for a person calling himself/herself an agile coach. I cannot accept that an agile coach doesn’t know about the work of all the people who were there in Snowbird in 2001;
– Process, management: It seems that in management, after so many years of agile, there is a tendency to put process first and people second, when it should be the other way around( of course ontology matters, but what I see is that there is always a single and identical ontology approach). In Scrum, the role of a SM can be filled in by anyone, I say this having in mind that this role is not so restrictive/specific/targeted like for an XP Coach. I am so tired to see/hear this scenario: “As long as a person is able to speak about processes/platitudes/nonsense, but in a very well masked way, that person is good enough to be a SM. The discourse is not aligned with the aptitudes.” → unfortunately, because of this, SM became, at least in my circles, ridiculed. I am very well aware that the problem is not Scrum but how it is applied. Maybe all this is deliberate, I mean why “sacrifice” a good developer, when some unskilled, but good with processes person can be put as SM/Agile Coach.
Moreover, SM are actually in management position, seen as PM – if this is ok or not is a different story, but it is happening;
– Complexity: XP and Scrum offer different conceptual boundaries. This means that also actions will differ.
– Technical: For me, initially, technical referred to the programming stuff beneath a software project. But, maybe, the “technical” word is actually about:
- what SM/Agile Coach can do to help actively(within a specific task or story) the team in their work;
- how to get the information directly via his/her skills;
- special work without which things would not be ok, but which is very close and very important to programming, like testing(Rapid Software Testing).
This means “technical” might be translated as being aware of the technicalities of each discipline in delivering the needed work.
– Utopia/Ideal: There are too many discussions about the ideal situation, ignoring the crude reality/present. Maybe the focus/managing should be on the present, the situated present(3), and this might influence what a SM/Agile Coach should actually do, instead of doing just what is prescribed in some guides. If this means being proactive, go beyond what he/she knows, have initiative, try to understand the details of the work of his/her team, do some work on the project then why not…
Conclusion: What I have tried is to show the multiple dimensionality of this problem. It’s not easy: we have history, methodologies, management, processes, reality/multi-ontology, utopias, expectations.
We have to see beyond a certain guide, or methodology, or situation. A SM/Agile Coach has a special role/meaning/importance in and for a team. The “Master” title means mastery, leading, experienced, great, cognoscente; a “coach” means teaching, training….We need to face the reality and see what works and what doesn’t and respond accordingly. How can a SM/Agile Coach respond to the multi-ontologies if he/she is not prepared? Yes, I am raising the bar because I saw too many clown SMs or Agile Coaches that follow a certain recipe and respond with platitudes and say “that’s it, my job is done”.
So, Does a Scrum Master/Agile Coache need a technical background?
I would say yes, among other things. Can I accept the fact that there can be exceptions ? Yes, but I hope that the SM/Agile Coach can really make up the lack of technical background with other skills.
(*)Update February 25, 2018: I made a mistake above in the sentence “XP(Extreme Programming) came with the idea of a coach(2) first, even before the scrum master was defined. ” . → Thank you Jim Coplien for your feedback:
“Well, no. Scrum had the ScrumMaster role in 1994. Mary Rettig was the first ScrumMaster and it was at Easel Corporation.
(1) Scrum Guide, http://www.scrumguides.org/scrum-guide.html
(2) Robert C. Martin, “The Agile Team”, https://cleancoders.com/episode/clean-code-episode-50/show
(3) Dave Snowden, “Managing the situated present”, http://cognitive-edge.com/blog/managing-the-situited-present/
You say, “Scrum does not address anything regarding technical aspects nor does it prohibit any such aspects – actually it borrowed a lot from XP.”
Can you name me anything that Scrum borrowed from XP?
There are teams who have filled out the Scrum framework to build their own processes using some XP practices, but I can’t think of much in Scrum itself that comes from XP.
This is most important because most people view Scrum as a method to build product. XP is indeed a method to build product. Scrum is not. Scrum is a framework, and you use it to create your process by filling it in with practices.
Instead of saying “Scrum does not address anything regarding technical aspects nor does it prohibit any such aspects – actually it borrowed a lot from XP.” I should have said :
“Scrum does not address anything regarding technical aspects nor does it prohibit any such aspects – it seems, at least in what I see, that teams practicing/applying Scrum borrowed a lot of the technical practices defined in XP.”
In the way I formulated that sentence, I made the error of associating, if I can say so, like in the literature class, the cause(Scrum framework) with the effect(how it is being applied), like they are the same.