Software Engineering needs leaders, not ScrumMasters!

I recently reflected on SCRUM and the role of the ScrumMaster. We know that a ScrumMaster should act as a servant-leader; she should provide guidance but not decisions, removing impediments yet empowering the team: in a word, the ScrumMaster should act as a facilitator within the team, shielding the team from the outside world, ensuring that the team follows SCRUM best practices.

We are also told that a SCRUM team should not elect a technical lead, since everyone in the team (with the exception of the ScrumMaster and Product Owner) should have the same responsibilites.

First, I think that no matter what SCRUM says, in any team at least one technical leader is destined to emerge; this happened in every single team I worked in. There is always someone who naturally takes the technical leadership and to whom team members look up to for decisions; I think it is right that this person(s) shoudl lead the team. This clearly contradicts what SCRUM tells us and therefore I simply believe that in this respect SCRUM has got it all wrong.

Secondly I think that, with the exception of teams approaching Agile and SCRUM for the first time and which would benefit from a ScrumMaster / Agile coach, the figure of ScrumMaster is unnecessary; I believe that experienced Agile teams know very well how to use Agile (SCRUM) tools and don't need a facilitator to tell them what to do. Sprints, TDD, pair programming, retrospectives, team responsibility, etc. are all normal capabilities of an experienced Agile team.

What is a servant-leader anyway? Look but don't touch? Touch but don't taste? Taste but don't swallow? No, I think that the old nice concept of team lead / technical lead still holds true for most of the situations I worked with and that this represents a natural evolution of any team.

We should delegate to the team the role of self-organising Sprints, removing impediments (more of a lean approach if you wish), grooming the burnup or burndown, run retrospectives, etc. I think the concept of a ScrumMaster goes very much in the direction of a Marketing campaign, where the typical consultant was suddendly able to re-sell herself as ScrumMaster, as an Agile coach, as a facilitator.

Software engineering doesn't need grey figures, which are there but whose presence can't be felt, who take responsibility for only part of what the team delivers (e.g. the observation of SCRUM practices, the removal of impediments, etc). We need people who can act throughout the whole project lifecycle, who can take decisions front-to-back, who can take the responsibility of driving the team towards a clear direction even when the team thinks the direction should be another...We need leaders, not marketing campaigns and labels.

 

Comments

[Vlad]

That's 100% true and I totally agree with you on your thoughts.
While working on a project for an ex-company I used to work for, there was this idea of having non-technical ScrumMaster to "guide" the Agile process for different project engineers. This doesn't work as the ScrumMaster was having no responsibility, and no project engineer will look up to someone that isn't more skillful than themselves. In any team, I successfully worked with, the ScrumMaster was also the TeamLeader, and the people accepted his role as he was working as hard as anybody else, not to mention the technical expertise the TeamLeader is projecting into the team.

So, you can't just have a ScrumMaster, whose role is just to have 15 minutes meetings and who doesn't take any responsibility of the undergoing project. You must have experienced TeamLeaders to guide the software design, implementation, and to coach his team the best he can.

[Marco Tedone]

Vlad I mostly agree with your view...I was not saying that according to SCRUM bibliography SM don't take any responsibility, on the contrary one will read on many resources that good SM take responsibility for the success of the delivery. However it's the kind of responsibility assigned to them which I don't like, and the role in general...As you say, the team will look up to and follow who works with the team for the technical delivery of a project, who not only knows what the team is doing but also how to lead the team in the best technical choices...In a word...A leader.

[Vernon Stinebaker]

Disclaimer: I am a Certified Scrum Trainer, so I have a biased view in favor of Scrum.

So, you know something about Scrum, but there still appear to be some gaps in understanding. First, Scrum is not an acronym, so there is NO NEED TO SHOUT IT.

Scrum encompasses more then just roles, and roles should not be confused with titles. In fact, much of the disfunction we see in teams 'doing' Scrum are closely related to his confusion. Scrum requires cross-functional teams, but this does not require 'everyone on the team does the same thing'. No where in Scrum is it stated or assumed that natural leadership (technical or administrative) will not emerge. It is expected. It is not, however, a 'title' that places someone in a 'superior' role. It is a natural emergence. Also, in my experience, those how have the strongest technical abilities are often poor at 'leading the team' and in many cases have no interest or capability in this area; so I don't agree that 'it is right that this person(s) shoudl (sp) lead the team'.

Scrum, just like other approaches to product or project delivery is not a panacea, however it is useful to seek to understand not just the superficial mechanics of an approach and to pass judgement. Indeed it is exactly this type of superficial understanding and application that leads to the very problems you are associating with what "SCRUM has got it all wrong".

Respectfully,
Vernon Stinebaker, CST

[Marco Tedone]

Vernon, thank you for the pointer to SCRUM not being an acronym, so there is no need to shout it.

Your blog is a thorough defence of Scrum, whereas my blog is about a critic to the role of SM within Scrum. Please note that I used the word "role" and not "title".

In my post I have never stated that Scrum 'requires everyone on the team to do the same thing', that was a comment to my article, so if anything you should reply to the person who commented to my post rathen than me.

In my experience a technical leader is not just somebody who has got excellent technical skills, but someone who knows how to use them to drive the team to excellence, occasionally is well connected exactly because of the respect she commands within the working environment, and I think that this person should lead the team providing "decision making" rather than guidance...The role Scrum attributes to SMs (correct me if I'm wrong) is one of guidance and not decision, is one of removing impediments, ensuring Scrum practices (and best practices) are followed; entire books have been written about Scrum coaching, how a good SM should be "invisible" to the team. Excuse me, but I believe that, with the exception of teams which have never met Scrum before, the role of SM is overstated (and overpaid if you allow me). Technical leaders are usually chosen by organisations as a consequence of a long-serving, demonstrated and demonstratable ability to lead teams and when an organisation moves to Scrum I find it natural that a firm elects these people to the role of team leaders. I think it's far more appropriate for a Scrum team to have a well recognised, respected and acknowledged "Team leader" than a "Scrum Master" (this of course, and as already stated in my post) when the team has already got extensive knowledge of Scrum practices. As I said in my post, my experience is that teams require leadership, not just guidance and someone who removes impediments. In a good team someone with the natural ability to remove impediments will emerge and take on the role naturally.

If you read my article more carefully, you will notice that I have never said that "SCRUM got it all wrong" as if nothing in Scrum is right...My sentence was put in the context of the SM not telling the team what to do but just act as a facilitator...

[quote]I think it is right that this person(s) should lead the team. This clearly contradicts what SCRUM tells us and therefore I simply believe that in this respect SCRUM has got it all wrong.
[/quote]

Respectfully,
Marco Tedone

[Martin Harris]

Some interesting thoughts provoked there. Much along the lines of this great and tongue in cheek article:
http://blog.assembla.com/assemblablog/tabid/12618/bid/71263/Tech-Leads-will-Rule-the-World.aspx

There is a great point made in the assemblablog though. This idea that the technical lead is more useful in organisations that have little choice but to distribute teams.

I believe its more complex though. Sure natural leaders emerge, why would they not? We should not discourage it either as long as its leadership and not dominance of one individual over the others.

Scrum masters have a role sometimes as do agile coaches.

For instance scrum, kanban etc seem to work well when your doing it with a few teams. As you scale things it gets harder. Then after some success you find one of the teams just does not "get it" and fails to transition.

One reason for this is there is nobody looking after the process end to end. Things bubble up in the retrospectives that the team alone cannot solve. Perhaps it needs other teams to collaborate.

Scrum masters, technical leads...all well and good but to solve those kind of issues you need a forum that is wider than the team. I have found in the past that finding these people and binding them into a group that comes together sometimes to solve these bigger issues gets your organisation over this issue of scale.

So for me, it does not matter if you have scrum masters or technical leads or both as long as you have people who lead and who can talk freely to other leads to solver the bigger issues.

[Jerry]

If there is a transition course for a Scrum Master to become a Kanban (or whatever) Master, it'll be very hot soon. :-D

Marco, many people see it now, but you're the man spoke it out ages ago.

[Joshua Partogi]

Marco,
Have you taken a Scrum Training before? Or did you just read about Scrum from somewhere?

Kindest regards

[Marco Tedone]

I just learned Scrum by myself "on the field" few years back and practised it ever since.

[KoW]

"...
We are also told that a SCRUM team should not elect a technical lead, since everyone in the team (with the exception of the ScrumMaster and Product Owner) should have the *same responsibilites*.
..."

Wrong assumption: a Scrum team has some shared responsibilities, but not everyone in the team has exactly the same ones.

The emergence of special roles (e.g. tech leads) is a natural process. If a team chooses to elect a tech lead, it should be accepted by all stake holders.

[Jenny Cohen]

From my experience it's really tough to work under someone who knows less than I do in the area. Well' it just didn't work in our company. I also agree though that it's a natural process. There are all kinds of training courses for SMs now, so maybe that should change something.