The term "agile coach" gets thrown around a lot. Sometimes it means a Scrum Master who's gone a bit broader. Sometimes it means an external consultant. Sometimes it's a job title on a LinkedIn profile that nobody can quite define at the interview. So let's be concrete about what an agile coach actually does, why the role exists, and what separates a genuinely useful agile coach from someone who just runs retrospectives with sticky notes.

If you're wondering whether you need one, want to become one, or are already doing the work without the title, this article is for you.

The core job: helping people think differently

At its most basic, an agile coach helps individuals, teams, and sometimes whole organisations think differently about how they work. Not just adopt a framework. Not just follow a process. Actually change the mental models that drive behaviour.

That's harder than it sounds. A team can do daily scrums for six months and still be fundamentally waterfall in how they plan, commit, and hand off work. An agile coach spots that gap and works to close it, usually through a mix of coaching, mentoring, facilitating, and yes, sometimes teaching.

These are distinct stances, and a good agile coach moves between them deliberately. You're not always coaching, and you're not always teaching. Knowing which mode the situation calls for, and being willing to switch mid-conversation, is one of the most practical skills you can develop in this work.

Coaching vs. teaching vs. mentoring: what's the difference?

These three words get used interchangeably, and that's a problem, because they require completely different behaviours from you.

Coaching

Coaching is about asking questions, not giving answers. You're helping someone surface their own insight. A classic coaching moment: a Scrum Master comes to you frustrated that the team keeps skipping the Sprint Review. Instead of telling them what to do, you ask, "What do you think is driving that?" and then you shut up and listen. The Scrum Master figures it out. That's coaching.

Teaching

Teaching is the opposite. You have knowledge the other person doesn't, and you transfer it. If a new Product Owner has never written a user story and doesn't know where to start, you don't coach them into discovering story format from first principles. You teach them. You show them examples, explain the structure, maybe run a short workshop. Teaching is direct, efficient, and totally appropriate when the knowledge gap is real.

The mistake a lot of agile coaches make is defaulting to coaching when teaching would be faster, or defaulting to teaching when the person actually needs to find their own answer. Good agile coaches read the room and choose the right mode. You can explore this further in our Team Coaching for Scrum Masters Training, which covers exactly this kind of situational awareness.

Mentoring

Mentoring sits somewhere in between. You share your experience, you offer perspective based on what you've seen, but you're not prescribing. You might say, "In a similar situation I saw a team try X, and here's what happened." The mentee takes what's useful and leaves the rest.

What does an agile coach actually work on?

Day to day, an agile coach might be doing any of the following:

• Observing team events (Sprint Planning, Daily Scrum, Retrospective) and giving feedback on dynamics and patterns they notice
• Coaching individual Scrum Masters or Product Owners on specific challenges they're facing
• Working with leadership to help them understand what it means to support a self-managing team (rather than managing it into the ground)
• Facilitating workshops, especially where a team is stuck or a conflict needs a neutral third party
• Helping a team inspect their own process, not just their product, so they actually improve between sprints
• Teaching concepts like the empirical process, the meaning of Scrum, or why agile is more than a methodology

Notice that most of this is about people and systems, not tools or frameworks. An agile coach who mostly talks about Jira configurations or Confluence templates probably needs to zoom out.

Agile Coach vs. Scrum Master: not as different as you might think

Here's the thing: a Professional Scrum Master is an agile coach. They have simply chosen Scrum as their framework of choice. The coaching stance, the facilitation skills, the work of helping individuals and teams think differently about how they work, that's all core to what a great Scrum Master does. The Scrum Guide 2020 is clear about this: the Scrum Master serves the Scrum Team, the Product Owner, and the organisation. That's an agile coaching role by any reasonable definition.

Where it gets confusing is that many organisations use "Agile Coach" as a kind of organisational hierarchy title, placing it above Scrum Master as if it were a promotion. In that framing, Scrum Masters do the day-to-day team work and Agile Coaches float above them doing something more strategic. This distinction is mostly an organisational construct, not a meaningful difference in skills or purpose. It can create unhelpful dynamics where Scrum Masters feel they need to "graduate" to become an Agile Coach, rather than deepening their coaching capability within the work they're already doing.

The more useful distinction is scope. A Scrum Master is typically accountable for one team's effectiveness. An agile coach might work across multiple teams, coach Scrum Masters directly, or partner with leadership on broader change. But plenty of senior Scrum Masters do all of that too, especially in smaller organisations. The title matters less than the skills and the scope of what you're actually doing.

If you want to develop a stronger coaching capability as a Scrum Master, the Professional Scrum Master Advanced (PSM-A) training is a good next step. It goes well beyond the mechanics of Scrum and into the kind of situational leadership and team dynamics that agile coaching requires.

What skills does an agile coach need?

A few things matter more than anything else:

• Active listening. Not waiting for your turn to talk. Actually listening well enough that you can reflect back what you heard and ask a useful follow-up question.
• Asking good questions. Open, curious, non-leading. "What's getting in the way?" beats "Have you tried X?" almost every time.
• Systems thinking. Teams don't exist in isolation. A team that keeps missing its Sprint Goal might have a planning problem, or it might have a dependency problem, or the Product Owner might be getting pressure from a VP who doesn't understand Sprint Goals. An agile coach traces the system, not just the symptom.
• Facilitation. Running a meeting is not facilitation. Facilitation is designing a session so that the right conversations happen and decisions get made. Our Professional Scrum Facilitation Skills training (PSFS) builds exactly this.
• Knowing when to step back. The goal of an agile coach is to make themselves unnecessary. If a team still needs you to hold their hand in their twentieth sprint, something hasn't worked.

Helping teams think differently, in practice

One of the most concrete things an agile coach does is surface assumptions. Teams often carry hidden beliefs: "We can't release without sign-off from legal," or "The Retrospective is just a venting session." These beliefs drive behaviour, and changing the behaviour without changing the belief doesn't stick.

Helping a team think differently means getting those assumptions visible. You might use a simple exercise in a Retrospective: ask the team to finish the sentence "We believe we can't do X because..." and then challenge whether that belief is actually true. Sometimes it is. Often it isn't. Either way, the team learns something.

This is slow work. Organisational habits are sticky. But done consistently, with patience and the right mix of coaching, teaching, and facilitating, it's the kind of change that actually lasts.