Killing Agile Cosplay Without Killing Agile
What we are witnessing is not the death of Agile, but the slow collapse of its theatrical version.
Every few months, familiar headlines appear again: “The Death of Agile” or “Why Big Tech Is Quietly Killing Scrum.”
The headlines may change, but the message stays the same. Scrum is called outdated, Agile is seen as misunderstood, and somewhere a burn-down chart quietly vanishes from a Jira board.
Is any of this true? In part, yes. But it is not as dramatic as these articles make it sound.
What is really happening is not a revolution, but a slow and awkward step back. The core ideas of Agile — iteration, fast feedback, incremental delivery, and learning by doing — are still strong. What is fading is the version of Scrum that feels like a corporate ritual, with required sprint meetings, an obsession with velocity, endless story point debates, and calendars packed just to look busy.
Large organizations did not suddenly decide to get rid of Scrum. They found that, at scale, Scrum often creates more show than real value. When teams deploy all the time, priorities shift every week, and much of the work is unplanned or comes from interruptions, two-week sprints start to feel like pretending the weather is always the same just because the forecast meeting is on the calendar.
So, Agile is not dead. It has just moved into what you could call its ‘post-framework’ phase.
In this phase, most companies are not swapping Scrum for one new method. Instead, they are building ways of working that match their real needs, not just what coaches recommend. This is when you start to see a range of alternatives appear.
The first and most common change is moving to flow-based delivery, often called Kanban or, more honestly, ‘Scrum without the parts we were pretending about.’ This approach works best when work arrives unpredictably, like in platform teams, infrastructure, editorial tools, internal products, or anything close to operations. In these settings, trying to plan all work into sprints is unrealistic. Flow-based teams focus less on making promises and more on keeping work moving: how long tasks wait, how quickly they progress, and how often they reach users. This suits organizations that prefer steady productivity over dramatic sprint finishes and teams that are tired of explaining why ‘this urgent thing was not planned.’
Another change, especially in product organizations, is splitting discovery and delivery into a continuous dual-track model. This shows up when teams realize their main issue is not how fast they build, but whether they are building the right things. These teams can deliver quickly but often wonder why users do not want what they made. Continuous discovery lets product managers and designers test ideas and prototypes without holding up engineers, while delivery continues as a steady stream of clear work. This model works well for digital products with real users, strong analytics, and leaders who see learning as part of the job, not a distraction.
Another trend is the quiet rise of DevOps metrics as a way to manage teams. In many organizations, story points faded away not because they were wrong, but because they did not mean much outside the team. Executives never really understood velocity, and teams did not think it mattered. Flow and reliability metrics changed this. Measures like deployment frequency, lead time, failure rates, and recovery time are things that engineering, product, and leadership can all agree on. This approach works best for organizations focused on reliability, scale, and operational excellence, such as SaaS, media platforms, and infrastructure-heavy companies. It shifts the question from ‘Did you deliver what you planned?’ to ‘Is the system getting healthier over time?’, which is a tougher and better question.
On another level, there is organizational design, often described through ideas like Team Topologies. This is not just a team method; it is a recognition that no process can fix a poorly designed organization. When teams are overloaded, rely on others, and are unclear about who owns what, more sprint planning will not help. This approach is best for large organizations where coordination is harder than delivering work, and the main problem is mental overload, not individual speed. It is often adopted after years of trying Agile without understanding why things still move slowly.
Finally, there is a model that makes Agile purists uneasy: appetite-based planning, best known as Shape Up. This method works in product companies with strong leadership and stable priorities. Instead of keeping endless backlogs, teams define problems early and commit to a set time frame with flexible scope. It is not more flexible, but it is more decisive. It fits organizations that trust experienced product leaders and want fewer changes in the middle of a cycle. It does not work well where leaders cannot stop interfering with ongoing work, which, to be honest, is common.
Taken together, these models are not a new set of rules. They are a way out.
The main point is not that people are rejecting Agile values, but that they are rejecting fake Agile practices. Teams are tired of acting like uncertainty can be planned out, that velocity means value, and that meetings count as progress. Organizations are moving away from Scrum not because they dislike Agile, but because they are finally taking it seriously.
Scrum is not dead. It is just not the default answer for everything anymore. In a way, that might be the most Agile result of all.