Agile coaching fundamentals

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.

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.

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 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.

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.

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.

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.

The coordination cost of many teams contributing to one product, and specifically the cost of finding out late. It solves three things reasonably well: a shared moment when cross-team dependencies become visible and get owned, a common vocabulary so two hundred people can discuss the same thing, and a legible structure that lets executives fund iterative delivery without feeling they have lost sight of it. What it does not solve is coupling. No framework reduces the number of teams that must move together to ship a feature, because that is set by how the system and the organisation are cut. This is the sentence to have ready: a framework administers the dependencies, it does not remove them, so the honest goal is needing less of it each year.

A prescriptive framework for aligning many teams on one cadence. Teams are grouped into an agile release train — conventionally five to twelve teams, or roughly fifty to a hundred and twenty-five people — sharing an iteration length and a planning increment of about eight to twelve weeks. The increment opens with a large planning event where every team plans together in one room and dependencies are negotiated in the open, and closes with an inspect-and-adapt session that produces improvement items. A release train engineer facilitates the train, product management orders the flow of work above team level, and a system demo shows the integrated increment each iteration. Weighted shortest job first is the prescribed ordering method. The fair summary is that it supplies mechanism where large organisations previously had informal escalation.

LeSS is Scrum applied to several teams with as little addition as possible: one product backlog, one product owner, one definition of done, one shared sprint, and a single sprint review for the whole product. Coordination happens by teams talking to each other directly and through multi-team refinement, rather than through new roles, and most of the guidance is about what to remove — component teams, handoffs, coordinator positions, separate testing groups. That is what descaling means: the framework treats added structure as the problem rather than the solution. LeSS Huge extends it with requirement areas and area product owners for genuinely large products. It asks far more organisational change than SAFe and adds far less process, which is exactly why fewer enterprises choose it.

The choice is usually made on politics and then justified on merit, so being able to state the actual trade-off is a differentiator.

                 adds                 removes            needs from the org
---------------  -------------------  -----------------  --------------------
SAFe             roles above team     little             permission to
                 level, a quarterly                      reorganise, and
                 planning cadence,                       tolerance for a
                 portfolio layer                         quarterly batch

LeSS             almost nothing.      component teams,   genuine appetite to
                 One backlog, one     coordinator        delete roles and
                 PO, one sprint       roles, handoffs    change structure

Nexus            an integration       nothing            one product backlog
                 team and wrapper     prescribed         and up to about nine
                 events around                          teams already working
                 Scrum's own                             as Scrum

Scrum@Scale      a network of         nothing            executives willing to
                 scrums plus an       prescribed         sit in the structure
                 executive layer                         themselves
                 for the what and
                 the how

Team Topologies  no ceremonies at     nothing            authority to move
                 all. A language      directly           team boundaries and
                 for team types                          ownership, which is
                 and interaction                         the expensive one
                 modes

Not a framework, and usually the real answer: cut fewer dependencies into
existence. Two teams that can each release alone need no scaling at all.

Read the third column rather than the first, because it predicts what will happen. SAFe is chosen most often precisely because its demand on the organisation is lowest: it maps onto an existing hierarchy, so adopting it is survivable for everyone currently holding a job. LeSS demands the opposite and is therefore adopted by organisations that already wanted the change, which contaminates every comparison of their outcomes.

Team Topologies belongs on the list even though it is not a scaling framework, because it addresses the thing the frameworks route around. Its subject is which teams should exist and how they should interact, which is the decision that sets the coordination cost the frameworks then absorb. In an interview, naming it as complementary rather than competing is the stronger position.

The last block is the one worth saying out loud. A programme where each team can independently build, test and release a customer-visible change needs no framework, and the only reason the question arises is that most large systems and most org charts make that impossible. Framing the choice as a treatment for a structural condition, rather than as a methodology preference, is what separates a coach from a certificate.

A release train is a set of teams put on a common iteration length and a common planning horizon so that an integrated increment exists at known moments. Three things change immediately. Planning becomes an event rather than a per-team activity, which surfaces dependencies early and creates a batch — a plan agreed for a quarter that teams then defend against what they learn in week three. Integration becomes scheduled rather than continuous unless the engineering practice already supports otherwise, so a train over weak automation produces a shared release date and a shared crisis. And priority moves up a level, since ordering across teams cannot be done by any one product owner. The gain is alignment; the price is batch size and a layer of decision-making further from the work.

A vocabulary for the decision the frameworks assume has already been made: which teams exist and how they talk. It names four team types — stream-aligned teams owning a slice of value end to end, platform teams, enabling teams that help others get better and then leave, and complicated-subsystem teams — and three interaction modes: collaborating closely for a bounded period, consuming something as a service, and facilitating. The useful move is that an interaction mode is a design choice with a cost, so a permanent collaboration between two teams is a signal that the boundary is wrong rather than a sign of good culture. For a coach it converts "we have too many dependencies" into a specific question about boundaries and ownership, which is actionable in a way that a coordination ceremony is not.

When the teams are not actually building one product, when there are few enough of them to coordinate by talking, or when the coordination problem is a symptom of a boundary problem that the framework will preserve. Three or four teams on one product rarely need more than a shared cadence, one ordered backlog and continuous integration; installing a planning increment and a train engineer over that is overhead with a certificate. It is also wrong where the teams are independent — twelve teams on twelve unrelated products have an alignment problem with the business, not with each other, and a train forces them into a shared batch for no benefit. The hardest case to refuse is the organisation whose real problem is layer-cut teams, because the framework will make administering that pain considerably more efficient and remove the pressure to fix it.

It is a piece of work that cannot complete until someone outside the team acts. The precision matters because the word gets used for three different things with three different treatments. A knowledge dependency — we need to ask them something — is resolved by a conversation and should never appear on a register. A resource dependency — we need their environment, their reviewer, their data — is a queue, and is treated by increasing the service rate or removing the need. An order dependency — their thing must exist before ours works — is the only one that genuinely constrains sequencing. Registers that lump the three together produce a long list where most rows need a five-minute call, which is how a coordination forum fills with items that did not need it and misses the two that did.

Every option is somewhere on a ladder from cheapest and least effective to most expensive and permanent, and knowing the order is more useful than knowing any one technique.

flowchart TD
    A[Cross-team dependency<br/>identified] --> B[Track it<br/>register, owner, date]
    B --> C[Reserve capacity<br/>a fixed share of their sprint]
    C --> D[Contribute the change<br/>we write it, they review]
    D --> E[Replace with a contract<br/>versioned plus consumer tests]
    E --> F[Self-service<br/>configuration, not a request]
    F --> G[Move the capability<br/>boundary redrawn]

Read it as increasing permanence and increasing cost. The first two steps change how predictable the wait is and leave its length alone, which is what makes them satisfying to install and disappointing to live with. Everything from the third step down changes who is allowed to act, which is where the wait actually goes.

The third step is the highest-value move available to a coach in most organisations, because it is technically small and organisationally survivable. Letting the consuming team write the change and the owning team review it converts a planning-cycle queue into a code-review queue — weeks into days — without anybody's reporting line changing. It fails for one reason, which is worth predicting out loud: the owning team must accept contributions to code they are on call for, and that requires their standards to be written down rather than held in someone's head.

The last step is the only one that removes the class of dependency rather than an instance, and it is a months-long organisational change involving codebase ownership, on-call rotas and often reporting lines. Recommending it without acknowledging that cost is how coaches lose engineering audiences.

Because it changes time-to-know and not time-to-get. A register makes a wait visible, gives it an owner and a date, and produces the escalation path that stops a week-ten surprise — all genuinely valuable, and none of it shortens the queue in the other team's backlog. Two failures follow. The first is that a well-run register creates the impression the problem is handled, which removes the pressure that would have produced a structural fix, so the steady state is a programme whose constraint is permanently the calendar. The second is that maintaining it consumes exactly the people who could have removed the dependencies instead. The measure that keeps a register honest is the share of a team's items requiring another team, because that number falling is the only evidence the coordination is temporary.

The mode two teams use is a design decision, and each mode has a characteristic cost that shows up in a different measure.

mode                what it looks like            cost it creates
------------------  ----------------------------  -----------------------------
Collaboration       two teams working together    highest. Both teams' cycle
                    on a shared problem, high     times couple. Correct only
                    bandwidth, shared ownership   for a bounded period while
                    for a period                  something is discovered

X-as-a-service      one team consumes something   lowest ongoing. Paid up front
                    the other provides, with a    in building the service and
                    contract and no conversation  the docs. This is the target
                    per request                   state for most pairs

Facilitating        an enabling team helps        temporary by design. If it
                    another get better at         has lasted a year it has
                    something, then leaves        become a permanent dependency
                                                  wearing a coaching label

Diagnostic: a collaboration that has run for more than a quarter is not
collaboration. It is a missing service, or a boundary in the wrong place.

The line worth carrying into an interview is the last one. Long-running collaboration between two teams feels like healthy culture and reads well in a survey, and it means every change requires two teams' attention indefinitely. The fix is either to build the service so the interaction becomes a contract, or to merge the teams because the boundary is imaginary.

The as-a-service mode is where the cost is misjudged in the other direction. It is cheap per request and expensive once — documentation, versioning, a support path, error messages that let a consumer self-diagnose. Platform teams that skip the once end up with a service and a ticket queue, which is the worst of both, and the coach's job there is usually to argue for the unglamorous investment in the interface rather than for another coordination meeting.

Because the number of pairs grows quadratically while the number of teams grows linearly. Three teams have three pairs to keep aligned; six teams have fifteen; twelve teams have sixty-six. Any mechanism that relies on every team knowing what every other team is doing therefore stops working somewhere between four and eight teams, which is roughly where organisations start buying frameworks. The framework's actual contribution is to replace the mesh with a hub — one planning event, one ordered backlog, one integration point — trading full information for bounded cost. That trade is sound, and it is also why the frameworks feel bureaucratic: a hub is a batch, and a batch is a delay. The alternative is to reduce the number of pairs that need to be aligned at all, which is a boundary decision rather than a process one.

That a system's structure will come to mirror the communication structure of the organisation building it, so the org chart is a design decision about the architecture whether anyone intended it or not. The coaching consequence is that dependency problems are frequently downstream of a team split made for staffing reasons years ago, and no amount of facilitation will fix a front-end team, a services team and a data team all being required for every customer-visible change. The deliberate use of it — sometimes called the inverse manoeuvre — is to organise teams the way you want the system to end up, and let the architecture follow. Naming this in an interview shifts the conversation from coordinating dependencies to designing them out, which is the level the question is really asked at.

When the alternative is duplicating something that must be consistent, or spreading a genuinely specialist capability too thin. A single team owning payment integration, cryptographic key handling or a regulated calculation is a dependency every consumer pays for, and it is usually cheaper than four teams each learning it badly and diverging. The honest treatment is to accept it explicitly, then make it cheap: publish a contract, invest in self-service, staff the team to a service level rather than to a project, and measure the wait so it stays visible. What makes this different from resignation is the explicitness — an accepted dependency has a stated service level and someone accountable for it, while a tolerated one just generates escalations and a quarterly complaint in a retrospective.

Every team on the train plans the next increment in the same place at the same time, drafting their own plan and then walking the room to negotiate with the teams they depend on. The mechanism doing the work is not the plan; it is that a dependency is discovered and owned in the same hour by both sides, in front of the person who can resequence it. Three things make it succeed: the work is ordered and roughly understood before anyone arrives, the business context is delivered by someone with genuine authority rather than read from a deck, and teams are permitted to say the plan does not fit. Three things make it fail: an unrefined backlog, a target that is really a commitment, and no time for the second draft in which the negotiated dependencies are actually absorbed.

The shape is the same everywhere, and the failure is nearly always at the same joint.

flowchart TD
    A[Business context<br/>and the top objectives] --> B[Teams draft<br/>their own plans]
    B --> C[Draft plans<br/>read out to the room]
    C --> D{Dependencies<br/>and conflicts<br/>surfaced}
    D -->|resequence| E[Teams replan<br/>second draft]
    D -->|cannot fit| F[Scope named<br/>and dropped in the room]
    E --> G[Risks accepted<br/>owned or mitigated]
    F --> G
    G --> H[Confidence vote<br/>and improvement items]

The joint that breaks is between the fourth and fifth boxes. Surfacing conflicts is easy and enjoyable, and replanning is neither, so events run out of time exactly there and finish with the first draft plus a list of known conflicts described as risks. Everything downstream then becomes theatre: the vote is on a plan nobody has adjusted, and week three produces the conflicts on schedule.

The branch to the sixth box is the other thing to protect. If nothing is dropped in the room, the event has not planned anything — it has recorded an aspiration, and the deletion will happen later, invisibly, by teams quietly not starting things. A facilitator's most valuable contribution is forcing a named removal while the business owner is still present to agree it.

The confidence vote is worth defending against the two ways it gets ruined. It has to be anonymous or near enough, and a low vote has to change the plan at least once, or it becomes a compliance ritual within two increments and stops carrying any information at all.

Because it drifts from a coordination event into a status meeting, which happens whenever the attendees are chosen by seniority rather than by having a dependency. The recognisable form is each team reporting in turn to a facilitator, nobody listening to anyone else's report, and no decision made — at which point it is a weekly tax on eight people. What works better is a shorter, need-based version: it exists to resolve cross-team blockers, only teams with a live blocker speak, the attendee is whoever holds the work rather than whoever holds the title, and every item leaves with a name and a date. If nothing is blocked, it is cancelled that week, and a facilitator willing to cancel it is the strongest signal that the event is genuinely about the work.

Not by putting eighty people in one room to generate observations, which produces a wall of notes and no decision. The pattern that works is two-stage: each team runs its own retrospective first and brings forward only the items it cannot fix itself, then representatives meet on the items that are genuinely cross-team or structural. That second session should produce one or two improvements with an owner outside any single team, because the whole reason an item arrived there is that no team could act on it alone. The failure to avoid is the programme retrospective that collects impediments and routes them back to the teams that raised them, which teaches everyone that escalating is pointless. If the programme cannot change anything, say so and stop holding the event.

The structure has to force items upward and force a decision, or eighty people spend two hours confirming what they already knew.

PROGRAMME RETROSPECTIVE - 90 minutes, one representative per team plus
the people who can change something. Held after every team has run its own.

  0  Last time's items                 15   Read out the improvements from
                                            the previous session, by owner.
                                            Done / not done / abandoned.
                                            If most are not done, the rest
                                            of this meeting is theatre and
                                            that is the item to discuss.

  1  The numbers, prepared in advance  15   Programme lead time distribution,
                                            share of items needing another
                                            team, flow distribution, the
                                            three longest-aged items. Not
                                            per-team comparisons.

  2  What each team could not fix      20   Two minutes per team, strictly.
     itself                                 Only escalated items. Anything a
                                            team can fix alone is out of
                                            scope and goes back.

  3  Group and choose one theme        15   Dot vote. One theme, not seven.
                                            The theme will usually be a
                                            dependency, a shared environment
                                            or an approval gate.

  4  Decide, with an owner who is      20   One or two actions. The owner is
     not a team                             a manager, an architect or the
                                            programme itself, because a team
                                            already tried.

  5  Close                              5   What would make the next one
                                            worth attending.

Rule that makes it survive: an action with a team as its owner is out of
order here. It has already been through a team retrospective.

Step zero decides whether the event has any value, exactly as it does at team level, and at programme level the stakes are higher because the owners are senior and the non-delivery is therefore less comfortable to name. Reading the previous items out with names attached is the only mechanism that makes the next set real, and a coach who softens it has removed the event's teeth.

The rule at the bottom is the one that distinguishes this from a large team retrospective. Items whose owner is a team have a home already; the reason a programme retrospective exists is for the items with no home — a shared test environment, a change-approval gate, a funding cycle, a platform team's staffing. Allowing team-ownable items in fills the ninety minutes and the structural items never get discussed.

Bringing the numbers prepared, and deliberately not as a per-team league table, is what stops the session becoming a negotiation about whose fault the quarter was. A programme lead-time distribution with a long tail is a shared object to look at; four teams' cycle times ranked is an argument.

It exists to make the integrated increment real — the whole product, from every team, working together, in front of people who did not build it. That is the only event that can falsify the plan, because teams can be individually complete and collectively broken, and nothing else surfaces that until much later. It is cancelled first for exactly that reason: it is the event most likely to produce bad news, it requires integration work to be genuinely finished, and it has no immediate delivery output. A coach's response is to treat cancellation as the finding rather than the inconvenience. If the integrated increment cannot be shown this iteration, the honest statement to the programme is that nobody currently knows whether the increment exists.

By splitting what genuinely needs everyone from what does not, rather than by moving a two-day event onto a video call in one region's working hours. Context setting and the read-out of draft plans are broadcast-shaped and can be recorded and watched; the dependency negotiation is high-bandwidth and needs the overlap window protected for exactly that. In practice that means teams draft asynchronously against written objectives beforehand, the shared hours are spent only on cross-team conflicts, and every decision is written where someone waking six hours later can find it and object. The failure to name is the compressed version: the same two days, on video, at one region's convenience, which produces plans made by whoever was awake and resentment from everyone else.

Only those a team cannot move without changing what a customer receives, and the test is worth applying before publishing anything. Lead time measured from the customer's request survives, because shortening it requires the queue in front of the team to shrink. Change failure rate and time to restore survive reasonably well, provided incident classification is not owned by the people being measured. Cycle time from team pickup does not survive: moving the clock start halves it overnight. Velocity does not survive at all, since the unit is the team's own calibration. Story counts fall to smaller slices. The general form is Goodhart's law, and the practical corollary is to pair any speed measure with a quality measure so that speed cannot be borrowed from correctness without showing up.

Because percentiles do not average, and the arithmetic is worth being able to do out loud.

Four teams, each reporting an 85th-percentile cycle time of 8 days.
Naive programme number: 8 days. It is wrong, and not by a little.

WHY. The programme's distribution is the union of the four, so its tail
is assembled from every team's tail.

  pooled items, 200 total, 50 per team
  each team:  42 items under 8 days,  8 items above, up to 30 days

  items above 8 days in the pool   =  32 of 200   = 16%
  so the pooled 85th percentile sits above 8 days, near 11

AND THE LARGER ERROR: the programme's item is not the team's item.
A customer request that crosses three teams has a lead time of

  team A cycle 6 + wait for B 9 + team B cycle 5
        + wait for C 11 + team C cycle 4        =  35 days

  every team reports 4-6 days. Nobody is lying. The 20 days of
  waiting between them belongs to no team's measure at all.

WHAT TO DO
  - recompute percentiles from the pooled item set, never average them
  - measure the customer-visible item end to end, and let the team
    numbers be for the teams
  - report the handoff waits separately. They are the programme's
    actual product and its actual problem

The second block is the finding that changes a programme's behaviour, and it is the reason team-level dashboards can be uniformly healthy while the organisation is slow. Twenty of thirty-five days exist in the gaps between teams, which no team's measure covers and no team is accountable for, so improvement effort goes to the fifteen days that are already the fast part.

The instruction to report the waits separately is the practical output. Once the handoff intervals are a named line on the programme's own report, the conversation moves from "which team is slow" to "why is there a nine-day wait between A and B", and that question has a structural answer.

The percentile point matters for a smaller reason too: it is the commonest way a programme accidentally over-promises. A service level assembled from averaged team percentiles will be missed considerably more often than the stated share, and the credibility lost the first time is not easily recovered.

It is the share of delivered items in a period that were new features, defects, technical debt or risk and compliance work. It is the strongest programme measure because it is the only one that answers what a sponsor actually wants to know — what did we spend the quarter on — and because no speed measure can reveal it. A programme with flat throughput whose defect and unplanned-risk share has gone from a fifth of items to half has got materially worse while every dashboard held steady. It also converts an argument about technical debt from virtue into arithmetic: showing that debt work has been under five per cent of items for four quarters and defects have doubled is a case, where "we need to refactor" is a preference. The cost is that somebody must classify every item consistently.

The interesting part of a dashboard is nearly always what is missing from it rather than what is red.

TRANSFORMATION REVIEW, month 6. As presented:

  teams trained                      14 of 14      green
  planning events run                 2 of 2       green
  boards migrated                    14 of 14      green
  certified practitioners                  31      green
  average team velocity          up 22%            green
  average team cycle time     8.1 -> 5.4 days      green

WHAT IS WRONG WITH EVERY LINE

  rows 1-4    adoption. They cannot go down, so they carry no
              information. Report them as cost, not progress.

  velocity    the unit is each team's own calibration, so a 22% rise
              is indistinguishable from re-anchoring the scale. It is
              also averaged across incompatible units.

  cycle time  clock starts at team pickup. Six months ago the intake
              queue was outside the measurement and it still is.

WHAT IS ABSENT, AND EACH IS THE ANSWER TO THE ACTUAL QUESTION

  lead time from request to production, as a distribution
  change failure rate and time to restore
  flow distribution - feature / defect / debt / risk
  share of items requiring another team
  handoff wait between teams, which is where the time went
  any baseline at all from before month 0

THE HONEST SLIDE
  "Cycle time inside teams improved. We do not yet know whether the
   time from a customer asking to a customer having it changed,
   because we did not measure it before and we do not measure it now.
   Here is the instrumentation I need and the date I can answer by."

Every line being green is itself the diagnosis. A measurement design where nothing can come back negative is not reporting on the programme, it is defending it, and a sponsor who has been handed six months of green cannot make any decision at all — including the decision to stop.

The cycle-time row is the subtle one and the one interviewers probe. An improvement from 8.1 to 5.4 days inside the teams is real work and may be worth having, and it is compatible with the end-to-end interval being unchanged or worse, because the queue in front of the board and the waits between teams were never in the measurement. Saying that plainly, while still crediting the improvement, is what makes the rest of the report believable.

The honest slide at the bottom is the deliverable, and its last sentence is the part that saves the engagement. A review that reports uncertainty with a date and a specific instrumentation ask reads as competence; one that reports uncertainty alone reads as failure, and one that reports certainty it does not have gets found out in month twelve.

An adoption measure counts whether the change happened to people; an outcome measure counts whether anything got better for a customer or the business. Teams trained, ceremonies held, tools rolled out and certifications awarded are the first kind, and their defining property is that the programme controls both the activity and the counting, so they rise monotonically and carry no information. Lead time, change failure rate, flow distribution and whether delivered work moved a stated product metric are the second kind, and they can get worse — which is what makes them worth reporting. The practical rule is that a measure which cannot fall is a receipt, not a result. Report adoption as expenditure, in hours and money, and keep the word progress for the outcomes.

From evidence that already exists, and with explicit limits on how far back it is trustworthy. Deployment history is usually recoverable from the pipeline, so deployment frequency and often change failure rate can be reconstructed for a year or more. Ticket timestamps give a rough lead time if you can identify a consistent creation event, though the definition will be weaker than a designed measure. Incident records give time to restore. Release notes give a crude flow distribution if someone is willing to classify them. Say what each number's weaknesses are before someone finds them, and pick a fixed window rather than the most flattering one. A reconstructed baseline with stated caveats is far stronger than the alternative, which is asserting improvement nobody can check.

A distribution of dates with the chance attached to each, forecast from measured throughput rather than from summed estimates, and wide enough to include the quarters where things went wrong.

Programme: customer onboarding replacement. Forecast at month 6.

Measured: customer-visible items completed per two-week period, last
12 periods, counted at the boundary a customer touches - not the sum
of team item counts.

    6, 4, 9, 3, 7, 5, 8, 2, 6, 5, 9, 4      mean 5.7   worst 2

Remaining: 61 items known. Scope has grown about 12 items per 100
completed on this programme, so forecast against 61 x 1.12 = 68.

    periods  date       chance done by   use
    -------  ---------  --------------  ---------------------------
       9     14 Nov          8%         nothing. This is the date
                                        someone has already promised
      11     12 Dec         41%         worse than a coin flip
      13      9 Jan         79%         internal sequencing
      15      6 Feb         95%         what I would commit externally

    "6 February is a 95% date. 12 December is a 41% date, which is
     another way of saying it will probably be late."

WHY WIDER THAN A TEAM FORECAST
  - the 2 and 3 periods are dependency stalls, not slow work. At
    programme level those are the norm, not the outlier
  - 68 items assumes today's understanding of scope. It is six months
    into a two-year programme
  - one external regulator sign-off sits outside the model entirely.
    Name it as an unmodelled risk rather than pricing it at zero

The essential discipline is counting at the customer boundary. Summing each team's completed items counts the coordination work as output and produces a forecast that is roughly twice as fast as reality, which is the single commonest reason programme forecasts are wrong in one direction only.

Naming the unmodelled item is what keeps this from being false precision. A statistical forecast implicitly assumes the future resembles the sample, and a regulatory approval with no history in the sample is not in the model at any confidence level. Saying so converts the forecast from a prediction into a decision aid, and hands the risk to the person who owns it.

Four sources, three of which are information. The first is a real mismatch: the framework's batch does not fit this team's work, which is the standard objection from support, platform and incident-driven teams and is usually correct. The second is a measurement defect — estimates aggregated upward and used to compare teams — which is the most legitimate objection of all and the one programmes are most defensive about. The third is a rollout that has absorbed two rounds of feedback and changed nothing, so the team has correctly concluded that participating is pointless. The fourth is genuine change aversion, which exists and is the one the sponsor assumes the whole conversation is about. Reaching for the fourth before eliminating the first three is visible to the team within a minute.

The value is in having a route through the question rather than a view about the team.

flowchart TD
    A[Team objects to<br/>the rollout] --> B{Can they say what<br/>would make it<br/>worth their time}
    B -->|yes, concretely| C{Is the ask<br/>within the<br/>programme's gift}
    B -->|only restates<br/>the objection| D[Ask what is going<br/>wrong today that<br/>this should fix]
    C -->|yes| E[Change the rollout<br/>and publish it<br/>to every team]
    C -->|no| F[Say so plainly<br/>and name the<br/>consequence to others]
    D --> G[If nothing, they may<br/>be right to be exempt.<br/>If unexamined, look together]

The first branch is the test that does most of the work. A team with a legitimate objection answers concretely — drop the second planning day, let us bring a forecast rather than a commitment, stop aggregating our numbers — while a team that is simply resisting tends to restate the objection in different words. That difference is diagnostic without being accusatory, which matters because the accusatory version ends the conversation permanently.

The branch to the fifth box is the one coaches skip. A concession granted quietly to the team that pushed hardest teaches every other team that private objection is the route to change, so an amendment must be published to everyone or it corrodes the rollout it was meant to save.

The branch to the sixth box is what makes the coach credible rather than compliant. When something genuinely cannot change, the reason given has to be a consequence to identifiable people — four teams will plan against assumptions about you that nobody checked — because "the framework prescribes it" is an argument that loses an engineering audience for good.

That organisations are implicitly optimised to avoid changing the status quo of middle managers, first-line managers and specialist positions and their power structures. What follows is a prediction rather than a complaint: any change that would remove a role or redistribute authority will be reinterpreted as something that does not, usually by adopting the vocabulary and keeping the structure. That is the mechanism behind teams becoming squads with the same approval chains, and behind scaling frameworks being chosen partly because they map onto an existing hierarchy. The practical use for a coach is to check any proposal against it in advance: if the plan requires a group of people to argue themselves out of authority, it will not happen on enthusiasm, and the sponsor either changes the structure explicitly or the change is cosmetic.

Because a mandated practice produces compliance, and compliance is indistinguishable from adoption on every adoption measure while producing none of the benefit. A team that chose the change will debug it when it does not work; a team that was told will attend and give it nothing, and the programme will not find out for a year because attendance is what gets counted. Invitation also gives you evidence: which teams volunteer, and what they say about the offer, tells you more about the organisation than any assessment. Where it does not work is anything requiring simultaneity — a shared cadence, a common definition of done across teams contributing one increment, a single ordered backlog. Those are not preferences a team can opt out of without imposing the cost on others, and pretending otherwise is its own dishonesty.

The content changes and the amount does not, which is the part nobody tells them. Assigning work, tracking it and reporting variance leave; what arrives is designing the system the teams work in — where boundaries sit, how funding reaches teams, which approvals still exist, whether the measures are honest — plus growing people and removing the impediments the teams cannot reach. That is a harder job than the one it replaced and it is much less legible, since a manager who is doing it well appears to be doing nothing on a day when nothing is escalating. Coaching engagements that ignore this produce the predictable failure: managers with no defined role in the new arrangement reassert the old one, usually through the measures, and the teams correctly conclude nothing changed.

Performance usually falls before it improves, because the team is simultaneously learning new practice, absorbing new dependencies and losing the informal arrangements that made the old way work. Change models describe this shape in different vocabularies and the practical point is the same: the dip is expected, not evidence of failure, and it has a floor and a duration that are worth predicting out loud. Talking about it in advance is the whole technique. A sponsor told at month zero that months two and three will look worse, with the reason and the measures that will show it, treats a dip in month three as confirmation; the same sponsor surprised in month three concludes the change is failing and reverses it precisely when the cost has been paid and the benefit has not yet arrived.

The one that decides how work is funded and admitted, because it sets everything downstream. Annual project funding with fixed scope makes iterative delivery impossible in principle — the money arrives attached to a scope agreed before anything was learned, so a team that adapts is off-plan by construction. Close behind it comes the intake path: if requests enter through a committee that meets monthly, the team's lead time has a floor no practice change can lower. Third is any utilisation target, since a system loaded to full capacity has no slack and therefore has long, unpredictable waits by arithmetic rather than by attitude. A coach with access to exactly one policy lever should spend it on funding, and a coach with access to none should say so to the sponsor before the engagement starts.

By becoming a permanent process administrator. The path is predictable: the coach starts by facilitating, the team finds it convenient, the coach ends up running every ceremony, maintaining the board, chasing the dependency register and writing the report — at which point they are the team's coordinator, they are load-bearing, and nothing they do transfers. The signal to watch for is that the team's practice degrades whenever the coach is on leave, which means the capability lives in the coach rather than in the team. The corrective is mechanical rather than attitudinal: rotate facilitation from the second month, refuse to be the person who knows the state of the board, and keep a written list of what the team can now do without you.

Because the ceremonies are where a team learns to run itself, and doing them on the team's behalf removes the learning while leaving the appearance of health. A coach facilitating every retrospective for a year owns the team's improvement rather than the team owning it, and the visible symptom is that no one else can run one. It also distorts the content: a facilitator who is also the person with a view on the answer cannot be neutral, so the retrospective quietly becomes the coach's agenda with the team consulted. The healthier arrangement is to run the first two, hand over the third with support, and then attend as a participant or not at all — while accepting that the team's version will be worse for a while, which is the price of it being theirs.

Treating a framework's prescription as the argument rather than as one implementation of an underlying mechanism. It shows in a few recognisable phrases — the Guide says, that is not real Scrum, you cannot do that in SAFe — and in an inability to say what a practice is for without naming its source. The damage is specific: an engineering audience discounts everything that follows, and the coach loses the ability to adapt a practice to a context it does not fit, which is most contexts. The alternative is to hold the mechanism and be flexible about the ceremony, so a daily coordination need can be met by a written update in a distributed team without any argument about whether it counts. If you cannot explain why a practice exists in terms of the failure it prevents, you are quoting rather than coaching.

Because maturity is not a property a team has independently of what it has been asked to do and what it has been given. A team that cannot forecast usually has no measured history because nobody instrumented anything; a team that will not commit has usually been punished for a missed commitment; a team that games a measure has watched the measure used against them. In each case the diagnosis names the team and the cause sits in the system, so the sentence functions as an explanation for why the coaching has not worked yet. The useful reframe is to ask what would have to be true for the team to be capable of this, and then to notice how many of the answers are things only a manager or the programme can change.

Interviewers ask about failure modes because everyone can describe the practices, and the tell is more diagnostic than the label.

anti-pattern              the tell                        what it costs
------------------------  ------------------------------  -------------------
Coach as coordinator      the team's practice degrades    nothing transfers.
                          the week the coach is on leave  You are load-bearing

Ceremony compliance       adoption dashboard is green,    a year, and the
as adoption               delivery numbers unchanged      credibility to try
                                                          again

Framework as argument     cannot explain a practice       an engineering
                          without citing its source       audience, permanently

Coaching the team,        the coach's backlog is all      better meetings and
never the system          ceremonies and no policies      no faster delivery

Measures pushed upward    velocity or points appear in    honest information.
                          an executive pack               It does not come back

The friendly coach        high team satisfaction, no      the reason the role
                          uncomfortable conversation      was funded
                          in six months

No exit criteria          engagement extended twice       the coach becomes
                          with no stated end state        staff, and the
                                                          question of whether
                                                          it worked stops
                                                          being asked

The last two are the ones candidates never volunteer, and they are the ones that end engagements badly. A coach whom every team likes and who has had no difficult conversation in six months has optimised for the wrong signal: the role exists to change something, and changing something is uncomfortable for somebody, so universal comfort is evidence of avoidance rather than skill.

The measures row deserves its own emphasis because the damage is irreversible. The first time a team's own numbers appear in an executive pack as a comparison, the team learns that instrumenting itself is dangerous, and the honest data stops arriving. No apology recovers it, which is why a coach's most important refusal is usually about a report rather than a practice.

It is a written statement of what the team or organisation will be able to do without you, and roughly when. It matters from the first week for two reasons. It converts the engagement from a presence into a change with an end state, which is the only framing under which anyone can judge whether it worked. And it protects against the drift into permanence, because a coach who has been extended twice with no stated end has become staff, and the question of whether the coaching achieved anything quietly stops being asked. Concretely it is a short list — the team facilitates its own events, forecasts from its own throughput, resolves cross-team dependencies without you in the room — with the current state next to each, reviewed with the sponsor.

Because the work involves telling people things they would rather not hear, and a coach optimising for warmth avoids exactly those conversations. The team that likes you most is often the one whose comfortable habits you have left alone: the retrospective with no actions, the estimate nobody believes, the dependency everyone has stopped mentioning. It cuts the other way too, and the honest version of this answer says so — a coach disliked by every team is not being brave, they are failing at the relationship the work depends on, since nobody accepts a difficult observation from someone they do not trust. The measure worth using is different: can the team now do something it could not do before, and can they name it without prompting.

Whether you can diagnose, and whether you know what you cannot change. Framework recall gets you through the screen and settles nothing, because everyone has the certificate and the material is public. What the later rounds test is a specific sequence: given a messy situation, do you gather evidence before prescribing, do you look at structure and incentives rather than only at ceremonies, do you distinguish what you would do from what you would recommend, and can you say what you would refuse. The senior signal is a stated limit — this needs a decision from someone with authority over funding, and if I cannot get it, here is what I can honestly deliver instead. Candidates who answer every scenario with a facilitation technique interview as scrum masters with more years.

Answer the mechanism, then the cost, then the condition under which you would not use it. Asked what a planning increment is, describe the alignment it buys and the batch it creates, and say for which teams the batch is wrong. That shape does three things at once: it demonstrates the recall the question asked for, it shows you have used the thing rather than studied it, and it opens the follow-up you want. The move to avoid is the definitional recital, because it is indistinguishable between someone who has run twelve planning events and someone who read the site last night. If you genuinely do not know a detail of a framework you have not used, say which one you have used instead and answer from that.

It depends entirely on whether the criticism has a mechanism in it. "SAFe is not really agile" is heard as tribal, tells them nothing, and is dangerous if the organisation is running it — which, given who is hiring, is likely. "The planning increment is a ten-week batch, so teams end up defending the plan against what they learn in week three, and the compensating practice is a genuine willingness to change the plan mid-increment" is heard as experience, and it works whether they love the framework or resent it. The same discipline applies to praise: an unqualified endorsement reads as certification-shaped. Hold both sides with a mechanism attached to each, and be willing to say which organisation you would recommend it to and which you would refuse.

Scenario answers are graded on sequence more than content, and the sequence is learnable.

"Six teams on one product, everything is late, the sponsor wants SAFe."

1  WHAT I WOULD FIND OUT FIRST                        30 seconds
   "Before recommending anything I would take five recently delivered
    items and trace each from request to production, marking every
    interval where it was waiting. I want to know what share of the
    elapsed time is queue rather than work, and where the queues are."

2  WHAT I EXPECT TO FIND, AND WHY                     30 seconds
   "In most six-team programmes the majority is queue, and the largest
    single interval is one team's work waiting in another team's
    priority order. If that is what it is, cadence alignment moves a
    small part of it and nothing else in the framework touches it."

3  THE STRUCTURAL MOVE, WITH ITS COST                 45 seconds
   "The leverage is in how the six teams are cut. If they are cut by
    layer, every feature needs four of them. Re-cutting towards teams
    that can release a customer change alone removes the class of
    dependency, and it is a months-long change involving codebase
    ownership and on-call, so I would name it as the direction and
    not as this quarter's plan."

4  WHAT I WOULD DO THIS QUARTER                       45 seconds
   "Contribution rights so a consuming team can write the change and
    the owner reviews. One ordered backlog with one accountable
    prioritiser. A shared cadence at the shortest length, and one
    integration point. Those are weeks, not months."

5  ON THE FRAMEWORK, TWO-SIDED                        30 seconds
   "Its planning event is the strongest single thing in it, and the
    quarterly batch is the real cost. I would use the event and
    argue about the batch."

6  WHAT WOULD MAKE ME REFUSE                          15 seconds
   "If I could not get access to whoever owns team boundaries and
    funding, I would say up front that I can deliver better
    coordination of the existing problem and not a faster
    programme, so nobody buys the wrong thing."

The first step is the one that separates candidates, and it is thirty seconds long. Almost everyone starts at step three or four with a recommendation, which reads as pattern-matching regardless of how good the recommendation is; opening with what you would measure and why reads as someone who has been wrong before.

Step six is the senior move and it is rarely made. Stating the condition under which you would decline, or would deliver something smaller than what was asked for, demonstrates that you understand which problems are outside a coach's authority — which is exactly the judgement the role needs and the thing an over-promising candidate reveals they lack.

Keep the whole thing under four minutes and stop. A scenario answer that runs to ten minutes has stopped being an answer and become a monologue, and the interviewer has follow-ups they would rather ask.

Plainly, with the mechanism, and with your own contribution to it in the account. Every experienced coach has one, and the interviewer is testing whether you can analyse a failure rather than distribute blame — an answer where the sponsor, the managers and the teams were all at fault and you were correct throughout is the answer that fails. The shape that works is what was expected, what actually happened, the specific structural reason, what you tried, what you would do differently, and what you now check for before starting. The strongest version includes something you could not have known then and now ask about in the first week, because that converts the failure into a stated diagnostic rather than a lesson learned in the abstract.

Questions whose answers would change whether you take the job. Who is accountable for delivery dates, and am I one of them. What am I measured on, and does anything on that list rise automatically. Who owns team boundaries, funding and the approval gates, and will I have access to them. What was measured before this started. Which team is unhappiest about it, and what do they say. What would make you conclude this was not working. Those six get you the shape of the engagement, and the last two are the most informative, because an organisation with no answer to either has not designed a way to learn anything from the programme it is running.

By measuring how much of the elapsed time from request to production is spent waiting outside a team, and how much of each team's work requires another team to act. A strong answer names both numbers before naming any framework, and says what each one implies: if most of the delay sits inside teams, a coordination framework is the wrong purchase and the work is team practice and engineering capability; if most of it sits in the waits between teams and a large share of items need someone else, the framework will make administering that visible and efficient without shortening it, and the leverage is in boundaries, contracts and contribution rights. The strong answer then adds the honest middle: while boundaries take quarters to change, the framework is a reasonable transitional mechanism, and the test of whether it is working as a transition is that the share of work needing another team falls year on year. A weak answer substitutes a preference — usually a comparison of SAFe against LeSS decided on which is more agile — and never mentions a measurement, which tells the interviewer that the candidate would arrive with the conclusion already chosen.