Why Agile May Not Be Your Solution: Demystifying Common Pitfalls

Project Delivery Assurance Services

My recent meeting with the senior leadership of a prospective employer last Friday was unexpectedly invigorating. We found common ground on the prevalent misunderstanding of Agile methodologies and their appropriate application. This has motivated me to compose a short article to express my views.

Did you know that 90% of executives believe Agile methodologies are crucial to their organisation’s success today, with 85% believing that importance will only grow (@Deloitte). Sounds good, right?

In theory, maybe. In the real world, the answer is more complex.

I’ve directly managed some very large projects and supported some of the largest capital projects imaginable; mega-facilities, pipelines spanning continents… the kind of projects that make the news. Yet, sometimes it’s the trendy buzzwords that throw projects into the most disarray. In my opinion, ‘Agile’ is one of them.

Don’t get me wrong—Agile has its place (and it is incredibly useful). But, like that shiny new drill bit, it’s the wrong tool for some jobs. Blindly applying it to the complex world of project delivery can backfire, causing more chaos than it solves. So, before you start drawing those iterative flowcharts, let’s get real about why Agile might just send your project off the rails.

The Agile-Rigidity Paradox

Seems ironic, doesn’t it? Agile is meant to be… well, agile. But with major infrastructure or energy sector projects (or any type of major project), change comes at a steep price. Early in a project, a seemingly minor tweak can trigger a cascade of expensive impacts. Procurement timelines, regulatory hurdles, fabrication schedules—it’s about more than moving a sticky note on a board.

The ‘inspect and adapt’ of Agile sounds great, but it assumes a level of flexibility that simply doesn’t exist once you’re pouring concrete or laying pipe. Agile can become its own anchor, especially if client expectations haven’t been carefully managed at the outset.

When the ‘Why’ Gets Lost

In my experience, some of the biggest project derailments happen because teams lose sight of why they’re doing things. Agile, with its focus on tasks and sprints, can inadvertently fuel that. Now, don’t get me wrong; execution is key. But teams get bogged down in the minutiae, forgetting the big picture or the ultimate value they’re delivering to a client.

Agile teams can become like those drill crews you see in movies, that keep going after hitting bedrock, burning budgets because no one stops to reassess the original plan.

The Illusion of Simplicity

Here’s why Agile can be deceptively dangerous: it seems easy. But true agility, especially within the constraints of a multi-billion-dollar project, requires a level of discipline and foresight that goes far beyond what’s in a textbook. Here’s what I often see go wrong:

• Undefined roles: Agile blurs the lines, and in a high-stakes project setting, unclear accountability is a recipe for disaster.
• Scope creep: Those ‘quick iterations’ become never-ending loops in projects where scope needs to be locked down early.
• Communication breakdowns: Agile replaces robust reporting with daily stand-ups, risking key stakeholders feeling out of the loop.

When Agile Works (And When It Doesn’t)

Let me be clear: I’m not saying Agile is inherently bad. It has its value, especially in the front-end design phases, where iteration is key, or in managing specific deliverables within a larger, traditional project. But here’s what dictates its success or failure:

1. Honest assessment of fit – Is your project heavily reliant on predictable timelines and long lead times? If so, Agile might be a square peg for a round hole.
2. Leadership with backbone – Agile demands strong sponsors to shield teams from external changes, and to enforce decisions when needed.
3. Communication that adapts – Transparency is key, Agile or not. Reporting must evolve to suit the methodology, keeping all stakeholders informed.

Basically, whether or not Agile ‘works’ all comes down to context. The main point I’m trying to drive home is that a methodology that thrives when iterating design concepts can really stumble when those concepts become unchangeable physical infrastructure.

Key Takeaways for Leadership

Don’t be seduced by buzzwords. Your choice of methodology should be based on a rigorous analysis of your project’s specific needs, not what’s trending.

• Hybrid approaches are valid: Agile elements can be successful within a larger Waterfall framework, if applied strategically.
• Set your team up for success: Agile without adequate training or change management will fail, regardless of good intentions.
• Remember the big picture: No methodology should replace a shared vision of the ultimate project outcome.

The biggest takeaway I want readers to get from this is pretty straightforward → The next time you’re getting pitched on Agile, ask the hard questions and demand specific examples of how it will work for your unique project.

What do you think? Are you all in on Agile or do you take a more nuanced approach? Let me know below ??

#agile #projectmanagement #projectdelivery