SCRUM MASTER STANCES
Scrum Master as a Coach & Mentor. No BS.
Is coaching utter bullshit or is it a way to actually help the teams?
Today we are going to continue exploring the Scrum Master stances. And it’s time to look at the magical term that is “coaching”. Savage!
I would like to hear from anyone who has never contemplated if coaching was actually a thing or rather mostly bullshit! Anyone, please leave a comment! I used to find it really hard to believe it was not the second. How am I supposed to help people be better at Agile by coaching them on something they don’t know?
On coaching
Today I will explain why we are not coaching the teams in Agile. No coaching, no bullshit, right? And I will clarify what we do instead, and call it coaching.
In the last articles, I spoke about the Scrum Master as an Impediment Remover and a Teacher. Today it’s time to talk about what it actually means to coach the teams, or should I say “mentor’? I will explore the difference between the two. Pay attention, as this is one of the most popular topics during the Scrum Master /Agile Coach job interviews.
Disclaimer — The Stances of Scrum Master
I use the term “stance” freely and base it on my own experience and two other sources: Lyssa Adkins’ book “Coaching Agile Teams” where she refers to them as Agile Coach “styles”, not stances, and Barry Overeem’s whitepaper “The 8 Stances of a Scrum Master”.
Depending on the situation, Scrum Masters adopt a number of stances. There’s the impediment remover, the teacher (both described in previous articles and linked videos), 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.
Definitions of a coach and a mentor
Let’s see what British dictionaries have to say about a coach and a mentor, so we are on the same page:
“An experienced person who advises and helps somebody with less experience over a period of time.”
Mentor, Oxford Dictionary“A person who is employed by somebody to give them advice about how to achieve the things they want in their life and work.”
Coach, Oxford Dictionary“A person who gives a younger or less experienced person help and advice over a period of time, especially at work or school.”
Mentor, Cambridge Dictionary“Someone whose job is to provide training for people or to help prepare them for something.”
Coach, Cambridge Dictionary
What’s the difference?
“The context of Agile makes you a mentor; the focus on team performance makes you a coach.”
Lyssa Adkins “Coaching Agile Teams”
Lyssa explains that in our Agile world, the word coach as in Agile Coach means both coaching and mentoring. Agile defines us as mentors:
“First and foremost, we uphold Agile. Second, we coach.”
Lyssa Adkins “Coaching Agile Teams”
We use skills from the professional coaching world to help us mentor Agile teams. We are not professional coaches and we don’t let the coachee lead the way because we need to influence them to use Agile well. Not just for the sake of Agile but in the context of our company. We want the teams to deliver great products using a healthy process. This way they can derive satisfaction from their work and that's a win-win situation.
Let’s summarize the difference between a mentor and a coach:
- A mentor is someone who knows more than you do about a certain domain and is guiding you through the learning journey. It is a counselor, a guide a great teacher. A Yoda. Someone who will advise you on how to make the most of a given domain.
- A coach doesn’t necessarily need to be a specialist in the subject of the matter, they are there to help you bring the best of you. Find your own solutions using what you already know. Barry wrote that coaching is “helping someone to see new perspectives and possibilities.”
What it means is that since we specialize in the Agile domain, we provide mentoring to the teams about it. Knowing at the same time what my colleague at Serius Scrum says that “Scrum is mastered together. A Scrum Master cannot master Scrum alone.”
Let’s see an example. A team member comes to us and says they don’t see value in the Daily Scrum because they are a Designer and the Developers use very technical language. We could start asking questions like, what do you think you could do about it? What could be a suitable moment to raise this with the team? (And pray for them to answer “The Sprint Retrospective”). We can do that or we could inquire how they run the meeting currently. And then offer some advice on how it could be tweaked to provide more value for all Scrum Team members. For example, employ the Walk the Board technique instead of going person by person and leave the technical conversations for after the Daily. This is the main difference between the two approaches. And my take on it is that if I know an alternative or a different way to do things, I can share them with the person as a mentor. A coach shouldn’t offer solutions because “effective coaching is guiding without prescribing”. You can find some interesting and light co-active coaching techniques here.
Why then do we call ourselves Agile Coaches?
Even Lyssa, who wrote a whole book about it, hints that it might not be the most adequate term to use. But it stuck and in an Agile context, we use the term coaching to describe our relationship with the people we work with. Even though we spend most of the time teaching, mentoring, or even preaching and rarely really coaching.
I find it important to underline because I met many Scrum Masters or Agile Coaches that were lost as to what is expected of them at work. And I was lost at some point too. And I would have appreciated it if someone would have explained it to me back then. OK, having this cleared out, let’s continue talking about our coaching.
Shu-Ha-Ri
In the previous article about Scrum Master as a Teacher, I explained how the teacher acts in the Shu phase. At the teacher stance, we teach the rules and the teams are to follow them. After the team members get to know the rules, they start breaking them, playing with the system or framework, the Ha. This is when the coach in the Scrum Master steps in and helps them see new possibilities. In the end, they get to the Ri — they become the rule. Then they find a mentor who will guide them and offer advice.
Be kind, be firm
Lyssa mentions three traits of a great coaching tone: loving, compassionate, and uncompromising. As an Agile Coach or Scrum Master, you should honor other people and appreciate them for what they know and bring to the team, and the company. While at the same time, you ought to be firm — we spoke about this already in the previous post about the teacher stance. Lyssa clarifies yet another myth about agile coaching:
“Coaching has nothing to do with stroking their vanity and making them feel good about themselves. Instead the coach takes the strong stand needed to get to the next level of agility possible for each person and, in so doing, raises the level of agility all around.”
Lyssa Adkins “Coaching Agile Teams”
Coaching individuals and coaching the teams
As Agile Coaches, we distinguish different coaching moments. We coach the whole team — especially at the beginning and end of a Sprint or an important release. And we also coach people 1-on-1. This is an important distinction yet it all depends on our soft skills to find the right moments for both. We don’t want to interrupt the team when they are full-on coding, focused, and immersed in solving complex problems. That is why the whole team coaching is best performed at the beginning or end of a Sprint or a release.
On the other hand, 1-on-1 coaching can be performed throughout the Sprint. Our job is to help “each team member take the next step in their Agile journey”. Establish a relationship with all the team members right at the start, so whenever a problem arises, you have the context of all the team. Coach the Product Owner, the Managers, Architects, UX Designers — all people that interact with the team.
Coaching with Metrics
I’ve quoted Lyssa above that a coach focuses on team performance. Having software delivery metrics accessible can help us a lot. On a retrospective, we can talk about our impressions on the past Sprit that are subjective. However, we can also talk about metrics that provide an objective view of things. Agile metrics help software teams to monitor their productivity across different phases of the delivery and also monitor their code quality.
Our role as Agile Coaches is to foster the usage of metrics, help everyone understand them, and learn to use them for continuous improvement.
And that’s all for today. I wonder what you think about this approach to coaching and if you too find this kind more convincing. For me, it was like a revelation and finding a sweet spot where I feel comfortable.
