The non challenging Scrum Master

Earlier this year I was invited to join the Scrum plop, to help write some patterns for the Scrum community, unfortunately the stars were not right and I was not able to attend. It did however help me answer a question that a great friend and fellow Agilist Sandy Mamoli put to me, which was "how do you make your blog posts smaller?"

This got me thinking that I could post some of my pattern ideas as individual posts get some vigorous feedback and test both the pattern and my understanding of Scrum and other Agile ideas.

If anyone could give me tips on a simple pattern format that would be great too.

The non challenging Scrum Master

Inexperienced Scrum Masters regularly forget that they can challenge the team on practices, and adopt a whatever the them says must be right approach instead.

This is most apparent at the Daily Scrum (Stand up). While team members are planning the day's activities one or more team members will mention activities that both an inexperienced team and Scrum Master will not challenge.

For example:

• Doing work not on the visible workspace


• Skipping elements of done


• Starting a new story when they could work on an incomplete one


• Ignoring defects on a story

My coaching solutions

Direct approach

Often when I am working with a new team I make an agreement with the team that I get to speak at the end of the Daily Scrum.

So in this case I would challenge John with the line I used above but also start with something like this. "Ok so remember when John skipped the automation and went on to the next story, if I was the SM I would have asked him "blah bah". This helps on two levels, it reminds the team that it is ok for the SM to do this and it also allows the SM to see how to be non threatening while still owning the practices.

Indirect approach

My other approach to this is to make a list of the things that the SM missed and work through them in private, getting them to practice. Repeating this for every daily scrum until they are confident on their own.

The trick is here that it's a fine line between, "John we all signed up to the definition of done, skipping the test automation is part of it, are there any impediments stopping you from getting it done before you start the next story?" and "Ok John you are going to work on the test automation today and you will not be starting anything else until I am happy with your work"

Essentially both statements the same, "hey John, what are you doing skipping the DOD!", it's the method of delivery that's different, the vagaries of servant leadership muddies the waters to. Many Scrum Masters often confuse servant with silent partner.

So to sum up, it's ok to ask a team member why they are doing something when it appears to contradict your practices, just remember to ask not tell.