Scrum Master as a Servant Leader

Scrum Master as a Servant Leader


“If you have an empowered, self-minded development team, how can you make sure they are doing it right?”


This was a question raised by one of my delegates on a Scrum Master training course last week. He was concerned about the danger that if the developers are empowered to decide how to deliver software, they could choose to deliver in a way that breaks the Scrum framework. As an illustration, he assumed that his development team would be having a Daily Scrum while he was away on the course, because he wasn’t there to enforce the rule.


There is an initial obvious response to the question and that is that you cannot “make sure they are doing it right”. To enforce rules upon the team disempowers them. Presumably, this is exactly what had happened with this team. They only held Daily Scrum events when the SM was there because they were told to. Consequently, if the SM was away, the team were not able (or not motivated) to organise the event themselves. Empowerment is essential for the success of a Scrum software development team (just as it is essential for a successful rugby team, from which Scrum originally took its inspiration)


There is a potential tension. The Scrum Guide is very clear that to benefit from Scrum you need to apply the whole framework. Part of the framework is the Daily Scrum event, so if you miss that, you break the framework. It’s not about just doing Scrum ‘right’ for the sake of it or about obeying the rules per se. It is that the framework only ‘works’ when it is complete. If you break it, you don’t get the benefit. However, another part of the framework is the empowered, self-organising team. If you disempower the team by telling them what to do, you break the framework that way instead.


There is a solution to the quandary though and that is for the SM to fulfil the role of “servant leader”. Servant leader is the primary description of the SM role, but I’m not sure that it is always fully appreciated by those working with Scrum, even by many SMs. It is the job of the SM to lead the team, to make sure they are going in the right direction, which, you should expect, would mean they adopt all parts of the Scrum framework. However, the SM exhibits servant (not autocratic) leadership. The SM doesn’t tell the team what to do, but rather seeks to help them do their best work.


One of the main misunderstandings I see in regard to the SM role is that people often see the role as either a servant or a leader, but not necessarily as a servant leader. That is, the SM is either someone who runs around arranging stuff when the team need it, e.g. room bookings, or the SM is effectively managing the team, by dictating how and when they should do things, Neither of these approaches benefits anybody, and certainly aren’t consistent with Scrum.


There are many characteristics of a servant leader that could be helpful in our samples quandary, here are a few examples:

  • A servant leader has effective listening skills. If a team expresses dissatisfaction with the Daily Scrum, a servant leader SM seeks to hear and understand their point of view, not simply assert the Scrum rules.
  • A servant leader influences through persuasion. The servant leader SM would seek to help the team understand why Daily Scrums are essential to the delivery, pointing out what is gained.
  • A servant leader is good at  building communities. The team would hold Daily Scrums because they are committed to one another, aided by the servant leader SM, even when the SM is not around.


It is interesting that the Scrum Guide is very clear that the SM does not need to be at the Daily Scrum. It is an event for the development team only, to ensure they are on track to meet their goal. The guide assumes that the team will want to do the Daily Scrum, because the SM, as a good servant leader, has helped them to do understand the benefits of this. The same principle applies to all aspects of the Scrum framework.


Like Scrum itself, this idea of a servant leader SM is easy to understand but much harder to actually implement in real life. The concept of servant leadership itself may be quite contrary to many organisations that favour a more traditionally autocratic leadership style (which many organisations do).

However, just because it is hard doesn’t make it not worth pursuing. SMs often focus on getting the technical details right, making sure the events happen, we’re using the right artefacts etc, but being a servant leader is as much part of the Scrum framework as any of those things, so maybe this is an area worth having a closer look at.