Reading Time: 5 minutes

One of my favorite statements: Scrum Masters aren’t session facilitators.
I love it. Because many people frown when I say this.

“What do you mean Wim? In my team, the Scrum Master is always facilitating sessions.”

Me: Why?

“Well, it has always been like this. And to be honest, the session is not effective otherwise. Without the Scrum Master, people are looking at each other and no one is taking the lead. We definitely need a Scrum Master to take care of the facilitation, agenda, invites, minutes of meetings, appointing the speaker, etc. If the Scrum Master is not here, the sessions tend to end in disappointment or even worse, the session will not be held at all. So that’s why our Scrum Master facilitates everything. Without him we need to organize it ourselves.”

The sound of crickets.

A more nuanced, but still narrow minded answer, and uttered many times, is like:

“You guys are good at it.”

Let’s have a closer look.
In many organizations, Scrum Masters are facilitating all kinds of sessions. Look around you. Is this happening at your company as well? Have you ever questioned why this is? Could it be that people suggested this because they saw it at their previous jobs? Perhaps they read it somewhere. Anyway, this does not alter the fact that the situation often arises and that many people think that this is how it should be. When Scrum Masters do facilitate everything, things may seem effective in that session or in a short period of time. But in the long run, things might not be that jolly after all. In fact these facilitating Scrum Masters become impediments to self organization and to the team. Organizations need Scrum Masters to help teams and individuals to organize themselves but Scrum Masters usually end up doing the exact opposite. I find this strangely ironic.
My hypothesis is: When Scrum Masters are not seen as facilitators and they focus more on finding ways to increase the effectiveness of the session and the ability to self organize, things might be more effective in the long run. Let them facilitate change, not sessions.
If an organization is used to having Scrum Masters facilitating every session, it might be hard to change this. And it will definitely take time. How can you help the organization grasp this concept?


When I want to bring about this change, I immediately think of conducting an experiment. This

is a fun way to test your hypotheses. Not exactly science, but a simple way to discover something. So I did. With multiple teams in many different compositions. Scrum teams, distributed teams, colocated teams, DevOps teams, Product Owner Guilds, etc.
One of our goals, as Scrum Masters, is to let everyone become proficient with the Scrum Values. Experiments are a nice way to focus on these values and get rid of misconception as well. Experiments can have an immediate effect, but also a long term effect. For example: getting rid of misconceptions has an immediate effect on the team members.
When you experiment, you can (1)test hypotheses, (2)reinforce the Scrum Values, (3)remove misconceptions and (4)learn by doing.

For this particular theory (Scrum Masters aren’t facilitators) we ran two experiments. The first essentially boils down to this: The retrospective will be facilitated by a volunteer from the Scrum team. They can fill it in completely according to their own wishes, maybe choose a subject, format if desired, etc. I always help him or her with preparing and even within the session itself, but only when this is necessary.
The second experiment is for a non-Scrum event for Product Owners. There was this tenacious paradigm that Scrum Masters should facilitate this event. After a couple of suggestions from my part, the Product Owners took the facilitation role and the experiment started.

Test hypotheses

In my post about Product Goals I wrote about hypotheses for your product. From a development perspective, a product can be considered a group of hypotheses which need to be tested in the real world. By studying the results of the tested hypotheses, we can pivot or persevere.
This concept is also applicable to other challenges, for instance testing this theory or hypothesis. By testing, you quickly learn what to do next. Be transparent about your findings and reflect on it regularly.


Scrum Values & Misconceptions

Running an experiment is a very good opportunity to reinforce the Scrum Values and get rid of any misconceptions. For example by committing to the experiment and spending the necessary time, focussing on change, show courage to facilitate, be open about available adjacent improvements and respect each other.

At the same time you can remove misconceptions. This actually always happens automatically by bringing up the subject and getting started with it. Every change starts with awkwardness and discomfort. Which is fine. It means that things are in motion. Try to help create a sustainable work atmosphere which fosters constant change, engagement, collaboration and innovation. The awkwardness and discomfort will eventually make way for a very nice feeling of reward as actual sustainable change is happening.


Not a day goes by without learning something. By experimenting you learn so much at once that it can be addictive. Experimentation drives change. And like I said before, change can feel uncomfortable, but what is wrong with that? It is a signal that things are in motion.

For this particular experiment we learned the following:
What the team learned:

  • They have a big responsibility and are important in so many ways. For the product, the company, the culture, way of working, etc.
  • They can self organize. Which shows in all kinds of other sessions as well. This is the beauty of experimentation. The ability to self-organize is a long term success and they will benefit from it.
  • Experiments are a very handy tool to maximize change. They started using this for other challenges, resulting in great outcomes.
  • Discomfort is okay. Contentment will follow.

What I learned:

  • People come prepared
  • My hypothesis has been proven
  • Biggest lesson: people are more self organized. By having a simple experiment, we created a very impactful change which hopefully lasts for a long time.

Facilitate change, not sessions.

Together you can find the most effective way that works for your teams. Help them figure out what the options are and experiment. Let them learn by doing it. Facilitate the change towards an environment which fosters collaboration, engagement and in the end even fun. Where conflicts are normal and the group of people act as an organic team.

I’m not saying you as a Scrum Master shouldn’t host or facilitate a Scrum event or other kind of sessions. I’m saying that you should always remember that your role is to find ways to increase the effectiveness of the session and the ability to self organize.

Facilitate change, not sessions.


I was a guest on the Scrum Facilitators Community Podcast regarding this topic. You can listen to it here:

Categories: Articles