Agile’s Fall from Grace

How Engineers Lost Faith in Their Own Revolution

(For a Technical Audience. Also available on Substack)

Agile began as a revolution.

Against bloated, bureaucratic software development.

Before Agile, the dominant approach was Waterfall — a rigid, linear process where teams spent months (or years) gathering requirements, designing systems, and coding before a product ever saw the light of day.

By the time the product launched, it was often outdated or full of incorrect assumptions.

The Agile Manifesto

A group of software engineers, frustrated by this inefficiency, met at Snowbird, Utah, in 2001 to discuss a better way. They were Kent Beck, Martin Fowler, Ward Cunningham, Jeff Sutherland, Bob Martin, and others — all veterans of software development who had experimented with lighter, more iterative approaches.

Together, they created the Agile Manifesto, a short but powerful document that outlined four core values:

1. Individuals and interactions over processes and tools — Great software development depends on skilled people communicating effectively, not rigid processes or expensive tools.
2. Working software over comprehensive documentation — Delivering functional, usable software is more valuable than producing excessive paperwork.
3. Customer collaboration over contract negotiation — Engaging with customers throughout the development process leads to better results than adhering strictly to predefined agreements.
4. Responding to change over following a plan — Being flexible and adapting to new information is more important than rigidly sticking to an initial roadmap.

https://agilemanifesto.org/

They also drafted 12 Agile Principles, emphasizing continuous delivery, adaptive planning, self-organizing teams, and regular reflection and improvement.

Agile was never meant to be a rigid framework — it was a mindset shift toward flexibility, feedback loops, and engineering-driven decision-making. But in the two decades that followed, Agile became something else entirely. What started as a developer-first movement became a management tool for control.

Today, Agile — especially in large organizations — has become a bureaucracy of its own.

The Rise of Process-Driven Agile

Engineers care about solving problems and shipping great code. Agile’s original vision aligned with that.

But for managers, Agile needed structure. They took Agile’s loose principles and turned them into rigid, repeatable processes. The most dominant of these was Scrum, a methodology formalized by Jeff Sutherland and Ken Schwaber.

Scrum introduced:

• Sprints — Short, time-boxed development cycles (often 1–2 weeks).
• Scrum Master — A role meant to facilitate Agile practices but often became a process enforcer rather than a servant leader.
• Daily Stand-ups — Quick daily meetings to sync up, but in many teams, these became status reports to managers.
• Burndown Charts — Visualizations of work completed vs. remaining, often weaponized to pressure engineers.
• Sprint Planning — Meetings to assign tasks, which frequently descended into micromanagement.

Scrum wasn’t the only offender. As Agile spread into large enterprises, it was scaled into heavily structured frameworks, the worst of which was SAFe (Scaled Agile Framework®).

The Agile “Industrial Complex”

SAFe promised to bring Agile to large organizations, but in doing so, it brought large organizations to Agile, and all the bureaucracy that Agile tried to escape in the first place. SAFe introduced layers of hierarchy, multiple planning sessions, and excessive coordination meetings.

To implement SAFe, companies needed SAFe Certifications — expensive training programs that turned Agile into a “pay-to-play” industry. Soon, Agile was dominated not by engineers, but by Agile Coaches, SAFe Consultants, and Certified Scrum Masters — many of whom had never written a line of code.

Meanwhile, JIRA, a project tracking tool originally meant for bug tracking, became the backbone of Agile project management. What started as a tool for engineers turned into a control mechanism for managers. Every task became a JIRA ticket. Engineers were required to estimate their work in story points, track every move, and update tasks constantly. Productivity became less about delivering working software and more about keeping JIRA up to date.

Agile as a Micromanagement Tool

Engineers once loved Agile because it empowered them. But today, Agile is often used against them. Consider what Agile has turned into in many companies:

• Stand-ups have become daily interrogations, where engineers must justify every hour of their work instead of discussing meaningful progress.
• Sprint planning is now an exercise in fiction, forcing engineers to commit to unrealistic deadlines dictated by non-technical stakeholders.
• Story points and velocity tracking have turned into weapons, pressuring teams to inflate estimates, cut corners, and rush incomplete work to “meet expectations.”
• JIRA tickets have transformed engineering into a soulless assembly line, reducing deep technical problem-solving to a mindless checklist.

Instead of trusting engineers, Agile has become a tool for repressing engineers.

How Engineers Are Fighting Back

Many engineers, fed up with “Enterprise Agile,” are quietly rebelling.

They ignore unnecessary rituals, find ways to work more efficiently, and adopt more flexible, engineer-driven approaches like Shape Up (created by Basecamp) or Kanban (a lean, pull-based system).

They recognize that Agile still works when done right — in small, empowered teams that actually follow the Agile Manifesto rather than the corporate version of Agile.

Can Agile Be Saved?

Agile was never meant to be a rigid process. It was meant to give engineers the flexibility to build great software.

For Agile to be useful again, it must:

• Ditch unnecessary rituals. Stop forcing process for process’s sake.
• Trust engineers. Give them autonomy instead of tracking every move in JIRA.
• Focus on working software, not story points or burndown charts.
• Stop treating Agile as a religion. Use it as a tool, not a doctrine. Servant, not God.

TL;DR: Agile started as a developer’s revolution. Today, it’s a management framework. Until it returns to its roots, engineers will keep doing what they’ve always done: ignoring the nonsense and finding better ways to build software.