The cult of Agile: how modern methodologies undermined software engineering

And why PERT, not Scrum, might save it

In the modern software industry, you don’t write a single line of code without someone asking what framework you’re using. Not framework as in React or Django — but work framework. Are you Agile? Kanban? Scrum? Maybe SAFe? Behind these labels lies a deeply entrenched belief: that “how” you organize teams matters more than what they build.

This obsession with process has metastasized. What began as a manifesto for collaboration and iteration has become a bureaucracy of rituals, certifications, and theater — Agile in name, but hollow in purpose.

Meanwhile, buried beneath decades of managerial fluff, lies a system created not for software, but for the most ambitious engineering project in history: the Apollo Program. It’s called PERT (Program Evaluation and Review Technique). It doesn't care about your feelings or standups. It cares about what needs to be done, how long it will take, and how it connects to everything else.

It might be time to bring it back.

The rise and rot of Agile

Agile began with good intentions. The 2001 Agile Manifesto emphasized individuals and interactions over processes and tools, working software over documentation, and customer collaboration over contract negotiation. It was a breath of fresh air for developers suffocating under Waterfall's rigid linearity. But what followed wasn't liberation — it was a new orthodoxy.

Scrum appeared with its sprints, standups, product owners, Scrum masters, backlogs, story points, and velocity charts. Kanban followed with boards full of sticky notes and swimlanes. “Agile coaches” started charging thousands to teach teams how to work. Certifications exploded. Job titles mutated. What was once lightweight became heavyweight. A methodology meant to reduce friction became a performative act.

You now attend meetings about meetings. You estimate story points no one believes in. Your Jira board is your prison. And all the while, actual engineering work — the craft of building reliable, meaningful systems — is deprioritized in favor of "process hygiene."

The tyranny of Scrum

Scrum claims to increase velocity and adaptability. In reality, it often reduces engineering to box-checking.

• Daily standups become ritualistic status updates, not collaboration.

• Sprints are artificially constrained timelines that encourage rushed work and tech debt.

• Sprint reviews reward short-term optics over long-term quality.

• Retrospectives are repetitive, often ignored, and rarely acted upon.

Worst of all, Agile turns engineers into throughput machines. It places project managers and product owners above the builders. The people with the least technical understanding decide priority, tempo, and estimation — often with absurd confidence.

Agile is no longer agile. It’s an industrial conveyor belt for mediocre software. It feeds an illusion of progress through ceremony, not substance.

The forgotten power of PERT

Contrast this with PERT, created by the U.S. Navy in the late 1950s to manage the Polaris missile project and later used during NASA’s Apollo program — a feat of multidisciplinary coordination never matched in complexity.

PERT is not a productivity cult. It’s a logic-driven scheduling technique that maps out all tasks in a project, estimates the optimistic, pessimistic, and most likely durations for each, and calculates the critical path — the sequence of tasks that determines the minimum project duration.

It asks questions that matter:

• What must be done?

• What can be done in parallel?

• Where are the bottlenecks?

• What happens if X is delayed?

PERT diagrams look like flowcharts, not backlogs. They reflect the real structure of a system, not a manager's fantasy of "agility." They emphasize interdependencies, not arbitrary two-week bursts of coding.

During the Apollo Program, teams of engineers from different companies, agencies, and nations were coordinated through systems like PERT. And somehow — without daily standups, sprint reviews, or velocity tracking — they landed humans on the Moon.

Why PERT makes sense today

Despite its age, PERT is timeless — especially for complex, cross-functional projects where deadlines matter and dependencies are non-trivial.

Here’s why it fits modern software development better than Agile:

• Clarity over ritual: No vague roles, no “Scrum Master” gatekeeping. Just tasks and time.

• Risk management: Multiple time estimates help foresee delays and buffer critical paths.

• Scalability: It works for 5-person teams or 5,000-person organizations.

• True planning: It requires actual thinking, not gut-feel estimation games.

Most importantly, PERT doesn’t pretend to be magic. It doesn’t offer “velocity.” It offers visibility. And in an industry plagued by missed deadlines, mounting technical debt, and micromanagement, visibility is everything.

Engineering vs. Consulting

Agile today feels less like engineering and more like consulting ideology. It’s no accident that the Agile industrial complex mirrors the world of management consulting — full of buzzwords, certifications, and vague value propositions.

But real engineers — the kind that send rockets into space, build medical systems, or secure infrastructure — don’t work that way. They plan. They use math. They map dependencies, not feelings. They don’t pivot every two weeks.

Software development should return to its engineering roots. Not blindly apply factory models or waterfall thinking, but adopt tools like PERT that reflect the reality of building complex systems.

Dismantling the dogma

Agile isn’t evil. It’s just overrated. It promised to fix the rigidity of Waterfall and ended up building a new rigidity — one made of post-its and platitudes. If you're a developer or manager tired of the noise, ask yourself: is this process serving the product, or is the product serving the process?

Maybe it’s time to resurrect an old ally. PERT isn’t hip. It’s not in your HR handbook.
But it got us to the Moon. That’s more than any daily standup can say.