Nov 1, 2021
Five Things Every Starting Scrum Master Should Know
(And that should benefit experienced Scrum Masters too)
You can also listen to this post in our podcast.
When I started as a Scrum Master, the thing that scared me the most was how to translate those lofty ideals into actual down-to-earth behavior. While it sounded great that “Scrum is about empiricism”, I had no idea what that should look like with my team, how I should behave to support that and how flexible I could be with the framework of Scrum.
One of my earliest blog posts was a good example of this. In it, I wondered if it was okay to add a fourth question to the set of three questions for the Daily Scrum that was provided as an example in the Scrum Guide back then.
I struggled with many similar questions. Was it okay to skip a Daily Scrum every now and then? Should I — as the Scrum Master — always lead the Scrum events, and how? What should my relationship look like with stakeholders, especially when they asked me to relay their criticisms to the team?
In this post, we collected five practical insights that I think every starting Scrum Master should know, and that are inspired by mistakes I made over the years. If anything, I wish I would’ve realized these when I started. For this post, I also asked our growing community of experienced Scrum practitioners on Discord for help.
1. Take it to the team
If you’re a new Scrum Master, it can be very tempting to feel pressured to fix whatever problem a team runs into. For example, I would jump on any issue or impediment that was raised during the Daily Scrum. I also spent a lot of brainpower on trying to come up with ways to involve more stakeholders, how to get more Done Increments out the door, and how to improve our deployment pipeline — and then presented my solutions to the team.
Even though I did all of this out of good intentions, the simple truth is also that I didn’t know how else to address it. My impression of my team was that they weren’t willing to spend time on these questions, and because I didn’t want to disrupt them further, I tried to solve impediments on my own. And for a while, this felt like progress to me. And the team was happy with it too.
Fortunately, I quickly realized that this doesn’t work. My first hunch was when my team increasingly delegated impediments to me where it felt very inefficient for me to resolve them. For example, my team asked me to go to the “Scrum of Scrums” on their behalf or to talk to the Product Owner to change the scope for the Sprint. And then there was a laptop that suddenly crashed, and the developer asked me to get a new one. My second hunch was when all sorts of basic issues remained on the board for weeks during my vacation, waiting for my return.
In a nutshell, this is why should you should “take it to the team”. When in doubt, when faced with a question on how to do something, when faced with an impediment: ask your team — including yourself — how they should handle this and then work together to actually do that. It works even better when you share your judgment-free observations (e.g. “I noticed that a lot of questions for the Product Owner accumulated and remained unanswered during my vacation.” or “I am noticing that stakeholders rarely have anything to say during Sprint Reviews”). When you do this structurally, others will start doing it too. Not only can you now benefit from the experience and insights from your entire team, but you also practice invaluable problem-solving skills that are the drivers of continuous improvement.
“When in doubt, when faced with a question on how to do something, when faced with an impediment: ask your team — including yourself— how they should handle this and then work together to actually do that.”
2. Do a Scrum Reboot with your team
As a new Scrum Master, you either have the luxury of starting a new Scrum Team, or you’re joining an existing one. A hard lesson I learned too many times, is that you really should reboot the team by bringing your team together as early as possible to answer three core questions:
- What is the purpose of this team, and the product it is creating?
- Who is part of this team and who are its stakeholders?
- What minimal set of rules do we need to follow as a team to manage the complexity of our work while at the same delivering value to our stakeholders?
Even when the answers are obvious to the team — which usually isn’t the case — this conversation creates the foundation for all your other work together. It sets the tone for your role and for that of your team, and it gives you the first opportunity to create transparency. This focus on the purpose over the mechanics also ties in nicely with what community-member Robbe added: “It is not about the framework, it is about what you do with it.”
“A hard lesson I learned too many times, is that you really should reboot the team by bringing your team together as early as possible to answer three core questions”
The third question naturally leads to how you use the Scrum framework to work empirically. It is often a great opportunity to refresh Scrum together and take a look at how you want to use the various events. Over the years, we developed a whole bunch of exercise material to do this.
How you answer the three questions is up to you. I always like to turn it into a 1-or 2-day workshop with the team that includes team building and developing a shared vision for what this can become if we put our shoulders under it. Whatever you do, fight as hard as you can to claim at least one part of a day for this. If it tastes like more, and it usually does, you can schedule a follow-up later.
3. Start with the stakeholders
My biggest mistake with Scrum — hands-down — was how long it took me to realize that the stakeholders should drive everything that a Scrum Team works on. It is very tempting to focus all your efforts on your team and leave the outside world to your Product Owner. That is a mistake.
Your stakeholders are your natural allies when it comes to improving how you work as a team. If you can’t release a Done Increment every Sprint because of unnecessary bureaucracy, it hurts your stakeholders just as much as it does your team. If your Product Owner lacks the mandate to make decisions, and everything slows down because of it, they lose too. If your team delivers a product of questionable quality, exposure to feedback from your stakeholders opens the door to important conversations about quality control and your Definition of Done.
I should note that, by stakeholders, I mean everyone who has an actual stake in your product. These are the people who invest in your product with significant amounts of money, time, or both. If you deliver a great product, they are happy. When you deliver a crappy product or nothing at all, they stand to lose that investment. This definition excludes people who may have an opinion about your product, but don’t lose anything personally when it doesn’t deliver.
So in your very first Sprints, work with your Product Owner and your team to identify where the stakeholders are and how you can involve them right now. Even if it is very hard, once actual stakeholders start showing up in your Sprint Reviews, and once the team starts hearing their feedback, everything in the Scrum framework starts making sense. And that is what makes this such an important bit of advice.
“So in your very first Sprints, work with your Product Owner and your team to identify where the stakeholders are and how you can involve them right now.”
4. Find help in the community
In your work as a Scrum Master, you will face many wicked challenges; problems that are so devious that there is no single solution that stands out. For example, how should you encourage the autonomy of the team while also stepping in when something really goes off the rails? How should you respond to requests from management to report the progress of the team and evaluate its members?
Other times, you will discover too late that you’ve been doing something that isn’t such a good idea in hindsight. For example, many Scrum Masters initially go along with story point estimation and comparisons of teams based on how many points they deliver each Sprint until they discover that story points cause all sorts of problems when you use them for this purpose.
Thankfully, you’re not alone. One of our greatest tips for all starting Scrum Masters — or any professional for that matter — is to find help from other Scrum Masters. There are many communities out there that facilitate this, like our own Liberators Network and our local Liberators User Groups, and the private Discord-server we have for our patrons. There are similar communities at Serious Scrum or Scrum.org, to name just a few.
Peers can help you find potential solutions to those wicked challenges, and they can help you discover and unlearn earlier what you might otherwise discover later (like the example of story points). On a smaller scale, you can also find help from Scrum Masters in your own organization. And if such a network doesn’t exist yet, you can start. We even have some strings of Liberating Structures that you can readily use for this.
5. Be kind (to what is already there)
It is easy to get excited about the potential of the Scrum framework for teams and organizations. In a desire to show leadership, starting Scrum Masters (and very experienced ones too) sometimes move too fast for their teams and organizations. I certainly did on occasion, and it annoyed the hell of out the people I worked with. Because in all that excitement, it is easy to treat how people work now as “traditional” or “outdated” and to get frustrated when people don’t see what you see. With that kind of arrogance and disregard for what is already there, it is very easy to create your own resistance.
The antidote to this is to remain humble. It will take time for you to deeply understand what the Scrum framework is and how its elements work together. Heck, I’ve been a Scrum Master for a dozen years and I’m still discovering nuances that I never fully appreciated before. Community-member Guillaume summarized this as “You know nothing, Jon Snow”. This realization alone should take away the hard edges of your enthusiasm for others.
Humility also translates into kindness. Be kind to how your team works now, even when it doesn’t seem to be Scrum yet. Be kind to people who don’t see the potential that you see (yet). And be kind to yourself when you don’t know how to act as a Scrum Master in a certain situation.
And this brings us to the Wicked Challenge of Scrum Masters: How can you be both humble and kind to what is already there while also enthusiastically encouraging your team to improve? There are at least two ways to navigate this challenge. The first is to firmly consider yourself as part of the team and to not put yourself above them. It is surprisingly easy to do this, even when there is no hierarchical difference. For example, statements like “I’m here to coach you to (team) discover the problem on your own” or “I’m here to coach you (team) to resolve your impediments” — however well-intentioned — do precisely that. You are not their coach — you are part of the team, and you absolutely lack the objectivity and detachedness that make an effective coach. But you can still use all those coaching skills and powerful questions to drive an honest and shared exploration of the challenge and the solutions.
“Firmly consider yourself as part of the team, and to not put yourself above them”
And this brings us to the second way out of the Wicked Challenge of Scrum Masters; transparency. You can contribute the most to your team and your organization when you continuously look for ways to make transparent what is working well and what isn’t. A simple way to do this is to share an observation without judgment and follow-up with an open question. For example: “What I see is that we individually work on our own items most of the Sprint, and I wonder how that benefits us and what we may be losing as a team because of that?”. Or: “I see that our Sprint Reviews are rarely attended by stakeholders, and I wonder what that means about our work together”. You can also work with your team to track useful metrics — like cycle time, bug count, and team morale —and inspect them together.
By combining humility and kindness with this radical transparency, you create a safe environment where your Scrum Team — which includes you — can improve continuously in their ability to work empirically.
“By combining humility and kindness with radical transparency, you create a safe environment where your Scrum Team — which includes you — can improve continuously in their ability to work empirically.”
Closing Words
While writing this post, and getting input from other Scrum Masters, I noticed how most of the advice had nothing to do with what we usually associate with professional success; the certificates you have, the amount of training that you’ve undergone, or even the years of experience you have. While it is true that it takes years to master Scrum, it is also true that this means that every Scrum Master should be able to apply them — regardless of their experience.
And that brings me to the final nugget. It is easy to completely freeze up as a Scrum Master, and walk on eggshells all day in the worry that you’re doing it wrong or that you lack the talents that you see in others. But just like you can’t build the perfect product in one go, it's only natural to learn Scrum with your team in an incremental fashion. You will make mistakes as a team, and sometimes one step forward is followed by two steps back. If you work together as a team, you’ll get through eventually! Community-member Yerlix expressed this nicely as “Whatever you do, it’s most likely better than doing nothing at all”.
