Let us talk about what A ScrumMaster is really about

I once attended an advanced ScrumMaster training. The trainer brought out the following pictures and asked us to discuss what the role of a ScrumMaster was. 

The answer? All of them! A ScrumMaster is so many things, he/she is a sports coach, a loving parent, a sheep dog, a servant, a bulldozer, an orchestrator, a meeting facilitator…

I wonder why the trainer didn’t include this picture:

The software industry (at least in China) is young male dominated, there are software companies who hire young pretty girls whose job is to talk to young mail engineers, motivate them and make them happy. If a ScrumMaster is also a cheerleader, wouldn’t be fantastic? :-)

But enough! Software engineering is hard enough, having this mushy, fluffy talk doesn’t help! A good ScrumMaster might need to be all those things (but a loving parent, really? How condescending!), but if you can produce a “certified” ScrumMaster after a two day’s training (plus some hefty training fee and an exam), that is a miracle!

Instead, let us get down to the earth and discuss what skills a ScrumMaster should have. In my opinion, for a ScrumMaster to be effective in facilitating the team, he/she needs to have a certain level of knowledge in every function of software development, including: 

•  Technical skills: software engineers are notoriously snobbish, they will respect you if you possess the skills that can participate and help them, they will not respect you because of your position (they might obey you for some time until they find another job, but it won’t inspire them). To build rapport with the team, a ScrumMaster needs to at least have a degree of technical knowledge to earn the team’s respect and is able to facilitate and participate the team’s decision-making.

• Business knowledge: in an Agile environment, defining/refining requirements is an integral part of development process, product owner acts as a proxy of users, and works out the details with team. A ScrumMaster needs to have a degree of business knowledge to be able to facilitate the team.

•  People management and leadership skills: in a traditional team, team members report to functional managers, and a project manager resorts to functional managers to impose control over the team members. An agile team is cross-functional, and it is expected to be self-organizing, but before it can reach that point, it requires much stronger leadership skills to build up the team, especially if a team is newly assembled from different component based teams in a traditional environment.

• Process improving capabilities: An Agile team is expected to improve practices as it conducts its business. Copying practices from textbook is doomed to fail. A ScrumMaster is not just a “retrospective” meeting host, he needs to have the capability to lead the team to do deep root cause analysis and come up with ideas to improve the process. 

(update on 2016/06/30):
I had an interesting discussion with my colleague on this. His opinion is, "no, the most important skills a ScrumMaster should have are communication skills and facilitate skills". I do not deny that a ScrumMaster's job is to facilitate the team to make it function better (despite what those mushy pictures describe), but my opinion is: to facilitate a team effectively, a ScrumMaster needs to have the above skills.

I reflect on a lot of discussions I had with my team, a lot of goes like this:
Me: "wait a minute, that is a 4th idea, let us park that idea, and first discuss through these ideas..."

Me: "we have discussed this idea, it is essentially the same as ..."

Me (interrupt someone): "please let him finish his thoughts, there is something interesting there, afterwards, you can bring up your opinion."


 Software technology is very intense, I am not sure if I hadn't possessed a certain degree of technology skills, I would be able to identify the 4th idea, and direct the team to have an effective discussion. What I have observed is that the team members usually think very quickly, jumping from idea A to idea B to idea C, and often times go back to idea A (in a different form), the facilitator needs to setup a structure to make sure team members discuss through ideas thoroughly, and everyone has an equal opportunity to voice their ideas.

A meeting happened yesterday run like this:
team: adding a checkbox in UI is very difficult 
Me: why?
team: because this UI uses a technology ... (I have very little idea what that is)
Me: who is using this UI?
team: administrators 
Me: does an administrator have to use this UI? 
...
Long story short, this is a discussion that uses business knowledge to select/define technology approach.