Scrum Masters: Stop Facilitating Scrum Events

If there’s one thing I see as a tell tale sign of where a team, organization, and even individual Scrum Master is in their journey of Scrum Mastery, it’s how active a Scrum Master is in Scrum events.

Like many Scrum Masters, I found early in my career that I was a very active facilitator in our Scrum events like the Daily Scrum and Sprint Planning.

As I learned more about effective Scrum, and increasingly discovered what makes teams successful, I’ve found myself guided much more strongly by an important line in the Scrum guide.

The Scrum Master serves the Scrum Team in several ways, including:

Coaching the team members in self-management and cross-functionality

I don’t believe it’s an accident that the very first accountability to the team that is called out in the Scrum Guide is ‘Coaching the team members in self-management’, but I do believe that many overlook or under-appreciate the importance of it.

And yet I’ve watched as many Scrum Masters, months or even years into their Scrum team’s journey, are still the person starting, ending, managing and talking, throughout the Scrum events.

This is a significant anti-pattern, as a team cannot self manage when their most important points of inspection and adaptation are being managed by one person.
In my experience, teams come to rely on the Scrum Master to tell them how to run these events, and will make no attempt to change or innovate them (This is for the Scrum Master to do, right?).

Worse, the Scrum Master becomes a bottleneck. When they are sick or busy, any value of the Scrum Events seems to quickly fade away. The events become ‘ceremonies’.

So what should a Scrum Master do during Sprint Events?

Well, there is no hard and fast rule. I would always suggest thinking carefully about what is needed in your context, and having the whole team think about and offer input into how events can be most valuable.
It’s also completely normal that when a team is new on their journey, struggling with specific events, or experimenting with something new, that a Scrum Master will act as the coach, helping the teams to get things right.

It’s important that this doesn’t continue forever though, as the Scrum Master should always be thinking about how to coach the team to self-manage these events.

However, let’s go through the inspect and adapt events one by one and I can share some patterns of success I’ve seen;

1. Sprint Planning

Sprint planning is the event I often see as the yardstick or turning point in a team’s journey to self management. When a team is new, it’s not uncommon for a Scrum Master to take an active role in the event so the team can learn what good looks like.
The Scrum Master helps the team consider what makes a good Sprint Goal, to inspect the Product goal, and to ask the right questions about Product Backlog Items before they are pulled into the Sprint.
This is very hard to get right for teams not used to working in Scrum, and so the Scrum Master should not be worried about actively coaching and facilitating the event.

As always though, self-management is the goal. The Scrum Master should always be helping the team understand why we are trying to do things this way. Don’t always ask the same open questions, but try asking the team if they can predict what you’re about to say next.
One of my favorite personal moments in team coaching is when you go from asking “What am I going to say next?”, to having someone in the team glance in your direction and say “You know Mike is going to ask us if we think this can be finished in the sprint”.

Once a team can get through a whole Sprint Planning event without needing direct guidance from the Scrum Master, it usually means their self-management skills are about to hit the next level.

2. The Daily Scrum

This is probably the most important place for the SM to fade away as quickly as possible. The Daily Scrum is for the developers, by the developers, and serves as a point to inspect progress toward the sprint goal, and adapt the sprint backlog.
Unless the Scrum Master is also a Developer, they should be entirely silent, allowing the people with accountability and knowledge of the work to do what’s best.
During the Daily Scrum, the Scrum Master is there to ensure we keep to the timebox, and that the event remains productive (which I would interpret as: not let it devolve into personal attacks when tensions get high).
The Scrum Master may well be listening for coaching opportunities. Are we focusing on the Sprint goal? Are we considering the customer? Are we taking into account our retrospective plans?
Importantly though, they should not interrupt the Daily Scrum, they are simply learning what they can for continued coaching and support throughout the sprint.

Similarly, the Scrum Master is likely listening for impediments, but it’s important they don’t immediately pick up and solve every minor challenge the team mentions. Coaching in self-management is the first priority , so give the team a chance to form their own plan.
If an impediment is not resolved by the end of the Daily Scrum, then causing it’s removal becomes the first thing on the Scrum Master’s daily plan once the time box is up.

The key thing here is that the Developers don’t see the Scrum Master as the reason for the event, or the person they are reporting to. The less the Scrum Master says, the sooner the developers will find ways to make the event into whatever they need it to be.

3. Sprint Review

The Sprint review is (In my experience) one of the best opportunities to coach the Product Owner in team and stakeholder collaboration. As always, the Scrum Master will often help more in the early days, but here I would always want the Product Owner, being accountable for the value of the work and the primary representative of customers and stakeholders, to be the person who most guides the discussion.

It’s also important that the developers learn how to effectively present the product increment(s) and their work, so it should never be a Product Owner presentation. This is a working session to show our outcomes and adjust our plan for future sprints, so helping the Product owner to focus the session while empowering the developers to show the completed work is paramount.

Getting feedback and adapting the Product Backlog is the most important outcome of the Sprint Review, and so the Scrum Master may well help facilitate the discussion to ensure we get to the root of the value delivered the value needed, but a self-managing team should ultimately be able to do this without too much direct help from the Scrum Master.

4. Sprint Retrospective

If there’s one place my argument might fall down, it’s here.
In my experience, this is the one place where active facilitation by the Scrum Master will never really go away. Not entirely.
As the person accountable for the team’s Scrum Practice, the Retro is the primary place to coach, guide, and plan our improvement opportunities. Bringing in new formats, focusing the retro on specific pain points, and ensuring we create an actionable plan for change will often be something the Scrum Master will own.

That said, it’s important that the Scrum Master isn’t the only person that can make a retro effective. We should absolutely encourage developers to learn how to run these without us. Once the team is practiced, perhaps this is even the default approach, with the Scrum Master taking over only by request, or when they see a significant coaching opportunity.

Ultimately, it’s up to the team like everything else. I would simply say that you should not let my argument scare you away running a retrospective where it is adding value. Just do your best to ensure the team can make them effective without you.

So then why is facilitation such an important skill for the Scrum Master?

Now that I’ve told you all the ways the Scrum Master should step back from active facilitation in the Scrum Events, you might be wondering why then we say that facilitation skills are so important for a Scrum Master.

Firstly, I hope my earlier points made clear that helping teams to get things right in the first place is still important. This requires those skills, you should simply aim to not be the only person capable of facilitation.

Additionally, passive facilitation throughout the sprint is still a key method of success. Helping the team collaborate, to build shared understanding, and to deliver upon their commitment (the Sprint Goal) is vital.

Finally, to pull another quote from the Scrum Guide from the Scrum Master service to the Product owner:

Facilitating stakeholder collaboration as requested or needed.

So while the Scrum Events are something that a self-managing team should be able to take on, other stakeholder and customer centric events are likely to need facilitation throughout the Sprint too. While these could still be facilitated by the developers, their first responsibility is in creating the increment and achieving the sprint goal, so the accountability, and often the skillset, still falls with the Scrum Master.

So, facilitation is still an absolutely vital skill for an effective Scrum Master, we should just be careful not to ‘own’ the Scrum events and disempower a self-managing team.

With all that said, stay tuned for my upcoming article on my training of a personal facilitation approach dubbed ‘the runner bean method’, aimed at helping improve your facilitation skills with some specific tools and guidance.

I hope this has been helpful, and I look forward to your comments.