Post-agile describes the period and mindset that follows the point where “agile” lost its shared meaning and became too vague to guide organizations. The original Agile Manifesto applied only to software development teams, not to whole companies. What works now is organizational development tailored to each company’s actual stage, drawing selectively from fast iterations, real customer feedback, and proven decision-making models.
Key Takeaways
- The Agile Manifesto is a manifesto for agile software development only, not for agile management or organizational leadership, yet companies applied it as if it covered all of those.
- Applying a fixed framework like SAFe pushes differentiation-phase companies deeper into rigid role structures rather than helping them adapt, because it copies organizational blueprints instead of developing fitting solutions.
- Fast iterations and genuine customer feedback are practices from the agile era that still hold value, but most organizations claiming to run agile no longer collect real feedback because they delay rollout.
- Arguing with management about dysfunction triggers automatic defensiveness, and the more a position is defended, the more the defender believes it, making direct argument counterproductive.
Why “Agile is dead” became the slogan of the moment
“Agile is dead” turned into the go-to phrase around 2024, and the reason is structural, not fashionable. The word has lost its power to distinguish anything.
Michael Mahlberg compares the fate of “agile” to the word “modern.” There was a time when “modern” pointed to specific painters and specific architects. Today, if you say you have a modern house, people ask about your home automation, not whether Mies van der Rohe designed it. “Agile” went the same way. It now means little more than “new.”
For large corporate clients, the term has gone further than empty. It actively hurts. In companies with several thousand people, “agile” puts strain on people and makes them unhappy, so it is a word to avoid. From that angle, the death of the word is something Michael welcomes.
The agile industrial complex pulled the idea off course
Market forces, not malice, hollowed out agile. Michael points to Martin Fowler’s earlier observation that an agile industrial complex tried to absorb the idea, and the takeover happened without anyone deciding to subvert anything.
A lot of consultancies have stepped back from the field. Big firms gave their agile employees room to develop their careers elsewhere. There was a wave of layoffs in the United States, and it has since reached Europe.
The damage came from overreach. Companies packed everything under the agile umbrella: design thinking, retrospectives, sprints, planning, all at once. People ended up overwhelmed and frustrated, and the umbrella lost any grip on what it was supposed to hold.
There is no agile manifesto, only one for software development
A point that irritates many people: there is no agile manifesto. What exists is the Manifesto for Agile Software Development.
It is not a manifesto for agile management. It is not a manifesto for running a company. It says almost nothing about organizational scope, yet it gets stretched to cover all of it. That stretch is where the trouble starts.
On the question of improvement, the manifesto carries one sentence. The twelfth principle says that at regular intervals the team reflects on how to become more effective and adjusts accordingly. That works for a team of five or seven. It is thin guidance for an organization of thousands.
What post-agile actually means
Post-agile is not a new method. It is a position in time, and two people gave the term weight.
David J. Anderson, from the Kanban method, used it back in 2010. His framing is logical: the manifesto’s authors described their observations at a point in time. Anything that came afterward could not influence the manifesto, so by definition it is post-agile.
Alistair Cockburn, one of the signatories and the person who invited people to the conference where the manifesto was written, has used the term as well. The line he draws runs modern, postmodern, post-agile, because the original word no longer carries meaning.
What replaces it is less branded and more demanding: organizational development, and solutions that fit a specific company rather than a poster bought off the shelf.
Why agile collides with how big companies are built
Large organizations sit in a development stage where strict structure is the whole point, and agile does not fit it. The model comes from Friedrich Glasl, who described three stages a company moves through: a pioneer phase, a differentiation phase, and an integration phase.
You cannot skip a stage. Each one informs the next. There is no differentiation without a pioneer phase before it.
Most big companies are stuck in the differentiation phase. Roles are defined precisely, there are manuals for everything, and who does what is spelled out. That clarity is the opposite of how agile teams are meant to work.
This explains why scaled frameworks land so easily in corporations. When you show a several-thousand-person company a large framework poster, it slots neatly into their world, because it pushes them deeper into differentiation where everything is specified. The fit is real, but it pulls in the wrong direction.
Copy-paste blueprints do not transform organizations
A framework poster looks like a fast solution. You pay for it and you appear to own the answer. That is the trap.
Every individual element on a scaled framework can be sound. The problem is the move of taking the entire blueprint and declaring “this is your company, take it.” Copy and paste does not produce a working organization, and the bad name agile earned over the last years grew straight out of that habit.
The alternative is harder. It means applying organizational development methods and finding what fits a particular company. Some of what the field learned over the past 25 years belongs in that picture, but as material to draw from, not as a starting template.
Don’t lean on one manifesto sentence when a body of knowledge exists
If you want to improve how an organization works, there is far more to draw on than the manifesto’s single principle on reflection.
Peter Senge’s The Fifth Discipline describes learning organizations. Lean, in the original Toyota Production System sense as Taiichi Ohno proposed it, gives a full account of how to improve iteratively while the work is running. Michael draws a deliberate line here: the original TPS, not the later Womack and Jones translation.
The point is simple. One sentence about reflection is a weak foundation when a whole literature on continuous improvement is available.
How to lead a stuck organization back to working
Start by taking a big step back, and make sure top management is not the only group taking it. In a hierarchical company, the core processes are spread very unevenly across the levels. One of them is the process by which an organization forms an opinion of itself. Reorientation needs that process to involve everyone, even though top management has to initiate it.
This work costs time, not consultant fees. The consultants mostly do not do much. What people need is room, in time and in physical space, to talk honestly about the situation and to reorient.
The harder obstacle is fatigue. Organizations that spent ten or twenty years moving into agile now have to admit it was not the right path and change direction again. People are tired of change, and asking them to switch once more is not easy.
Why most companies will not change yet
Change starts with a genuine sense of urgency, and most companies do not have one. Michael leans on Kotter’s eight-step change model here, where urgency comes first.
The urgency has to be real. Ducking someone underwater creates the feeling of urgency, but it is play. Being five miles out at sea with no boat is real urgency. Manufacturing a sense of danger that does not exist does not move an organization.
Many companies are simply too comfortable. They still earn well, the machine works, and a certain number of burnouts per year is treated as normal. With no felt need, there is no change.
Michael’s own company frames its work around this: helping organizations be able to work again after an agile transformation. By his rough sense, only about ten percent of companies feel that need acutely. Another third have people who suffer, but the suffering has not yet registered in the system. And in many places, agile in name only works fine, so why touch it.
The companies that truly struggle with what happened under the agile label have an opening. They no longer want the burned terminology, which frees them to find what they actually need.
How an individual can move the topic upward
If you are a tester, developer, or architect who sees the problem, arguing your way up the hierarchy will not work. Let managers experience what you experience instead.
The moment you tell a manager “this is bad and it does not work for us,” a reflex kicks in. They go into defense. And once someone has defended a position often enough, they start to believe their own defense, which only makes the position harder to shift.
After you have defended a point often enough, you start to believe the defense. — Michael Mahlberg
Pull them into your situation instead. Ask for help with the things that do not work. When they start to feel it, you can drop in small pebbles of information: task loading, task switching, the gap between the defined process and what the team actually does. From there, look beyond agile resources into organizational development, especially systemic and system-theory material. The pointers are there.
Which agile practices still earn their place
Some practices hold up almost everywhere, and the clearest is fast iteration with real feedback. Many organizations that call themselves agile lost the real part. They build iteration on iteration and release only after some longer stretch, which is rarely the smallest possible amount of time. Without delivery to the customer, the feedback is not real.
Other elements of the original manifesto remain useful for teams, though they were never instructions for running an organization.
For organizational questions, better answers often sit outside the agile world entirely. If you want a sound way to make decisions, look at sociocracy, but extract the decision-making parts rather than adopting the whole. That practice predates agile by more than a century.
What scaled frameworks get right, and where the trap sits
Scaled frameworks contain genuinely good ideas, and the people behind them are skilled at picking strong material. Release trains make sense if you build software in a certain kind of environment. Portfolio Kanban is one of the better ways to get the workload in a huge company under control.
There is a full-circle irony worth knowing. The conference that produced the manifesto was called a conference on lightweight methods, and one stated goal was to give RUP enthusiasts, users of the Rational Unified Process, compelling reasons to switch. Dean Leffingwell helped write parts of the RUP book. Dean Leffingwell is also the person behind SAFe.
So the brand sold today as agile is heavily shaped by the same person who once promoted the very heavyweight process the manifesto pushed against. The pieces can be good. The packaging is the problem.
The advice that follows is practical. If you want portfolio Kanban, you can take it from a framework, or you can look at Klaus Leopold’s flight levels model, which may offer a more fitting solution. The fixed-role part of SAFe is where Michael has yet to see a company find it genuinely helpful.
