Learn more about Velocity Partners offshore software development company.

I’ve been writing a bit “around” the role of ScrumMaster lately because I don’t think most folks fully understand it. And by that I mean, they don’t take it seriously enough – don’t view it as a serious and necessary role within Scrum teams. I find that to be an unfortunate view and I want to do my best to at least speak to Scrum Mastery as something of value.

 

Kelvin Lawrance published the following article on LinkedIn around the end of 2015 –

In it he was searching for feedback related to the technical skills and competency required for someone to be a solid ScrumMaster. Kelvin’s position is that the ScrumMaster role doesn’t have to be technical (writing code) in order for the ScrumMaster to be effective.

And he references the following article that has a different perspective –

Manjit shares some personal experience about how a lack of technical skill made her feel ineffective as a ScrumMaster. That she didn’t necessarily know what’s being discussed and often felt feel left out.

I would agree with that. But, I would say that other members of the team probably feel the same way (testers). What I normally recommend is that everyone engage on the team in listening, collaboration, and learning. I suspect that over time, Manjit’s comfort level will improve. And not only is this her job, but her team should be helping her to feel more and more comfortable within her role.

And here’s a quote from a CST discussion group. The question surrounded the size of CSM classes. The contributor will remain anonymous, but the spirit of the comments lands on one side of this question:

I used to dislike private courses, but now I prefer them. For some reason my public courses are attracting a disproportionate number of washed up project managers just wanting to add “CSM” to their resumes. I had a public class where hardly anyone could write a line of code; we had to recruit developers from the venue host to get through some of the exercises. In private courses I get to meet people who do the real work.

The comment made me quite sad from a variety of perspectives, not least of which is the fact that a Certified Scrum Trainer has such a skewed view of certain roles. I would expect much more maturity, respect, and balance from such an influential person in our community. But then, there is dysfunction everywhere…

My Take?

I fully understand the “essence” of the ScrumMaster role. Not only from my 15+ years of coaching, but also from a careful reading of the Scrum Guide. It is not a coding practitioner or a technical role. In fact, I agree with Kelvin and think that often gets in the way.

I sometimes joke in my Scrum classes that I could walk into any organization on the planet without a clue.

• Without a clue of their technology stack
• Without a clue of the organizational structure
• Without a clue of their business domain

And I believe I could still be a highly effective ScrumMaster.

How you might ask?

Because my effectiveness would be solely dependent on the team and on my facilitative skills. I literally couldn’t get in their way or second guess them. And I couldn’t influence their technical decision-making. I’d have to rely on their experience to solve their challenges.

Yes, I would need general skills and competence within software development organizations. BUT, do I need hardcore development or architectural chops?

I’d say no.

In fact, I’ve noticed a reverse phenomenon. That these skills, so valuable for developers, can actually get in the way when you’re assuming the ScrumMaster role.

It can get in the way…

Quite a few years ago I spent a little time coaching at Siemens Healthcare. At the time, they were perhaps the largest Scrum instance in the world. They had approximately 120 Scrum teams and a pool of about 150 ScrumMasters spread across three primary application divisions.

One of the decisions they made was that ScrumMasters could only come from the development-side and their roles were mostly Technical Team Leads.

While this wasn’t a terrible decision, you can imagine that out of 150 ScrumMasters, some really didn’t understand the true essence of the role. Many of them overpowered their teams by basically telling them what approaches to take technically. Often they would overly influence estimates and who was tasked with doing the work. And all of this was related to their technical knowledge AND their being assigned to the ScrumMaster role. They inherently viewed the role as a leadership one rather than a facilitative one.

I was part of an assessment team and one of our recommendations was to consider other roles as ScrumMasters. First, to get more balance, but also to see how other functional roles approached it.

Over time, they noticed that testers made as good if not better ScrumMasters than developers. They were better facilitators, had a broader view of the products, asked better/more questions, and had much better soft skills. They also seemed to be more inclusive of the “whole team” when collaborating.

Wrapping Up

Clearly there isn’t a single answer here. I’ve seen outstanding ScrumMasters who were highly technical and others who weren’t.

I suspect that’s a bit of an answer unto itself. That is – it depends on the person and the context.

But I also believe it’s a greater challenge for highly technical individuals to assume that ScrumMaster role and STILL be effective. So the maturity and experience level of the ScrumMaster needs to be greater the more technical they are.

Or at least that’s my experience over quite a few years of coaching.

Stay agile my friends,

Bob.