Agile hasn’t failed—but many organizations are frustrated with how they’re using it and are wondering what comes next.

Explore why some teams feel they’ve reached “peak agile,” what’s driving the backlash, and how more flexible, disciplined approaches can bring back joy and effectiveness in project work.

Why Some Organizations Are Pushing Back on Agile

Many companies are quietly rebelling against agile.

Some have let go of agile coaches, reverted to old ways of working, and see little return on the large investments made in training and frameworks over the past 20 years.

Attendance at major agile conferences has dropped, partly due to costs and COVID, but also because many leaders feel they haven’t seen the value they expected.

In some organizations, “agile” has gained a bad reputation, to the point where leaders ask for help improving delivery—but explicitly request that it not be called agile.

Agile Methods Are Helpful—but Incomplete

Scrum, SAFe, XP, and the many other agile methods are useful starting points but are not complete solutions.

Treating any one framework as “the answer” leads to disappointment, because every organization, team, and context is different.

The core question becomes: which parts of a method genuinely help this team, in this environment, on this work—and which parts are waste?

Without that tailoring, teams can end up following ceremonies rigidly without improving outcomes or satisfaction.

The Roots of Scrum: Why It Was Needed

To understand the current backlash, we look back to the world where Scrum emerged in the 1990s.

Software development was dominated by cubicle-based, waterfall-style work: thick requirements specs were thrown over the wall to developers, who often worked alone and interacted minimally with others.

Weekly status meetings with project managers were long and painful, and process improvement happened, if at all, only at the end of a project.

Scrum was a deliberate forcing function: daily standups pulled introverted developers out of their cubicles to coordinate work, and retrospectives enabled continuous improvement within the project, not just after it.

Breaking work into sprints created regular opportunities to show progress and adjust.

Today’s Teams and “Scrum Fatigue”

The world has changed since that cubicle era. Many modern teams—especially younger, highly collaborative ones—naturally work side-by-side, pair frequently, and get continuous feedback from business partners without needing formal standup rituals.

In studios like ThoughtWorks’ London office, teams collaborate constantly, adjust on the fly, and feel energized and productive.

For such teams, formal daily Scrum events and scheduled retrospectives can feel redundant or constraining.

Over years of strict adherence, teams can accumulate hundreds of sprint ceremonies—planning, reviews, retrospectives, daily standups—amounting to at least 10% process overhead in Scrum and over 30% in some implementations of SAFe.

When teams are forced to keep doing every ceremony by the book, they may continue the motions while mentally checking out, a pattern labeled “Scrum theater.”

When Scrum Is Still Valuable—and When It Isn’t

If Scrum is working well for a team and they genuinely find value in the structure, there is no reason to abandon it.

The point is not that Scrum is wrong, but that it was designed for a specific context and era, and not every team today needs all its ceremonies all the time.

Over time, many strong Scrum teams naturally “lean out” their process, removing meetings or artifacts that no longer add value and shifting toward lean or Kanban-style ways of working.

Lean, Kanban, and Just-in-Time Improvement

Lean and Kanban approaches emphasize continuous flow, work-in-progress limits, and just-in-time process improvements rather than fixed, recurring ceremonies.

For example, one team used a colorful Kanban board with WIP limits and playful avatars (like characters from their favorite shows) to track who was doing what, making coordination both effective and fun.

Instead of waiting for a retrospective, they would change a process immediately when they saw a better way, embedding improvement into daily work.

In these environments, daily standups may be unnecessary because team members already communicate constantly, and roles like “Scrum Master” may evolve into rotating team leads or facilitators rather than fixed positions.

The most productive teams observed over time are often lean/continuous delivery teams that minimize ceremony overhead and maximize flow.

How Over-Rigid Frameworks Create Pain

Frameworks become problematic when organizations treat them as rigid prescriptions enforced by a PMO or central authority.

Teams may be told “we are a Scrum shop” or “we are a SAFe shop,” and required to execute every prescribed event and artifact regardless of local context or value.

This removes autonomy, stifles continuous improvement, and turns agile into a burdensome compliance exercise instead of an enabler of better work.

When that happens, it’s not surprising that teams and business stakeholders grow tired of hearing the word “agile” and question what they’re getting for all the overhead and consulting spend.

The Case for Disciplined Agile as a Toolkit

Disciplined Agile (DA), is presented as a toolkit rather than a prescriptive framework.

It contains over 1,600 practices collected from many sources, organized not to dictate one “right way,” but to help teams understand their options for different goals like forming teams, exploring scope, planning, testing, and releasing.

Most agile teams are not adequately equipped to truly optimize their way of working because they don’t know what alternatives exist beyond their current framework.

DA aims to “help you fail less and succeed earlier” by giving context-sensitive guidance so teams try options that are more likely to fit, rather than experimenting blindly.

Updated Principles and the Role of Management

One contribution of Disciplined Agile is a more modern set of principles, promises, and guidelines that update and extend the original Agile Manifesto.

These include explicit emphasis on psychological safety and diversity—areas largely absent from the 2001 manifesto—and clearer articulation of management’s role.

Rather than assuming middle management disappears in agile, DA positions managers as responsible for creating effective environments that foster joy and high performance.

Culture change, in this view, comes from changing systems and environments, not from trying to “fix” people.

Goals, Decision Points, and the DA Browser

To make its large body of practices usable, DA organizes them around goals and decision points.

For each goal—such as “Form Team” or “Explore Scope”—there are decision points (e.g., team longevity, requirements techniques), each with options, trade-offs, and guidance.

A browser lets practitioners click into a goal and see options like stable teams vs. project teams vs. ad hoc teams, with pros and cons for each.

This turns DA into a “pantry of ingredients”: teams don’t need to memorize all 1,600 practices; they just need to know where to look when they want to improve a specific aspect of their way of working.

Choosing Life Cycles That Fit

Disciplined Agile also provides multiple lifecycle patterns rather than a single default.

Teams can choose from:

• Agile lifecycles based on Scrum with sprints and periodic releases.

• Continuous delivery agile, where each sprint can go live.

• Lean and continuous delivery lean lifecycles, focused on daily or more frequent deployment and flow.

• Additional lifecycles for lean startup–style experimentation or for larger programs.

Some lifecycles are more project-oriented (clear start and end), while others are more product-oriented (persistent teams delivering release after release). The key is selecting a lifecycle that reflects how your work and value actually flow, rather than forcing all work into one template.

A Real Example: Reducing Requirements Waste

One large U.S. life insurance company had been using Scrum for several years but was required by the PMO to produce 11 different requirements documents for every initiative, often totaling 200 pages even for simple projects.

Few people read them, they were often wrong, and the process created considerable frustration and waste.

Using Disciplined Agile’s “Explore Scope” goal as a guide, they redesigned their approach:

Replacing the 11 documents with four lightweight textual artifacts (personas, user stories with acceptance criteria, a glossary, and a short non-functional requirements document) plus two simple visual models (a user story map and low-fidelity UI prototypes).

This cut their requirements burden by about 80% and significantly increased team satisfaction and flow.

Bringing Back Joy to Project Work

At the heart of this talk is the question: what does your end-of-day conversation at home sound like?

Is it a story of endless meetings, scope fights, and checking retirement accounts—or a story of shipping value, delighting stakeholders, and being applauded for useful releases?

Reimagining agile is not about abandoning agility; it is about moving beyond rigid frameworks, choosing ways of working that fit your context, eliminating wasteful process, and embracing hybrid and lean patterns where they help.

With the right toolkit and mindset, project teams can deliver value faster, reduce frustration, and rediscover the joy that drew many of us to agile in the first place.