I am not anti-agile. I have been on projects where it was clearly the right way to work, and the value it added was obvious. But I have also watched the same set of rituals get run long past the point where they did anything useful, purely out of habit, and that is the part worth talking about. The challenge with agile is not the method. It is knowing which phase of a project you are actually in.
Where agile genuinely works
In the early phase of a project, especially one with several parties involved, agile is great. This is the phase where nobody fully knows the shape of the thing yet. The client has goals but not specifics, the designers are still exploring, the developers are surfacing constraints nobody anticipated, and everyone needs to stay aligned while the picture comes into focus.
That is exactly the situation agile was built for. Short cycles, frequent check-ins, and the ability to course-correct quickly are real advantages when the uncertainty is high and the number of people who need to agree is large. The ceremonies that feel like overhead later are doing actual work here. They are keeping multiple parties pointed in the same direction while the direction itself is still being decided.
If I am starting a multi-party project, I want that cadence. It is the cheapest way to catch a misalignment before it becomes three weeks of wasted work.
Where it stops paying off
The problem is that projects do not stay in that phase. Once the core product is produced, the work changes character. Now you are adding features and maintaining what exists. The big questions have been answered. The shape is known. The uncertainty that justified all the coordination has largely gone.
And this is where agile quietly loses its value, because the ceremony stays exactly as heavy as it was, while the thing it was solving has mostly disappeared. You are still running the same standups, the same planning, the same rituals, but you are now applying a process designed for high-uncertainty alignment to a phase that is mostly steady, incremental work. The overhead is unchanged. The payoff is not.
That mismatch is the real frustration. It is not that agile is broken. It is that the same process gets run across two phases that have completely different needs, because switching it off feels like admitting something failed, or simply because nobody stops to ask whether the rituals are still earning their keep.
Match the process to the phase
The honest takeaway is that agile is a tool for a specific condition, not a permanent operating system. The condition is uncertainty plus multiple stakeholders who need to stay aligned. When that condition is present, lean into it. The coordination is worth every minute.
When that condition fades, when the core is built and the work becomes features and maintenance, the responsible move is to lighten the process to match. Less ceremony, more flow. Not because agile was wrong, but because the project moved on and the process should move with it.
The teams that struggle with agile are usually not struggling with agile itself. They are running early-phase rituals on a late-phase project and wondering why it all feels like overhead. It feels like overhead because, in that phase, it is. The skill is recognising the moment the project crosses that line, and being willing to change how you work when it does.
