For several years now, a rumor has been going around: Agile is dead. Executives announce it in governance meetings. Articles declare it obsolete in the face of today’s economic crises. Companies cut their investment in Agile transformation, let go of their coaches (or Scrum Masters), and return to “more traditional, more serious” models. As far as they are concerned, Agile did not hold up against real challenges. Except that the numbers tell a very different story.
In 2023, 60% of organizations that had adopted Agile increased their revenue and profits. Agile teams are 25% more productive and bring products to market 50% faster (Delta Matrix study, 2023). Even more striking: according to a recent World Economic Forum report on the future of jobs (2025), 61% of organizations plan to adopt or strengthen Agile practices over the next two years. Agile is not disappearing. It is even spreading beyond IT: into manufacturing, industry, human resources and strategy. People now talk about “Business Agility,” which covers every function of the company.
So why do people say Agile is dead? Why is there such a gap between adoption data and the feeling of failure?
The answer may have less to do with the method itself than with what happens when an organization genuinely tries to apply it. And above all, with what gets triggered inside the organization and prevents it from doing so.
Has AI killed Agile?
There is a new rumor, even more recent: with AI, Agile no longer really has a reason to exist.
The argument sounds appealing: with generative AI, we can now predict a great deal. We can anticipate bugs, generate code faster, automate repetitive tasks. Isn’t this a return to predictability? Do we still need to iterate when AI models can give us answers so quickly?
This is a misconception. And it reveals precisely why Agile will not disappear: complexity keeps increasing.
AI does not make the future more predictable. It makes it more complex. Yes, AI can produce a prototype in a day instead of a week. But that speeds up the need for iteration rather than removing it. Because AI can also produce something that looks perfect on paper but fails completely with real users. Or that introduces subtle biases. Or that opens security holes.
The massive arrival of AI in organizations actually increases the need for Agile. Why? Because no organization really knows how AI will affect its processes. No AI model is stable in the long run (they degrade, require retraining, reveal unexpected behaviors). And above all, AI creates constant pressure to adapt.
What we actually see in 2025 is that organizations adopting AI without real agility end up with the worst of both worlds: the speed of a machine and the decisions of a frozen hierarchy. They produce solutions quickly, but those solutions do not really match needs. They accelerate in the wrong direction. Conversely, the rare organizations that combine AI with “genuine agility” create something powerful: the ability to generate quickly, iterate often, learn fast and adjust. So no, AI has not killed Agile. AI has made it indispensable.
I. The apparent failure of Agile: how did we get here?
Look through testimonials and company cases from 2024–2025 and you will find a recurring, almost identical pattern.
A large organization decides to go Agile. It hires a well-known consulting firm. Teams are trained. Tools are rolled out (Jira, Azure DevOps, whatever). Scrum Masters are appointed. Sprints, daily stand-ups and retrospectives are set up. The Agile ceremonies take hold. For a few months, there is energy and engagement. Then, gradually, something starts to crack.
Sprints turn into reporting sessions where everyone justifies their week’s work. Retrospectives go around in circles: problems are listed, but nothing really changes. Teams apply the method and follow the rituals, but the spirit is gone. They do Agile without being agile. And after two years, sometimes three, an executive declares: “Agile doesn’t work here. It’s too slow. We’re going back to something more structured.” These organizations are not lying. They sincerely feel that Agile did not work. But what they applied was not really Agile.
What they applied was a method stripped of its essence. An Agile shell filled with very traditional content.
The distinction matters. There is a difference between knowing Agile practices and adopting the Agile mindset. Many consultants master the former. Few organizations are ready for the latter. And that is exactly where the problem lies: it is not that Agile doesn’t work. It is that organizations defend themselves against it without even realizing it.
Signs of poor implementation
Spotting fake agility is easy once you know what to look for. Here are the most common signals:
-
First, rituals without autonomy. Teams hold daily stand-ups, but no decisions are made at that level. Everything goes up to the manager who was already there before Agile. Dailies become reports to the hierarchy rather than moments of self-organization. This is even more true of retrospectives.
-
Second, backlogs managed as to-do lists. Instead of the team asking “what really creates value?”, client requests are listed, handled in order, and sprints are closed. No reconsideration. No questioning of what truly matters.
-
Third, superficial retrospectives. Problems are identified (often the same ones), but the systemic causes—the organizational patterns that create them—are never raised. Problems that threaten the status quo stay quietly buried.
-
Fourth, the absence of experimentation. Agile is supposed to enable fast learning through iteration. But when a team is asked to try something new and it fails, the message is clear: “We don’t have time for experiments. Stick with what works.” The right to fail, fundamental to Agile, disappears.
-
Finally, closeness to the customer weakens. Instead of teams talking directly and continuously with users, requests go through a Product Owner who in turn depends on management. Feedback becomes indirect, filtered and slow.
All of this looks Agile. The walls are covered in pink and yellow sticky notes. Burndown charts are on display. People talk about iteration and feedback. But the core of the system has not moved an inch: decision-making remains centralized, control remains tight, and collective learning remains taboo.
And that is when the organization concludes: “Agile isn’t right for us.”
II. The real diagnosis: Agile exposes organizations’ defenses
To understand why so many Agile adoptions remain superficial, we need to ask the uncomfortable question: what does Agile really threaten in an organization? Not operational efficiency. Not sprint discipline or backlog size. Something much deeper. Genuine Agile confronts the organization with an existential question: “Are we ready to question our ways of working, our hierarchies, our habits? Are we ready to give teams real power? Are we ready to accept that we don’t know, and that we must learn together?”
These questions are unsettling. Not because people are resistant by nature (that cliché is inaccurate). They are unsettling because they threaten psychological safety systems deeply rooted in organizations.
Organizations, like people, build defenses. These defenses are not pathological. They serve a purpose. They allow the organization to maintain order, stability and certainty. They reassure. They make the world predictable. They protect established roles, statuses and power. (See Chris Argyris’s book Knowledge for Action: A Guide to Overcoming Barriers to Organizational Change.)
But Agile is a practice built precisely on accepting uncertainty, the right to fail, experimentation and continuous questioning. It asks organizations to live in a permanent state of unfreezing, to borrow the vocabulary of social psychologist Kurt Lewin. And that, fundamentally, creates anxiety.
When an organization detects this threat, it does not consciously say: “No, we’d rather stay rigid and inefficient.” Instead it says: “Let’s adopt Agile best practices, but in a way that doesn’t destabilize anything fundamental.” And that is where unconscious sabotage begins.
Agile requires “double-loop” questioning
To grasp why this sabotage is almost inevitable without real work on mindset, we need to understand a distinction that organizational theorist Chris Argyris set out clearly: the difference between “single-loop” and “double-loop” learning.
- Single-loop learning means improving what we already do: running a process faster, using a better tool, optimizing the task. We stay within the same frame of reference. We ask: “How can we do this more efficiently?”
- Double-loop learning means questioning the frame itself: “Why are we doing this? What assumptions underpin our decisions? Do our unspoken rules still serve us? What is the real problem we are trying to solve?” We step outside the frame of reference and challenge it. Genuine Agile requires double-loop learning. It is not a better way of doing what we did before. It is a question about what we should be doing, and why.
Yet organizations naturally resist double-loop learning. Not out of ill will, but because this kind of learning is uncomfortable. It creates a gray zone where nothing is certain. It requires giving up certain beliefs. And giving them up carries a psychological cost.
So here is what happens: organizations adopt the forms of Agile (single loop: let’s learn to do Scrum better), but avoid its essence (double loop: let’s question how and why we organize work).
Once this workaround is in place, frustration builds up. Teams see that self-organization is talked about, but no real autonomy is granted. Continuous feedback is talked about, but the real problems are never addressed. Innovation is requested, but experimentation fails as soon as it leaves the authorized zone. After a while, everyone gives up. And the executive concludes: “Agile didn’t work.”
Defensive routines: how organizations sabotage themselves
Argyris uses a precise concept to describe these mechanisms: “defensive routines.” These are actions, practices and unspoken rules that allow people to avoid embarrassing situations. But they have an unintended consequence: they prevent honest discussion and the resolution of real problems.
Here is what this looks like in practice in pseudo-Agile:
During a retrospective, someone says: “I feel we don’t have enough autonomy to make decisions.” Everyone knows it’s true. But there is a defensive routine at work: don’t openly criticize the structure. So the answer is: “Yes, but someone has to sign off for quality.” Or: “True, but we don’t have the budget for that.” A rhetorical band-aid is applied. And the meeting moves on.
The real problem, which is systemic, is never named: “We have built an organization where control outweighs trust, and Agile requires the opposite.” That sentence will never be spoken, because it would expose people to the risk of being seen as critical of management, or as inexperienced.
Result: the retrospective took place. But nothing changes.
Over time, everyone understands the implicit message: “We can talk about change, but in reality we will never tackle the questions that threaten the established order.” At that point, Agile is no longer a way of working. It is a simulation. And the simulation eventually collapses.
Unconscious mechanisms: anxiety as an organizing force
We need to go further still. Defensive routines are not just choices. They are triggered by something deeper: organizational anxiety. Social scientist Elliott Jaques put it this way: “Social systems, even apparently rational ones, often function as defenses against anxiety.” In other words, hierarchical structures, rules, processes and rituals are not only there to be efficient. They are also there to contain anxiety. They create a predictable space where everyone knows their place, their responsibilities and what is expected of them. That is reassuring.
When an organization operates within such a system, the structure itself acts as an anxiety reliever. It keeps people in a state of psychological balance. Then Agile arrives and says: “From now on, you will self-organize. You will experiment. You will accept uncertainty. You will question your ways of working.”
This is not a technical problem. It is an attack on the defensive system itself. The anxiety that the structure was containing resurfaces. And faced with that anxiety, the organization reacts entirely unconsciously. It does not say: “I’m afraid, so I’m going to sabotage.” It says instead: “We’ll do Agile, but in a reasonable, structured, safe way.” And without knowing it, it empties Agile of its meaning.
This automatic response is a normal, universal phenomenon. Kurt Lewin called it “unfreezing”: the moment when the old structure breaks down and anxiety rises. It is an unavoidable phase of change. But many find it unbearable. And rather than going through it consciously, the organization unconsciously tries to push it away. Hence pseudo-Agile. What is crucial to understand is that this reaction is not caused by bad faith or stupidity. It is a psychological reaction of self-preservation. And as long as it remains unconscious, it will keep undermining adoption efforts.
That is precisely why so many Agile projects fail.
People are trained in Scrum. They are given tools. Processes are changed. But no one ever works on what is really blocking things: fear. And without confronting that fear consciously, the old protective mechanisms will keep operating, silently, until pseudo-Agile implodes.
III. The four psychological defenses that sabotage Agile
We now know why organizations defend themselves against Agile: it threatens the psychological system that has contained them until now. But this defense is not uniform. It operates on several levels, triggering different psychological mechanisms depending on the context.
Understanding these four levels helps diagnose exactly where an Agile effort has stalled.
1) The existential anxiety defense
This is the most basic and most universal level. Every person in the organization feels anxiety in the face of the unknown. Agile asks people to accept uncertainty, iteration and trial and error. For someone who has spent ten years working in a predictable, hierarchical system, this request triggers real anxiety.
That anxiety does not disappear because of a Scrum training course. It persists. And it causes unconscious regression: people try to rebuild predictability in a new form. Hence sprints that become small waterfall cycles. Hence daily stand-ups that become status reports. Hence retrospectives that go around in circles: problems are listed without ever touching the structure.
The psychological mechanism is simple: the anxiety is unbearable, so it is fought by turning Agile into something that resembles the old order. It is a form of escape. And it works, temporarily. Pseudo-Agile offers a sense of safety: you have the forms of Agile (so you can say you have adopted it), but the content stays familiar.
2) The identity and status defense
Here the mechanism is different. It is not just anxiety about the unknown. It is a threat to professional identity and status.
Take a traditional manager. Their role has been to make decisions, control and approve. Their status came from that. When Agile arrives and says “teams will self-organize, decisions will be distributed,” this manager hears: “Your role no longer exists.” It is an existential threat to their professional identity.
But the manager will not say: “No, I don’t want to lose my power.” They will say: “We’ll do Agile, of course. But with governance, approvals and checkpoints.” And gradually, they will rebuild the old control mechanisms, this time disguised in Agile language. Or take a technical expert. Their identity came from specialized knowledge. Agile values collaboration, versatility and mutual learning. For this expert, it dilutes what made them unique. Their defense? Positioning themselves as the “guardian of quality” and blocking experiments that could affect their domain.
This level of defense is particularly powerful because it is legitimate. Everyone needs a stable professional identity. But when that identity is threatened, the person will unconsciously protect the status quo while saying they support change.
3) The collective defense (group norms)
Kurt Lewin showed it: to change an individual, you have to change the group’s norms. Why? Because groups function as entities. They have their own life, their own unspoken rules, their own cohesion.
When an organization adopts Agile, it upends group norms. For example, an implicit norm was: “We don’t publicly criticize decisions from above.” Agile says: “Say what you really think. Challenge assumptions.” That violates the established norm. But people will unconsciously resist, because respecting the norm is what keeps them part of the group. Breaking it means risking rejection. So even if someone agrees with Agile intellectually, emotionally they will hesitate to truly expose themselves. And the group, collectively, will exert silent pressure to maintain the old norms.
Result: in retrospectives, people will talk about change. But no one will dare actually propose it. And no one will dare actually criticize it. The group stays united in its inertia.
4) The informational defense (defensive routines)
This is the most sophisticated level, and perhaps the most destructive, because it hides behind an appearance of rationality.
Argyris calls these “defensive routines”: communication patterns that make it possible to avoid the real questions. For example: “Yes, it’s true we don’t have enough autonomy, but we have other priorities right now.” Or: “The problem isn’t our structure, it’s that we haven’t fully understood Scrum yet.” These routines let everyone carry on without confrontation. But they come at a cost: no one ever learns. Real problems are never named. So they are never solved.
This defense operates mainly at the organizational level, not the individual level. It is not that one person refuses the truth. It is that the organization, as a system, puts in place informational mechanisms that make certain conversations impossible.
IV. Agile: not a method, but a change in the relationship to power
Now we need to ask the real question. We talk about “poor implementation” of Agile. But what is Agile, really?
It is not Scrum. It is not sprints, stand-ups or retrospectives. Those are tools, containers. What fills the container is something deeper: a transformation of the relationship to power within the organization. As long as Agile is seen as a project management method to apply, the point is missed. And that is precisely why consultants who “know the method” are not enough. They can teach the mechanics. But they cannot change the fundamental beliefs that govern how the organization works.
Genuine Agile rests on a radical assumption: the people doing the work understand better than the hierarchy what needs to be done. Not systematically, not in every situation. But often enough that the real question is no longer who knows, but who decides. This is exactly what David Marquet demonstrated aboard the USS Santa Fe, an experience he recounts in Turn the Ship Around!: instead of moving information up to authority, he moved authority to where the information was. It is a complete challenge to how organizations have been structured for decades. Modern organizations inherit a model born in the manufacturing era: the hierarchy decides, people execute. That model worked when work was repetitive and predictable. But as soon as there is complexity and change (in other words, in almost every modern context), that model breaks down.
Agile is not a “better version” of this model. It is an alternative. It asks: what if we trusted the people who do the work? What if we really listened to them? What if we organized decision-making power differently? This ties directly to a fundamental distinction in organizational theory: the one between “Group Activity” and “Group Work” in Berne’s Organizational Theory. Group Activity is what the group does to adapt to the hierarchy and the established system. It is often sterile energy, politics, power games. Group Work is the group genuinely creating value, innovating and producing together.
Pseudo-Agile is Group Activity. It is the group pretending to change while protecting the old structures. Genuine Agile requires a shift to Group Work: creating spaces where the group can truly think, truly decide and truly create without being constantly hijacked by mechanisms of adaptation to the hierarchical system.
This is only possible if two conditions are met.
First, the hierarchy must give up a certain form of control. Not all control, but control over detail, over every tactical decision. It must hand over power. And that requires a deep transformation of leaders’ mindset.
Second, the group must be ready to accept real power. That means accepting real responsibility for its mistakes. Accepting that self-organizing also means accepting failure. And that requires a deep transformation of employees’ mindset.
Without these two mindset shifts, all you have is theater. Rituals without substance. A pseudo-Agile that accumulates frustration before collapsing.
V. Why Agile isn’t dead—it’s more necessary than ever
Let’s return to the numbers, because it matters not to stay in the abstract. Organizations that have truly adopted Agile are winning. The data shows it. They are faster, more innovative, more responsive. They retain talent better (because working in an environment where you have real power is more engaging). And yes, they are more profitable.
So why do so many organizations give up? Because they never really adopted it. They adopted the form, not the substance. And form without substance is exhausting and ineffective.
Yet today’s context makes Agile even more necessary, not less.
Companies face three simultaneous challenges: the growing complexity of their environments (technology, regulation, competition), market volatility (you can no longer plan five years ahead), and the rapid transformation of required skills. None of these has eased. All three are accelerating.
In this context, centralized, predictive management models are simply outdated. Not in theory but in practice: organizations trying to operate with a traditional model in 2025 are increasingly falling behind. At the same time, a new wave of Agile adoption is emerging. It is less visible than the 2010s wave, less driven by marketing. But it is real. It is not only in IT. It is in manufacturing (hardware agility), in human resources, in strategy. And what is different is that organizations adopting Agile now have finally understood: it is not a project method. It is a deep organizational transformation. And they no longer try to pretend. They accept the deep work: transforming mindsets, creating psychological safety, embracing double-loop learning.
The question for every organization is therefore simple: are you ready to face your own psychological defenses? Are you ready to transform your relationship to power? Or will you keep up the pseudo-Agile show until reality forces your hand?
VI. Getting out of the trap: responsibilities at each level of the hierarchy
If pseudo-Agile is inevitable (and it is, as long as psychological defenses are not addressed), how do you get out of it?
The answer requires clarifying something that often remains vague: each hierarchical level has a different transformational responsibility. And as long as each level believes that “it’s the others who need to change,” nothing changes.
This is a very common organizational defense mechanism: leadership says “we’re going Agile, it’s up to the teams to change their mindset.” Managers say “I agree with Agile, but leadership has to let go of control.” Teams say “we’d like to be agile, but the manager won’t let us.” And meanwhile, nothing moves. Here is what a coach should work on at each level.
The coach’s role: building awareness and navigating anxiety
A coach or consultant who comes into an organization with an Agile transformation plan should not start with practices. They should start with anxiety. Because anxiety is what drives the defenses. As long as it is not named and worked through, it will keep sabotaging. But the coach is not a therapist. Their role is not to resolve the anxiety. It is to make it visible and help each level become aware of it.
In practice, this means creating spaces where anxiety can be talked about. Not in formal meetings with all levels together (that would be a defensive routine: no one would dare speak frankly). But in confidential moments with each level separately.
With leadership: “What really frightens you about genuine Agile? What is the nightmare scenario? What could you lose?”
With managers: “How do you picture your role if teams really made the decisions? What would change for you?”
With teams: “What are you afraid would happen if you really had power? What would hold you back?”
Once the anxiety is named, the real work can begin. The aim is not to reassure (“everything will be fine”). It is to help the organization go through its anxiety consciously (the “unfreezing” phase). The coach must help people stay in that discomfort without reacting defensively. Next, the conditions for double-loop learning must be created. That means creating moments where the real questions can be asked, even if they threaten the status quo. Building a culture where saying “I don’t know” and “I was wrong” is not only acceptable but valued. And this is ongoing work, not a three-month project.
The team manager’s role: creating the space, not directing it
The team manager is often forgotten in discussions about Agile. People talk about leadership and teams. But the manager is the critical friction point.
Traditionally, the manager’s role was to make decisions, control execution and approve work. Agile asks for something radically different. The manager must become a facilitator. Someone who creates the conditions for the team to make decisions, ensures the team has the information it needs, and shields the team from external disruption.
But this change is terrifying for many managers. Because their professional identity was built on knowing, deciding and controlling. If that role disappears, who are they?
That is why many managers will unconsciously sabotage Agile. They will say “of course, be agile.” But they will keep demanding detailed reports, second-guessing the team’s decisions and imposing their vision. And the team will understand the real message: “You can play at Agile, but I’m the one really in charge.”
So the manager’s transformation must be explicit. And it must address their anxiety: “What would you fear if you really let your team decide?” Once named, there is a conversation to be had: “If Agile means your team decides, what is your role, really?” And the answer is: creating clarity (what are our objectives?), protecting the team (from conflicting demands coming from elsewhere), removing blockers (are there obstacles only you can remove?), and, of course, being accountable for results. But not directing how those results are achieved. That is fundamentally different. And this change must be visible. The coach must check on it regularly. Because it is easy to say you have transformed your role. It is hard to really do it. Old habits will resurface under stress.
The role of senior leadership: letting go of micromanagement, accepting uncertainty
Leadership and senior levels play a different but equally crucial role. Traditionally, leadership’s role was to forecast, plan and issue directives. Then check that the directives are followed. It is a predictive model. You anticipate the future (or think you do), set a course, and make sure everyone follows it. Agile requires accepting that the future cannot be predicted. That it will surprise us. That the best way to navigate is to have an overall direction (why do we exist? what are our strategic objectives?), but to let teams adapt how we get there.
This is dizzying for many CEOs and executives. They have always been told their role is to forecast and control. Letting go of the “how” means accepting uncertainty. And that creates anxiety. But this anxiety must be faced. Because if leadership stays in “predictive micromanagement” mode, it will mechanically prevent managers from letting teams self-organize. And so the transformation stops at the first level. In practice, leadership must:
-
First, provide a clear, stable vision (the “why”) while leaving tactical flexibility (the “how”). And accept that the “how” will evolve and will surprise.
-
Second, be willing to communicate uncertainty. Instead of saying “here is the plan for the next five years,” say “here is our direction. Here is what we know now. Here is what might change. And we will adapt together.” It is less reassuring. But it is true.
-
Third, measure real impact rather than compliance with plans. Have we created value? Have we learned? Have we innovated? Not: did you follow the plan 100%?
-
And fourth, leadership must accept that if teams are asked to take risks and experiment, there will be failures. And those failures must not be punished. Otherwise, no one will really take risks.
This is hard for leaders who fear failure. But it is the condition.
What must change at each level: a summary
-
Leadership: moves from “I forecast and control” to “I set the direction and accept adaptation.”
-
Managers: move from “I decide and control” to “I create the conditions and remove obstacles.”
-
Coach: is not an “Agile doer,” but a facilitator of awareness and mindset transformation.
And the critical point: each level must see and accept its own transformation, not just ask others to change.
As long as leadership believes that “managers can change without us changing,” it won’t work. As long as managers believe that “teams can change without us changing,” it won’t work. And as long as teams believe that “it’s up to the manager to change, not us,” it won’t work. This is a systemic transformation. Every level must contribute.
VII. Conclusion: Agile isn’t a choice, it’s an evolution
Let’s go back to where we started. People say Agile is dead. The numbers say it is spreading. The paradox is only apparent.
What has died, perhaps, is the illusion that Agile could be adopted simply by changing processes. Agile is dead as a buzzword, as a fad, as a miracle solution you can buy from a consulting firm.
What is not dead, far from it, is the deep need that Agile meets. That need is the ability to navigate complexity. To learn fast. To adapt. To innovate.
These needs will grow, not shrink. Because the world is becoming more complex, more volatile, more uncertain. Organizations that have gone through the uncomfortable phase of genuine Agile transformation will thrive. Those that stay in pseudo-Agile will increasingly feel the gap between their image (agile) and their reality (hierarchical, slow, rigid). And those that do nothing will simply disappear.
Agile isn’t dead. It is becoming normal. Which means that soon, we will no longer talk about Agile. We will simply talk about organizations that know how to reinvent themselves, that trust their people, that learn together. And that will simply be the condition for survival.
