Scrum Master is one of three roles described in the Scrum Guide. SM is a servant leader, a facilitator and a guardian of the process. Portrayed so many times, that I do not know if I can add anything else to the topic. On the other hand, I still see so many problems in my organisation about the Scrum Master’s role that I need to stand up and clarify this role once again. I uploaded a little addition at the end of this post. Enjoy!
Scrum Guide’s definition
In the beginning, I would like to go through the Scrum Master role according to the Scrum Guide:
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.Scrum Guide
That’s all. After that, Scrum Guide describes how the Scrum Master can support the Development Team and can give a hand to the Product Owner. Nothing more – nothing else. Maybe this is a problem – because there is so little info in the Scrum Guide about Scrum Master, there is room for adjustments.
… and the sad reality
It is a funny part. From my experience, the truth is quite different, and there are more requirements to Scrum Masters than just that:
- administrate board,
- prepare metrics or charts
- make decisions for the team and represent them
- organise and facilitate all meetings
- Conduct 1-on-1s
- be ready for the worst
- and so on.
In most cases, it comes from lack of understanding the Scrum Master’s role, but it may also emerge from organisational structure, expectations from within the team or managers which end up with whole Agile “Mambo-Jumbo”.
During my career, I faced the problem of Board Master or Jira Guru job. I was the person who can do magic with our bug tracking tool and who have the power of changing the ticket’s status! There was also expectation I will write User Stories (and of course, use the user story template) for the Product Owner and the Development Team. The reason for that was simple – I am a Scrum Master, and this is my duty.
It is not Scrum Master’s job to update the Scrum Board and make sure it stays up-to-date. It is solely the Development Team’s job. Maybe the team does not understand its importance? Development Team has the Sprint Goal to deliver. Circumstances can change every day. A whole team need the moment in time (Daily Scrum) to discuss their progress. They should do it by using the Scrum Board and the information it provides. Because of that, it is their job to have all of the information updated at least once a day. They have to prepare an action plan for the next day based on the most recent state of Sprint Backlog.
Scrum Master provides ideas on how to measure different areas of the Scrum Team’s work, but all these metrics should have one thing in common – they should have a purpose for the team. Measuring what is essential or gives value. Development Team should prepare data for these metrics on their own or use an automated tool to gather them. They should never spend time on something which is not needed – it is waste!
The Scrum Master’s role is not to measure the performance of the team, make reports or prepare such analysis. He should focus on Empiricism. Scrum Master job is to make sure that both inspection and adaptation, are appropriately used by the Scrum Team. They should be using transparent data to make decisions.
Based on the above – Scrum Master shouldn’t make decisions for the team. It should only guide them and present information necessary for the decision making process. Why? It takes away the ownership from the team. Scrum Master should focus on the self-organisation of the team. He should encourage the team to make decisions on their own – to decide on both: WHAT (Product Owner via Product Backlog ordering) and HOW (Development Team via a plan for the Sprint).
As an example, I will use the Management 3.0 Celebration grid. For me, it is an excellent visualisation of different actions taken by the team and their outcome. Everything showed on the scale of the learning curve. Scrum Master, by its stances, should always help the team to be in the middle of behaviour axis.
Failing is learning – however, making the same mistakes over and over again is just stupid…
Meetings organiser and facilitator
Only the Scrum Master has access to the conference room’s calendar, and can organise meetings there.a rule in one of my previous companies
The team should be self-organised. That also means they should know which meetings they need and which ones are waste. There are only a few required events in Scrum framework: Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective (and the heart of Scrum – Sprint itself as the container for everything else). All other meetings are optional. They should be organised if needed and required by the Development Team (to not disturb them during their sprinting).
If the Development Team cannot organise a meeting, because they do not have permissions to put meetings in the conference room’s calendar it should be raised as an impediment and taken care as something which blocks team’s self-organisation. Scrum Master’s job is not to be the team’s secretary
What about Backlog Refinement meeting?
For too long I thought that Product Owner should organise backlog Refinement. It is his job to make sure the Development Team understands items in the Product Backlog to the level required to pick up the job. Let’s move things around. If the Development Team is not able to understand the Product Backlog item, it is their problem. They will waste time during the Planning and then during the Sprint to get that knowledge. Product Owner should not tell Development Team how they should do their work. So Development Team – “you will require that meeting!”.
In general, the Scrum Master should not conduct 1-on-1s as the way of working with the team. He (or she) should focus on the team level as the smallest entity within the Scrum Team. Of course, it does not mean that Scrum Master should not talk with team members in private. It may help him better understand the team and help them grow. This path, however, is very fragile. Scrum Master needs to be aware that people may have shared very delicate information which revealed to the team may jeopardise the trust within between team members and Scrum Master is not an exception.
If you want to have 1-on-1s with your team, please be aware of these issues and be careful with your findings. At first focus on your team and use 1-on-1s to:
- Explain the desired mindset and behaviour, and help individuals see new perspectives and possibilities;
- Influence the individual team members to use Scrum well;
- Help each person take the next step on his or her agile journey.
Barking up the wrong tree
Moment of honesty. All these actions are incorrect in the Scrum world, but we are not working in ideal Scrum world. Sometimes these actions need to be performed by Scrum Master. There are numerous reasons why this happens. Sometimes the reason is simple. The team is new and not experienced, and there are more important issues to solve, and these topics need to be left alone – for now! Scrum Master always should have a plan for how to get rid of these responsibilities and pass them to the proper role. Scrum Master supports the team on the topic temporary. The different issue is more critical at the moment and at the same time, it is transparent to everyone that it will change. Everyone should understand, it is not Scrum Master’s role to manage board or to take the wheel during the review.
Long story short
It is quite challenging to be a great Scrum Master. The work description is blurry and the outcome uncertain. Scrum Values and Empiricism can summarise all the above problems. Once again: openness, focus, courage, commitment, respect and, based on them, Empiricism – transparency, inspection and adaptation. I use them as boundaries for my work. If any of my action may jeopardise these elements, I would rather not like to perform it.
In the end, the ultimate goal for the Scrum Master should be UNNEEDED. Development Team should be self-organised and should be able to handle their issues on their own. Product Owner should have a vision of the product in his sight and should move forward to it. Scrum is a journey to create an efficient machine in value delivery, a piece of machinery able to deliver the best outcome from available resources and workforce. The key to unleash Scrum Team’s full potential is Scrum Master’s work.
I promised a little bonus at the beginning of this post. Here it is. I tried to summarise whole this post with a single mindmap. I used it several times within my organisation to describe Scrum Master’s role. Maybe you can use it too and even extend it. Go ahead!
- https://www.scrum.org/resources/8-stances-scrum-master – 8 stances of Scrum Master by Barry Overeem
- https://www.scrum.org/resources/blog/scrum-master-coach-0 – Scrum Master as a Coach by Barry Overeem
- https://www.scrum.org/resources/blog/scrum-master-vs-project-manager-overview-differences – Scrum Master vs Project Manager — An overview of the differences by Robbin Schuurman
- https://medium.com/serious-scrum/the-scrum-master-729e223f4b64 – A deeper understanding of the Scrum Master’s role by Sjoerd Nijland
- https://www.scrum.org/resources/blog/what-servant-leadership – What is Servant Leadership by Joshua Partogi