The Scrum Master role is sometimes difficult to understand and implement, especially for organisations with more traditional approaches in organising software development teams. That is because a Scrum Master is NOT a Team Leader OR a Project Manager. The role does not posses the level of authority and responsibilities that come with these two positions.
Simply put it, a Scrum Master is a facilitator both for the Product Owner and the Scrum Team. He is responsible for making sure a Scrum Team follows the values and practices of Scrum. The SM is often considered a coach for the team, helping the team do the best work it possibly can. The SM can also be thought of as a process owner for the team, creating a balance with the project's key stakeholder, who is referred to as the Product Owner.
The Scrum Master removes any impediments that obstruct a team's pursuit of its sprint goals. If developers don't have a good sense of what each other are doing, the SM helps them set up a physical task board and shows the team how to use it. If developers aren't collocated, the SM ensures that they have team room. If outsiders interrupt the team, the SM redirects them to the Product Owner. If the team has not learned how to develop a potentially shippable product increment every Sprint, the SM teaches them Test Driven Development (TDD), or finds people who can teach them.
The Scrum Master
People who are new to the SM role find difficult to understand the apparent contradiction of the Scrum Master as both a servant-leader to the team and also someone with no authority. The seeming contradiction disappears when they realise that although the Scrum Master has no authority over the Scrum team members, the Scrum Master does have authority over the process. A SM can decide for example to change the duration of a sprint.
The Scrum Master is there to help the team in its use of Scrum. It has authority, but that authority is granted to him by the team. A Scrum Master can say to a team, we were supposed to deliver potentially shippable software at the end of each sprint. We didn't do that this time, so what can we do to make sure we do better the next sprint? This is how Scrum Master is exerting authority over the process; something has gone wrong with the process if the team has failed to deliver something potentially shippable.
But because the Scrum Master's authority does not extend beyond the process, the same Scrum Master should not take decisions on what the team should do in order to correct this. He should provide enough support so that the team finds the correct actions (hence the concept of self-organising team).
With authority limited to ensuring the team follows the process, the SM's role can be more difficult than that of a typical project manager. Project managers often have the possibility to say do it because I say so. The times when a Sm can say something like that are limited and restricted to ensuring that Scrum is being followed.
The role of Scrum Master is very important to keep the team members engaged. The SM can be seen as a coach for PO or for every member of the team no matter what the industry is even if it was started in agile software development industry.
This article is part of a bigger topic called: Agile Software Development
Some (final) thoughts