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 meetup 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, 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.
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.
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.