PART 1: THE REALITY CHECK - When Agility Is No Longer Enough

Sophie ends her Teams call and stares at the virtual retrospective board on her screen. Colored sticky notes are arranged in neat columns: “What went well,” “What didn’t go well,” “Action items.” The same categories as last sprint. And the sprint before that. And the sprint before that.

Fifty retrospectives. She’s been counting.

In the “What didn’t go well” column, she can see the familiar themes:

• “Waiting too long for operational validation” (mentioned in 38 of the last 50 retros)
• “Test environment unavailable when we need it” (mentioned in 42 of 50)
• “Stories not fully refined at sprint planning” (mentioned in 35 of 50)

The action items column has seventeen actions, carried over from previous sprints. Some are six months old. The oldest one: “Escalate ops validation delays to management.” Created in Sprint 15. It’s now Sprint 50.

Her team builds ground segment software for a space agency—critical systems that process data from Earth observation satellites and deliver it to scientists and environmental monitoring teams. Important work. Work that matters. Yet here they are, sprint after sprint, marking stories “done” that won’t reach production for another four to six months.

Sophie is PSM II certified. She’s read the Scrum Guide cover to cover. She facilitates the ceremonies flawlessly—daily stand-ups at 9:00 AM sharp, sprint planning that always finishes on time, reviews with great demos, retrospectives with psychological safety and engaged participation.

But as she prepares for her 51st retrospective next Thursday, she knows exactly what will happen. The team will raise the same issues. She’ll facilitate a good discussion. They’ll create new action items. And nothing structural will change.

Because Sophie doesn’t have the authority to change the operational validation process. She doesn’t control the test environment provisioning. She can’t modify the sprint planning cadence to match the Product Owner’s availability. She can facilitate, document, escalate—but she can’t solve.

And that’s the problem.

Three hundred kilometers away, Nicolas is having a similar moment of clarity. Except his realization is happening during a budget review meeting.

Nicolas manages three teams in the French public sector—about twenty-five people total, building digital services for citizens accessing government programs online. He’s been a Scrum Master for five years. Senior Scrum Master for the last two. He’s the person other SMs come to for advice. He mentors junior SMs. He’s considered reliable, competent, knowledgeable.

But sitting in this budget meeting, watching the finance director go through headcount line by line, Nicolas hears a question that makes his stomach drop:

“Nicolas, can you explain what value your role delivers?”

He starts with the usual answer: “I facilitate the Scrum ceremonies, coach the teams, remove impediments, enable self-organization—”

The finance director interrupts: “Yes, but what’s the business outcome? The product managers deliver features. The engineering managers deliver team performance and retention. The DevOps engineers deliver deployment frequency and system uptime. What do you deliver?”

Nicolas pauses. What does he deliver?

Well-run retrospectives? That’s an activity, not an outcome.
Stable velocity? That’s a vanity metric that doesn’t correlate to business value.
Team happiness? Important, but hard to tie to business impact.
Documentation of impediments? That’s not delivery, that’s documentation.

“I… I enable the teams to deliver value more effectively,” he manages.

“Can you quantify that? Show me the before and after. What changed because of your facilitation?”

Nicolas can’t. Because he’s never measured it. Because nobody ever asked him to. Because his success has always been defined by activities performed, not outcomes achieved.

Nicolas doesn’t know it yet, but he’s not alone. According to the 18th State of Agile Report published by Digital.ai in 2025, 42% of practitioners describe their Agile culture as “better than nothing, but could be more effective.” Only 27% say Agile is enabling them to deliver real value. And here’s what should give every Scrum Master pause: 29% of respondents now report being accountable for tying Agile work to business outcomes—a clear signal that organizations are demanding measurable impact, not just facilitation. The finance director’s question isn’t hostile. It’s the new normal.

The meeting moves on. His position isn’t cut—not yet. But Nicolas walks back to his desk with a new understanding: in a world that demands measurable impact, facilitation without accountability is vulnerable.

That evening, Nicolas does something he’s never done before. He maps out exactly what happens to a feature after his teams mark it “done”:

1. Code is merged (immediate)
2. Wait for legal compliance review (average: 2 weeks)
3. Legal review completed (2 days of work)
4. Wait for GDPR validation (average: 1.5 weeks)
5. GDPR validation (half day of work)
6. Wait for security audit slot (average: 3 weeks)
7. Security audit (1 day of work)
8. Wait for interministerial approval (average: 2 weeks)
9. Approval meeting (2 hours)
10. Wait for accessibility compliance check (average: 1 week)
11. Accessibility check (1 day of work)
12. Wait for quarterly deployment window (average: 3 weeks)
13. Deploy to production (1 hour)

Total time from “done” to “in production”: 14 weeks on average.
Total work time: 6 days.

The teams are “done” in week 1. Citizens can use the feature in week 15.

Nicolas’s teams have a stable velocity of 28 points per sprint. Management sees this and thinks: “Everything is working well.” But the reality is that 96% of the lead time is waiting. And Nicolas has no authority over any of those waiting periods.

He can’t change the legal review process.
He can’t modify the security audit schedule.
He can’t eliminate the quarterly deployment batch.
He can’t even influence them.

All he can do is facilitate discussions about them.

Alix is standing at the back of a large conference room in Toulouse, watching eighty people work through day two of PI Planning. Ten teams, each clustered around their planning boards, mapping out their next ten weeks of work.

This is Alix’s fourth PI Planning as Release Train Engineer for this Agile Release Train. On the surface, it’s going well. Teams are engaged, dependencies are being called out, risks are being noted on the big board at the front of the room. The energy is good.

But Alix has a growing sense of déjà vu.

On the dependency board, Alix counts sixteen cross-team dependencies. Twelve of them are the same dependencies that appeared in the last PI Planning. And the PI before that. Different feature names, same underlying structural dependencies.

On the risk board, three risks are marked “ROAM’d” (Resolved, Owned, Accepted, Mitigated). But “mitigated” means “we’ll work around it,” not “we fixed the root cause.” The same three risks—architectural review process, security validation timeline, deployment windows—have been “mitigated” for the past three PIs.

Alix pulls up the metrics from the last PI:

• PI objectives delivered: 78% (respectable)
• Average lead time from feature idea to production: 12 weeks
• Time spent in actual development work: 3 weeks
• Time spent waiting: 9 weeks
• And that’s just to production. Whether customers actually use these features and whether they deliver the intended business outcomes? Nobody tracks that.

The teams are productive. The train is coordinated. But three-quarters of the value delivery time is pure waste—waiting for reviews, waiting for approvals, waiting for deployment slots.

And here’s the thing that bothers Alix most: nobody is accountable for that waste.

The teams are accountable for building working software. Check.
The Product Management is accountable for prioritization. Check.
The System Architect is accountable for technical coherence. Check.
But who is accountable for the twelve-week lead time? Who owns the outcome of “ideas turned into customer impact faster”?

Not the teams—their scope ends at “code working.”
Not Product Management—their scope is what to build, not how fast it flows.
Not the Architect—they ensure technical soundness, not flow speed.

Alix, as RTE, coordinates. Facilitates. Aligns. But doesn’t own the lead time. Doesn’t have authority to change the architectural review process, or eliminate the quarterly deployment batching, or restructure the teams to reduce dependencies.

Alix is a leader without authority to lead. A coordinator without power to change the system.

And as this PI Planning wraps up with the final confidence vote and everyone heads home feeling aligned and energized, Alix knows that ten weeks from now, at the next PI Planning, the same dependencies and risks will appear again.

Because facilitating PI Planning doesn’t change the system. It just makes the system’s constraints visible every ten weeks.

I had my own version of this realization. Late 2022, I was working as a consultant at a major aerospace company on their Identity and Access Management systems. I was good at the role—PI Planning ran smoothly, the train delivered predictably, my stakeholders trusted me.

But I was hitting the same ceiling that Sophie, Nicolas, and Alix were hitting: I could see the systemic problems. I just couldn’t fix them. I could facilitate, coordinate, escalate. But I couldn’t decide. I couldn’t change processes that crossed organizational boundaries. I couldn’t allocate budget. I couldn’t restructure teams. My influence was limited to persuasion and facilitation.

Then someone recommended a book: Agile Coach to Chief Agility Officer by Steve Peacocke. I almost didn’t read it—I’d grown tired of agile books that promised transformation through better facilitation or deeper servant leadership.

But something in the title caught me: “Chief Agility Officer.” Not Coach. Not Servant Leader. Officer. A role with authority. A seat at the table where structural decisions get made.

I read it in two days.

What struck me wasn’t the specific path from coach to CAO—most organizations don’t have CAOs, and probably don’t need them. What struck me was the fundamental shift in posture the book described: from influencing to deciding. From facilitating to owning. From activities to outcomes.

The book articulated something I’d been feeling but couldn’t name: organizations increasingly want accountability, not just coaching. They want someone who can say, “I own the lead time, and here’s how I’m going to reduce it,” not someone who says, “I’ll facilitate discussions about lead time reduction and hope someone else implements the solutions.”

After reading that book, I started experimenting. I started measuring things nobody had asked me to measure—end-to-end lead time, deployment frequency, flow efficiency. I started presenting data instead of anecdotes. I started proposing changes instead of facilitating discussions. I started asking for authority over specific processes, backed by data showing their impact on business outcomes.

Some experiments worked. Some didn’t. But I learned something crucial: the organizations that valued me most were the ones where I was accountable for measurable outcomes, not the ones where I was celebrated for excellent facilitation.

Here’s what Sophie, Nicolas, Alix, and I all came to realize, each in our own way:

The Scrum Master role, as traditionally defined, has a fundamental flaw. It’s defined by activities—facilitate ceremonies, remove impediments, coach the team—but not by outcomes. And in an era where every role is being scrutinized for ROI, activity-based roles are vulnerable.

Compare it to other roles:

• DevOps Engineer: Accountable for deployment frequency, mean time to recovery, system uptime. Clear, measurable outcomes.
• Product Manager: Accountable for user adoption, feature usage, customer satisfaction, revenue. Clear outcomes.
• Engineering Manager: Accountable for team performance, retention, delivery throughput. Measurable.

Scrum Master: Accountable for… having held the ceremonies? Keeping Jira updated? “Team enablement”?

When budgets tighten and organizations ask, “What exactly are we paying for with this role?”, vague answers about enablement don’t cut it anymore.

The 18th State of Agile Report (2025) confirms this bifurcation is accelerating. When asked how their roles had changed in the past 12–18 months, 26% said they were doing less coaching or framework evangelism as teams moved to hybrid approaches, while 14% reported their Agile-related responsibilities had decreased outright. Another 13% said their role had shifted away from Agile entirely, and 10% reported their role had been eliminated or absorbed into another function. Meanwhile, those who are thriving are the ones expanding into outcomes: 29% are now accountable for business results, and 26% have moved into product planning and portfolio decisions. The message is unmistakable: activity-based roles are contracting, while outcome-based roles are growing.

Before we go further, let’s be honest with ourselves. How many times have you:

• Identified a major obstacle but lacked the authority to remove it?
• Known exactly what should change but been unable to act?
• Felt reduced to an administrative role when you know your potential impact is far greater?
• Documented, escalated, facilitated… without being accountable for actually solving the problem?

If these questions resonate—and I suspect they do—then you’re experiencing what I call the accountability gap. The gap between the impact you could have and the authority you’ve been given. The gap between the problems you can see and the solutions you can implement.

Here’s the harder truth: even when Scrum Masters are skilled, passionate, and well-intentioned, they often can’t succeed because the organization isn’t set up for them to succeed.

Sophie’s team is agile, but her organization’s validation processes are designed for waterfall. She can’t “embrace change” when every change requires three layers of regulatory approval.

Nicolas’s teams self-organize beautifully, but they’re required to fill out timesheets by project code, attend status meetings at three organizational levels, and produce weekly PowerPoint reports for executives who’ve never read the Agile Manifesto. The agile mindset lives in his teams. The rest of the organization operates on command-and-control.

Alix’s train is supposed to deliver value incrementaly, but the deployment schedule is quarterly batches. The architectural review board meets once a month. Security audits have a six-week backlog. No amount of PI Planning excellence can overcome those systemic constraints.

The metaphor I use: it’s like trying to run a marathon in concrete shoes. You can have perfect running technique, proper breathing, optimal pacing—but if your shoes weigh twenty kilograms each, you’re not going anywhere fast. The problem isn’t your technique. It’s the shoes.

For many Scrum Masters, the organization is those concrete shoes.

Fixed-price contracts that demand detailed upfront specifications. Risk-averse cultures that punish failure. Siloed budgets that make cross-team collaboration nearly impossible. Individual performance metrics that reward personal achievement over team outcomes. Approval processes that add weeks of delay in the name of “governance.”

I’ve watched brilliant Scrum Masters burn out not because they weren’t good at their jobs, but because they were trying to implement agile practices in organizations fundamentally incompatible with agile principles.

And the worst part? They blamed themselves. “If I were a better facilitator…” “If I had better coaching skills…” “If I understood servant leadership more deeply…”

No. The problem wasn’t them. The problem was the system.

So here we are. Sophie preparing for her 51st retrospective, knowing the same issues will surface. Nicolas wondering how to answer “What do you deliver?” Alix watching the same dependencies appear in the fourth consecutive PI Planning. And all three of them—all of us—realizing that something fundamental needs to change.

The good news? You’re not alone. Thousands of Scrum Masters around the world are having this exact realization. Some have already started to evolve.

The rest of this book will show you how.

We’re going to explore why agility seems to be failing (spoiler: it’s not agility that’s failing, it’s how we’ve institutionalized it). We’re going to understand how we fell into the ceremony trap. And then we’re going to dive into a new approach—a new posture, really—centered on measurable value flow rather than activity completion.

But before we get to solutions, we need to fully understand the problem. Because the problem isn’t Scrum. The problem isn’t you. The problem is that we’re applying a framework from the 90’s to a 2026 reality, and wondering why it doesn’t quite fit anymore.

Scrum was revolutionary. It enabled enormous progress. But like any revolution, it eventually needs to mature and adapt to the world it helped create.

Sophie, Nicolas, and Alix are about to discover what that adaptation looks like. So are you.

Ready to turn the page?