_ Scrum Master in Agile Software Development

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

• does anything possible to help the team perform at their highest level. This involves removing any impediments to progress, facilitating meetings, and doing things like working with the product owner to make sure the product backlog is in good shape and ready for the next sprint
• is often viewed as a protector of the team. The most common example is that the SM protects the team by making sure they do not over-commit themselves to what they can achieve during a sprint (such cases appear in projects with overly aggressive product owner).

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.