注目イベント!
春の新人向け連載企画開催中
新人エンジニアの皆さん、2024春、私たちと一緒にキャリアアップの旅を始めませんか?
IT業界への最初の一歩を踏み出す新人エンジニアをサポートする新連載スタート!
mameyose

Starting Out as a Scrum Master Stage 1: Facilitation

| 8 min read
Author: misato-kamei misato-kameiの画像
Caution

This article has been automatically translated.
The original article is here.

This is the article for Day 15 of the Mamezou Developer Site Advent Calendar 2023.

Introduction

#

Hello, it's been a while. I am Kamei, a fledgling Scrum Master (hereafter, SM).

As I wrote in the Summer Relay Series 2023, I made my debut as an SM in May and joined a project, and it has been 7 months since then. I am grateful for the opportunity to write again, and I would like to share the challenges and solutions I encountered in "facilitation," which was a major hurdle in the first project I participated in as an SM.

Joining the Project and Debuting as an SM!

#

It was only a month after I declared I would become an SM that I had the opportunity to participate in a project as an SM.

The project details are as follows:

・Adopted large-scale Scrum "LeSS"
・Primarily online work
・1 Sprint lasts 1 week
・Sprint Planning on Thursday afternoon
・Daily Scrum every morning
・Refinement three times a week (Friday, Monday, Wednesday)
・Sprint Review on Wednesday evening
・Retrospective on Thursday morning

Information

LeSS is a framework that scales up the Scrum conducted by one Dev team. In LeSS, there can be up to 8 Devs per team and a maximum of 8 teams. Similar to Scrum, it includes:
・One product backlog
・One PO (Product Owner)
・One Sprint
Differently from Scrum, it has:
・Sprint Planning, Daily Scrum, and retrospectives are conducted both for the whole group and for each team individually
For more details on LeSS, please see here.

At the time I joined in May, the Scrum team composition was as follows:

・Dev (developers): About 5 people per 3 teams (total 17 people)
・PO: 1 PO and 5 area POs per team (total 6 people)
※ Originally, LeSS has one PO, but due to busyness, area POs were assigned to support the PO and create PBIs for each Dev team
・SM: 1 already participating + me (total 2 people)
→ Total 24 people

Information

PBI stands for Product Backlog Item. First, there is something called the "product backlog," which is a prioritized list of items and features necessary for the realization of the product. Each item or feature listed in the product backlog is a "Product Backlog Item," which includes feature additions and bug fixes.

Initially, since it was my first time as an SM, I acted under the guidance of the veteran SM already participating. While getting used to the weekly flow of events that occur in one Sprint, I observed how Scrum events and development were conducted in this project during the first few Sprints. This project had started about a year ago, and the participants were generally knowledgeable about Scrum and fairly mature. Therefore, there was no need for SM support during the events. Since there was no need to help the Scrum team understand Scrum, I could focus on switching my thinking from a Dev perspective to an SM perspective on how to create a better product with Scrum. As I became more familiar with the project, I was given the opportunity to facilitate a general retrospective, which had been handled by the veteran SM until then.

Unbelievably Failing in Facilitation...

#

Facilitation, simply put, is "smoothly advancing discussions in meetings and other conversational settings." However, I had never before facilitated a discussion involving more than ten people, gathering ideas, and summarizing them. With a spirit of "just give it a try," I attempted to facilitate a one-hour general retrospective attended by the entire Scrum team, and it ended disastrously. The reasons for the failure included:

  1. Unable to discuss items brought by individuals in order of importance or relevance to the Scrum team due to time constraints
  2. Due to the specifications of the provided PC, there was a delay in response during online, camera-off conversations, making it unclear whether participants were thinking or had difficulty responding. This led to prolonged silences until someone intervened.
  3. Uncertainty about who to direct the discussion to, leading to questions like "What do you think about this?" without specifying the recipient, resulting in continued silence

I vividly remember being so nervous about the general retrospective that I could almost hear my heart pounding. I was secretly dreading facilitation after that first failure. Despite this, I continued to facilitate the general retrospectives, and now, five months later, my initial apprehension has faded, and I can facilitate somewhat comfortably. Essentially, by accumulating experiences of failures and minor successes, one can improve their skills. However, without a conscious effort to improve, simply accumulating experiences will not lead to enhancement. Next, I would like to discuss how I addressed the three points of failure mentioned earlier.

Countermeasures to the Causes of Failure

#
  1. How to prioritize multiple discussion topics?

If it is determined that not all topics can be discussed within an hour, I have attendees vote on the discussions they wish to engage in. Topics with more votes indicate higher interest among the attendees, allowing us to prioritize discussions accordingly. If the number of topics seems manageable, we proceed without specifically prioritizing them based on votes.

  1. Dealing with the dreaded silence during conversations

I received a golden piece of advice from a veteran SM: "Consider the silence following a question as time for thinking." Additionally, I was advised that people in the Kanto area tend to respond more slowly to conversations than I was accustomed to, which was surprising as I am originally from Kansai and used to a quicker pace of dialogue. Moreover, because online interactions only unmute during speaking, it's possible that thinking noises like "hmm" aren't heard. Therefore, when silence occurs, I wait a few seconds for a response; if it continues, I ask, "Are you thinking?" to reengage.

  1. Deciding whom to address in discussions

If it's clear who the discussion is intended for based on the content, I direct the question accordingly. However, it's often not specified. In such cases, if the topic is about technology or the development environment, I turn to the Devs; if it's about the product, I turn to the PO. Even if I address the wrong person, someone usually redirects the conversation to someone more appropriate, like "Would you know about this, [name]?" or "I think Dev Team XX was handling this." Even if I make a mistake in choosing whom to address, no one gets upset, and by gaining more experience, I've become better at judging the appropriate recipient based on the content of the discussion.

Conclusion

#

It's often said that an SM is not merely a facilitator of events. However, there are many occasions where an SM needs to facilitate: developing discussions, organizing points for clarity, and leading conversations towards problem resolution. Beyond facilitation, there are several points to consider in the order of conversation, especially in voice-only online interactions. Nonetheless, facilitation is a skill worth honing, not just for SMs. I would like to recommend a book suggested by a veteran SM, "Introduction to Facilitation, 2nd Edition." I hope you find it helpful. Thank you for reading to the end.


豆蔵では共に高め合う仲間を募集しています!

recruit

具体的な採用情報はこちらからご覧いただけます。