Every so often, capitalism seems to need a new innovation to hype up, selling it as a miracle cure for all of humanity’s problems in order to keep its own frantic, seemingly unstoppable growth going. This happens regularly in the tech world — a few years ago it was blockchain, now it’s artificial intelligence, and so on — but management trends are no different.
Over the past two decades, few ideas have been marketed with the same evangelical zeal as Agile project management. At some point, “going Agile” stopped being presented as one possible way of organizing work and started being sold as the enlightened alternative to everything that came before it: faster, smarter, more humane, more adaptive, more collaborative, more innovative. In short, not just a methodology, but a moral upgrade.
And like all management orthodoxies at the height of their popularity, Agile has gradually acquired the kind of aura that makes serious criticism sound almost impolite. If a project is failing, the problem is not the budget, the strategy, the leadership, the contradictory requirements, the absurd deadlines, the chronic under-staffing, or the general confusion of the organization. No, the team simply wasn’t Agile enough. They didn’t do stand-ups properly. They didn’t estimate correctly. They didn’t embrace iteration deeply enough. They didn’t believe.
This is usually the point where methodology turns into superstition.
To be fair, Agile began as a reasonable reaction to a real problem. Rigid planning, excessive documentation, and top-down decision-making often produced exactly what they were supposed to prevent: slow delivery, brittle systems, and teams disconnected from reality. In contexts where requirements change quickly and uncertainty is unavoidable, shorter feedback loops and incremental delivery make a great deal of sense. No mystery there. The problem begins when a useful set of practices is inflated into a universal doctrine.
Because that is what often happens in organizations: a pragmatic toolkit becomes a worldview, and a worldview becomes an excuse.
Agile does not fix poor leadership. It does not magically clarify contradictory priorities. It does not compensate for a lack of domain knowledge, or for the inability of stakeholders to make decisions, or for the habit of executives to demand flexibility while simultaneously imposing immovable deadlines and non-negotiable scopes. It certainly does not create trust in environments where people are punished for mistakes, kept in the dark, or treated as interchangeable resources in a PowerPoint slide.
And yet Agile is constantly asked to perform precisely these miracles.
A team can hold daily stand-ups and still have no real alignment. It can work in sprints and still chase arbitrary deadlines. It can produce immaculate backlogs while remaining strategically lost. It can worship velocity and burn itself out with impressive efficiency. None of this is rare. In fact, it is common enough that one begins to suspect the real product being sold is not effectiveness, but reassurance: the comforting feeling that, because a process exists and everyone has learned the vocabulary, management is somehow happening.
This is one of the less charming habits of contemporary organizations: replacing thought with ritual.
Ceremonies multiply. Roles proliferate. Boards, tickets, retrospectives, planning sessions, refinements, reviews — the whole liturgy of productivity unfolds with solemn regularity. But in many cases, the deeper issues remain untouched. Who has decision-making authority? Is the team adequately staffed? Are priorities stable for longer than forty-eight hours? Is technical debt being addressed or merely renamed? Are people collaborating meaningfully, or just reporting to one another more frequently? These are management questions, not methodological details, and no framework can answer them on behalf of people who would rather avoid them.
This is why Agile so often ends up functioning as a kind of organizational theater. It offers the appearance of responsiveness without necessarily producing it. It allows managers to say that change is being embraced while still preserving the habits that make genuine adaptation impossible. Teams are told to self-organize, but not too much. They are encouraged to experiment, but not in ways that might affect quarterly targets. They are invited to be autonomous, provided they continue to deliver exactly what was decided elsewhere.
Under these conditions, Agile becomes what many fashionable management ideas eventually become: a language for describing dysfunction in a more upbeat tone.
One might also see the proliferation of Agile ceremony as a response to a quieter social change: many of those who have entered the workforce in recent decades have been shaped by a society that offers less room for genuine autonomy, normalizes continuous supervision, and leaves people less accustomed to exercising independent judgment. That is not a moral failing, still less a generational indictment; it is simply what one would expect from a culture marked by precarity, over-monitoring, and the steady erosion of unstructured responsibility. In that light, the endless sequence of stand-ups, check-ins, retrospectives, and alignment sessions can look less like a triumph of enlightened collaboration than like an adaptation to reduced self-reliance — a way of making the team permanently available as a source of operational direction and psychological reinforcement. Entirely understandable, perhaps, but rather less profound than the evangelists of Agile ritual would have us believe.
Moreover, there is, of course, an entire cottage industry that has flourished around this confusion: consultants, coaches, evangelists, and certified prophets of agility who have done remarkably well by presenting fairly ordinary managerial common sense as if it were esoteric wisdom. For a generous fee, they will explain that teams should communicate more, adapt to change, and deliver work incrementally — insights so revolutionary that they apparently require workshops, certifications, branded canvases, and a small liturgy of acronyms to be properly understood. One cannot help but admire the business model: take problems largely created by managerial incompetence, rename them in Agile vocabulary, and then invoice handsomely for the translation.
There is also a deeper irony here. Agile, at least in its better moments, was supposed to bring work closer to reality — closer to uncertainty, feedback, learning, and human collaboration. But once institutionalized, it often drifts in the opposite direction. It becomes abstract, procedural, and bureaucratic in its own special way. The old command-and-control model does not disappear; it simply learns new words. Deadlines become “commitments.” Orders become “prioritized user stories.” Micromanagement becomes “tracking progress.” And the result is the same old managerial anxiety wrapped in friendlier terminology.
None of this means Agile is useless. It means it is limited — which is a very different thing. Used intelligently, Agile practices can be valuable. They can help teams reduce waste, surface problems earlier, collaborate more frequently, and deliver work in a more incremental and transparent way. But these benefits only appear when the surrounding conditions allow them to. A healthy methodology cannot thrive inside an unhealthy organization.
This should be obvious, and yet it is curiously difficult for many companies to admit. It is much easier to buy a framework than to confront structural incompetence. It is easier to appoint Agile coaches than to address incoherent governance. Easier to reorganize teams into squads and tribes than to ask whether leadership has any real understanding of the work being done. Easier, in short, to rebrand management than to improve it.
And that, perhaps, is the central misunderstanding. Agile is not a cure for bad management. It is not a substitute for strategy, clarity, trust, competence, or responsibility. It cannot rescue an organization from its own confusion. At best, it can make that confusion more visible, more quickly. Which is useful — but only if someone is willing to look.
The real challenge, then, is less glamorous and far less marketable than the consulting industry would like. Managing projects well requires judgment. It requires trade-offs, honest communication, realistic planning, technical literacy, and the maturity to accept that uncertainty cannot be eliminated by renaming meetings. It requires leaders who can make decisions and teams that are trusted enough to carry them out. No manifesto, however elegantly phrased, can do that work for us.
So yes, by all means, use Agile if it fits the context. Borrow what is useful. Discard what is not. Adapt practices to reality rather than forcing reality to bow to a framework. But let us stop pretending that the latest management doctrine — however polished, certified, or branded — is a magic wand. It isn’t. It never was.
What it can be, on a good day, is a set of decent habits.
And decent habits, while undeniably helpful, are not the same thing as wisdom.
