The power of shutting up

One of the roles of scrummaster is facilitatig the scrum meetings. Throughout this, the team is expected to come up with answers and solutions to various problems, but often the scrummaster might be in a situation where the team expects him/her to come up with solutions - especially in sprint planning meetings and in retrospects, where the team needs to come up with answers as to "what to do" - either technically or methodologically.

One of the hardest - but most powerful - things the scrummaster needs to do in these situations is to just shut up.

Why is this?

Providing answers can be tempting - it's very easy for a technically-experienced scrummaster to whip up a technical solution to planning a story, or to tell the team they need to pair more or to focus on automated builds to improve their performance during a retrospect.

But doing this could be devestating to the overall team's empowerment - assume that the scrummaster would introduce a technical solution to a problem. The team would be very glad (hey, they just got a free solution without needing to think about it, right?) and would go ahead and work on it. But what happens if during the sprint the solution seems to not exactly fit the problem? what if a change in plan becomes necessary? the team would probably either:

a) go back to the scrummaster saying "Hey look, your solution is giving us problems. what should we do now?"

or b) assume the scrummaster's solution was really profound and insist on doing it even if it doesn't fit. Essentially breaking the agile value of "Adapting to change over following a plan" and effectively slowing the team down.

We can see that both of these scenarios would be bad - asking the scrummaster what to do next would start a vicious circle of relying on the scrummaster to provide even more solutions, effectively turning him/her into a team lead. The team would take little to no responsibility for this solution since it was the scrummaster's idea.

On the other hand, insisting on going through with the plan even if it doesn't fit the problem would cause lots of waste for the team - and stop them from seeking a probably better solution which would be easier and more time-effective for them to implement.

Old news

We know this situation in other fields as well - in parenting, we're often asked by our kids to help them with homework. The quickest and most tempting kind of help is just giving them the solution to a homework question. (1+8*9=? oh the answer is 73). However many parents already know this is the wrong thing to do - it doesn't really help our kids find the solution themselves, and so they would have a hard time solving other homework problems and in the end we'de be doing them more damage than good.

The proper kind of help we can provide is guiding them into finding the solution themselves - "let's see, how did your teacher say you should solve this question? what happens if you break down the exercise into smaller parts? how did you solve other similar questions? How about taking a break and trying again later?". Guiding our children to find the solution themselves is much more rewarding for them and gives them the power and ability to solve other problems themselves, and in the long run is the right thing to do.

This is also a key factor in personal life/work coaching - the coachee is expected to know and have the power to solve his/her problems, whereas the coach's duty is to lead the process and light the way. This is a key difference between coaching and consulting - a consultant is expected to provide solutions, while a coach is required to refrain from it, in favor of empowering the coachee.

There's more than one way to skin a cat:

Keeping silent sound easy - but there are many subtle and creative ways to refrain from intervening.

Here are a few:

1. Redirecting the question:

If a team member asks the scrummaster what he/she thinks they should do - redirect the question to another team-member . "John, what do you think Sarah should do?", "Sarah, what do you think about the solution John just suggested?"

2. Reflecting the question back :

If the team is asking the scrummaster a question -  sometimes just repeating the question back to them provides a different perspective - when they hear the question being asked they take the role of answering.

Sometimes writing the question on a board or paper or drawing a picture of the problem can provide the team with a new perspective.

"- Mr scrum-master,  how can we make the database distinguish between 8 oranges and 8 apples?

- Let's see (writing down: "how to distinguish between 8 oranges and 8 apples?")

- Aha, we can just put the string "8 apples" or "8 oranges" in the database, that should do the trick!"

3. Pointing in the right direction:

Sometimes the scrum-master will see something the team can't see at the moment. 

For instance, the team might have had a hard sprint where in the last day of the sprint they had to redo 3 days worth of work because they found out it was breaking something else. During the retrospect the team might ask the scrum-master what they could do about this - so just pointing out the fact that the team was having a long feedback cycle might get the team an aha moment, realizing they should do regression testing earlier,  breaking down the development into smaller baby-step cycles.

4. Making it a team decision:

A team-member might come up with an idea which other team members feel uncomfortable about. Furthermore, the scrum-master might be approached as a referee - asking him/her to decide for the team.

In this case the scrum-master can immediately put it up to finger-voting - "Sarah is suggesting you all start using XUnit instead of YUnit. Does anyone have an objection?" if someone does, go ahead "Ok, John, you objected so you need to come up with an alternative suggestion. What'll it be?"

The team will quickly realize it's up to them to both decide and stand up to the decisions, and will pick up on the collective decision making techniques through this.

5. Reminding of the principles

When approached with a concrete question, the scrummaster can point at the principles and values of agile, scrum or the team's own principles and let them figure out what to do that can fit.

For instance, the team might ask the scrum-master what to do if the PO doesn't answer emails with questions they need answered. Reminding them the principle no. 6 of the agile manifesto "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation" will let them realize they probably just need to go and talk to the PO in person. 

The fine line between facilitating and teaching:

No doubt there is a fine line to walk between neutral facilitating and active teaching - some of the silences mentioned above are a good teaching opportunity for the team - reminding them of the principles, getting them better at problem solving or teaching how to get a team decision.  The more opportunities the team and scrum-master have to do this the better - leading to an overall stronger and more performing team, reducing the chances the same dilemmas will reappear in the future.

Do we really need a Yoda?

Some might question why we need a scrummaster to attend the meetings if he/she "doesn't actually do anything", especially upper management that needs to pay the scrummaster to just sit there.

For highly performing and experienced teams it might be unnecessary - they will have learned and gained both skill and team dynamics of figuring out everything for themselves. However for most teams - especially teams starting out with agile and scrum - just throwing them into the water and letting them figure it out themselves can be as devastating as providing the solutions.

It's like telling your kid to "just do the homework yourself" - you might find he was getting the wrong answers, hiding it from his teacher and getting no feedback as to how to get the work done right. Or even worse - feeling unsupported and thus resentful to both the schoolwork and the neglective parent. 

In professional programming these feelings can result in an excuse to doing sloppy work, hiding away problems or just getting the team-members demotivated enough to leave the workplace and go seek a more supportive one.

When in doubt... believe.

A scrum-master is just a human being, and so can be doubtful and fall into the same traps as the team. Often or not, the scrum-master will doubt the team's ability to find the right answer themselves, or will feel tempted or pressured to just give the team a solution.

When this happens, try and re-believe in the team - recall their past achievements and unique abilities, be impressed with their insights, take pride in their achievements and celebrate their successes. Keep a positive, supportive and patient attitude. Reflect these to the team members themselves - remind them of their strengths, of what went well, of how they handled similar dilemmas in the past. And don't forget to believe in yourself too - reminding yourself of the progress you've helped the team make by letting them shine on their own.