Coaching SAFe TTA: Scaling Agile Across the Enterprise
Coaching and Scaling Team and Technical Agility means the coaching unit shifts from one team to cross-team dependencies across an Agile Release Train.
Add a coach to every team on an Agile Release Train and coordination still breaks down; because coaching and scaling Team and Technical Agility is not a bigger version of coaching one team. The unit that needs coaching changes: from a team’s behaviour to the quality of interactions, dependencies and technical flow across a whole network of teams.
What Coaching and Scaling Team and Technical Agility Means in SAFe
Coaching and scaling Team and Technical Agility means shifting the coaching unit from one team’s behaviour to the quality of interactions, dependencies and technical flow across every team on an Agile Release Train, using SAFe’s Team and Technical Agility competency as the frame for what changes. A team coach watches how one group plans, builds and reviews its own work. A TTA coach at scale watches how a dozen of those groups hand work to each other, share a codebase, and hold a shared delivery date; and the questions that matter shift accordingly.
The Team and Technical Agility Competency and Its Three Dimensions
SAFe treats Team and Technical Agility as one of the core competencies organizations need for Business Agility, built from three dimensions: high-performing Agile Teams, teams of Agile teams working together, and Built-in Quality running through everything a train ships Built-in Quality (Scaled Agile Framework). Each dimension asks a different coaching question. Agile Teams asks whether a single team plans, builds and reviews its own work well. Teams of Agile teams asks whether those teams synchronize, integrate and remove dependencies between each other without a program office arbitrating every handoff. Built-in Quality asks whether the code, tests and architecture a train produces stay releasable at the end of every iteration, not just at the end of a hardening phase.
A coach who only ever watches the first dimension is doing team coaching with a wider address book. Scaling the practice means adding the second and third dimensions as explicit, separately observed targets, dependency flow between teams, and the engineering discipline that keeps an increment shippable, rather than assuming that healthy individual teams automatically add up to a healthy train.
Which Roles Hold Coaching Responsibility on a Train
Coaching responsibility on a train splits across the SAFe Scrum Master or Team Coach at team level and the Release Train Engineer at train level, with SAFe Practice Consultants brought in to drive the transformation itself. The Scrum Master/Team Coach owns the first dimension directly: team facilitation, impediment removal inside the team, and the habits that make a single team self-managing. The Release Train Engineer owns the second dimension at train scale, running Program Increment Planning and the ART Sync events where cross-team dependencies surface. Neither role is optional at scale: a train with strong team-level Scrum Masters and no RTE coaching function will still stall at every cross-team handoff, because nobody owns the second dimension.
SAFe Practice Consultants and Advanced SAFe Practice Consultants sit above both, brought in specifically for the transformation period rather than the steady-state operation of an established train Lean and Agile (Scaled Agile Framework). Where the SM/TC and RTE run their trains day to day, the SPC’s job is to get the train and its surrounding portfolio structures into a state where those roles can function; which is why the two roles are described later as change agents rather than as coaches embedded permanently in the train.
Where the Agile Release Train Fits
The Agile Release Train is the long-lived team of Agile teams aligned to a shared mission and value stream, and it is the object scaled coaching actually targets once coaching moves past a single team. An ART is not a temporary program structure assembled for one release; it persists, carrying the same teams, the same backlog and the same cadence across Program Increments, which is what makes cross-team coaching worth doing systematically rather than as one-off firefighting.
That persistence matters for coaching design. A coach working with a project team that disbands after delivery has no reason to invest in the second and third TTA dimensions; there’s no future cross-team relationship to protect. An ART’s permanence is the reason coaching effort spent on dependency flow and shared engineering discipline compounds: the same teams will hand off to each other again next Program Increment, so fixing the handoff pattern once pays off repeatedly. Lyssa Adkins’s Coaching Agile Teams remains the field’s starting reference for the coaching craft itself; applying that craft to a train the size of an ART, rather than to a single team, is where the analysis below picks up.
Lyssa Adkins’s Coaching Stances Applied Across an Agile Release Train
Lyssa Adkins’s coaching stances, teaching, mentoring, professional coaching and facilitation, transfer to an Agile Release Train only when the coach learns to alternate between letting a team find its own answer and intervening directly when cross-team structures, incentives or technical constraints make local improvement impossible. At team level, a coach can usually stay non-directive: ask questions, reflect behaviour back, and trust a self-managing team to arrive at its own fix. At train level, that trust runs into obstacles no single team can remove on its own.
The Four Coaching Stances, in Brief
Adkins names four stances a coach moves between: teaching a skill or practice the team lacks, mentoring from direct experience, professional coaching that draws answers out of the person or team rather than supplying them, and facilitation that keeps a group’s process moving without taking a position on the content. Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, published in Mike Cohn’s Addison-Wesley Signature Series, aims all four stances at self-managing, high-performing teams as the target state.
Each stance assumes the coach can act on the person or team directly in front of them. That assumption holds at team level. It stops holding the moment the obstacle a team faces sits outside the team’s own authority: a shared component owned by another group, a release train that both teams sit on but neither controls, or an incentive structure set by management several levels above either team.
Applying the Coach Stance to the ART System
Applying a coaching stance to the ART system means treating the train itself, its structures, incentive design and technical constraints, as a coaching subject alongside the individual teams inside it. A team that keeps blocking on another team’s API changes does not have a facilitation problem; it has a dependency the two teams cannot resolve by talking harder in their own retrospective, because the fix requires a decision, an interface contract, a shared component boundary, a change to who reviews what, that sits above either team’s authority.
Coaching the system means the coach spends time in ART Sync and Program Increment Planning watching for these cross-team patterns, then raises them as system-level issues rather than routing them back into a single team’s retrospective where they cannot actually be solved. The stance itself does not change, the coach still teaches, mentors, professionally coaches or facilitates, but the target of that stance widens from a team’s internal behaviour to the structural conditions the ART’s teams share.
When to Hold Back and When to Intervene
A coach should hold back and let a team find its own answer whenever the fix is within that team’s authority, and intervene directly whenever the obstacle sits in cross-team structure, incentives or a technical constraint no single team can change alone. The judgment call repeats constantly at scale, because most impediments look identical from inside a retrospective, a blocked story, a missed commitment, a recurring argument, until the coach traces the cause back to its actual owner.
| Signal in the room | Likely cause | Coach response |
|---|---|---|
| One team’s retrospective keeps naming the same blocker | Local process or skill gap | Hold back, teach, mentor or facilitate inside the team |
| Two or more teams name the same blocker independently | Shared dependency or interface | Intervene, raise at ART Sync or PI Planning |
| The blocker traces to a funding or incentive decision | Structural, outside any team’s authority | Intervene, escalate to the RTE or portfolio level |
| A technical constraint recurs across teams (shared library, environment, pipeline) | Built-in Quality gap at train level | Intervene, treat as an engineering-practice issue, not a facilitation one |
The table’s second and third rows are where non-directive coaching stops working: a team can process a shared-interface blocker in every retrospective it runs and never resolve it, because the resolution requires authority the team doesn’t have. Recognising that pattern early, usually by noticing the same blocker named independently by more than one team, is what separates a coach who scales from one who burns out repeating the same advice to teams that structurally cannot act on it.
Foundational Model or Current Practice: The Relevance Debate
Coaching Agile Teams remains the foundational reference for the coaching stances themselves, and its current relevance in 2026 comes from how those stances meet scaled agility, flow practice and engineering discipline: not from a newer edition replacing the model. A systematic literature review of the agile coach role found the role itself is defined inconsistently across studies and organizations, which is part of why the underlying stances stay useful even as the surrounding practice evolves (A Systematic Literature Review on Agile Coaching and the Role of the Agile Coach).
Research on mindset formation reinforces the same point from a different angle: an interview study of how agile coaches create an agile mindset in development teams found that mindset change follows from how a coach applies the stances in context, not from the existence of the stances alone (How agile coaches create an agile mindset in development teams). The debate worth having, then, is whether a given coach has learned to apply teaching, mentoring, professional coaching and facilitation to a train-sized system instead of only to the team in the room.
The SAFe Scrum Master as a Boundary-Spanning Team Coach
The SAFe Scrum Master/Team Coach carries team facilitation into Program Increment Planning, ART Sync and cross-team impediment removal, functioning as a boundary spanner rather than a ceremony host once a team sits inside an Agile Release Train. The role’s SAFe definition already builds in this dual reach: it is a servant leader and coach for an Agile Team, but the team it serves does not operate in isolation, so the role’s effective scope extends to wherever that team’s work touches another team’s.
From Ceremony Host to Boundary-Spanning Coach
A SAFe Scrum Master stops being a ceremony host the moment their team joins an Agile Release Train, because facilitating a stand-up or a retrospective well no longer covers the obstacles the team actually hits. Those obstacles increasingly originate outside the team: a dependency on another team’s component, a shared environment another team also deploys to, a planning conflict between two teams’ priorities for the same Program Increment.
The role’s tension is protecting the team’s self-management while making the team effective in train-level planning and dependency negotiation. Push too hard toward train-level advocacy and the Scrum Master starts making decisions the team should own itself, eroding the self-management the role exists to build. Stay too focused on internal facilitation and the team’s cross-team dependencies go unmanaged, because nobody at train level is watching for them from that team’s side.
PI Planning, ART Sync and Cross-Team Impediments
PI Planning and ART Sync are where a SAFe Scrum Master’s boundary-spanning work becomes visible, because both events exist specifically to surface the dependencies and impediments a single team’s own ceremonies cannot see. During PI Planning, the Scrum Master represents their team’s capacity and constraints while negotiating the dependencies that planning surfaces against other teams’ plans for the same increment. ART Sync gives a lighter-weight, recurring version of the same negotiation between planning events, catching new dependencies and blockers before they compound.
Impediment removal at this level looks different from impediment removal inside a single team’s daily stand-up. A blocked story inside one team usually has a local fix. An impediment that surfaces at ART Sync usually involves at least one other team, which means the Scrum Master’s job shifts from removing the obstacle directly to brokering the conversation between the teams, or escalating to the Release Train Engineer, that will actually remove it.
Handing Leadership Roles Back to the Team
A mature SAFe Scrum Master hands leadership roles back to the team over time rather than holding onto them indefinitely, which is precisely what frees capacity for boundary-spanning work at train level. A quantitative study built on the 9-Factor Theory of Scrum Master leadership roles found that the roles a Scrum Master performs are meant to transfer to the team as it matures, tracking the presence and change of those nine roles against team maturity over time Scrum Master (A Quantitative Exploration of the 9-Factor Theory).
That transfer is not incidental to scaling: it is the mechanism that makes scaling possible. A Scrum Master who still personally holds all nine leadership functions for their team has no spare capacity to spend on PI Planning negotiation, ART Sync attendance or cross-team relationship building. Separate research modelling the interactions between a Scrum Master and their development team through a game-theoretic lens found that the Scrum Master’s own behaviour shapes how much the team steps into those functions, which means the handover is something a Scrum Master actively drives rather than something that happens automatically as a team ages Scrum Master (Understanding the Interactions between the Scrum Master and the Development Team).
Why Organisations Struggle to Fill the Role
Organisations consistently struggle to fill the SAFe Scrum Master role well, because the skill set it demands, team facilitation plus cross-team negotiation plus enough technical fluency to broker engineering disputes, is uncommon and hard to train quickly. Research examining how universities and industry teach the Scrum Master role found that most software-engineering education still treats Scrum Master training as a short course covering ceremony mechanics, leaving the boundary-spanning half of the role largely untaught, and that companies report real difficulty both hiring good Scrum Masters and persuading existing staff to take the role on Scrum Masters (Teaching the Scrum Master Role using Professional Agile Coaches and Communities of Practice).
| Skill the role needs | Where it’s usually taught | Gap at scale |
|---|---|---|
| Ceremony facilitation | Short certification courses | Well covered |
| Team-level coaching stances | Coaching Agile Teams and similar texts | Reasonably well covered |
| Cross-team dependency negotiation | Rarely taught explicitly | Learned on the job, unevenly |
| Enough technical fluency to broker engineering disputes | Rarely taught to non-engineers in the role | Frequently missing |
The last two rows explain most of the hiring difficulty organisations report: certified Scrum Masters exist in volume, but Scrum Masters who can also negotiate a cross-team dependency or recognise when a delivery problem is actually a testing-automation gap are scarcer, because nothing in the standard training path builds those skills deliberately.
Coaching Technical Agility: Why Facilitation Cannot Offset Weak Engineering
Team effectiveness and engineering capability have to be coached as one system, because facilitation skill and psychological safety cannot compensate for weak integration, missing test automation or an inadequate Definition of Done. A team can run flawless retrospectives and still ship unreliable software if nobody is coaching the engineering practices that determine whether an increment is actually releasable.
One System: Team Effectiveness and Engineering Capability
A TTA coach has to read engineering practice, not delegate it to someone else, because a delivery problem that looks behavioural on the surface is frequently technical underneath. A team that consistently misses its Program Increment commitments might have a planning or estimation problem, the facilitation-side diagnosis, or it might have a flaky test suite that eats a full day of every sprint in manual verification, which no amount of better retrospective facilitation will fix.
Treating these as one system means the coach’s diagnostic questions cover both halves before assigning a cause. Is the team struggling to agree on priorities, or is the team agreeing fine and then losing days to a broken build? The two failure modes look similar in a status report and require opposite interventions, which is why a coach who only reads team dynamics will misdiagnose a meaningful share of the delivery problems they encounter.
Engineering Practices a TTA Coach Must Read
A TTA coach must be able to read Definition of Done, test-driven development, continuous integration, peer review and test automation well enough to tell when each one is the actual cause of a delivery problem a team is describing in behavioural terms.
Definition of Done and Peer Review
A weak Definition of Done is the single most common technical cause of a team that looks unreliable at the story level: if “done” doesn’t require passing automated tests, a completed peer review and a successful integration into the shared codebase, then stories marked complete routinely aren’t, and the gap surfaces later as integration failures that get blamed on planning.
Peer review closes part of that gap by catching defects and knowledge silos before code merges, but only when it’s treated as a required step in the Definition of Done rather than an optional courtesy. A coach who sees a team skipping peer review under deadline pressure is watching the Definition of Done erode in real time: a pattern worth naming directly, because the cost shows up two or three sprints later as harder-to-diagnose integration bugs, not immediately.
Test-Driven Development, Test Automation and Continuous Integration
Test-driven development, test automation and continuous integration function together as the mechanism that keeps an increment releasable at the end of every iteration rather than only at the end of a hardening phase. Writing the test before the code forces the requirement to be explicit before implementation starts; automating that test means it runs on every change rather than once at release time; and continuous integration means the whole team’s changes get merged and tested together constantly, so integration problems surface in hours instead of weeks.
Skip any one of the three and the others lose most of their value: automated tests that nobody runs continuously still let integration drift accumulate unnoticed, and continuous integration without meaningful test coverage just runs a broken build faster. A coach evaluating a train’s Built-in Quality should be able to see which of the three is actually missing, because the fix differs for each; more test-first discipline, more automation investment, or a CI pipeline that actually gates merges.
Why a New Silo Is the Wrong Fix
Creating a separate quality or DevOps team to fix an engineering gap reproduces the functional-silo dysfunction the coach is supposed to be removing, rather than solving it. Jez Humble made this argument directly: the DevOps movement exists to address the dysfunction that results from organizations built out of functional silos, so building another functional silo, a “DevOps team” sitting between development and operations, is a poor and ironic response to that same dysfunction (Jez Humble).
Humble cites Elisabeth Hendrickson’s account of a product company that hired a VP of QA and stood up a dedicated QA division to fix a quality problem; and watched the number of bugs increase, because developers stopped feeling responsible for quality once a separate team existed to catch it, and shipped features into test faster instead of building quality in from the start. The same logic applies directly to coaching: a coach who responds to a weak Definition of Done by recommending a dedicated quality team is treating the symptom as the disease, and will likely watch the underlying engineering discipline degrade further as the rest of the organisation quietly outsources responsibility for it. Humble’s Lean Enterprise extends the same argument to cross-functional delivery at enterprise scale, making the case that the fix is always integration of the practice into existing teams, never a new specialist team standing between them.
Coaching the Team of Teams with Team Topologies and Architectural Runway
Scaling coaching is an interaction-design problem: the coach improves team boundaries, interaction modes and decision ownership so that teams stop needing each other for every routine change. Some impediments cannot be fixed by coaching any single team, because they sit in team structure and architectural decision authority rather than in any one team’s behaviour; which is exactly where Team Topologies and decentralised architecture governance give a coach something concrete to work with.
Team Topologies as a Coaching Map
Team Topologies, developed by Matthew Skelton and Manuel Pais, gives a coach a map for diagnosing dependency problems: four team types and three team interaction modes that describe how teams should be structured and how they should relate to each other, with the stream-aligned team as the primary, outcome-oriented unit Team Topologies (Martin Fowler).
Four Team Types and the Stream-Aligned Team
The stream-aligned team is a long-running, full-stack, full-lifecycle team responsible for a single business capability end to end, front end, back end, database, testing, deployment and monitoring, and it is outcome-oriented rather than activity-oriented, meaning it is judged by the business result it delivers rather than the function it performs. The other three team types, platform, enabling and complicated-subsystem teams, all exist to reduce the cognitive load a stream-aligned team would otherwise carry alone, by taking on shared infrastructure, temporary skill-building support, or hard technical subsystems respectively.
A coach mapping an ART against these four types is doing diagnostic work most facilitation-only coaching skips entirely. A train where every team is nominally stream-aligned but several are secretly doing platform work on the side, maintaining shared libraries nobody officially owns, will show exactly the dependency symptoms described earlier, and no amount of retrospective facilitation inside any one team will resolve it, because the fix is a team-boundary change, not a behaviour change.
Three Team Interaction Modes
Team Topologies names three interaction modes, collaboration, X-as-a-Service and facilitating, as the vocabulary for describing how any two teams should relate at a given moment, replacing the vague default of “teams should talk to each other more” with a specific choice. Collaboration mode is deliberately temporary and high-bandwidth, used when two teams are jointly discovering something neither already knows how to do. X-as-a-Service mode is the opposite: one team consumes another’s output through a clean, well-documented interface with minimal ongoing communication required. Facilitating mode is explicitly a coaching relationship, where one team, often a platform or enabling team, helps another become more capable and autonomous rather than doing the work for them.
Naming the mode explicitly changes what a coach recommends when two teams are stuck. A dependency that’s stuck in permanent collaboration mode, with constant back-and-forth months after the joint discovery work should have finished, usually needs to move to X-as-a-Service: a defined interface that lets the teams stop synchronising constantly. A dependency where one team keeps doing another team’s work for them, rather than teaching them to do it, is stuck in a role that should be facilitating mode instead.
Decentralising Architectural Decisions Without Losing Alignment
Architectural decision authority works best when it’s aligned to C4 abstraction levels, context decisions to the Enterprise Architect, container decisions to the Solution Architect, component decisions to the Solution Engineer, and code-level decisions to the Tech Lead, because that alignment gives distributed teams clear ownership boundaries without requiring a central approver for every choice Tech Lead (Architecting Autonomy at Scale).
Architecture governance forums support this decentralisation rather than undermining it, when they’re designed as escalation and alignment mechanisms rather than approval gates; clarifying the organisation’s constraints and direction instead of granting or withholding permission for every team’s decision. Fitness functions, automated checks embedded directly in CI/CD pipelines, continuously validate architectural properties like SLO adherence and security thresholds, which shifts governance from periodic review meetings to structural enforcement that runs on every change. Without Architecture Decision Records maintained at team or domain level, this whole model breaks down, because architectural reasoning becomes tribal knowledge that new team members inherit without context; making safe experimentation harder and any later reversal of a bad decision much riskier to assess.
Architectural Runway and Dependency Management as Coaching Targets
Architectural runway, the existing code, components and technical infrastructure needed to implement near-term features without excessive delay, and dependency management are the two ART-level targets where team-of-teams coaching earns its keep. A coach who has mapped a train’s teams against Team Topologies and pushed architectural decisions down to the right level still has to watch whether the train is building runway ahead of its roadmap or constantly playing catch-up, because a train that never invests in runway will keep generating exactly the cross-team dependencies described above.
Dependency management, in this frame, is a structural design problem the coach keeps surfacing at PI Planning and ART Sync: which dependencies are temporary and expected to resolve through collaboration mode, which are permanent and need an X-as-a-Service interface, and which point to a team boundary drawn in the wrong place. A coach who treats every dependency the same way, as something to track on a board rather than something to design away, will keep the train dependent on active coordination indefinitely instead of reducing the coordination burden over time.
How SPCs, RTEs and Coaching Communities Spread TTA Practices Beyond One Team
Coaching capacity scales through certified change agents, communities of practice and leaders who learn to coach: not by hiring one dedicated coach per team, which is both prohibitively expensive and unnecessary once the other mechanisms are in place. Spreading TTA practice across dozens of teams follows a repeatable sequence rather than requiring a coach embedded permanently in every one of them.
Step 1: Deploy SPCs and ASPCs as Change Agents
SAFe Practice Consultants are certified change agents who combine technical knowledge of SAFe with the job of improving an organisation’s software, systems and Agile business processes, working closely with Agile Teams, ARTs and portfolios to implement Lean and Agile practices at scale Lean and Agile (Scaled Agile Framework).
SAFe Practice Consultants and the Implementation Roadmap
An SPC’s engagement is deliberately transformation-scoped rather than permanent: they connect a train’s day-to-day practice to the underlying Lean-Agile principles that make it effective, and they typically work through the critical moves defined in SAFe’s Implementation Roadmap rather than staying on indefinitely as an embedded coach. That scoping matters for capacity planning: an organisation budgeting coaching capacity should expect SPC involvement to be heaviest during the transformation period and to taper as internal roles take over the ongoing coaching function.
Advanced SAFe Practice Consultants for Complex Transformations
Advanced SAFe Practice Consultants go beyond implementation into leading, navigating and sustaining complex SAFe transformations, contextualising the framework to the specifics of a given organisation rather than applying it uniformly. Where an SPC gets the standard implementation moving, an ASPC is the role to bring in when the transformation is large enough, or unusual enough, that off-the-shelf implementation guidance stops fitting; multiple business units on different timelines, or a regulatory environment SAFe’s default patterns don’t anticipate.
Step 2: Make the RTE the Train’s Coach
The Release Train Engineer is the ART-level coach for Program Increment Planning, System Demo and cross-team flow, filling the second-dimension coaching role that individual Scrum Masters cannot fill from inside their own teams. Where a Scrum Master coaches one team’s behaviour, the RTE coaches the train’s behaviour as a whole; facilitating PI Planning, tracking the dependencies and risks that planning surfaces, and running the cadence of events that keep a dozen or more teams synchronised across a Program Increment.
Treating the RTE role as the train’s coach, rather than purely as a logistics and reporting function, is what connects step one to step three: an SPC installs the practices, but the RTE is who sustains and coaches them day to day once the SPC’s engagement tapers off.
Step 3: Build Coaching Communities of Practice
Communities of practice let coaching skill travel between trains through peer learning, without requiring a dedicated coach embedded in every team on every train. Simon Powers’s Adventures with Agile community, built specifically around scaling Agile and organisational design, is a working example of the pattern: Scrum Masters and coaches from different organisations and different trains compare what’s actually working, rather than each relearning the same lessons in isolation Scrum Masters (Simon Powers).
A community of practice inside a single enterprise works the same way at smaller scale; Scrum Masters and RTEs from different ARTs meeting regularly to compare dependency patterns, engineering-practice gaps and what worked when escalating a cross-team blocker. The mechanism is what makes coaching capacity scale sub-linearly with team count: a lesson learned on one train, surfaced in the community, reaches every other train without requiring a coach to personally teach it on each one.
Step 4: Teach Leaders and Line Managers to Coach
Leaders themselves have to learn to coach, because the responsibility for the systems that govern how work is performed cannot be delegated to a coaching function sitting outside the leadership structure. SAFe’s Lean-Agile Leadership material opens with W. Edwards Deming’s point, from Out of the Crisis: it is not enough for management to commit to quality and productivity; they must know what they specifically have to do, and that responsibility cannot be handed to someone else Built-in Quality (Scaled Agile Framework).
Line managers’ role in this handoff changes shape as a transformation matures. Research tracing a large-scale agile transformation in depth found that line managers act like missionaries early on, using influence and persuasion to foster adoption of agile values, and evolve into a role closer to priests at maturity, where discipline mechanisms sustain the practices that persuasion originally introduced (The Evolution of Line Managers during Agile Transformation). A coaching strategy that stops at Scrum Masters and RTEs and never reaches line managers misses this shift entirely, leaving the organisation dependent on persuasion indefinitely instead of building the discipline mechanisms that let good practice hold once the transformation’s initial energy fades.
Measuring Coaching Impact by Changed Behaviour, Not Ceremonies Facilitated
Coaching impact should be judged by changed behaviour, improved collaboration, faster learning and better delivery; never by the number of workshops run or ceremonies facilitated, because activity counts measure the coach’s effort and tell you nothing about whether the teams actually got better at anything. The distinction matters most in exactly the cases where it’s hardest to see: a coach who is popular, busy and constantly in demand can still be building dependence rather than capability.
Behaviour Changed or Friction Removed
The test that separates useful coaching from coaching that creates dependency is simple to state and hard to apply honestly: did the team’s behaviour actually change, or did the coach just remove today’s immediate friction? Removing friction feels productive in the moment, a blocked story gets unblocked, a tense meeting gets smoothed over, but if the same friction recurs next sprint because nothing about how the team operates has changed, the coach has become a recurring cost rather than a capability the team now owns.
Recognising the difference requires watching what happens when the coach isn’t in the room. A team whose behaviour changed handles the same category of problem without the coach the next time it recurs. A team that’s become dependent on the coach hits the same problem and waits, because the coaching interaction removed the friction without transferring the skill that would let the team remove it themselves.
Outcome Signals Worth Collecting
Coaching outcomes worth collecting are changed behaviour, improved collaboration, faster learning and better delivery; signals that reflect what a team can now do, not how many sessions a coach ran with them. Research on teamwork quality in large-scaling environments found that collaboration quality is itself a measurable, trackable dimension of agile team performance during transformation, separate from delivery throughput (Agile Team Work Quality in the Context of Agile Transformations), which gives coaching evidence a concrete target beyond velocity charts.
Interpersonal signals matter alongside delivery signals. Research examining emotional intelligence’s role in agile software engineering leadership found that a leader’s or coach’s emotional intelligence measurably shapes communication and conflict resolution within a team Program Increments (Impact of Emotional Intelligence on Leadership and Team Dynamics in Agile Software Engineering Projects), reinforcing that the interpersonal half of coaching outcomes is as real and as trackable as the delivery half; psychological safety and trust are conditions a coach can watch build or erode over successive Program Increments, not just soft framing around the harder delivery numbers.
Where Outcomes Become Visible: Inspect and Adapt and the System Demo
Inspect and Adapt and the System Demo are the ART events where coaching outcomes actually become visible, because both events force teams to show real, working output and real data about how the increment went rather than a report about activity. The System Demo shows whether Built-in Quality held across the increment: a train with weak engineering practice produces a visibly rougher demo, with more caveats and more “this part isn’t quite done yet.” Inspect and Adapt shows whether the train’s retrospective process itself is improving, by comparing what problems recur Program Increment after Program Increment against what got fixed.
A coach who wants evidence of changed behaviour should be watching both events over successive Program Increments, not just the most recent one. A single strong System Demo proves little; a System Demo that’s visibly less caveated than it was three Program Increments ago, alongside an Inspect and Adapt session naming new problems instead of the same recurring ones, is closer to real evidence that coaching changed something durable.
Sustaining Scaled Coaching After the Transformation Ends
Coaching has to shift from installing practices to sustaining learning once large-scale agile becomes routine practice rather than an active transformation, because the coaching need doesn’t disappear when the transformation officially ends: it just changes shape, and coaching budgets are usually the first thing cut by sponsors who assume otherwise.
From Transformation to Normalisation
An exploratory study of a large-scale agile transformation examined what actually happens once agile practice moves from being the transformation’s active subject to being simply how the organisation works, finding that the existing literature on large-scale transformations is thin on exactly this normalisation phase; most research and most coaching effort concentrates on the installation period and largely stops paying attention once the practices are in place (From transformation to normalisation). That gap in attention is precisely where coaching capacity gets cut, because the visible signs of an active transformation, training sessions, new ceremonies, visible change management, have stopped, even though the underlying discipline still needs active maintenance.
Separate research into an incumbent firm’s agile-at-scale transformation, built on interviews conducted across the organisation over the life of the transformation, found that the challenges and lessons worth capturing continue well past the point where the organisation would describe itself as “done” transforming (Scaling organizational agility).
Keeping Coaching Capacity Once the Programme Ends
Coaching capacity persists past the formal transformation programme only when it’s deliberately embedded in structures that outlast the programme itself; internal communities of practice, line managers who’ve learned to coach rather than merely comply, and an RTE function that keeps running the train-level coaching described earlier. Research on scaling agile company-wide, examining the specific tension between agile-scaling frameworks and enterprise architecture, found that seamlessly integrating what teams built agilely at project level with enterprise-level processes and applications stays complex well past the transformation’s formal close, precisely because enterprise architecture decisions keep evolving after the transformation programme has wound down (Scaling Agile Company-Wide).
A sponsor deciding whether to keep funding coaching after launch should treat that ongoing architectural tension as the argument for sustained investment, not a one-time cost: the coaching need created by an evolving enterprise architecture doesn’t end when the transformation programme’s budget line does.
Coaching Human-AI Teams
Coaching now increasingly has to account for teams that include AI collaborators alongside human ones, a shift Scott M. Graffius has been applying agile coaching thinking to directly in his 2024-2026 work, and one Lyssa Adkins continues to address in her ongoing work on collaborative coaching and organisational change, including her Women in Agile 2025 programming. Coaching a human-AI team raises a version of the same boundary-spanning question this piece has returned to throughout, who owns a decision, and where does the coach intervene versus hold back, applied to a collaborator that doesn’t attend a retrospective or respond to a coaching stance the way a human team member does.
The organisations furthest ahead on this question are treating it as an extension of existing coaching practice rather than a wholly separate discipline: the same judgment about when to let a team find its own answer and when to intervene on structural grounds applies, with the addition of new structural questions about how AI-generated work enters a team’s Definition of Done and where human review sits in that pipeline.
How to Start Coaching and Scaling
Before committing budget to coaching, ask which of the three TTA dimensions is actually failing, team-level behaviour, cross-team flow, or engineering discipline, because the wrong hire fixes the wrong problem. An organisation that hires a facilitation-focused coach when the real gap is a missing Definition of Done and no continuous integration will see coaching activity increase and delivery reliability stay flat, then conclude coaching doesn’t work, when the actual conclusion is that the wrong dimension got staffed.
The failure mode to watch for in the first ninety days is a coach who becomes indispensable rather than one who builds capability that persists their absence; measurable, per the earlier distinction, by whether teams still handle a recurring problem competently when the coach isn’t in the room. A useful early test: pick one cross-team dependency currently stuck in permanent, months-long collaboration mode, and use it as the first case where a coach applies the Team Topologies question directly. Should this relationship move to a defined interface, or does it still need active collaboration? Getting one concrete dependency resolved this way, visibly, does more to establish what scaled coaching actually looks like than any amount of upfront framework training, and it gives sponsors an early, legible signal of whether the coaching investment is producing structural change or just busier retrospectives.
Anonymous. Counted, not tracked.
Where is your organisation with this right now?
What is the hardest part where you are?
In a sentence: what are you trying to work out right now?
No names, no company. Anonymous. Counted, not tracked.