Simon Baker (@energizr) recently tweeted “If ur a scrummaster protecting the team is a bad move. Help the team fend for itself. Shielding ppl from the big bad world creates ignorance” (04 Sep 2012). Simon might be right about creating ignorance, but the Scrum Master as a shield might also be good for delivering the project.

Actually I found Simon’s tweet interesting for three reasons:

1. It contradicts Scrum orthodoxy
2. It prioritises staff development over delivery
3. It could result in a “just say no” team culture

Agile contradiction

Mike Cohn, a Scrum colossus, characterises Scrum Masters as “shields”. This is because Scrum Masters should help by “by protecting the team from outside distractions” (Mike Cohn: Check in don’t Check up).

So we’ve got a Scrum heavy weight saying shield the team. On the other hand a major Agilist from the other side of the pond says shielding creates ignorance. I pity the poor Agile novice who is trying to make sense of this.

In this particular case both Mike and Simon are right. They agree that somebody should shield the team, they just disagree on who does the shielding (Scrum Master versus Team).

Staff Development versus Delivery

The orthodox Scrum approach has the team doing the work, building stuff, and the Scrum Master ensuring they are free to build that stuff. This, in my book, is putting the focus on software delivery.

But there are times when an organisation might want to sacrifice some efficiency on software delivery for longer term benefit. For example, having a junior programmer work on a task is always going to be slower then a more experienced developer. But doing that work is how the junior will grow and gain experience. Slower in the short term (e.g. for a project) but better for the organisation in the long term.

Simon’s advice to “Help the team fend for itself” kind of fits with this. Rather than being the shield the Scrum Master now spends time training up some novice shields. However I think the value to the organisation of more and better shields is less apparent than the example of gaining experience in programming.

Just Say No

A naive software developer is going to say “yes” to outside influences. It is human nature. In contrast a naive Scrum team member is likely to just say “no”. That is because an Scrum training says to say “no”. And to be fair saying “no” is often the right thing. But not always. And a just say no culture is bad, bad, bad.

Political judgement

I believe that responding to influences outside the team requires some political judgement. The right response might be “no”, “yes”, “maybe”, “later”, “you realise that this means …”, “what will you drop to get it?” “what do we get in return?”, “have you asked Jim?”, “lets talk about it over lunch”, or any number of other options. Gaining that judgement takes time. Longer than the duration of your average project. So I think the team would be better off with a more experienced person, the Scrum Master, running interference for them. The junior might give it a go next project – it depends on the priority you put on delivery over staff development.