Someone in your organization right now is asking whether you should still be doing Agile. Well, first of all, you can't really "do" Agile, but most of us know what they mean by that.
It could be a board member who just read the latest McKinsey article. Maybe it's your VP who heard that a competitor has moved on from Agile and is doing something else. Maybe it's you. And you know something? They may be right.
My name is Lance Dacy, otherwise known as Big Agile. I'm a certified Scrum trainer, and I coach product and technology teams on how to actually deliver. This week, I want to address the "Agile is dead" conversation head on. I've done it several times in writing, but not in video. I don't want to be defensive about it. I'm not going to be evangelical about it. I just want to be honest.
We're facing this conversation all over the place, and we're going to look at where the narrative actually comes from. In my opinion, there is some legitimacy in it, and some of it is just consulting noise. Let's talk about what it might actually mean for your organization, especially in 2026.
The Scenario You've Probably Seen Before
I think about a company that starts on an agile transformation journey. They bring in a consulting firm, sometimes it's me. They train the teams, stand up Scrum everywhere: two-week sprints, daily standups, sprint reviews on the calendar, everything buttoned up. Retrospectives on Friday afternoons if we're all part of the same product group.
But then I come back two years later, and the teams are exhausted. The ceremonies are still happening, but nothing is actually changing. The retrospectives produce the same vague action items every quarter. Sprint reviews are even worse. They're just demos that nobody outside the team attends, or they get canceled when we can't get the right stakeholders there. The product backlog is a graveyard of ideas that leadership keeps shifting one way or another, but nobody ever really reprioritized.
And then somebody reads an article that says, "Agile failed us. We need something new."
The hard truth is that Agile didn't fail the organization. What failed them is Agile theater. It seemed like they were doing it all, but they really weren't doing anything. They adopted the Scrum calendar without understanding the reasoning behind it. They performed all the rituals without internalizing the principles, taking a magic diet pill and expecting everything to change overnight. When the rituals stopped producing results, they started blaming the methodology instead of looking at how they were actually running it.
Agile isn't even a methodology if you really look at it. But what tends to happen is people get inundated with information, and they need to look at the real problem. The real problem was the theater, not the actual practice. Because if you're truly practicing agile, you are getting better all the time, or at least trying to get better. We call it progress over perfection. We don't expect perfection, but we expect to know what perfect might look like right now and start building a plan to get there. It's more of an asymptotic goal.
What's Actually Dying in 2026
If I look at what is actually dying in 2026, I don't think it's agility. I think it's the performance of agility, and those are very different things. I actually think agile is more important than ever. We're going through a lot of transformative technology right now.
How We Got Here: Three Phases of Agile
I think context matters, and agile has gone through three distinct phases. Understanding them is the key to knowing where you actually stand.
Phase One: The Practitioner Movement (2001–2010)
This is when 17 people wrote the one-page document with four value statements and 12 principles and called it the Agile Manifesto. It was a practitioner movement: small teams, mostly software developers, pushing back against heavy process. They were trying to ship better software faster. Nobody was talking about certification. It was just about delivering the highest business value items as early as possible with the least amount of cost. No transformation budgets, just people experimenting and sharing what worked.
Phase Two: Corporate Capture (2010–2018)
This is where enterprises discovered Agile and wanted more of it at scale. Scaling frameworks appeared, consulting firms built transformation practices, and credentialing bodies issued millions of certifications. The word shifted from describing a way of thinking to describing a product you could buy, and that's where we got into a lot of trouble.
The Agile Manifesto literally says "individuals and interactions over processes and tools." The enterprise transformation industry turned that upside down. Processes and tools became the thing you purchased, and individual thinking, team autonomy, empirical learning got squeezed out to make room for compliance.
Phase Three: The Hangover (2018–Present)
This is where we are now. Organizations that spent years doing agile as a process are burned out and fatigued. Leaders are skeptical. Practitioners are defensive or disillusioned. Articles are appearing with titles like "Moving Past Agile" and "Agile is Dead."
The Brand Failed, But the Ideas Didn't
Here's what's actually interesting about all of this. The Age of Product community, one of the largest and most respected Agile practitioner communities in the world, published a piece in early 2026 making an observation that I think is spot on.
They pointed out that enterprises claiming to have moved past agile into product operating models are, when you look closely, still doing autonomous teams, outcome orientation, continuous discovery, customer feedback loops, and iterative delivery. That's basically the Agile Manifesto's principles, just with a different vocabulary and none of the transformation baggage. One practitioner shared that a client told them, "We don't do agile anymore. We do product discovery and continuous delivery." When asked what that looked like, they basically described Scrum without ever using the word. The brand failed, but the ideas didn't.
Forrester's 2025 State of Agile Development report found that 95% of professionals globally affirm that agile principles are still critical to their operations. That's not a methodology in decline. It's a methodology whose name became radioactive in some circles while its substance kept spreading everywhere.
But the uncomfortable number from that same report is that only 7% of organizations have ever reported achieving full proficiency in agile practices. Seven percent. The principles are affirmed nearly universally, but nobody's actually doing them very well. That gap is the real problem. It's not that agile is dead. The problem is that most organizations got really good at performing agile and kept critics at bay for a while, but they never got good at practicing it.
What the Scrum Guide Actually Says
The Scrum Guide, meaningfully updated in 2020, has been clear for a long time about what Scrum is actually for. It says Scrum is founded on empiricism and lean thinking. Empiricism holds that knowledge comes from experience and that decisions are based on what is observed, not plans, not frameworks, but observed reality.
Scrum makes visible the relative efficacy of current management, environment, and work techniques so that improvements can be made. Its job is to expose what is not working so you can fix it. That is not a feel-good ceremony or framework. It's a harder way to work. Scrum is easy to understand, but hard to do, because the feedback and learning system is what's hard. If your version of Scrum is not surfacing what's not working, then it's really not Scrum.
We often say you can't "do" agile. You want to be agile. Agile is a state of being. The Agile Manifesto is a philosophy, and Scrum is a way, not the way, to be agile. I think of it like being healthy. I want to be healthy, but my body's different than your body. I may choose keto and an exercise plan. You may need something radically different. But I can't choose keto, skip the part about cutting sugar, and then blame the diet when I don't lose weight. If I wasn't following the plan, I can't say it didn't work for me.
The Agility Reality Check: Three Questions That Cut Through the Noise
I've narrowed it down to three questions that cut through the noise pretty fast. I call it the Agility Reality Check, and you can run it with your leadership team in about 20 minutes.
Question 1: Do our feedback loops get shorter every quarter?
The entire point of iterations, sprints, and incremental delivery is to learn faster than your competitors, not to keep up a two-week cadence. If your team ships every two weeks but makes strategic decisions once a quarter, your feedback loop isn't two weeks. It's three months. That's not agility. That's waterfall with smaller batches.
Question 2: Do our events drive decisions or confirm them?
A healthy sprint review asks: based on what we learned this sprint, what should we do differently next sprint? How did this sprint affect the overall budget, release, and timeline? What shifted? If the decisions about the next sprint were already made before the review happened, that's review theater.
The same applies to retrospectives. If your team holds a retrospective and produces the same action items they produced a month ago, it's not creating learning. It's creating the appearance of learning.
Question 3: Does our team adapt based on evidence or based on opinion?
Opinion data is the bane of existence of most organizations. Too many people with opinions who don't run experiments to test them. The Scrum Guide calls it transparency, inspection, and adaptation. That hasn't gone away. The type of work we do is still complex, risky, and uncertain. We still need those things.
Transparency means the real situation is visible. Inspection means you actually look at it. Adaptation means you change course when the evidence says to. If your product backlog is ordered based on what the loudest stakeholder wants, that's not evidence, that's opinion. You have the vocabulary of agile without the operating system installed.
It's Not an Indictment, It's a Starting Point
Saying your team's agile is theater is not an indictment. It's a normal state for a lot of teams right now. Most teams doing agile theater do so because the system they work in rewards compliance over learning. If executives are measuring success by whether ceremonies happened or whether velocity went up, then the teams optimized for ceremonies and velocity. That's rational behavior, but it's the opposite of what high-performing teams actually do.
The organizations thriving right now are the ones people point to and say, "They don't do agile." Those organizations are doing something very specific. They're protecting the feedback loop above everything else: short iterations, real customer signals, genuine willingness to adapt. Leadership treats a failed experiment as information, not a performance problem.
Joiner and Josephs' research on Leadership Agility describes leaders who drive real organizational agility as people who are not enforcing a methodology. They're building the conditions for teams to inspect, adapt, and improve continuously. They answer questions with questions. They call it catalyst leadership. We're not looking for a leader who controls execution, but one who creates the environment where learning is rewarded and adaptation is the norm.
If your leadership model rewards output and punishes uncertainty, no framework in the world is going to fix that. That's what's broken. You're not running an agile organization, you're running a compliance organization in the name of Agile.
What You Can Try Next Week
Here's one thing you can do next week. It takes 15 minutes and will tell you more about your situation than any formal assessment tool.
Sit down with two or three people from your team informally and ask one question: If we had to justify each of our agile practices from scratch, which ones would we keep?
Not the ones that are required. Not the ones we do because we've always done them. Which ones would we choose to keep if we had to make the case from evidence?
That question surfaces theater really fast. The practices people fight for are the ones that actually create value. The ones people shrug at are the ones worth examining. I'm not saying get rid of them, but when you have that list, your next move is simple. Pick the one practice on the "worth examining" list that's consuming the most time and ask: What was this practice supposed to produce? Is it producing that? If not, what would?
That is empiricism applied to your own process. It's what agile was always supposed to enable. You don't need a consultant or a transformation program for this. You need 20 minutes and honest people, maybe a good facilitator too.
The Bottom Line
Agile, the word, may be losing cultural cache in some corners of the enterprise, and that's fine. Words wear out, especially words that got co-opted, commoditized, and turned into a compliance checkbox by the very industry that was supposed to champion them.
But agility, the actual capability, is more necessary in 2026 than it's ever been. We're going through a massive technological transformation. Markets are moving faster. AI is compressing feedback loops even further. The organizations that learn fastest, that adapt on evidence rather than opinion, that give teams the conditions to actually improve, they're not moving past agile. They're living the principles more fully than most companies running certified transformation programs.
So if someone asks you whether agile is dead, I think the honest answer is: the theater version? It probably deserves to die. But the empiricism, the short feedback loops, the genuine willingness to adapt based on evidence, that version is more relevant than ever.
The question is: which version are you actually running? And do you need to upgrade?
If these ideas resonate and you want to go deeper, check out our upcoming classes and workshops. We work with product and technology teams to move past the theater and build real agility, the kind that actually shows up in how your team delivers.