A deeper understanding on…
The Scrum Master
Road to PSM III — Episode 7, part 1.
“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 Guide
Where to start
Understanding and explaining the role of the Scrum Master should be simple. Surprisingly, I find it very difficult to explain to others what exactly a Scrum Master does and what makes a good Scrum Master.
Even though the Scrum Guide has a short and simple list explaining the responsibilities of a Scrum Master, I know how hard it can be to fulfil them. I imagine every Scrum Master struggles with this. Every Scrum Master will fulfil their role in their own way. Trainers and coaches may point out various stances a Scrum Master can, should or shouldn’t take. Personally I find it pretty much impossible to ‘act’ out stances. It’s similar with coaches and captains in sport. How coaches coach is determined mainly by character. Perhaps the best stance to take is an authentic one. Don’t ‘act’ your role. Just be you. Just be aware that that the team will look to you for setting the tone. But if you need to act anything… act calm.
I believe many Scrum Masters are insecure about their role. I know I am. It helps to be working with other Scrum Masters.
“The Scrum Master is a servant-leader for the Scrum Team.” — The Scrum Guide.
The Development team doesn’t report to a Scrum Master, yet I’ve witnessed such cases. It is common for traditional managers, lead developers or project managers to take on this role. Being a Scrum Master inadvertently puts a person in a potential position of power and it is tempting to act in a controlling way and to micromanage, because one might feel responsible over the team and its production. If this is the case, Scrum falls apart completely. If the Scrum Master acts in this way, it is killing pretty much everything that Scrum stands for.
It might even be tempting for Scrum Masters to, as they might argue, temporarily act in a directing and controlling fashion as “the team still has to learn how to self-organise”. Well, by interfering, controlling or directing the team, it absolves the team from its responsibility to self-organise and it steals opportunities from the team to learn how to.
If anything, the Scrum Master facilitates the team. It’s the team that is best able to determine how it can best be facilitated. The Scrum Master is there for the team, not the other way around.
Recently I was in a bit of a squabble with Atlassian over their definition on what a Scrum Master is. Though they took some of my lectures to heart, they still cling on some false assumptions and popular anti-patterns regarding the role of Scrum Master. This illustrates just how persistent traditional behaviours are that they somehow, against everything that Scrum stands for, make it into popular definitions on what a Scrum Master should do.
So before I run you through what the actual responsibilities of a Scrum Master are, I’d like to first call out which popular assumptions aren’t.
Against popular claim, it is NOT the responsibility of a Scrum Master to get status updates from the team during a Daily Scrum. Neither is it the responsibility of a Scrum Master to make sure the ‘Scrum Board’ is kept up to date and do board administration.
On the contrary, it is the Scrum Master’s responsibility to back-off and let the Development Team manage this. But sure, when the team is struggling with this, the Scrum Master may help the team.
Performance analysis and reporting
It is also not the Scrum Master’s responsibility to manage reporting or do team performance analysis, neither to dictate how the team should do this. You also DO NOT determine which tools the the team should be using.
A popular coaching practise is to have 1on1s. This may or may not be a good practise and this very much depends on the level of trust and coaching qualities a Scrum Master has. It does however increase the chance for backroom politics. A Scrum Master, during personal conversations, may learn much that it can act upon. Much of what will be said during these sessions will be said in confidence. If a Scrum Master errs in dealing with sensitive information, it could be devastating to the level of trust that team members build in each other, including the Scrum Master. Having 1on1s will, inadvertently, put the Scrum Master in a position of power that may not be fitting to the role. Remember, Scrum is teamwork. Though some members might be more comfortable to be open with a trusted coach, than en groupe, not all Scrum Masters have the right background to deal with this level of personal coaching professionally! The retrospective serves for the team to align, and a Scrum Master can work with the team to make that safe enough so whatever needs to be said can be said respectably.
“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.” — The Scrum Guide.
The Guide doesn’t provide examples of what interactions are helpful and which aren’t. I’ll try to share a few:
- Asking the Scrum Team for status or performance reports is not a helpful interaction. Joining a Sprint Review, inspecting actual progress, and providing direct feedback is.
- Giving the team a deadline is not a helpful interaction. Taking the time to explain the urgency and value in a calm and substantiating fashion, and allowing the Product Owner to prioritize accordingly is.
- Being frustrated with a Scrum Team about changes in the plan, because of newly discovered complexities and changing conditions, is not a helpful interaction. These changes are valuable. Value the team’s adaptability.
- Ping-ponging spaghetti e-mail discussions are a terrible form of discussion/communication. A brief, personal, face-to-face conversation can save a lot of time and frustration.
- Those that say “This is not my problem” are part of the problem.
- Telling the team to work overtime when the team struggles to meet a goal is a terrible interaction. Though the team ‘commits’ to achieving Sprint Goals, commitment means that the team will reasonably do its best effort.
- Telling the team to postpone a Sprint Review because not all work is properly ready for review, is likewise bad meddling with the Sprint Cadence. Always honour the routine. The routine is not the issue here. Don’t create a precedence for postponing or abandoning the practises that are there for the team to inspect and adapt.
Helpful interactions include, as I have covered many times, questions like “Let’s take a look at this together?”, “What do you need?”, “Can I help?”, “How can we make this even better?”.
In the next part of this episode I will cover the services of a Scrum Master towards the Product Owner, the Development Team and the organisation as specified by the Scrum Guide.
Please help your fellow Scrum practitioners out by sharing your techniques in dealing with the above. Please correct me if I have misstepped. Just drop them in the comments below, highlight the statements you found to be helpful and /or share them. Oh right, and don’t forget to clap! 👏 it truly means a lot to me if you do.