Agile Zone is brought to you in partnership with:

I'm an Agile and Lean Strategist specialised in coaching and managing the transformation of IT departments, from startups to enterprise-scale organisations, to highly efficient, productive and energised environments. I also have experience as senior development manager and architecture governance in large enterprises, especially in the finance sector. Marco is a DZone MVB and is not an employee of DZone and has posted 26 posts at DZone. You can read more from them at their website. View Full User Profile

Software Engineering needs leaders, not ScrumMasters!

  • submit to reddit

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 cleary 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.


Published at DZone with permission of Marco Tedone, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Jilles Van Gurp replied on Wed, 2011/06/15 - 3:14am

Assuming everyone is equal is a big mistake in software engineering. People are not equal. The difference between good and ok can be enormous in terms of productivity. Scrum operates on the premise of self organization. That makes it an excellent match for getting the best out of mediocre/bad teams or very balanced teams. In unbalanced teams (i.e. the real world), self organization has to be a form of meritocracy rather than just a democracy. Every decent OSS project operates on this premise.

If you have good people in the team, it is actually a problem that needs to be managed. Do you really want your best programmer (productivity 20x everyone else on the team) bogged down in arguing with his team on this or that rather than coding? I've seen this happen. The team democratically agrees to disagree with what normally would be the tech lead and goes off and does the exact wrong things. Bad situation, especially if nobody backs up the only guy with a clue. So, don't do that. If the tech lead says foo, than foo it is unless there is a very good reason to do otherwise. It is called trust.

Your tech leads are more equal than your juniors: they get to veto stuff; they get to set the direction; its their call. Do scrum by all means but ensure buy in from your experts and tech leads for any decision. Pair up the juniors, tell them what to do and correct them if they are doing the wrong things, which they will do (all the time). The hard problems always should be lead by somebody competent. 

There seem to be people in the industry that have endorsed scrum as the latest silver bullet. I find this very tiresome to deal with because like with previous fashions (UML, model drive architectures, RUP, etc.) discussions tend to get quite religious and irrational and tend to throw the book at you if you disagree. Scrum is not a ritual (which it seems to be especially in the eyes of inexperienced managers and junior devs) but a pragmatic process that is all about self organizing principles. 



Marco Tedone replied on Wed, 2011/06/15 - 10:49am in response to: Jilles Van Gurp

I find your answer excellent and to the point. It captures the whole sense of my post. Thanks!

Balázs Bessenyei replied on Wed, 2011/06/15 - 2:41pm

SMs have their uses, as any form of management, they can be used to remove most of the paper work and organizational problems. If you have a largish project  with 10+ SCRUM teams + an almost half as numerous testers, organized into several levels (manual, automated, SIT, etc.).

There will be a significant coordination overhead, thats needs to be addressed; without SMs, usually the most talented developers. Will be the ones that have to deal with these things. Because usually they have the most time, since everyone else is too slow or lack the necessary understanding. Which will wastes almost all their time. So SMs can be a great help in this case. With 1 or 2 teams, probably a full time SM would be an overkill. 
In short, there are a significant amount of administrative work, mandated by the different processes, that can be delegated to them.

Usually each team has to have a dev/tech lead and 1 or 2 close second. No matter, if they are acknowledged or not by the actual interpretation of the given Agile methodology. Without their leadership the system would fail. Also in case of larger projects a global technical lead is also necessary, regardless of methodology.

Usually most of the time SCRUM and other Agile methodologies, are utilized in a Cargo Cult manner by the management. Then they are surprised that it didn`t work, their developers starting to flee or they are constantly tired and overworked.

So yes, I agree leaders are necessary. Dedicated SMs can be useful, if the coordination and organization overheads reaches a certain limit.

Zqudlyba Navis replied on Wed, 2011/06/15 - 6:05pm

The SCUM Master should be the one removing all the impediments that developers don't want to have to deal with, like administrative duties such as filling out time sheets, organizing a PC and build environments, attending useless meetings, getting pizzas on late nights, etc.

Basically, a SCUM Master should act as a glorified secretary who is subservient to every whim of a developer, so that the developer could concentrate on what s/he passionately does best.

Kim David Hagedorn replied on Thu, 2011/06/16 - 3:51am

I fully agree that some form of technical lead is necessary for any IT project, BUT...

If this role is formally assigned to any person, it is often not the most competent, but the loudest mouth who gets this role. In the end decisions might be dictated by the less competent but more dominant people. This will kill intrinsic motivation, which, as I believe, is the secret sauce that makes good Scrum teams productive. Even a good technical lead might be less knowing in some areas, e.g. he might be a great database guy but know nothing about web technology, and make wrong decisions that should have been discussed in a team.

It is okay if some form of informal technical lead arises from the discussions that a team has. These discussions are complicated in their own right, but necessary if you want the team members to buy into the decisions made. Difficulties in this process might also be dominant but less competent persons, very competent but also very silent persons, or simply missing respect in a discussion.

And I think this is where a (good) Scrum Master comes into play and why he is necessary even for experienced Scrum teams. It is his obligation to observe how a team communicates, to encourage the silent and to slow down the dominant members, to coach the team in respectful communication, and to enable a situation in which informal leadership works.

Marco Tedone replied on Fri, 2011/06/17 - 10:11am in response to: Zqudlyba Navis

Question: how did all the paper work used to get done before SCRUM came along? I believe that was the work of the Project Manager...The difference though is that the PM historically had decision power.

I believe that every person working in an enterprise environment should get accustomed to some "bureaucracy" work and that it's simply naive to assume that someone else will sort things for you. What happens in real life? Do you have a PA who does all the paper work for you? I don't mean this disrespectfully, just realistically. 




Marco Tedone replied on Fri, 2011/06/17 - 10:14am in response to: Balázs Bessenyei

I hadn't thought of a project running several Scrum teams, probably because in my world each team is responsible for its own deliveries. Maybe, and I'm saying maybe, in this case a SM (for all the 10 teams) might be useful.

But I would still consider the idea of having a Scrum of Scrums where all team leaders meet and coordinate the overall project direction.

Balázs Bessenyei replied on Fri, 2011/06/17 - 3:13pm in response to: Marco Tedone

The administration overhead is significant enough to warrant 1 SM per 2 Teams.  The platform has multiple applications. The primary application is worked on by several teams, fortunately on separate parts. Also there are multiple POs. Some of them are shared between multiple teams. Further more the development teams are geographically distributed as does the business.

Although the functionalities are separated, the components are still depended from each other. The teams are responsible for their deliverables, but they still can`t be completely independent from each other.

Considering the pace of the business (Online Travel) there is a significant pressure from the business side on the PO. Which is translated towards the teams. The pressure includes to commit not fully developed stories, features as bug fixes, hacking the SDLC process, push major features in already released version as point releases. Also there are quite a few process that needs to be managed.
SMs are used for pushing back back most of these attempts. 

SoS is working, but considering the application size and the fact that each team is limited to a specific part of the application. The big picture is only partially visible to each teams, most of the time.
So SoS coordination is only enough for preventing major changes, that would hurt the other teams Sprint commitments.
Inter team coordination of course occurs mostly naturally. In case of tight commitments SMs are used to handle the resourcing part. 

Big picture technical directions are decided at a higher level, than SoS. There is a dedicated Overall Technical lead that accessible to the SCRUM teams for big picture related directions.  There is a weekly sync up, just to make sure that the general directions are followed. Most of the feature level implementation decisions are with the Teams. 
The Overall Technical lead is a highly respected member of the project. Also regularly designs and do actual development. Usually creates components which are needed for the continuation of the project and used by multiple teams. But have no direct business value. Like an unified Configuration Framework. 

The team level Technical Leads are usually selected by a process similar to meritocracy. However in our team the technical decision is usually made with consensus and not by force. The other teams usually operate similarly.

TPMs are also introduced next to POs to bridge the gap between business and developers. The business side more likely believe its own kind than the developers. That this feature is not possible without a few other bigger changes (several sprints or require cooperation of multiple teams), which does not have direct business value (like removing architectural constraints).

Also there are a few no SCRUM teams. Some of them using Kanban. The others are either too small for SCRUM or working a non planable way. Like Performance Testing, Build Engineering, Release Engineering, Database Administration, The Overall Technical Lead "Spec-Ops" team (3rd Party component update, common component development).

Yes, we are keeping up to date with the 3rd Party components. The SCRUM teams thus can focus on business features and not environment upgrades.

So SMs are useful to the followings:
- push back the business as much possible
- handle inter team resourcing
- solve environment related problems (like the Continuous Integration environment died)
- enforce the SCRUM process towards developers and business
- overtime handling (yes, it occurs sometimes or the developers want it to happen)
- status meeting with the business stakeholders

As said before the number of SMs are depending on the size of the project and the complexity of the management structure.
It is a sad fact that the good technical people are bad when it comes to politics and dealing with non technical matters. Even if they are good at this, is it really worth to waste their time to do this?!
No, this should be delegated to people, whose time can be wasted and better at politics than your precious developers.

Shumona Kapil replied on Sat, 2012/02/11 - 12:30pm

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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.