Picture a coach working with four teams. Yes, a Scrum Master or agile coach can serve multiple teams. Every Daily Scrum stays inside its 15-minute time box. Every retrospective produces action items. Sprint reviews are well attended, and people actually ask questions and make decisions. I love all of that.
By every measure that coach was hired to improve, those teams are doing great. Anyone looking at the coach's checklist would say so. Yet the teams have missed every delivery date this quarter.
So the coach does what the job seems to ask for. A fresh retrospective format. A refresher on the framework. Tighter facilitation. They're asking themselves how they can get better. The events get even healthier, and the dates keep slipping. Pretty soon you have the best-run meetings in the world with nothing shipping.
So where should that coach be looking?
What the State of Agile data says about coaches right now
This is the last episode of the third quarter of 2026, and I want to spend it on the people we just opened with: the coaches.
Digital.ai publishes a survey every year called the State of Agile. The 2025 edition, their 18th, asked practitioners how their role in agile has changed over the past 12 to 18 months.
Some scope first, because it matters for everything that follows. It's a vendor survey with 349 respondents, and Digital.ai describes them as mostly coaches and consultants at very large enterprises. So keep in mind who was answering. It isn't a full picture of the industry, but it's close enough for me to connect the dots on this topic.
A role pulling in several directions
26% said they're doing less agile coaching or framework evangelism as teams move to hybrid or custom approaches. Is 26% a lot? On its own, I couldn't tell you, because 22% said nearly the opposite: they're doing more to reinforce or expand a formal framework. So it isn't one direction. Some of the work is moving away from frameworks, and some of it is moving back toward them, whether you like that or not.
The same question offered other answers, and people picked those too:
29% said they're now accountable for tying agile work to business outcomes and monitoring it. That's good. 28% are involved in defining or evolving a new delivery model. 26% are more involved in product planning, prioritization, or portfolio decisions, which is my favorite. And 23% have been asked to evaluate or integrate AI or automation tools into their agile workflows.
Respondents could check every box that applied, so you can't add these up or read them as slices of one pie. And I can't find anywhere that Digital.ai publishes how the boxes overlap. Nobody reading the report can tell you who moved where. Maybe the 2026 edition will.
This is exactly where the story I want to tell could get ahead of its data, so I'm going to be careful. What the survey does show is respondents describing a role that's being pulled in several directions at the same time, with each of those directions sitting at roughly a quarter of respondents. That's what I want to focus on.
The retreat is real
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 aren't zero, and each one is somebody's job. It's a person out there trying to do better for their teams, and I have a lot of compassion for that.
So which of these directions has a future? The survey alone can't answer that. It measured what people said they were doing. It didn't measure which of those things anyone will keep paying for, and that's the part that decides how we make a living.
The constraints moved. The coach's eyes should too.
Over the last few years, the way we organize product development work has changed. Things that used to be the constraints in the system, like coding, testing, and deploying, are much quicker now when they're done well. Product is still trying to keep up.
What hasn't changed is that all of it still runs through cross-functional people who are no smarter than the collective wisdom of the group. So we have to focus on how they collaborate and how work moves through their hands, because almost every pair of hands has to touch the work.
What is a flow engineer?
I want to offer a term for where this role is being pulled. I'm not trying to invent a new role or a new title. I keep coming back to the phrase flow engineer. You won't find it on many job postings yet, and I'm not claiming the market uses it, although I am seeing the word flow come up more often, which excites me.
A flow engineer watches how work moves through the whole system. Framework compliance matters less to them than two questions: where does the work actually go, and how does it perform along the way?
Back in 2018, I wrote that a Scrum Master is like a head coach on the sideline. When you're in the game, it's much harder to see how the team plays together. From the sideline, you can see it. I still believe that. A good Scrum Master, like a good agile coach, works on the system rather than in it. What I'd change today is where the coach points their eyes.
Framework coach vs. flow engineer
A framework coach watches the events. Did the Daily Scrum stay inside the time box? Did the retrospective produce action items? Is the backlog refined? Those are important, and I'm not trying to take them away. They should be relatively easy to get going. Our coach from the top of this article can answer yes to every one of them.
Once those are running, the coach can switch to flow engineer and watch the work between the events. Call those gaps the seams: the seams between events, and the seams between teams. Where is the work waiting? How much is in progress at one time? Who's waiting on it? The more things we work on at once, the longer everything takes.
Why AI makes flow the coach's job now
AI is a big part of why I'd point the coach at flow now more than ever. Back in August, we spent a whole week on verification becoming the new bottleneck. I won't rehash it here, but it's a big issue to watch.
DORA's research points the same way. The 2025 DORA report surveyed nearly 5,000 technology professionals. Among them, people with higher AI adoption reported higher delivery throughput. They also reported higher delivery instability. So I don't know what truly got better. Progress over perfection, I guess, but instability doesn't sound like a good outcome to me.
DORA is careful to say that a comparison between similar people isn't proof of cause, and I want to be careful about that too. The authors suggest the friction doesn't disappear. It moves from doing the work toward deciding and verifying it, which is where a lot of our time goes now. That's their interpretation, not a measured result. But if it's even half right, the waiting has moved somewhere a framework checklist barely looks, which is where this quarter started back in July.
DORA's framing still holds: AI doesn't fix a team. It amplifies the system that's already there. Plenty of teams glaze right over that.
What a flow engineer actually sees
Go back to our coach and look at the same sprint through different eyes. For that, I want to bring in a flow master himself. Donald Reinertsen wrote The Principles of Product Development Flow in 2009. It's foundational work, and it predates everything we're doing with AI. AI is just amplifying what he described.
Product development inventory is invisible
One of Reinertsen's principles is that product development inventory is invisible. Walk into a Costco or a Walmart and you can see the inventory stacked on the floor. In product development, the inventory is half-finished work. It sits on nobody's balance sheet, and it's waste.
You only see it through its effects, and he names them: longer cycle times, delayed feedback, shifting priorities, and status reporting. That last one is part of why Scrum aims to be self-reporting.
Read that list again. Every item on it can happen while the events look perfect. None of them is on a framework checklist.
What to count instead
In that same sprint, the flow engineer counts different things:
How many items are in progress right now, compared to how many people are on the team? How long did each finished item spend waiting rather than being worked on? Is that good, bad, or ugly? How many times did priorities change during the sprint? How many status requests landed on the team that week? How's it looking, how much will it cost, when will it be done? Every one of those questions adds cognitive load and transaction cost for the team.
The utilization trap
The measure most leaders focus on is how busy everyone on the team is. Let's look hard at that one.
Reinertsen shows from queueing theory that queues grow sharply as a system gets close to fully loaded. In his model, each time you cut your spare capacity in half, the average queue roughly doubles. Going from 80% to 90% busy is one of those doublings. Have you heard "I want everyone fully utilized" before?
His model assumes work arrives and gets done at random, so treat it as a direction rather than a law. But it's typically how things play out. Think about what it means for a team that's proud of being fully booked. It may be proud of the very thing that's making it late. I see that constantly.
Limit work in progress and watch the queue
Reinertsen's answer isn't to push people harder. It's to limit work in progress and watch the size of the queue instead of chasing utilization. I think he's spot on about the cost, too. Tighter limits cut the waiting, but they also add some blocking and leave some capacity idle. That's scary for team members, and even scarier for the people paying their salaries. You know who I'm talking about.
A flow engineer makes those trades on purpose and can explain them to a leader in terms the leader understands. A framework checklist doesn't even show the trade exists. It just sits there as a line on a waste ledger nobody sees.
That's the job: watch the queues, the work in progress, the verification load, and the instability. I'm putting together a flow engineer charter you can copy, covering what a flow engineer observes every week and the decisions those observations should influence. Watch the blog for it.
Connecting the quarter
Since this is the last week of the quarter, I want to connect the dots. If you've been following along, every week this quarter landed on one of two things: how work flows, or who exercises judgment about it.
The verification week was about flow. So was the week on dashboards, where the point was that a metric that changes no decision is overhead. That's why the flow engineer's list is short. Each thing on it should change a decision, or it comes off the list. Last week's piece on judgment as the scarce skill was about the other half.
A flow engineer is someone who takes responsibility for both. That's the role we've been describing all quarter, one week at a time. And we can still call that person an agile coach or a Scrum Master. That's the service we provide to the team. The trouble is that if you look closely at how the role gets used, many of us aren't given the room to focus on any of this. So, leaders, let's change that. Empower these people to do more than check off events.
Your team may not need more events
Our coach from the top didn't need a better retrospective format. The retrospectives were already working. Your team may not need more events, for crying out loud. It may need a flow engineer.
You don't have to go hire one. If we're honest, that person is already there. Maybe we should quit reinventing roles and do a better job of empowering the ones we have where they've been held back. My gut says we need to put more light on how our teams' work actually moves and less on the checklist of events.
If you want to build that capability in your coaches, Scrum Masters, and leaders, our upcoming Scrum Master and leadership classes are the place to start. And if you need help seeing where the work is waiting in your own system, reach out. We'll be back next quarter with a new set of topics to point us in the right direction for a great 2027.