SCRUM MASTER STANCES
Scrum Master as a Teacher
How does a Scrum Master teach Agile to the teams?
Today we are going to continue exploring the Scrum Master stances. And this time we’ll touch on my favorite one: Scrum Master as a teacher. I’ll teach you, just tell me what you want to learn. Or better yet, I’ll tell you what you want to learn! Let’s see how this goes!
Disclaimer — The Stances of Scrum Master
I use the term “stance” freely and base it on my own experience and two other sources: Barry Overeem’s whitepaper “The 8 Stances of a Scrum Master” and Lyssa Adkins' book “Coaching Agile Teams” where she refers to them as Agile Coach “styles”, not stances.
Depending on the situation, Scrum Masters adopt a number of stances. There’s the impediment remover, as described in the previous article, the teacher, facilitator, change agent, coach, and mentor. In his “8 Stances”, Barry also mentions a servant leader and a manager. However when you think about it, Scrum Master should always be a servant leader and never a manager, so the last two don’t depend so much on a situation, but rather on the role itself.
What Does It Mean To Teach?
Let’s see what British dictionaries have to say about it, so we are on the same page here:
“To help somebody learn something by giving information about it.”
Oxford Dictionary“To give someone knowledge or to train someone; to instruct.”
Cambridge Dictionary
I guess I like the teacher's stance so much because I enjoy training people and promoting knowledge. What it basically means is, facilitating the learning of the teams. That’s also why I enjoy recording the videos for my channel and writing these articles. I am very glad to be helping others learn about Agile and Scrum Master’s accountabilities.
In practice, it means that as a Scrum Master I set up training sessions to teach about Agile, Scrum, etc. I also enjoy teaching Management 3.0 practices, hence my video about “Kudos and recognition” or about “Nonviolent communication”, which, in a context of an organization, means fostering the feedback culture. I think Scrum Master’s and Agile Coach’s role is to develop an Agile toolbox that can help us to choose a useful tool for a variety of situations.
Be a teacher, be firm
When you read Lyssa Adkins’ “Coaching Agile Teams”, you see the difference between a Professional (life) Coach and an Agile Coach pretty clearly. I also explain this distinction more in my article about “Agile Coaching”. She talks clearly about the firmness of an Agile Coach in their teachings about Agile. As opposed to letting the coachee find the best way themselves, an Agile Coach directs the coachee to look for answers in Agile practices:
You know a better way to work, so feel the steel rod as you teach agile. Convey the rules strongly, along with your belief that agile gives us a better way to work.
Lyssa Adkins “Coaching Agile Teams”
She compares the teaching stance with“Shu” in Shu-Ha-Ri. Meaning that when you are a teacher, you should be firm in your position. Your attitude should be solid because you are setting the foundation — you are at Shu. At this point, the team needs to learn the rules and start applying them. There will be time for “breaking the rules” once the foundation is solid — at that point the team won’t need a teacher anymore. They will work with a mentor.
“Follow these rules. I have followed them before, and I know they will give you what you want. So, for now, just follow.”
Lyssa Adkins “Coaching Agile Teams”
It makes a lot of sense when you think about it. If you don’t know a framework you cannot know if it will work for you or not. I remember how challenging it was for me when I was getting to know Kanban. I didn’t know it well and I knew Scrum much better. So I was reluctant to try it — manage the flow and limit work in progress? Sounds too drastic! This can’t work! I needed to be persuaded, I needed to learn about it, to see some examples and exercises before I was willing to try it out. And look, afterward, Kanban worked out for me so well that I keep on adding it to Scrum.
To coach or to nudge?
When talking about coaching, we have this notion not to push anyone to do anything. We explain and they should voluntarily come onboard. We don’t want to be mistaken for a Project Manager, god forbid! And I don’t have anything against Project Managers. It is just that sometimes in the world of agile coaching it feels like there are people who have a hard time defining their role. And the only thing they know is that they don’t want to be a Project Manager. And they end up fearing a firm approach because they associate it with project management and “command and control”.
It is misleading because people don’t know what they don’t know and teaching is not pushing directly to do something, it is pushing to learn something, to expand one’s horizons. Maybe “nudging” is a better way to put it. Only after the teams try a new practice and decide if it works for them or not. Be firm, have no fear!
Teaching moments
Lyssa mentions that in the cycle of working with the teams, there are many opportunities to put on the teacher’s hat for a coach:
“Teaching agile during team start-up, during restarts, during unexpected moments, teaching the roles in agile; and continuously holding people to the best expression of these roles.”
Lyssa Adkins “Coaching Agile Teams”
I will explain a bit how to make use of the teaching moments in practice. Let’s see how we can use them to help the teams learn about Agile.
1. Team start-up — I helped to set up a number of new teams throughout my career. Both co-located where we could hold in-person workshops, and distributed via Zoom.
Lyssa mentions three important ingredients of bootstrapping the teams:
1. Learning about the process to be used,
2. Learning about the team,
3. Learning about the work ahead.
I like to change the order and start with the team introduction. There are many activities to help the team get to know each other like Personal Maps, Journey Lines, or Market of Skills. Look them up as they will help you break the ice and help the team better relate to one another by learning about similar interests and skills.
After the team gets to know each other a little bit better, we can move on and have a session about the process to follow. This can be combined with roles explanation. This too can be done as an interactive exercise so the teams learn by playing and interacting. Last but not least, would be great to invite some stakeholders and explain the product (and their roles) and what would be the goal of the team. Usually, at this point, I would ask the team to come up with a name they could identify with — could serve as a great closing exercise.
2. Teach new team members — teams change constantly, we hope they would stabilize for some time but the change is inevitable. This should be a short version of the previous point. Get the team member up to speed on the process, the product, the team goal, and try to find a slot when they can meet the team and present themselves. A 30 mins meet-the-team event on the calendars should do the trick. One thing I liked about my previous work was that each new member was tasked to schedule short 15-30 mins 1-on-1 intros with all the team members. That helps to create a relationship and a link with other team members.
3. Teach Agile roles — there are different kinds of agile roles like Product Owner, Scrum Master, and Developers from Scrum but we also have User Experience Designers, Product Managers, and all kinds of Agile Managers too. You probably noticed how different roles get misunderstood or interlocked resulting in great confusion and sometimes even frustration. Helping set up the expectations and responsibilities for each role can spare us headaches later on. We should still put a lot of emphasis on the team and people being team players though as opposed to confusing the responsibilities with silos and separation.
4. Teach the teacher—We are not the only people that know stuff, are we? There are many Developers and Product Managers that follow great practices and they can share them with others. Maybe they need a little “push” to do it. Then, we can create some knowledge-sharing opportunities.
There are a lot of ready-made formats to leverage peer-to-peer learning like:
- Communities of Practice,
- Lightning Talks,
- Brown Bags,
- Bridge Talks, etc.
You can start the initiative yourself and gather people who want to share some best practices with others. Creating communities of practice around a certain area of knowledge, a domain can help learn best practices of coding, reviewing pull requests for developers or best practices of product development, etc. Those are working groups that learn from each other. Then there are the talks where people just prepare a training or a presentation about a given subject and teaches something new or share their experience with others. Those are some great practices that keep people engaged.
Let’s take an example of Bridge Talks that we do in Outsystems. The main goal of a Bridge Talk is to inform, ask, or educate other teams.
Inform — We’re working on a thing or we need teams to be aware of this security measure;
Ask—We want to ask other Developers or Product Owners for assistance. E.g. have a prototype and need engineers to help test it.
Educate — I’m using this tool and think others should know, so I share my experience with it.
5. Make use of teachable moments—those occur constantly. We are having a retrospective and while talking about the daily, we learn that its goal got lost in execution. We can take this opportunity to explain briefly the goal of a Daily Scrum and set up a session for the team to explain it better along with some alternative ways to do it. It is great to take advantage of such teachable moments to teach the basics and also expand the horizons of the team. We can send an interesting article (like this one) or a cool YouTube video via Slack so the team can learn more on their own if they want to.
One important point to touch here — beware of coming across as pedantic when in the teaching stance. The way you approach it can be a make or break your relationship with the team. I think one way to avoid annoying the team with your teachings is to draw their attention to what’s in it for them. Underline the value for the team, as opposed to quoting the Scrum Guide. “You think the Daily Scrum is a waste of time? What if we re-designed it in a way so that you can eliminate some other meetings from your agenda?” Let’s keep in mind the goal is not to do Scrum or be agile, the goal is to help the teams optimize their work and deliver great products.
Scrum Master as a teacher is a great stance, at least for me. We get to help people learn and improve their ways of working. We can help them be more efficient and optimize some of their processes. We can also teach them where to find useful information by explaining Agile, Lean, Extreme Programming, and so on.
That’s all for today! I hope this article will help you be a great teacher for the team and also find a lot of satisfaction in your daily work!
