Skip to content
Preptima

Agile coaching fundamentals

What a coaching interview assumes you can already discuss: the stances and when to drop them, what each scaling framework adds and removes, dependency reduction as distinct from dependency tracking, facilitating a room of a hundred people, and which programme measures survive being made targets.

56 questions

Go deeper on Agile Coaching
Standard Sheet View

Coaching vocabulary and stances

Put coaching, mentoring, teaching, facilitating and consulting side by side.

Job adverts use the five words interchangeably, and the interview usually turns on whether you can say which one a situation calls for.

stance        who holds the answer      what you do            when it is right
------------  ------------------------  ---------------------  --------------------
Teaching      you do                    transfer knowledge,    the team genuinely
                                        explain the mechanism  does not know a
                                                               thing yet

Mentoring     you do, from having       share experience,      someone growing into
              done the role             offer what you would   a role you have held
                                        do and why

Coaching      they do                   ask, reflect, hold     they have the answer
                                        silence, refuse to     and have not yet
                                        supply the answer      articulated it

Facilitating  the group does            own the process, stay  a decision belongs
                                        neutral on content     to the group and the
                                                               process is failing

Consulting    you do, and you are       diagnose, recommend,   the organisation
              accountable for it        put your name on it    needs an answer and
                                                               owns the risk

The failure is not picking wrongly once. It is holding one stance for
everything - usually coaching, because it is the one with the certificate.

The distinction that matters most in practice is between coaching and consulting, because they are opposites in where the accountability sits. A coach asking a team what they think about their release process, when the coach can already see the release process is the constraint and the team cannot, is wasting a fortnight on a Socratic performance. Say the thing, own it, and go back to coaching afterwards.

Facilitation is the stance most often needed and least often named. Half of the work at programme level is a room of people with a decision to make, no agreed process for making it, and someone senior who will fill the vacuum. A facilitator who is genuinely neutral on the content is unusually valuable there, and it is a different skill from having a view.

The tell of a mature practitioner is announcing the switch out loud. "I am going to stop asking questions and tell you what I have seen in three other teams, and then you decide" costs one sentence and removes the ambiguity about who now owns the answer, which is otherwise the source of most confusion about what a coach is for.

Why does "agile coach" mean four different jobs in four adverts?

Because the title was never defined by anything with authority, and three separate needs collapsed into it. One is a genuine coaching role — improving how teams and managers work, with no delivery accountability. The second is a scrum master for several teams, renamed to justify a higher band. The third is a delivery or programme manager whose organisation prefers not to use that word, and the fourth is a framework rollout specialist paid by a transformation programme. The four have different daily work, different measures and different politics, and taking one thinking it is another is the commonest career mistake in the field. Ask early which of the four this is, using their words: who is accountable for the dates, and who am I measured by.

What is a coaching stance, and what does holding one cost you?

It is the deliberate choice to leave the answer with the person who owns the problem, even when you can see the answer, because a solution the team reaches is one they will maintain and a solution you supply is one they will abandon when you leave. The cost is real and worth naming: it is slower, it is uncomfortable for everyone in the room, and it reads to an impatient stakeholder as the coach not contributing. That last cost is why coaches abandon the stance under pressure and become the team's most senior task-assigner. Holding it requires that somebody has agreed in advance that your value is not measured in decisions made this week, which is a conversation to have at the start rather than at the first escalation.

When should you drop the questions and simply tell them?

When the cost of the team discovering it themselves is paid by someone else. A team about to release something that will lose customer data, a rollout about to publish a measure that will be gamed within a quarter, a plan that assumes a dependency nobody has spoken to — in each case the learning is worth less than the damage, so you say the thing plainly and take the consequences of being wrong. The second case is expertise the team has no way to acquire in time: they cannot reason their way to how consumer-driven contract tests work, so teach it. The rule that keeps it honest is to name what you are doing and hand the decision back afterwards, because a coach who tells them for their own good, repeatedly, without saying so, has quietly become the person the team waits for.

Walk me through the GROW structure on a conversation that goes somewhere.

GROW is goal, reality, options, will, and the value is entirely in refusing to move on before each part is genuinely done.

G  GOAL - what do you want that you do not have
   SM   "I want the planning event to be less painful."
   You  "What would less painful mean by the end of the next one?"
   SM   "That my team leaves with a plan they believe."
        [vague -> specific. Do not proceed until this exists.]

R  REALITY - what is actually happening now, with evidence
   You  "What happened at the last one?"
   SM   "We committed to eleven features. We delivered five."
   You  "What did the other six turn into?"
   SM   "Four were blocked on the data team. Two we never started."
        [the goal has just changed shape. Reality does that.]

O  OPTIONS - generate before evaluating, and generate too many
   SM   "Push back on the number. Get data in the room. Bring a
         range instead of a commitment."
   You  "Three more. Bad ones are fine."
   SM   "Split the features smaller. Refuse anything with a
         dependency we have not spoken to. Ask the RTE to
         sequence data first."
        [the last option is the one that will work, and it only
         appeared because you asked past the obvious three.]

W  WILL - what will you do, by when, and what could stop you
   SM   "I will speak to the data team's lead before planning."
   You  "By when, and what would stop you?"
   SM   "Thursday. She might say no."
   You  "What do you do then?"
   SM   "Bring it to planning as a risk with her name on it."

The reality step is where most conversations are cut short, and it is where the useful information is. Moving from "the event is painful" to "we committed to eleven, delivered five, four were blocked externally" converts a complaint about a ceremony into a dependency problem with a specific team in it. Nothing in the options step would have been worth anything without that.

Asking for three more options after the obvious ones is the single most transferable technique here. The first three options are the ones the person has already considered and rejected in private; the fourth and fifth are new thinking, and the good one is nearly always among them. Ask for bad options explicitly, because the permission to be silly is what unblocks the list.

The will step fails when it ends at an intention. A commitment with no date is a wish, and a commitment with no obstacle named is one that dies quietly on Thursday afternoon. Asking what could stop you, then asking what you will do then, is what makes the difference between a pleasant conversation and a change.

What makes a question powerful, and why does "why did you do that" fail?

A powerful question is open, short, unloaded, and about the person's own experience rather than about your hypothesis. "Why did you do that" fails all of the last three: it demands a justification, which produces a defence rather than a reflection, and it usually contains an implied answer the person can hear. The equivalents that work are "what were you weighing at the time", "what would you do differently", "what did you expect to happen". A second failure mode is the question with the recommendation hidden in it — "have you thought about talking to the data team" — which is advice wearing a question mark, and everybody detects it. The discipline is that the shorter the question, the more room the answer has.

What does it mean to coach the system rather than the team?

It means treating a team's behaviour as an output of the structures around it, and going after those, because the behaviour is usually rational given the incentives. A team that will not commit has often been punished for a missed commitment; a team that hoards work has watched work taken away; a team that games a measure has watched the measure used against them. Coaching at team level in those conditions is asking people to absorb a cost the system is imposing. The practical version is that a coach's backlog contains items about funding cycles, approval gates, utilisation targets, incentives and reporting lines, not only items about ceremonies. If a coach cannot get access to the people who own those, the engagement will produce better meetings and nothing else, and that is worth knowing before signing.