A team can run every event by the book and still miss every delivery date. The reflex is more coaching on the framework: a new retrospective format, a refresher, tighter facilitation. Ask me about the future of agile coaching and I will point somewhere else, at the work sitting between the events.
What the survey shows about the coaching role
Digital.ai's 2025 State of Agile report, its 18th edition, asked practitioners how their role in agile had changed over the past 12 to 18 months. It is a vendor-published survey of 349 respondents, which Digital.ai describes as mostly coaches and consultants at very large enterprises. Read every number below as a view from inside the role, not a census of it.
26% said they are doing less agile coaching or framework evangelism as teams move to hybrid or custom approaches. 22% said they are doing more to reinforce or expand a formal framework. The role is not moving in one direction. It is moving in several at once.
The same question offered other answers, and respondents picked those too. 29% said they are accountable for tying agile work to business outcomes, 28% are defining or evolving a new delivery model, 26% are more involved in product planning or portfolio decisions, and 23% have been asked to evaluate or integrate AI or automation tools. Respondents could select all that applied, so these groups overlap: they cannot be added up, and nothing Digital.ai publishes shows who moved where.
The survey also shows some retreat. 14% said their agile responsibilities decreased, 13% said their role shifted away from agile, and 5% said their role was eliminated or absorbed into another function. Those numbers are small, and each one is somebody's job.
A separate question asked what is driving changes to agile investment and roles. 65% of respondents called the consolidation or elimination of agile-specific roles, such as agile coaches, a factor. That is a pressure people recognize, not a count of organizations cutting coaches, and the bar was low: the 14 drivers Digital.ai asked about ranged from 46% to 79%.
Digital.ai, The 18th State of Agile Report (2025), vendor-published: the report's resource page
Which of those directions has a future? The survey cannot answer that. It measured what people said they were doing. It did not measure which of those things anyone will keep paying for, and that is where a coach makes a living.
The flow engineer is a place to look, not a new job
I call the work I keep coming back to the flow engineer. It is my term, not a market title, and you will not find it on a job posting. I am not arguing for a new role or a new hire. I am arguing for pointing the coaches and Scrum Masters you already have at a different part of the work.
A framework coach watches the events. Did the daily scrum stay inside its time box, did the retrospective produce action items, is the backlog refined? Those matter, and a good coach gets them running early. Once every one of those answers is yes, a flow engineer watches the seams instead: the gaps between events and between teams, where work waits, how much is in progress at once, and who is waiting on it.
AI is a big part of why I would point a coach there. DORA's 2025 report, a Google Cloud survey of nearly 5,000 technology professionals, finds AI adoption associated with higher software delivery throughput and also with higher delivery instability. DORA is careful to call that a comparison between otherwise similar respondents, not a cause.
DORA's authors go a step further and suggest that AI does not remove friction so much as move it, from manual work toward deciding and verifying. That is their interpretation of a null result, not a measured finding. If it is even partly right, the waiting has moved somewhere an event checklist does not look, which is the ground we covered in August when we called verification the new bottleneck.
It is also where this quarter started. DORA's 2025 report concludes that AI acts as an amplifier, magnifying the strengths of high-performing organizations and the dysfunctions of struggling ones, and that was the argument of our July piece on how AI didn't fix your team, it made everything louder.
DORA, State of AI-assisted Software Development 2025 (v. 2025.2): the full report
The Coach Capability Redesign: four shifts
I would rebuild the coaching role around four shifts. I call the set the Coach Capability Redesign, and it is Big Agile's model, not a survey finding. A few of the survey's answer options rhyme with it; none of them measure it.
1. From event facilitation to flow observation
Donald Reinertsen's The Principles of Product Development Flow (2009) is foundational work, argued from queueing theory rather than measured, and written before AI-assisted development. One of his principles is that product development inventory is invisible. It is half-finished work, not boxes on a warehouse floor, and you see it only through its effects: longer cycle times, delayed feedback, shifting priorities, and status reporting. Every one of those can happen while the events look perfect.
2. From process adherence to AI governance
Adherence asks whether the team followed the process. Governance asks who decides what AI is allowed to do, and on what evidence. In the same Digital.ai survey (2025, vendor-published, 349 respondents), 49% agreed their organization has clear guidelines or guardrails for how AI is used across teams and 51% disagreed, on a yes-or-no question that forced a side. A coach who can help a team decide delegation by risk is doing work an adherence checklist cannot see.
3. From retrospectives to real learning loops
A retrospective that produces action items is not the same as a loop that changes a decision. We argued in August that a metric which changes no decision is overhead, and the same test applies to anything a coach tracks. If an item never changes what the team does next, it comes off the list. That is why a flow engineer's list stays short.
4. From team-level coaching to removing leadership friction
In the same survey, Digital.ai asked what role business and executive leaders play in guiding agile practices. 15% of respondents said leaders are actively involved in shaping and sustaining them, and 33% said agile is treated as a delivery function rather than a strategic lever. That question measures involvement, not friction. The link to friction is mine: pilots stall on ownership and decision rights, and in my experience the decisions that slow a team down sit above it, where team-level coaching does not reach.
What a flow engineer observes every week
The Flow Engineer Charter below is drawn from years of product development work, not from a dataset. It covers what a flow engineer observes every week and the decisions that observation should influence. Copy it, cut what does not fit your teams, and keep it short.
One question deserves its own paragraph, because in my experience it is the one leaders reach for first: how busy is everyone? Reinertsen (2009) shows from queueing theory that queues grow sharply as a system approaches full load. In his model, each halving of spare capacity roughly doubles the average queue, so going from 80 to 90 percent busy is one of those doublings. The model assumes work arrives and gets done at random, so treat it as a direction, not a law.
A team proud of being fully booked may be proud of the very thing that is making it late. Reinertsen's answer is to limit work in progress and control the size of the queue rather than chase utilization. He is clear about the cost: tighter limits cut delay, but they add blocking and leave some capacity idle. A flow engineer makes that trade on purpose and can explain it to the leader paying for the idle time.
FLOW ENGINEER CHARTER
Run weekly with the team. Keep the list short:
anything that changes no decision comes off it.
MISSION
Keep work moving through the whole system, and
make every trade between speed, load and risk
a decision someone made on purpose.
WHAT TO OBSERVE EVERY WEEK
1. QUEUES
Where is finished or half-finished work
waiting, and who is it waiting on? Count
priority changes and status requests too.
Answer: ________________________________
2. WORK IN PROGRESS
How many items are in progress right now,
against how many people are on the team?
Answer: ________________________________
3. VERIFICATION LOAD
What is waiting on a review, a test, or a
sign-off, and for how long?
Answer: ________________________________
4. INSTABILITY
What shipped and came back as rework or an
unplanned fix?
Answer: ________________________________
DECISIONS THIS SHOULD INFLUENCE
- Lower or raise the WIP limit.
- Put people on the queue, not the busiest spot.
- Add review capacity, or cap work in flight
at what can be reviewed.
- Take a mid-sprint priority change back to
the person who made it.
- Drop an observation that changed nothing.
DONE WHEN
All four have an answer, and at least one
decision above was made, or declined out loud,
this week.ILLUSTRATIVE EXAMPLE. FICTIONAL.
QUEUES Six items waiting on one reviewer.
Priorities changed three times;
nine status requests landed.
WIP Eleven items in progress, five
people on the team.
VERIFICATION Four AI-drafted changes waiting
more than two days for review.
INSTABILITY Two items reopened after release.
DECISIONS WIP limit set to six. A second
reviewer paired on the queue.
Mid-sprint priority changes go
back to the Product Owner.Try this next week
Spend one event watching flow instead of adherence. Pick a daily scrum or a refinement session, leave the format alone, and count four things: items in progress against people on the team, how long finished items spent waiting rather than being worked, how many times priorities changed, and how many status requests landed on the team that week. Write the numbers down and bring them to the retrospective.
Then take them to whoever funds the coaching and ask one thing: if one of these moved the wrong way next week, who would act on it? If nobody would, the coach is being paid to run meetings. If someone would, you already have a flow engineer on the payroll, whatever the title says.
Your team may not need more events. It may need a flow engineer.
If you want to build that capability on purpose, our next Scrum Master and leadership classes are on the Big Agile events page.