Agile as a Platform: How It Slowly Gets Enshittified

Agile was introduced as a way to reduce friction, not create new layers of it. Teams adopted it because it helped them move faster, make decisions closer to the work, and respond to change without waiting for permission. For a while, that promise held up. Delivery improved, collaboration felt more natural, and processes stayed lightweight enough to adjust when needed.

Over time, though, something tends to shift. The same practices that once helped teams move quickly begin to feel heavier. Meetings multiply, backlogs grow harder to navigate, and metrics that once helped teams understand their work start to shape it in less helpful ways. None of this happens abruptly. It’s usually the result of small, reasonable decisions accumulating until the system begins to behave differently.

Looking at Agile through the lens of platforms helps explain why this happens.

Platforms shape behavior. They define what is easy, what is allowed, and what is expected. In the early stages, they are designed to attract and support users. As they grow, they introduce structure to make that growth manageable. Eventually, they risk becoming systems that require effort just to maintain themselves.

Agile tends to follow a similar path.

At first, it serves teams directly. Workflows are flexible, ceremonies are adapted rather than enforced, and metrics are used to understand how work flows rather than to evaluate performance. The system feels supportive because it is still close to the people using it.

As more teams adopt Agile, the focus widens. Leadership needs visibility across teams, coordination becomes more important, and consistency starts to matter. Practices that were once optional begin to standardise. Tooling is introduced to make reporting easier. What used to be local decisions gradually become shared rules.

At a certain point, the system can start to revolve around itself. Teams continue following the process, but not always because it helps them deliver better. Some parts remain useful, others become habits. The connection between effort and outcome becomes less obvious.

This shift can be understood as a gradual transition through three stages. They are not strict boundaries, but they describe patterns that show up in many organisations.

Agile is introduced to solve real delivery problems. Teams experiment, adjust, and figure out what works in their context. Ceremonies are lightweight, and most of the effort goes into building and learning rather than maintaining the process.

At this stage, you often see:

• Teams are adapting practices instead of following them rigidly

• Metrics used as feedback, not targets

• Retrospectives leading to actual changes in how work is done

There is a sense that the system is there to support the team, not the other way around.

As the number of teams increases, coordination becomes more complex. Leadership needs a clearer picture of what is happening across the organisation. Agile starts to take on a second role: not just enabling delivery, but making it observable.

Standardisation follows naturally:

• Ceremonies become more uniform across teams

• Metrics are aligned, so performance can be compared

• Tooling enforces consistent workflows

These changes often bring benefits. Planning becomes more predictable, reporting becomes easier, and cross-team dependencies are easier to manage. At the same time, some of the flexibility that made Agile effective in the first place begins to narrow.

In larger systems, the process can take on a life of its own. Practices continue because they are part of the system, even when their original purpose is no longer clear.

This tends to show up in subtle ways:

• Backlogs grow, but not all items are equally meaningful

• Metrics remain stable, even as teams feel more friction

• Ceremonies are attended, but not always used to drive decisions

The system still functions, but more effort is spent maintaining it. The original goal—helping teams deliver value efficiently—becomes harder to see through the layers of coordination and reporting.

In product platforms, complexity often grows through the steady addition of features. Each addition solves a problem, but over time, the experience becomes harder to navigate.

Agile similarly accumulates complexity, though it shows up as process rather than functionality. Extra steps are introduced to handle edge cases, more tracking fields are added to capture information, and additional meetings appear to improve alignment. Individually, these changes are reasonable. Together, they increase the amount of effort required just to keep the system running.

The result is a shift in where time is spent. More of it goes into managing the process, less into moving work forward.

As systems scale, governance becomes necessary. Without it, coordination breaks down and consistency disappears. The challenge lies in how far that governance extends.

In earlier stages, teams decide how to apply Agile practices based on what helps them deliver. Later on, many of those decisions are made centrally. Templates are introduced, workflows are fixed, and success criteria are defined at a broader level.

This makes the system easier to oversee, but it can also make it harder to adapt. Teams working on different problems may find themselves following the same structure, even when their needs differ. The process becomes easier to manage, but less responsive to local context.

None of this happens because teams misunderstand Agile. The progression is driven by real pressures: the need for visibility, the need for coordination, and the desire to reduce risk as systems grow.

Each step makes sense in isolation. Standardising ceremonies improves alignment. Introducing metrics helps track progress. Adding structure reduces ambiguity. The challenge is that these decisions accumulate, and over time, the system drifts away from the conditions that made it effective.

In that sense, Agile behaves much like other platforms. As it scales, the incentives change, and the experience evolves along with them.

Reversing this drift does not require starting from scratch. What tends to help is treating Agile as something that needs to be managed and improved over time, rather than something that was “implemented” once.

That involves paying attention to how the system is experienced, not just how it is defined. Some useful questions to revisit regularly include:

• Where does the process help teams move faster, and where does it slow them down?

• Which practices are actively used, and which are followed out of habit?

• How much time is spent managing work compared to doing it?

Answering these questions becomes easier when supported by real data. Platforms like Agile Analytics help surface patterns that are otherwise hard to see, such as where work tends to stall, how effort is distributed between feature and non-feature work, or whether process overhead is increasing over time.

These signals don’t prescribe solutions, but they make it easier to spot when the system is drifting and where adjustments might have the most impact.

Agile is often introduced as a set of practices, but over time, it behaves more like a platform that shapes how work happens across an organisation. Like any platform, it changes as it grows, influenced by the needs of the people who use it and those who depend on it.

Keeping it effective requires more than following the original playbook. It calls for the same kind of attention you would give to any product that matters—watching how it is used, understanding where it creates friction, and being willing to adjust it as the environment changes.