A ScrumMaster (SM) has to ensure that all impediments are resolved. Impediments could be as small as the Air Condition is a bit too cold or could be as big as team members become overly stressed and start fighting with others.
Thanks to Bas Vodde, and his informative SM course, there are basically 5 moves that one could perform and combine as a SM when his team face an issue. They are:
- Actively do nothing.
First glance at the list, there is absolutely no move that directly resolved the issue, this is a common mis-perception that SM will resolve issues for the team. A adequate SM will do that, while a great SM will help the team to do that; to make the team more self-managing, self-learning.
Let's elaborate on these 5 special moves:
SM makes plenty of questions, those questions should be simple and direct. For example, if two members have a code issue, SM should gather both of them in a room and just ask "Hey, can you two talk to each other about the code?". Even if the SM have the solution, he should not just throw a solution unless it is inevitable. After asking them, SM hears their opinion and facilitate the talk :) Yes, facilitate. That's the 2nd move.
SM facilitates all of the official meetings and informal and sudden meetings as well (like the example in the "Question" part). For example, if the team has a hard time to estimate using Poker Planning over an User Story, (some says 5 story points, others insist it is 21 points) the SM has to facilitate the estimation by asking the team to refer the estimating US to the anchor US.
Issues like some team members say "hey, writing automation test takes a lot of time, let's just do manual test." These issues are suitable for the "educate" part.
A SM also educates the Scrum team about the Scrum process. SM educates Product Owner about the importance of Grooming Backlog meeting or Team Members that they are one cross-functional team etc...
4. Actively do nothing
This is my favorite move. The best lesson that one can learn is from the mistake that one make.
Sometime, SMs tend to be nosy and want to show "team work" spirit by getting involved in all of the team issues. This makes the team depend on the SM and unable to solve problems without SM help. Sometimes, a SM recognizes the team is heading the wrong way but let them do it anyways so that they can learn from it.
I was SM of a team once, and they said Daily Standup Meeting (DSM) was not useful and decided not to show up. I decided to keep silent and did nothing about that, after one sprint of no DSM, many of that sprint features fell apart (code conflict, redundant; QA and Dev didn't share the same view); at the sprint retrospective, I told them why the sprint failed, they then learned about the importance of DSM and from then on always showed up with even better preparation.
This strong action must make sometimes if the team is heading a very wrong way and can bring a horrible result.