Transformation Anti-Patterns: Seven Ways Agile Change Fails

Seven organization-level patterns that derail agile transformations, why they fail according to GAO and DORA, and what leaders can do instead.

Transform Agile · Last reviewed October 24, 2026 · 5 min read

Agile transformations rarely fail because a team could not learn to hold a stand-up. They tend to fail in recognizable, organization-level patterns: the transformation is run like a one-off project, imposed from the top, aimed at vague goals, or quietly converted back into the old process with new names.

These anti-patterns are worth studying because they are predictable. The U.S. Government Accountability Office (GAO) documents several in its Agile Assessment Guide (GAO-24-105506), including a full appendix of agile myths and case studies drawn from its program reviews. DORA, the research program run by Google Cloud, describes common pitfalls in its guide to transforming organizations.

This guide groups those findings into seven anti-patterns, explains why each one fails, and suggests what leaders can do instead. It does not offer failure-rate statistics; the sources below describe mechanisms, and that is what leaders can act on.

1. Treating the transformation as a one-time project

DORA lists this pitfall first. Many transformation programs, it says, are treated as large-scale, one-time events after which everyone returns to business as usual. Teams are not given the capacity, resources or authority to keep improving, and performance gradually degrades. DORA's guide describes a typical pattern: performance gets worse at the start of a program before improving, then the organization drifts back to business as usual while cynicism and disengagement increase.

What to do instead: budget for improvement as ongoing work. DORA advises thinking of technology transformation as a value-delivery part of the business that you will not stop investing in, and warns teams not to let normal delivery work crowd out improvement work.

2. Mandating agility from the top

DORA's second pitfall is treating transformation as a top-down effort, where reporting lines change, teams are restructured and new processes are imposed with little input from the people affected. It notes that this can cause stress and lost productivity, and that the teams running such programs rarely gather feedback and adjust.

The Large-Scale Scrum (LeSS) adoption guidance makes the same point sharply: "Ordering teams to manage themselves is a contradiction." GAO adds a policy angle. It warns that using a policy or mandate to force adherence to agile principles does not produce healthy adoption, and that policies put in place too early may lead to basic compliance without the needed change in culture and mindset.

What to do instead: LeSS recommends combining top-down and bottom-up effort, because either one alone is likely to fail. Leaders provide support and structural change; the people doing the work provide energy and learning.

3. Launching with vague or conflicting goals

DORA's third pitfall is failing to agree on and communicate the intended outcome. Goals such as "faster time-to-market" or "lower costs," it says, make it impossible to know whether the improvement work is having the intended effect. Sometimes goals are unachievable or pit one part of the organization against another. DORA observes that in many such cases the failure is not analyzed; instead, a new wholesale change initiative is started or entire methodologies are discredited.

What to do instead: agree on a small number of measurable outcomes with teams. DORA also cautions that when targets are set in a top-down way, teams may "game" them, so let teams set their own target conditions toward shared outcomes.

4. Spreading effort across too many initiatives

DORA calls this "death by initiative": identifying initiatives in too many areas, which ultimately leads to under-resourcing important work and dooming them all to failure. Its guide links this to a "mashup" approach, which 40 percent of respondents to the 2019 survey reported using, and which it says lacks sufficient funding and resources in any particular investment.

What to do instead: DORA recommends selecting a few initiatives and dedicating ongoing resources to them, including time, money, and executive and practitioner sponsorship. LeSS expresses a similar preference as "deep and narrow over broad and shallow."

5. Waterfall with new vocabulary

Sometimes the process stays the same while the labels change. GAO's case study from its 2019 report on Department of Defense space acquisitions (GAO-19-136) describes a program office that, even after its contractor adopted an agile approach, directed the contractor to plan out all work across software builds to keep control over requirements. GAO also warns that without high-level encouragement, agile implementation might become a paperwork exercise.

GAO's appendix on myths is a useful diagnostic for this anti-pattern, because the myths often justify a hollow version of agile. It rejects the claims that agile requires no documentation, no planning, no oversight, no architecture and no risk analysis. It also rejects the idea that using any agile framework will automatically result in program success, noting that agile is not necessarily the solution for every program.

What to do instead: check behavior, not labels. Are plans detailed only for the near term and revisited regularly? Do product owners actually have authority to reprioritize? Does working software get reviewed with users?

6. Scaling before one team works

Scaling a broken process multiplies the problems. GAO's guide states that if an agile approach is not successful for a single team, the organization should address the organizational impediments that prevent teams from working in an agile way rather than scaling it up. The Scrum@Scale Guide puts it bluntly: "If an organization cannot Scrum, it cannot scale."

What to do instead: get a small number of teams working well, with real product ownership and integration, before adding coordination layers. LeSS's adoption advice to focus on one product group and give it all the support it needs follows the same logic.

7. Managing by the wrong numbers, and adding process when things go wrong

Two measurement habits regularly undermine transformations. The first is comparing teams by velocity. GAO notes that velocity is team-specific and should not be compared across teams.

The second is reacting to production problems with more approvals. DORA's capability page on streamlining change approval lists "responding to problems by adding more process" as a common pitfall, explaining that it drives up lead times and batch sizes and creates a vicious cycle. Its research found no evidence that more formal external review was associated with lower change fail rates.

What to do instead: measure outcomes and flow at the level of the product or system, use team metrics for the team's own improvement, and invest in making changes quicker and safer rather than slower.

Key takeaways

DORA identifies three leadership pitfalls: treating transformation as a one-time project, running it top-down, and failing to agree on measurable outcomes.
GAO warns that mandates and early policies can produce compliance without real change, and that agile without real sponsorship can become a paperwork exercise.
Avoid "death by initiative"; fund a few efforts properly instead of many poorly.
Fix what blocks a single team before scaling, as both GAO and the Scrum@Scale Guide advise.
Don't compare velocity across teams, and don't answer instability with heavier approvals.

Sources

Spotted something out of date? Let us know.