Why iteration isn't always the answer

Agile project management is everywhere. The idea is simple: Start with something small, iterate, and let the final product emerge organically. The classic metaphor they're using here? You don’t build a car by designing the whole thing upfront — you start with a skateboard, evolve it into a bicycle, then a motorcycle, and eventually, you get your car.

The premise sounds great. You don’t have to know precisely what you’re building at the start, instead, you'll figure it out as you go. Stakeholders will provide feedback, and with each sprint, the product gets closer to something useful.

But here’s the problem: How do you know when you’re done?

The Cracks in the Agile Dream

While Agile solves some of the rigid limitations of traditional waterfall-style project management, it introduces its own problems—problems that more and more teams are noticing. Waterfall’s main flaw is its inflexibility; once the project’s scope, requirements, and timeline are set, any changes later on can be costly and lead to significant delays. Agile addresses this by allowing iterative development and flexibility, enabling teams to adapt as they go. However, this freedom can also lead to ambiguity and a lack of clear direction, which is where Agile itself can fall short.

1. When Are You Done?

Agile emphasises continuous improvement, with teams regularly reviewing progress, gathering feedback, and refining the product in short, iterative cycles known as sprints. This allows teams to adjust the product based on real-time user feedback and changing requirements. However, that often translates to never-ending development cycles. Is a project done when stakeholders stop complaining? When users stop requesting features? When the budget runs dry? The truth is, in an agile environment, “done” is often a moving target, making planning, resource allocation, and even product marketing a nightmare.

2. The Loop Problem: Going in Circles

Stakeholders rarely have a unified vision of what a product should be. They might think they do at first, but as development progresses, priorities shift, new concerns arise, and suddenly, you’re building features you thought were unnecessary two sprints ago. The result? Circular changes. You build a feature, remove it, and then build it again with slight modifications. Each loop burns time and money, but because Agile thrives on “iteration,” teams often fail to recognise when they’re simply spinning their wheels.

3. Do You Even Know What You Built?

A significant problem with modern Agile implementations is the lack of structured documentation. Requirements change mid-project, priorities shift, and no one is tracking why. When the project is finally “done,” teams often struggle to identify the choices that led them there. What infrastructure decisions were made? How did the product evolve? What key learnings were discovered along the way? Without proper documentation, scaling or improving the product in the future becomes incredibly difficult.

Agile’s Real Weakness: Reactionary Increments

Agile was meant to bring flexibility, but in many cases, it has simply created chaos. Instead of solving fundamental issues at the start—like infrastructure limitations, technical constraints, or long-term scalability—teams react to problems as they arise. The result? A reactionary, incremental approach that never truly builds a foundation for long-term success.

Many companies fall into this trap even when they initially had a clearly defined product vision. They run over budget, encounter repeated infrastructure challenges, and—worst of all—end up in cycles of unnecessary changes. Agile doesn’t provide a framework to stop this from happening; it only encourages more iteration.

The Real Solution: Know When to Use Agile (And When Not To)

Agile works well in situations where rapid experimentation is the goal—like testing 10 MVPs and killing off the eight that don’t work. But for projects that require long-term stability, scalability, and well-planned infrastructure, a more structured approach is necessary.

A clear timeline, defined goals, and upfront technical planning are not outdated relics of traditional project management. They are critical tools for avoiding the pitfalls of endless iteration. Because in the real world, a skateboard never turns into a car. It’s either a skateboard, or it’s something else entirely.

It’s time for companies to stop blindly following Agile and start asking: Is iteration really the best approach for this project? Sometimes, the answer is no.