The necessity of the scrum master role
In one of my past articles I briefly mentioned the roles in a scrum team. One of them is the scrum master who guides the team to be successful applying scrum. But why do you need this role? Asking from a different perspective: what happens if you remove the scrum master from a team?
I worked in teams with and without scrum master. I even was a part-time scrum master myself for some time. Experiencing work from those very different perspectives gave me the possibility to understand the value of a scrum master (how you call this woman or man doesn't matter).
Important tasks of a scrum master
Let's have a look at what important tasks a scrum master does in my opinion.
Observing and asking questions
For me the most important work a scrum master does is observing the team in what it does and especially how. She tries to have an objective view on the happenings and asks questions that you as a team member usually do not challenge. Those could be:
- Why have you solved the problem in this way?
- Have you tried x?
- If you are stuck with your current approach is there an alternative that you haven't considered, yet?
Sometimes you just have to talk to somebody else about what you tried to come to a better solution.
Recapitulation
Another very important point a scrum master takes care of is to carefully force the team to recap in facilitating retrospectives or asking targeted questions. Of course, besides that the scrum master also takes care of organisation, preparation and coaching.
A team without a scrum master
Those are just some points that have to be done by other team members if there is no scrum master in the team. Usually, as engineers and developers do not want to deal with those tasks, they do not get done.
The result is a team that focuses on the usual work that was planned and is written down in a road map - or just daily business. In my opinion this is a sad place to be. The team focuses on working, having the same workflow as ever before and not having the support to recapitulate.
By that I especially mean that issues are not just raised - this usually works quite well - but also taken care of, that somebody gets the time and also the energy to improve. If the majority of team members do not want to do this even motivated co-workers with an attitude towards improvement will lose their belief that this is even possible in their environment.
In my experience, the fact that you not only speak about what you dislike about the current approach of doing things but also act to make them better is a key point. It is this one important step further that some teams miss as it involves hard work, time and energy but also a mindset that makes change desirable. Considering change the environment - other teams, management, the whole company - has to support this notion of work, too.
Often change is hard. Particularly if it means changing old structures and workflows that have existed for years already. However, not doing it can limit what you can achieve as a team.
What is your experience working in a team without a scrum master? Let me know in the comments below.
Post image taken by Laura Castro published under CC BY-NC-ND 2.0.