Hi! I’m your new Scrum Master!

Or: the first-day-on-a-team Scrum Master speech.

Thanks for having me join your team! I’m very excited to get to know you all. I’m also curious to hear about all the cool things you are doing.

illustration courtesy of abstrakt.design

So let me first quickly introduce myself. My name is Rieks, a software engineer turned Scrum Master who’s always up for a good laugh. I love spending time with my wife and daughter. I also make rock music, paint tiny army men, play tabletop games, and do many other things. I basically collect hobbies for a hobby. But let’s talk more about that over coffee.

Starting on this team, I’d like to take a moment to share with you a personal view of the role a Scrum Master plays. I talk about this with every team I join. There are a few reasons for that:

1. Even though the Scrum guide has a clear description of the Scrum Master role, I’ve never seen two people fill the role in exactly the same way.
2. As a Scrum Master, you have responsibilities and accountabilities. You’re not just a cheerleader. It’s therefore really important to express your needs as a Scrum Master, while also observing what works for the team. Otherwise, you risk becoming either a bystander of little value or a clueless source of interference. By talking about it from day one, we prevent that from happening.
3. The Scrum Master role has some paradoxes. On the one hand, I should teach you the rules of Scrum. But, I should also help you to become self-managing and find your own solutions as a team. You could even say that teams who truly mastered Scrum, aren’t that busy doing Scrum anymore.

Combine these three and there’s definitely room for confusion. By sharing with you my views on the Scrum Master role from day one, our work together will make more sense. At worst, you can decide that you don’t actually want a Scrum Master. 😉

illustration courtesy of abstrakt.design

Ask ten Scrum Masters to explain what they do and you’ll get ten different answers. Quite a few of those asked will appear nervous and embarrassed. It still happens to me. Describing my job is by far my least favorite part of family gatherings. It is challenging enough to explain the role to fellow professionals. Never mind giving a short and smooth “explain like I’m a five-year-old” version of the activities that fill my days. Though they nod politely, I’m pretty sure my relatives still have absolutely no clue what I do.

So, let’s look for help by going to the source. By the Scrum Guide’s definition, I’m accountable for two things:

1. Establishing Scrum as defined in the Scrum Guide. Teaching our team and the organization about Scrum’s theory, practices, and values.
2. The Scrum Team’s effectiveness. I should enable this team to improve its practices, within the Scrum framework.

The first one is pretty clear. Roughly speaking: teach people everything about what it means to practice Scrum. The second one, “accountable for the team’s effectiveness”, well that’s a bit trickier, right?

This is where I like to bring in my personal quick answer to “what do you do?”. So, here we go:

“I’m coach and trainer in the game of Scrum, accountable for building the right environment for teams”.

It’s a dense one-liner, clearly not perfect, but it covers a lot of ground:

• ‘Coach and trainer’ works well with Scrum’s game spirit analogies.
• I coach Scrum teams, while also training them to understand the purpose and rules of the game.
• ‘Environment’ expresses the role being both inside and outside the team. I work to improve whatever context the team is in.

Sure, many of the nuances are lost on those not familiar with Scrum. So don’t use this one at birthday parties. In professional settings, it packs a decent enough punch. Even so, I always follow up with:

“Ultimately, I hold up the mirror. I am accountable for teams holding themselves accountable.”

It’s my job we inspect and adapt each sprint. We inspect ourselves, our way of working, and the product we build. I am accountable for us as a team to act on the lessons we learn from valuable inspections. As a team, we need to maximize transparency so these inspections make sense. We need a clean mirror to see clearly. That will make use more effective, and that is what I am accountable for.

illustration courtesy of abstrakt.design

Unfortunately, “accountability” is often twisted into “who do we blame”. The exact opposite of what we’re aiming for here. It’s always a team effort. Trusting everyone in this team as the capable people with good intentions you are. When we are challenged, let’s not seek blame, but instead, support each other and learn from it together. Together we set goals, help each other and regularly inspect the progress we’re making. It’s positive accountability that helps us improve, be on top of our game and win as a team. It’s my job to make sure that happens in a safe, productive, and joyful way.

To start holding up a clean mirror, I will need your help answering some practical questions. We’ll dive into these topics in the coming days:

• Does each sprint have a clear Sprint Goal that encompasses our focus? A goal that delivers value to our users or stakeholders? A clear ‘what’ and ‘why’ that enables us to think about the best ‘how’?
• During each sprint, are we delivering slices of working product that are ready to use or release? Something we can at least inspect and review? If not, what can we do to make that happen?
• Do we have a Definition of Done that makes clear what Done and ‘ready to release’ means to us as a team?

These questions are our first look in the mirror. This is where I need your help in being the best Scrum Master I can be for our team.

Well, that was quite the speech, wasn’t it? Does anyone have any thoughts about it they would like to share?

PS: The inspiration for this speech comes from a recent realization: the importance of setting clear expectations from day one to empower yourself. As a Scrum Master or coach, it can be challenging to induce change. You want to observe at first. How is this team “doing their thing”? But the longer you wait, the harder change becomes. You’ve lost the blank check that “being new” provided you. Pretty soon, you’re part of the status quo. It‘s somewhat akin to US Presidents making the most out of their first 100 days. They expect to get bogged down after that initial phase.

Voicing your needs and accountabilities from day one creates transparency. It creates an anchor point to refer back to. Of course, make your speech your own. Just keep the ‘deliver working software each sprint’ part in there. Trust me on that one.

Join us! Do you want to write for Serious Scrum or discuss Scrum?