This morning, on my way to the train station, I was truly showcasing how well I’ve adopted London culture by ignoring everything and everyone around me with a particular disdain. As I was walking, I thought to myself (as one does—thinking to someone else is not a skill I’ve picked up yet), “If Agile is all that, then why are so many engineers unhappy with it?”

It’s true—a quick Google search for “Is Agile failing?” brings up countless results. If you browse long enough, you’ll find forums created by, or at least frequented by, software engineers venting about how Agile isn’t working for them. They often complain about being swamped with too much work, shifting priorities, and constant pressure. One particular website, Programming Motherf#$ker (NSFW due to strong language), is a prime example of the frustration some folks feel with the methodology.

Let’s dig into why this is the case. But first, let’s quickly glance at the Agile principles.

Agile Principles

I won’t list all the principles of Agile Software Development—you can read them for yourself here. In essence, they boil down to:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

If we simplify further, we get:
A methodology that promotes an indefinitely sustainable software development lifecycle (SDLC).

Sounds great, right? The best part of Agile is that it’s iterative—you’re always trying to improve the process. So, is there an inherent flaw frustrating all these engineers?
Yes. Well, no. But also, yes. Let’s first explore why Agile exists.

Why Agile?

Software development isn’t like building a rocket. When building a rocket to go to the moon, a stakeholder isn’t going to show up during the launch countdown and suddenly change the requirements. (At least, I hope not.) But with software, this kind of scenario happens all the time.

Priorities shift overnight, new work comes in, and existing work becomes obsolete. On top of that, underlying technologies and platforms constantly evolve. Left unchecked, this chaotic environment leads to engineers working late nights and burning out—clearly unsustainable. Agile was created to address this.

Agile isn’t just a project approach—it’s a way of working for teams across new and existing projects.

Agile Implementation

If Agile is supposed to prevent burnout and overwork, why are so many engineers unhappy with it?

In my opinion, the issue lies in how Agile is implemented.

We’ve all heard it: “Agile with a twist.” That “twist” is often the problem.

Agile isn’t meant to be an all-or-nothing approach. It actively promotes iterative improvement to fit what works best for a team. However, problems arise when Agile processes are applied unevenly across teams and stakeholders.

Stakeholders, like everyone else, resist change. But they’re often in a position of power, enabling them to override Agile principles. That “twist” usually involves business stakeholders sitting outside the Agile process, clinging to traditional roles. They demand that everything is a priority and make last-minute changes, justifying it with, “The team is Agile.”

This behaviour undermines the sustainable SDLC that Agile promises. It leads to engineers red-lining from one sprint to the next, burning out, or even resigning. Unsurprisingly, this prompts engineers to complain that Agile isn’t working for them.

So there’s the kicker: It’s not Agile that’s failing—it’s how Agile is being implemented.

Fixing Agile Implementation

The solution is simple: don’t adopt Agile gradually. Slowly introducing it invites resistance and half-hearted implementation. Stakeholders may halt progress when the change becomes too uncomfortable.

Instead, apply Agile universally and decisively- sledgehammer it. Everyone involved—stakeholders, operational teams, and delivery teams—must adopt it simultaneously. After adoption, use retrospectives to improve the process iteratively.

Agile coaches should work with operational and delivery teams alike. If only one side understands the methodology while the other fears it, the system will fail. Take input from everyone to identify what works, what doesn’t, and what could improve.

Conclusion

It’s not Agile itself, but rather its flawed implementation, that frustrates engineering teams and drives them to vent online.

If you need proof that Agile works, look to the companies that have mastered it. Many organisations, likely much larger than yours, have invested heavily in Agile frameworks, iteratively improving while maintaining that sweet, sustainable SDLC.

Further Reading

If you’d like to learn more about Agile, I always like recommending Robert C. Martin’s books, in particular either of these:

Of course, I would be remiss not to mention these two:

The latter do an excellent job describing modern environments in a novel format that makes it easy to follow along.

The above links are Amazon affiliate links. I stand to benefit from any sales.