About five years ago I published the paper “The 8
Stances of a Scrum Master”. Although it definitely needs an update, the core of
the paper is still relevant. In the paper, I describe the misunderstood and
preferred stances of a Scrum Master. One of the misunderstood stances is the
teacher. It often gets fulfilled in such a way the Scrum Master becomes Scrum
police. A recent meet up in The Liberators Network triggered an interesting
conversation between a couple of Scrum practitioners. Within their
organization, Scrum Masters are not teaching but preaching. At first sight, the
difference doesn’t seem significant. But from my own experience, I’ve learned
that it can have a big impact on how Scrum is used within your team or
organization. In this blog post, I’ll describe the difference between Scrum
teaching & preaching, why it matters, and what you can do to improve the
situation.
The Scrum Master
as a Teacher
As we describe in our paper “Scrum: A Framework To
Reduce Risk And Deliver Value Sooner”, it’s up to the Scrum Master to include
the perspective of empirical process control and the quality by which
transparency, inspection, and adaptation are taking shape in and around the
Scrum Team. The Scrum Master is there to make the elements of the Scrum
framework come to life in the team and the broader organization. For this,
Scrum Masters adopt a number of stances, depending on the situation they find
themselves in. These stances are the teacher, facilitator, impediment remover,
change agent, coach, and mentor.
As a teacher, professional scrum masters teach and explain
the purpose of the Scrum framework as a means to work empirically. They work
hard to make sure that everyone understands how the artifacts, events, roles,
and principles promote empiricism and agility. A Scrum Master teaches their
team and organization how Scrum helps them to be effective in complex
environments.
SM as a Teacher
The Scrum Master
as a Preacher
The opposite of the Scrum Master as a teacher is the
Scrum Master as a preacher. This is a Scrum Master who preaches the rules of
Scrum without considering the context of the team, the unique characteristics
of its environment, and the dynamics in the wider organization. The rules of
Scrum are presented as dry facts that should be adhered to, without explaining
why they are important.
It’s quite easy to spot the Scrum Master as a
preacher because every conversation about Scrum remains theoretical. Often it’s
not even a conversation since the only argument is “because it’s in the Scrum
Guide…”
·
Why should a
team use a Product Goal? → because it was recently added to the Scrum Guide.
·
Why can’t we
talk about Development Teams anymore? → because they removed from the updated
Scrum Guide.
·
Why isn’t the
Scrum Master a servant leader anymore? → because according to the Scrum Guide
(s)he “is a true leader”.
·
Why should we
change “self-organizing” into “self-managing” everywhere? → because the Scrum
Guide changed the wording
This of course slightly exaggerated, but this is how
I perceive conversations with Scrum preachers. It’s not even about who’s right
or wrong. The point is that preaching Scrum isn’t helpful for anyone. It’s
rarely a good way to engage people in changing their behavior and understanding
of how things work. Instead, it’s far more likely that you only create
resistance by being pedantic about what people are used to. By doing so, you
close conversations instead of opening them. As a result, the team will learn a
couple of facts, but don’t understand why it matters, and how it could benefit
them. The facts might stick, but that doesn’t mean they’ve learned something.
Three
Characteristics of the Scrum Preacher
The Scrum Master as a preacher seems to have three
distinct characteristics: lack of experience with Scrum, too much ego, and
Scrum as the only tool in their kit. Let’s dig deeper into why lack of
experience is a characteristic of a Scrum preacher, first.
Lack of
experience
Teaching becomes powerful when you can put your
knowledge into the context of a team. If you understand the impediments a team
is facing and the environment they’re part of, you can offer a tailor-made
approach. However, if you don’t have experience with Scrum, and don’t truly understand
the situation of the team, all that is left is simply repeating what the Scrum
Guide states.
In all honesty, I’ve experienced this myself as
well. When I discovered Scrum about 12 years ago, I did understand the
situation of the team, and due to my lack of experience with Scrum itself, my
initial approach was to preach to rules of Scrum hoping to convince the team to
use them. The result was that they actually followed the rules initially, and
because they didn’t understand why it was important, the rules didn’t stick and
were only used mechanically.
One of the movements I see in today’s Scrum
community is that the Scrum Master role is considered a junior position by
organizations and Agile consultancy agencies. These agencies recruit people
without any Scrum and work experience, quickly give them a Scrum Master badge, and
offer them to organizations as contractors. Although it’s done with the best
intentions, the only thing these Scrum Masters can do is preach the Scrum
Guide.
Ego
Let’s be clear: there’s nothing wrong with ego. It
can be the fuel to get things done and help you achieve personal goals. It can
also get in the way. The teaching stance puts you in a position of authority.
You have knowledge about Scrum the team doesn’t have yet. So, explaining all
the facts about Scrum to the team will feel good. Especially if you don’t have
the experience yet, it gives you the feeling that you add value. Before you
know it, you’re the companies thought-leader, how cool is that?!
I’ll confess that I enjoyed this status myself as
well. Especially when I started to combine my Scrum Master role with being a
Professional Scrum Trainer at Scrum.org. But the more experience I gained as a
Scrum Master, the less I used the teaching stance. Nowadays, I rarely explain
Scrum. I don’t consider it effective. Although there’s nothing wrong with
teaching, it quickly becomes preaching. So I started to use a different
approach on how to fulfill the teaching stance. Keep on reading if you want to
learn more about it.
Scrum, Scrum,
Scrum
As the saying goes: “if all you have is a hammer,
everything looks like a nail”. So, if the only thing you know is Scrum, it’s
likely that this is your number #1 recommendation as well. The Scrum Master as
a teacher doesn’t only explain what Scrum is about, but also how Kanban, XP, or
Lean can help. The Scrum Master as a preacher focuses on Scrum only. Other
frameworks or methodologies are considered as ‘evil’ if taken into
consideration at all. To spot a Scrum preacher, all you have to do is spend an
entire day on LinkedIn and track the many discussions Scrum fanatics have…
When faced with complex work, Scrum is an excellent
framework. But so is Kanban. It really depends on the type of work the team is
doing, and their context. Maybe working in Sprints doesn’t make sense to them,
and they would benefit to focus on flow only. Maybe a hybrid situation where
Scrum and Kanban are combined works best. A Scrum Master should always have an
open mind and explore multiple frameworks, methodologies, and practices. That’s
what serving the team is about. The good news is that this is even described in
the Scrum Guide ;-)
How not to
become a preacher?
When I noticed that I became a Scrum preacher
instead of a Scrum teacher, I made a couple of changes that I can definitely
recommend to you as well.
First, challenge
yourself to stop talking about Scrum (or Agile)! Whenever you explain something about Scrum to your
team, do so without using any Scrum terminology or other buzzwords. You’ll notice
that this prevents you to ramble the dry facts about Scrum but instead helps
you to explain why it matters. We used this approach ourselves as well when we
wanted to explain the purpose of Scrum in one illustration. The result is a
comic that doesn’t talk about Scrum at all but does explain its purpose.
Purpose of Scrum
The purpose of Scrum explained without using any
difficult terms or buzzwords.
Second, whenever
you hear yourself say “because it’s in the Scrum Guide”, ask yourself why this
was your answer. Be brutally
honest. It doesn’t mean you’re wrong, it could be a signal of a knowledge gap.
Which is fine. But instead of paraphrasing the Scrum Guide, take some time to
do more research. Or even better: make it a joint exploration with your team!
Third, practice
explaining Scrum to fellow Scrum Masters.
Only by explaining something to others, you’ll discover if you truly understand
it. Create or join a Scrum Master community in which you can safely practice.
Help each other to hone the teaching skills, and to move away from preaching
only. Often you need others to become aware of your own behavior. So ask a
fellow Scrum Master to be your mirror.
Fourth, make
teaching a joint discovery and exploration.
Whenever you feel the tendency to teach the team something about Scrum, ask
yourself “how can I make this a joint discovery?”. So instead of explaining the
Scrum roles, artifacts, and events, use an exercise that helps the team figure
this out themselves. Our webshop is packed with exercises that help you do so.
For example, “Management in Scrum” creates a better understanding of the roles,
“Scrum events & activities” clarifies the events, and the “Definition of
Done exercise” shows why a Done increment matters.
Fifth, try other
Scrum Master stances. Especially the
stances of the coach, and facilitator. As a coach, you help the team grow by
asking the right questions and to draw attention to the reasons for an
empirical approach. As a facilitator, you help the team find the best way to
make work, impediments, and team dynamics transparent. Done right, inspection
and adaptation become much easier. So, instead of teaching the concept of e.g.
Sprint Goals, make transparent what current happens without a goal, help the
team inspect how it impacts them and why it matters, and encourage them to come
up with improvements.
Closing
The Scrum Master is responsible to teach and explain
the purpose of the Scrum framework as a means to work empirically. A common
pitfall is that teaching becomes preaching. In this blog post, we described the
difference, and why it matters. Preaching probably will only result in
resistance to Scrum. You close conversations instead of opening them. So we
offered you 5 ideas to fulfill to role differently. Give it a try, and let us
know your experiences.
Resource: https://www.scrum.org/resources/blog/when-scrum-master-teacher-becomes-preacher
