Following up on the last episode about Scrum Master for Kanban Teams, today we are going to talk about Agile Coaches. Who are they? I call myself an Agile Coach but also a Scrum Master and at my current work, I am called an RTE (Release Train Engineer as per SAFe). Which is it?

YouTube Video on the subject by the author

Today we’ll talk about the difference (or its lack) between a Scrum Master and an Agile Coach and how to step up your game as an Agile Coach.

Moreover, I will mention an important distinction between outcome, output, and activity. And I will introduce the different Agile Coaching frameworks. In the end, we will ponder a bit whether the Agile Coach is the most suitable name for the role.

DISCLAIMER: Today I am going to express my opinion, A LOT. Of course, I will support it with Scrum Guide and Agile Coaching frameworks. But just keep in mind, it’s just one opinion of many out there.

Let’s see how this goes!

Priests of the Agile religion

Recently, I’ve got a question from a colleague at work: “Agile Coaches, who are they anyway? — I am used to working with Scrum Masters, I know who they are. But Agile Coaches? They seem more like priests of Agile religion.”

I wanted to part from Agile dogmatism and call out this frequent antipattern. I think it is an issue we face in the Agile Coaching practice. Instead of coaching, we find ourselves preaching: thou must do Daily Scrums, thou must do Retrospectives. In his recent article about biases, Serious Scrum founder, Nijland, writes about how to read Scrum articles critically by asking questions:

Why is an author using certain metaphors? For example, why is the author referring to ‘ceremonies’ instead of events and using words like ‘dogmatism’, ‘preaching’, ‘cultivating’, and pictures of churches and priests?
“How to detect bias when writing and reading about Scrum” by Sjoerd Nijland

This kind of approach alienates people. Instead of helping the teams be more efficient and get things done, we create artificial processes they don’t understand. Let’s see how we can overcome this.

Misleading notions

I have to confess that a few years ago I had my moments of being an Agile priest too. Have you ever found yourself on a meeting discussing what a spike really is and derailing the meeting’s objective for the sake of spike philosophy? Or have you ever spent time and energy discussing why calling Sprint Review a “Demo” is a mortal sin? Well, I did.

Did it bring anyone more clarity—maybe? Was it productive and brought anyone real value — I don’t think so! Today I prefer to call it a Sprint Review but won’t make a fuzz if it’s called a “Demo”, I just want to make sure the goal of the meeting is understood. And believe me, many times it isn’t!

The naming

The naming of the role is also misleading. I remember preferring the term Agile Coach over Scrum Master because it sounded better, more professional, more senior. I remember learning from the internet that Scrum Master is focused on the team, and an Agile Coach is focused on the organizational level and acts as a kind of Senior Scrum Master. All the more reasons to want to be an Agile Coach instead. Just a reminder from Scrum Guide, 2020:

“Scrum Masters are true leaders who serve the Scrum Team and the larger organization.”
Scrum Guide, 2020

So the idea of Agile Coach being the designated organization evangelist is to say the least, not in line with Scrum. Scrum Masters also serve the organization in its Scrum adoption.

I gotta tell you that there is a lot of bullshit about the Agile Coach role circulating on the internet. And when you are new to the role you might buy into it and end up confused.

From my experience, and it’s an experience limited to Europe as I worked in German, Icelandic, Austrian, Spanish, and Portuguese companies, the term Agile Coach was brought to replace Scrum Master for various reasons. One was to get rid of any confusion if Scrum Master can work with teams that are using Kanban, hence my latest video: Scrum Master In Kanban.

Another reason would be that the company decided to have fewer people in the role and Agile Coach, in their view, should be able to work with more teams. There is also this notion of Agile Coaching as a service — working next to the teams rather than being an equal team member like a Scrum Master, as Scrum Guide prescribes:

“Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.”
Scrum Guide, 2020

In my view, that’s all optimization of the role, to have less people in an organization and be more attractive as a recruiter: you will be an Agile Coach in our company. I think we should stop overthinking this.

How much coaching is there in Agile Coaching?

This one is really messed up. Don’t even know where to start. Let me start with this — I prefer to call myself an Agile Coach as opposed to a Scrum Master because in Agile Coach there is at least the noun “coach” which can give someone a notion of what I’m doing.

“Ah, coaching, ok.” Rings a bell. If I say Scrum Master I only get a blind look. I am explaining this because this coaching part is a common misconception among Agile Coaches. I met some, that consider that their work consists mainly of asking powerful questions as per being a real coach.

Well, I tell you what, there is not so much coaching in Agile Coaching. There is teaching, and mentoring and facilitating, and other flavors to it. I will explain more when we get to Lyssa Adkins' framework. My point here is not to confuse professional coaching with Agile coaching.

We are not life coaches, we help people understand and practice Agile. And as opposed to the professional coaches, we are allowed to give advice, consult and teach Agile to teams and individuals. To understand it better, I recommend watching Geoff Watts’ lecture on the subject where he compares the two ways of coaching.

This lecture will hopefully prevent you from going through your day and only asking the “powerful questions” and being all “flower-power” about the practices that go against the team’s effectiveness. Responding, “Oh, the team knows what’s best for them” — when the team is struggling to collaborate and refuses to inspect ad adapt their ways of working.

Because guess what, they might not know how to foster their collaboration or why stopping to reflect on what is going on will help them improve. As an Agile Coach, you are there to provide them with context and teach them the practices and tools that might help them improve their teamwork.

Let’s see the different Agile Coaching frameworks and understand how much coaching there is in Agile Coaching.

Agile Coaching Framework by Lyssa Adkins

This is Lyssa Adkins’ framework and you can find it in Agile Coaching Institute. Lyssa is the author of any Scrum Master or Agile Coach bible: Coaching Agile Teams.

That book should be a recommended read for anyone who is working with teams in an agile environment. It explains the different stances of coaching teams, just like Barry Overeem’s “The 8 Stances of Scrum Master”: The Scrum Master as a Servant Leader, Facilitator, Coach, Manager, Mentor, Teacher, Impediment Remover, and Change Agent.

And in the introduction to the stances, Barry coincides with what I previously said:

“Also included are the most common misunderstandings of the Scrum Master role and why Barry has changed his title from Agile Coach to 100% Scrum Master. The reasons behind this change describe his motivation for writing this white paper.”

Agile Coaching Framework as per Agile Coaching Institute

For a great number of great materials on Agile Coaching, go to Agile Coaching Institute and see the long bibliography on their website.

There are some other frameworks I want to mention here. They all have the same outcome, slightly different output, and detail to each of the parts.

Agile Coaching Growth Wheel

Agile Coaching Wheel provides more detail to each stance. Can be helpful when you just discover the framework and want to understand each stance.

Agile Coaching Wheel. Find more at http://whatisagilecoaching.org/

Agile Coaching DNA

My friend, Joan, shared this one with me recently. I like Agile Coaching DNA because it is more about the overall outcome, not explaining how to do things, just outlining the value an Agile Coach can provide. I guess if you are new to the role, you first might want to get acquainted with the previous two and then understand this one.

Agile Coachging DNA

Be pragmatic and get some perspective

When you are on your path to becoming an Agile Coach don’t forget to get some context about the company, the product you are developing.

This will prevent you from preaching Agile a bit too hard, going into philosophical discourses on the teams’ meetings, and well, wasting everybody’s time. I don’t mean it is not good to get philosophical from time to time but you can go and do that in your Community of Practice with other Agile Coaches. That’s a great opportunity for that.

However, when you are with the teams or with the leadership, focus on the problem to solve and help facilitate the meeting, so as few people as possible consider it a waste of time. From my experience with Zoom meetings, it is almost impossible to have everyone happy with any meeting, so no moonshots here.

Outcome, output, and activity

So we talked a lot about those misleading notions, philosophy, and treating agile as a religion as opposed to being pragmatic. Now it’s time to move forward and start getting things done.

For this, I want to present you what I call Barnet’s framework. Barnet is one of the Directors at Outsystems and I indirectly report to him. He brings up a lot the distinction between outcome, output, and activity.

Which is basically a distinction between keeping busy and providing value. I think this is crucial to our role as Scrum Masters and Agile Coaches. Not only for what we do but also to help the teams understand what’s expected of them.

So think about “activity” as being busy, doing things, attending meetings, etc. The “output” is what you produced, a story has been done and functionality added to the product, you wrote meeting minutes, etc. And the “outcome” is the value these previous things provided to the customer, the company or yourself. What is the gain?

There is a huge difference between keeping oneself busy and producing an outcome. If you keep yourself busy, even produce a lot of output but if there’s no outcome and there is no value to the customer, to the company, and/or to yourself — ask yourself, why did we even have the output? Why did we engage in this activity in the first place? This should be the question you ask yourself and the teams everyday. This is how you provide value — teaching the teams to think in outcomes and not in outputs.

Growth mindset

You probably heard the term “feature factory” that’s a popular term to call a company that focuses on delivering features. One that never stops to consider if any of them are valuable to the customers and what value they bring to the company.

As an Agile Coach, you should be teaching this growth mindset to the teams and individuals to avoid working in a feature factory. Help them shift their thinking to it.

It will also help you determine what is the goal behind your role. What is the outcome you want to achieve through your activity with the teams? Do you want them to do Daily Scrums in under 15 mins and have a long list of things to improve after the Retrospectives? Or do you want them to understand why iterative development will help them in their complex work? And why planning their collaborative work each day helps keep their focus on the goal and quickly react to any changes?

And that’s all for today. I hope this episode has given you some food for thought and you’ll get some inspiration in your role as Scrum Master, Agile Coach, or Agile-Lean Practitioner. Happy to hear your thoughts in the comments!