Ep1 SPEED Coaching

February 3, 2026

Episode Summary

In this inaugural episode of the Agile Skills Library, Geoff Watts and Paul Goddard introduce SPEED Coaching — a practical framework for choosing how to help teams and individuals more deliberately.

Many coaches default to a single stance: either asking questions endlessly or jumping straight into advice. SPEED Coaching challenges that reflex. Instead, it offers five distinct ways of intervening, each suited to different contexts, relationships, and needs.

Using a realistic Scrum Master scenario, Geoff and Paul walk through the SPEED model:

Suggestions — offering ideas quickly when clarity or expertise is genuinely needed  
Proof — using data and safe experiments to build shared understanding  
Enablers — removing impediments and creating conditions for progress  
Environment — changing the surrounding system so better behaviour becomes easier  
Drivers — working with values and motivations to create deeper, longer-lasting change

The key insight is that faster interventions tend to create quicker results but shallower impact, while slower approaches often build greater ownership, agency, and resilience over time.

No option is inherently right or wrong. The real skill lies in pausing, assessing the context, and consciously choosing how to show up as a coach or leader.

This episode includes a free downloadable SPEED Coaching template to help you apply the model with teams, individuals, or even yourself.

Full Transcript

Read full transcript

<h2>Agile Skills Library — Episode 1</h2>
<h3>SPEED Coaching</h3>

<p><strong>Geoff Watts:</strong><br>
Hello, and welcome to the Agile Skills Library. I’m Geoff Watts, and I’m here with my good friend and colleague, Paul Goddard.</p>

<p>We’ve created this podcast to share our favourite tools and techniques from the last 50 years between us of coaching teams and organisations to become more effective at whatever they’re doing.</p>

<p>In every episode, we’ll explain a specific technique and share a downloadable template to help you put it into practice.</p>

<p>Thanks for listening — it’s great to have you here.</p>

<p><strong>Paul Goddard:</strong><br>
Welcome, listeners.</p>

<p><strong>Geoff:</strong><br>
This is the inaugural episode in a new series we’re calling the Agile Skills Library — where Paul and I basically give away everything we’ve ever learned, for free.</p>

<p><strong>Paul:</strong><br>
Well, great guys we are.</p>

<p><strong>Geoff:</strong><br>
Every episode we’ll introduce a new technique you can use with someone you’re coaching, a team you’re supporting, or even yourself.</p>

<p>This week’s episode is about something we call <strong>SPEED Coaching</strong>. SPEED is an acronym, and it’s a meta-technique — a way of consciously choosing <em>how</em> to help based on the context you’re in, the team you’re working with, and the relationship you have with them.</p>

<p>It’s primarily aimed at coaches — Scrum Masters, Agile Coaches, delivery coaches, product coaches — but we’ve also used it successfully with people in broader leadership roles.</p>

<p>So Paul, why do you think SPEED Coaching is useful?</p>

<hr>

<h3>Why SPEED Coaching?</h3>

<p><strong>Paul:</strong><br>
I think it helps coaches and Scrum Masters realise that it’s okay to have an opinion.</p>

<p>It gives you a way to decide <em>when</em> an opinion is appropriate, depending on what the team actually needs. Sometimes people just want advice — “What do you think about this?” — and SPEED Coaching legitimises that.</p>

<p>It also helps coaches notice their own bias. Most of us default to one coaching style. This model gives you options and encourages you to ask:<br>
<em>Is there a different way I could help in this situation?</em></p>

<p><strong>Geoff:</strong><br>
We’ve often used the word <em>intervention</em> for this — choosing how you show up and how you intend to help.</p>

<p>There’s a common myth that coaching must be purely Socratic questioning. That the only way to build confidence, competence and agency is by asking non-directive questions.</p>

<p>You absolutely <em>can</em> have an opinion as a coach.</p>

<p>At the same time, many people who call themselves coaches default almost entirely to directing — telling teams what to do. That’s not wrong, but it’s a very specific type of help.</p>

<p>SPEED Coaching gives us a pause point. It helps us consciously choose the <em>right</em> kind of help for the team in front of us.</p>

<hr>

<h3>A practical scenario</h3>

<p><strong>Geoff:</strong><br>
Let’s make this concrete.</p>

<p>Imagine I’m a Scrum Master working with a team that runs regular retrospectives. They generate plenty of improvement ideas — but very few ever get implemented.</p>

<p>I’ve noticed the pattern, and I want to intervene.</p>

<p><strong>Paul:</strong><br>
So they’re reflecting, but not taking ownership of improvement?</p>

<p><strong>Geoff:</strong><br>
Exactly — not as much as I think they could.</p>

<p>Let’s walk through the SPEED model using this example.</p>

<hr>

<h3>S — Suggestions</h3>

<p><strong>Geoff:</strong><br>
The first letter is <strong>S: Suggestions</strong>.</p>

<p>This is me offering ideas — what I think they <em>could</em> do. It’s fast. It’s comforting. The team doesn’t have to think too hard.</p>

<p>But there’s a downside. If my idea works, it increases dependency on me. Long-term, that’s not what I want.</p>

<p>This isn’t really coaching — it’s closer to mentoring.</p>

<p>That said, if I <em>genuinely</em> know the answer, and they know I know the answer, then pretending not to have it is just irritating.</p>

<p>When I do give suggestions, I try to give <strong>three plausible options</strong>, not one “right” answer. That preserves some agency.</p>

<p><strong>Paul:</strong><br>
And you’re using your experience transparently — “I’ve tried this before, and it worked in this context.”</p>

<p>That framing matters.</p>

<hr>

<h3>P — Proof</h3>

<p><strong>Geoff:</strong><br>
Next is <strong>P: Proof</strong>.</p>

<p>Here, instead of ideas, I bring data or help the team gather evidence themselves.</p>

<p>For example, I might say:<br>
“You average around seven improvement ideas per sprint, but only implement one. When you <em>do</em> implement them, delivery improves and team happiness goes up.”</p>

<p>That information alone might be enough to trigger change.</p>

<p>This approach is slower than suggestions — it takes time to gather and interpret data — but it strengthens ownership.</p>

<p><strong>Paul:</strong><br>
And sometimes you don’t know the answer. Proof lets you run safe experiments instead of relying on gut feel.</p>

<hr>

<h3>E — Enablers</h3>

<p><strong>Geoff:</strong><br>
The first <strong>E</strong> stands for <strong>Enablers</strong>.</p>

<p>This is about asking: <em>What can I do to make progress easier for you?</em></p>

<p>That might mean removing impediments, introducing tools, or creating enabling constraints.</p>

<p>For example, I might limit the team to no more than two improvement actions per sprint — a constraint designed to help, not control.</p>

<p>Or I might introduce an experiment canvas to help them structure their thinking.</p>

<p>This is slower again — but it builds capability.</p>

<hr>

<h3>E — Environment</h3>

<p><strong>Geoff:</strong><br>
The second <strong>E</strong> is <strong>Environment</strong>.</p>

<p>Here we stop focusing on the team and look at the system around them — incentives, policies, habits, cultural signals.</p>

<p>Often the behaviour we’re seeing is the <em>natural outcome</em> of the environment they’re operating in.</p>

<p>Small environmental changes — recognition, authority boundaries, psychological safety — can make better behaviour the path of least resistance.</p>

<p><strong>Paul:</strong><br>
This is one of my favourite parts of the model. The most effective changes here are often subtle — the team might not even notice them consciously.</p>

<hr>

<h3>D — Drivers</h3>

<p><strong>Geoff:</strong><br>
Finally, <strong>D: Drivers</strong>.</p>

<p>This is about values, motivations, and what truly matters to the team or individual.</p>

<p>If we understand those drivers — or help the team articulate them — we can hold decisions and behaviours up against them.</p>

<p>It’s the slowest lever, but often the deepest and most durable.</p>

<hr>

<h3>Wrapping up</h3>

<p><strong>Geoff:</strong><br>
So to recap:<br>
<strong>Suggestions → Proof → Enablers → Environment → Drivers</strong></p>

<p>The further you go, the slower the change — but the deeper and longer-lasting the impact.</p>

<p>No option is inherently good or bad. The skill is choosing deliberately.</p>

<p>We’ve added a free SPEED Coaching template to the website, with an example and a blank version you can use with individuals, teams, or even yourself.</p>

<p>Let us know how it goes — we’d love to hear what you discover.</p>

<p><strong>Paul:</strong><br>
And stay tuned — we’ve got a whole library of tools and techniques coming your way.</p>

<p><strong>Geoff:</strong><br>
Thanks for listening to the Agile Skills Library. You’ve got another agile skill in your toolbox. Use it well.</p>