Agile Doesn’t Fail. Leadership Does.
- Bill Holmes
- 4 days ago
- 4 min read
“The best executive is the one who has sense enough to pick good people to do what he wants done, and self-restraint enough to keep from meddling with them while they do it. ”Theodore Roosevelt
“You cannot manage knowledge workers the way you managed factory workers. ”Peter Drucker
I’ve seen it over and over again.
Managers cannot let Scrum be Scrum. They have to meddle. They impose reporting where none is needed. They override team decisions. They tell subject matter experts how to do work they themselves could not execute. And when outcomes degrade, they blame Agile.
For a long time, I thought this was a government problem.
During my career in the U.S. government, I watched well-intentioned Agile initiatives slowly suffocate under layers of approval, status reporting, and “just checking in.” Stand-ups became performance theater. Backlogs became suggestion lists. Scrum Masters existed, but authority did not.
At first, that felt like government behaving exactly as expected.
Then I began working with other governments. Different countries. Different cultures. Different political systems. The same pattern showed up almost immediately. Scrum was introduced. Agile language spread quickly. And managerial control quietly reasserted itself in the form of additional reporting, approval gates, and “guidance” that looked suspiciously like direction.
At that point, I still believed this was a public-sector pathology.
That assumption didn’t survive consulting.
In private industry, the structures were different, but the behavior was the same. Managers adopted Scrum vocabulary while preserving the instincts they had always relied on. Teams were told they were empowered right up until their decisions became inconvenient. Agile ceremonies existed, but authority still did not move.
By the time I began teaching and coaching teams across organizations and industries, the conclusion was unavoidable.
This isn’t a government problem. It isn’t an industry problem. It’s a leadership problem.
And it shows up most clearly in how organizations react to Scrum’s most uncomfortable premise that execution belongs to the people doing the work.
Agile does not delegate execution to developers as a cultural gesture or an act of blind trust. It does so for a far more practical reason. Developers have the most accurate, immediate understanding of how the work can actually be done.
Scrum assumes that the people closest to the work are best positioned to make decisions about sequencing, design, tradeoffs, and implementation. That assumption isn’t ideological. It’s operational. Complex knowledge work cannot be effectively directed by someone who is structurally removed from the details.
This is where many managers become uncomfortable.
A manager who has never written production code, never debugged a failing integration, and never had to balance technical debt against delivery pressure will still feel compelled to tell a developer how to do the work. Not because they know better, but because traditional management models reward visible control. Direction feels like leadership. Intervention feels like value.
Agile quietly rejects that instinct.
It argues that inserting less-informed decision-makers between the problem and the people solving it does not improve outcomes. It degrades them. Authority moves closer to the work, not farther away from it. For leaders whose identity is tied to directing execution rather than enabling systems, that shift can feel like abdication instead of evolution.
In Scrum, managers are not removed because they are unnecessary. They are constrained because their role must change. The work of deciding how something is built belongs to the people who understand the constraints, the tools, and the tradeoffs in real time. When managers override that authority, they are not adding rigor. They are introducing delay, distortion, and risk.
This is why Agile deliberately protects team-level decision making and why so many Agile implementations collapse under the weight of “helpful oversight.” Managers cannot stop managing the way they always have, so they reach into spaces they no longer understand, and Agile pays the price.
This is also where SAFe is often misunderstood.
SAFe does not exist to reintroduce command and control through a larger framework. It exists because, at scale, the tension between leadership oversight and team autonomy becomes unavoidable. Dependencies multiply. Integration risk grows. Strategic alignment matters. Pretending that multiple Scrum teams can self coordinate purely through ceremonies is just as naïve as believing managers can micromanage their way to agility.
SAFe’s contribution is not more management. It is explicit structure.
It makes clear what leaders are responsible for and just as importantly, what they are not. Strategy, investment decisions, economic prioritization, and cross team coordination are elevated and made visible. At the same time, the Scrum team’s authority over how work is designed, built, and delivered is intentionally protected.
That distinction is the part many organizations miss.
When implemented as designed, SAFe gives leaders legitimate mechanisms to lead without reaching into the team’s execution space. It replaces informal meddling with formal alignment. It gives managers real work to do at the system level so they are not tempted to interfere at the team level. And it forces hard conversations about tradeoffs, capacity, and sequencing before teams commit to work, not after.
Agile doesn’t fail because teams lack discipline. It fails because leadership refuses to change where decisions are made.
The solution is not fewer managers, less visibility, or blind trust. The solution is clear decision boundaries, enforced by structure and respected by leaders. Scrum defines those boundaries at the team level. SAFe extends them across the enterprise.
When leaders learn to lead the system instead of the sprint, Agile stops looking fragile and starts looking exactly like what it was always meant to be. A practical way to deliver complex work in complex environments.
If this sounds familiar, that’s not a failure. It’s a signal.
If you’re leading Agile at scale and recognize these tensions, this is where leadership work really begins. Teaching teams is the easy part. Helping leaders change how they lead is where Agile actually succeeds.
Comments