Do ScrumMasters need to be Technical?

Scrum does not define any technical disciplines so, strictly speaking, Scrum Masters do not need to be technical. However, if technical disciplines (like TDD, Continuous Integration, Refactoring, etc.) are not used, then the code produced by the scrum team will very quickly rot into a festering pile, leaving the team entombed in an ever deepening and thickening tar pit. Therefore _effective_ scrum teams must be good at technical practices; and someone must play coach for those practices. That technical coach might be the scrum master, or it might be the lead developer.

Bob - strictly you're right Scrum doesn't define technical practices. It doesn't even say you should build software using Scrum.

However I also think that all the Scrum Trainers and Coaches (CST, CSC or otherwise) teach teams that are developing software about the technical practices. In the case of some teams I'm working with right now, I introduce the technical practices as soon as we have a minimal project management framework in place. They hadn't started their first sprint but already have been discussing how to write JUnit tests.

Scrum master doesn’t need to be technical however I believe, if he/she has technical knowledge will definitely more helpful to the team.
As scrum master job is to facilitate the teams and help them to solve any impediment either technical or non technical.

Daily scrum meeting will also make more sense to the scrum master if he/she understand what’s going on in team in term of technology.
However, I strongly urge that if scrum master doesn’t know technology but he/she must have good knowledge of business.

Maybe knowing what they are doing helps. Non-technical project managers, exactly what you need to sink your projects...

The answer to this question is within the definition of Agile / SCRUM.
Any statement that the SCRUM Master needs to be technical c contradicts the fundamental Agile / SCRUM project objective that is "Delivery of 'value for money' to the customer / end-user within a controllable timeframe or ‘Time Box’ enabling their control (Stop or Continue’) on the project”.
The SCRUM Master (who is NOT a Project Manager) has a number of tasks during the Agile / SSCRUM project and these include (but not limited to):
1. Manage the Sprint Backlog (and associated tasks)
2. Facilitate the Agile / SCRUM plan (inclusive of estimation)
3. Facilitate the Release and Spring Backlogs based on the Product Backlog
4. Maintain and manage the ‘Burndown’ chart and deduce the Release ‘Velocity’
5. Run the daily SCRUM meeting
6. Communicate inbound (to the Agile / SCRUM team members) and outbound (Stakeholders)
7. Remove impediments (Administrative, Technical and Social)
8. Coach the Agile / SCRUM team members (e.g. BAs, Designers, Developers, Testers)
Note: In this context coach means see that Agile / SCRUM practices are followed
9. Shield the Agile / SCRUM team members from the external variables
10. Maintain and display Information Radiators
11. Verify completion (i.e. Done, Done, Done)
12. Facilitate reviews, retrospectives, presentations to stakeholders and end-users
The points above (and others) indicate a ‘full-time job’ with tasks, none of which are associated with the developer’s framework (e.g. Java, C++, C#, .Net) and technical capabilities.
Lastly, the ‘Agile Manifesto is discussing amongst other elements:
a. Trust between the Agile / SCRUM team members (without need for policing)
b. The professional-level of the developers
My suggestion, to all Developers, since you want to be trusted, “do the job right” leave the SCRUM Master to do “the right job”. In effect the best SCRUM Masters are those that are NOT technical.

If Scrum Masters possess technical abilities it might stand in the way of the project.

The core of the ScrumMaster role is in providing process guidance. However, the ScrumMaster must be able to judge whether activities in the team are providing value. In my experience, they cannot do this without technical knowledge.

I don't see so many 'process' people picking up technical skills. The other way around does happen.

So, for my teams, the ScrumMasters are people with a technical background, but with a strong focus on process and teaming aspects.

Many thanks for the points you raised.

I do agree that it is advantageous if SCRUM Masters have some technical background. However, I feel that I should clarify what technical skills / background means (or does not mean):

1. SCRUM Master should not be a Developer (although it is advantageous if he / she understands SDLC)
2.

Jun 30, 2010 5:01 AM by Yaacov Bar-Tor

Many thanks for the points you raised.

I do agree that it is advantageous if SCRUM Masters have some technical background. However, I feel that I should clarify what technical skills / background means (or does not mean):

SCRUM Master should not be a Business Analyst, Designer, Architect, DBA, Developer or Tester (although it is advantageous if he / she understands SDLC). I myself am coming from the Process Engineering / Software Development world and have been a SCRUM Master for over 4 years. It toook a lot of self discipline to learn to trust the team members that they are sufficiently professional to to the job and report truthfully. This has been attained primarly through focusing on my tasks and allowing them to do their's.

It depends on what we mean by technical knowledge... addressing technical concerns by the team would require the scrum master to have been exposed to building software ... in that sense the technical knowledge is absolutely necessary.
where technical knowledge is not necessary is in the choice of the technology and even that is relative ... domain wise is important having a scrum master with only procedural programming background working with a team using object oriented programming might not work very well
At the end I don't believe a good scrum master can be without not only technical knowledge but also technical experience

like any form of "management", someone who doesn't know the job cant manage those who do


i dont care what the latest fad "thinking" might be

nontechnical managers only make a mess when trying their one-size-fits-all approach

scrum is nothing more than micromanagement run amok
daily meetings? gimme a break! meetings, ALL meetings are a waste of time

standup meetings? oh, that makes it ok -- not!

sprints? backlog? stories? cycles? yadayadayada...

the whole 'agile' thing is recycled pointy hair idiocy

From your rant you don't appear to be interested in engagement or actually discussing your thinking. I will just two things: Would you share your name? The other people who commented have.

Scrum as micromanagement seems odd since scrum teams are self organizing. Perhaps you can tell us something about your experience with Scrum? What you do? How large is your team? What process you use and how it works today?

Cheers
Mark Levison
Agile Pain Relief Consulting

Alexandre - Interesting I've had the opposite experience. On one project I was both a technical lead and Scrum Master. As technical lead I had ideas I was advocating for, as Scrum Master I should have neutral. Overall it wasn't my best moment. I've seen few people play both roles well.

Cheers
Mark Levison
Agile Pain Relief Consulting

Yaacov - thanks for your thoughts. Just for a different perspective. You say: "SCRUM Master should not be a Business Analyst, Designer, Architect, DBA, Developer or Tester", I've seen effective ScrumMasters from the BA, Developer and Tester roles. I've seen ineffective ScrumMasters from many roles as well. For me the key is the personality and attitude. Do they understand what impediments are? What will they do to help remove them.

Cheers
Mark Levison
Agile Pain Relief Consulting

Dear Mark,

I agree totally with what you say. What I don't agree with Phloid Domino (if that's is his / her name) is the issue of micromanagement. Where I come from micromanagement is required where incompetency is exhibited. This is in direct contradition to the Agile Manifesto. The biggest hurdle I had was to learn to trust the other team members that they:
1. Are IT professionals
2. Can be trusted to do their assignments in the best possible way
3. Trust others to do their job
4. Are not interested in the administration surrounding the assignment
5. Respect the contribution of others

Otherwise Agile / SCRUM has no meaning. I learned that when you claim to operate Agile / SCRUM there is a period that requires a 'Leap of Faith' until you become converted.

Mark - What do you think about the following experioence in an environment of multiple SCRUM projects where the individual plays Product Owner in one project, SCRUM Master in another and a Developer in Yet another simutaniously - I think it is possible with exceptional individuals, but on average impossible.

One more idea. The attitude of pushing away the individuals that are not SMEs (i.e. Developers) is counter-synergetic and will bring the industry (that follows SCRUM)back into the middle ages.

As a QA trainer / mentor of End-Users, PMs, BAs, Designers, Developers, Testers, etc.) I found it difficult (but not impossible) to change the state of mind of these individuals.

Mark - What do you think about the following experioence in an environment of multiple SCRUM projects where the individual plays Product Owner in one project, SCRUM Master in another and a Developer in Yet another simutaniously - I think it is possible with exceptional individuals, but on average impossible.

One more idea. The attitude of pushing away the individuals that are not SMEs (i.e. Developers) is counter-synergetic and will bring the industry (that follows SCRUM)back into the middle ages.

As a QA trainer / mentor of End-Users, PMs, BAs, Designers, Developers, Testers, etc.) I found it difficult (but not impossible) to change the state of mind of these individuals.

Imho agile processes are futile if the development team is unable to do agile development. I believe agile development is a relatively rare skill.

Therefore, for scrum masters to succeed they need to be technically capable of teaching and mentoring agile development. What do I mean by agile development? Being able to build software with a tool based mentality.

Yaacov - what a load of hypothetical mumbo jumbo!

Do scrum-masters need to be technical? Hmm ... does a mechanic need to be able to drive a car? Strictly speaking no, but chances are they will be a lot better mechanic if they do! So in practice, YES absolutely!