Is Agile really better? Realities from 20 Years in Consulting

Agile has become the go-to methodology for delivering technology projects. Its promises are appealing - faster delivery, more flexibility, and tighter alignment with customer needs. Over the past 20 years in consulting, I’ve seen Agile implemented across countless organizations, industries, and project types. And while I don’t long for a return to waterfall, I’ve come to question whether Agile, as it’s commonly practiced today, is really delivering on its promise.

The short answer? Often, it doesn’t.

---

The illusion of progress

In one project, we were tasked with implementing a standard CRM solution. The software came pre-packaged with well-defined features. Instead of configuring and demonstrating these capabilities quickly, we spent sprint after sprint going through ceremonies to showcase what the software already did out of the box. It was agile in name, but not in spirit. Progress was slow. Decisions were revisited. Teams were bogged down in rituals that added little value.

The irony? A leaner, more structured upfront setup would have served us better. Once the foundation was in place, agile could have been used for what it does best: refining based on feedback, adapting to real-world usage, and iterating where innovation was needed. But the way it was applied here made things more complicated than necessary.

---

The velocity trap

In many agile projects, there’s a troubling pattern: user stories pile up sprint after sprint. More work gets pushed forward than completed. It becomes the norm. And rather than addressing the root cause - misalignment, overcommitment, or lack of clarity - the team adjusts to the dysfunction.

This isn't agility. It's inertia dressed in agile vocabulary. When stories continually move forward without being completed, the team loses focus. Prioritization becomes muddy, morale suffers. These are the moments where leadership needs to step in, not with blame, but with structure and clarity.

---

When metrics fail us

Agile encourages teams to track effort using abstract measurements like story points

instead of hours or days. In theory, this helps focus on complexity rather than time spent. But in practice, many organizations end up running two parallel systems: one based on story points (for show), and one based on person-days (for reality).

This duality creates confusion and waste. Story points become meaningless if everyone still converts them back into hours. Worse, it distracts from what we should be tracking: value delivered. Even more concerning is the absence of a proper value realization stream. Most agile projects lack clear success benchmarks. They might deliver functionality, but can’t say whether that functionality moved the needle for the business. Without defined KPIs or a measurement framework, the whole Agile engine is operating without a speedometer or a map.

---

The contractual disconnect

Agile works best when teams are empowered to adapt. But this flexibility clashes with the way many projects are sold and scoped. Fixed-price contracts don’t account for change. Time-and-materials models are often viewed with skepticism by clients. Agile-specific models, such as pricing based on story points, are still immature and frequently misunderstood. Worse, commercial discussions often bleed into delivery. Teams get dragged into scope debates, budget issues, and contract interpretations, which should be handled separately. Agile teams need room to deliver not negotiate.

---

Structural conflicts

Another challenge I’ve seen is structural: separating development from testing. Agile relies on continuous feedback. If testing is handled by a different team (or even a different vendor) feedback slows to a crawl. Bugs pile up. Trust erodes. Agile can’t function if testing is bolted on as an afterthought. These structural gaps (contractual, organizational, procedural) are often what derail agile at scale.

---

What real agility looks like

Agile is not inherently flawed. When done right, it enables teams to adapt, learn fast, and improve continuously. But to work, it needs:

• Clear boundaries: Don’t use Agile where a traditional approach is faster and more appropriate.

• Discipline: Rituals should support delivery, not become the delivery.

• Measurement: Define what success looks like and how you’ll know if you’re getting there.

• Contractual maturity: Structure agreements that support agility without undermining trust.

• Integrated teams: Testing and quality assurance must be part of the team, not a separate track.

---

Conclusion

Agile can work, but not by default. It’s not a magic wand, nor is it a one-size-fits-all solution. What I’ve learned after two decades in the field is this: true agility is about discipline, clarity, and measurable value.

Everything else is just theatrics.