What Exactly Does a Scrum Master Do?

This is the article for the 19th day of the Mamezou Developer Site Advent Calendar 2023.

I'm Nakasato.

You might think the title of this article is a bit late in asking. About 10 years ago, when Scrum started to spread in Japan, this question was often asked. The descriptions in the Scrum Guide are abstract, and it emphasizes that it's "not the traditional project manager or leader," but then what exactly do they do?

Since then, various books have been published and recommended, and I've tried to explain it over and over, but I've secretly been frustrated that I couldn't put it into my own words succinctly. Recently, I finally came across a phrase that I think fits, so I'll use that as the topic for this Advent Calendar article.

To be precise, it's two sentences.

"Observe whether the flow of information and results between stakeholders, product owners, and developers is smooth, and if you notice any stagnation, take some measures. Furthermore, maintain the transparency of the behavior of the team, including yourself."

I'll explain bit by bit.

Agile development is a method where this information (mainly requests) and the results produced continue to flow in a short span. With much shorter cycles than traditional development, any stagnation immediately leads to delays and waste.
The Scrum Master must constantly observe this Value Stream.

Saying "observe" might sound simple, but it's quite challenging. The Scrum Master needs to know where this exchange of information and results is happening within the team. This could be during Scrum events, regular meetings other than Scrum events, or interactions on chat tools and ticket management tools.
If the work is primarily remote, there might be less informal communication (such as chats in front of the snack shrine or in the smoking room), making it easier to grasp but harder to casually obtain information.

In any case, many problems often emerge when the Value Stream stagnates. The Scrum Master needs to be aware of the team's situation daily to investigate the causes when problems surface.

Beginner Scrum Masters might initially focus only on communication among developers. However, please gradually expand your support to include the product owner and then stakeholders.

As more people gain experience in agile development, interactions among developers often go smoothly. However, there can still be confusion, especially with new team members or those from other companies. New members need to grasp the team's Value Stream as soon as possible to contribute to the outcomes.
Supporting communication between the product owner and developers is well-known as a role for the Scrum Master.

It's often said that "Scrum Masters first facilitate Scrum events," and this is not wrong. This facilitates the team's Value Stream. If Scrum events run smoothly without the Scrum Master's facilitation, it's okay to leave them be and focus elsewhere.

Lately, I often see issues in communication between stakeholders and product owners, and even among multiple stakeholders. At this point, many people might feel it's beyond their responsibility due to different companies or large organizational units being involved.
However, if these issues affect the team's productivity, the Scrum Master should consider it within their scope of interest to support the team.

For those who think they can't possibly approach stakeholders (sometimes including senior management of the company) themselves, that's why I said "take some measures."
If it's something you can do yourself, then do it; if it's better to have someone else (like a developer) take action, then let them. Simply stating that something needs to be addressed is also a form of action. Observing the team daily helps you decide the best course of action.

Moreover, if you believe the issue cannot be resolved by the Scrum team alone, please approach management. Saying, "We are doing agile development with the goal of XX, but the interactions at YY are not going well, affecting the team's productivity. We need management to act on this," is something anyone on the team could say, but the Scrum Master, who is always observing the team, will likely notice it first and know who to approach and how.

I included "stagnation," but this also covers "likely to stagnate."
Events involving many people can fail to facilitate effective communication if just held casually. You need to think well in advance about how to enable participants to communicate effectively and make the event meaningful.

Although the Scrum Master is technically outside the Value Stream, they are undoubtedly a member of the team. They need to be prepared to take responsibility for everything that happens within the team.

Good Scrum teams have strong cohesion. While this is generally positive, it can also make the team's activities unclear to those outside the team.
This applies to the Scrum Master as well. Because they are not directly involved in creating value, it can be easy for both outsiders and sometimes even team members to be unclear about what they are doing.

Such a lack of transparency can lead to distrust towards the team and the Scrum Master themselves. Sometimes you need to speak up to management, and if there's distrust, they might not listen to you. To avoid this situation, think about how you can make your and your team's actions visible to stakeholders.

As you all know, the three pillars of Scrum are transparency, inspection, and adaptation.
Transparency comes first because it is the premise for inspection and adaptation, but in a remote work environment, transparency requires deliberate effort to maintain.

The Scrum Master should ensure the transparency of their and the team's actions while smoothing the flow of value and paying attention to whether the cycle of inspection and adaptation is functioning properly.