The Two Ways to Run an Agile Transformation

There are two ways enterprises approach agile transformations.

The first is by design. Leaders architect a target operating model top-down: strategy cascaded through goals, people assigned to defined roles, standardized practices enforced, and planning cadences synchronized across the board.

The second is by evolution. Teams focus on customer outcomes, adopt agile principles, and continuously improve the organization’s fitness for purpose. They refine how work flows, improve how teams collaborate, and eliminate constraints. No fixed target state—just a continuous learning loop.

The problem with the designed path is simple: it creates solutions that everyone agrees to in theory, but that crack the moment they touch the real world.

Top-down architecture quietly assumes a simple, predictable environment. It assumes written plans will execute as intended, work will flow smoothly through the org chart, and employees can be relieved of the burden of problem-solving. It promises to drive out uncertainty by design.

But the real world always has other plans.

Fake Agile Tries to Control Uncertainty Out of Existence

Top-down operating models run on an older logic: that organizations can eliminate uncertainty through tighter controls, broader standardization, deeper centralization, and the eradication of duplication. They declare “one right way” for everything. Fake Agile is simply that legacy mindset wearing a new name.

In this scheme, controls are introduced preemptively—nobody waits for a failure to justify them. Management assumes an organization functions because it has strict rules and detailed instructions, which turns every instance of variation into a defect waiting to happen. Teams get no space for local adaptation and no permission to experiment.

Consider what heavy standardization actually does to an organization’s resilience. A standard marks the outer boundary of what a team can decide for itself. The more a framework specifies, the less room remains for local judgment. When conditions change, teams face a false choice: comply and fail, or deviate and face correction. The habit of local negotiation was designed out along with the uncertainty.

Removing uncertainty removes agility. They are two sides of the same move.

Look at what this machinery produces in practice:

• Cascaded OKR pyramids rewrite “we are heading that way” into rigid numerical quotas.
• Central resource pools and RACI matrices attempt to solve dependencies with org charts, stripping out local negotiation and context.
• Heavy planning cadences treat change as a failure of foresight. When reality strays from the plan, the answer is simply a bigger plan.
• Single-source-of-truth dashboards prioritize executive visibility over ground truth, leaving zero room to report genuine uncertainty.

The structure enforces a strict hierarchy: lower levels execute, middle management coordinates, and executives strategize. Nobody owns the end-to-end system because nobody is permitted to.

It looks pristine on paper. But paper is easy to design for. Paper doesn’t have to negotiate trade-offs, protect its calendar, game faulty metrics, or maintain a secret second spreadsheet because the official dashboard is useless.

The moment real people enter the picture, a massive gap opens between work as imagined and work as done. The business actually runs on the second, while the model keeps describing the first. Because the official process makes no room for real-world judgment, people improvise in secret—hiding their solutions because the system treats adaptation as a violation.

You Can’t Eliminate Uncertainty—You Just Hide It

Uncertainty doesn’t vanish just because an operating model pretends it isn’t there. Shifting dependencies, conflicting priorities, and sudden market changes remain. The top-down design simply hands employees two jobs instead of one: satisfying the model, and doing the actual work on stolen time.

When formal systems fail to address reality, the real work goes off-book:

• Side channels handle real dependencies.
• Shadow spreadsheets replace official tools.
• Personal favors are traded to secure time from specialists who are nominally allocated to six teams at once.

All of this coping mechanism is uncertainty showing up on the org chart’s blind side—unmanaged and unbudgeted.

Meanwhile, the official layer stays clean while executive metrics track the wrong things. Rollout rates and ceremony attendance prove the “lab” is running, but they say nothing about whether customer value is actually improving. The lab model didn’t remove uncertainty; it just blinded leadership to it.

Build Stability Into the System, Not the Environment

Operating environments never simplify. Every quarter brings competing stakeholder demands, capacity bottlenecks, and unforeseen shifts. Prioritization is never a clean, mechanical formula, and no framework will ever turn it into one.

Real agile organizations leave the market unpredictable and build stability directly into their operating system:

• Short feedback loops over long plans: Treat plans as hypotheses and cadences as experiments. Discover a direction is wrong before over-investing in it.
• Decisions closest to the work: Push authority to the people with direct context.
• Alignment by intent: Communicate strategic direction clearly, but let local teams choose the tactical moves.
• Evolution through experimentation: Allow practices to mutate through safe-to-fail experiments. When a local fix works, keep it. When it fails, adjust quickly without waiting for a steering committee.

Solutions built by teams don’t suffer from the “paper problem” because they are forged in reality: real teams, real customers, real constraints. There is no gap between model and reality to fall into. When a solution stops working, the team adapts it locally on the next turn of the loop.

This brings us to the core reality of transformation: Agility requires uncertainty to exist.

Adaptation is what agility is made of. A team has nothing to adapt to if the environment is fixed, the plan is law, and the process is final. Ban uncertainty, and you haven’t made the organization safe for agile—you’ve removed its raw material.

Beyond tolerating uncertainty, organizations must grant permission. A team can only adapt when adaptation is treated as legitimate: choosing a different move, varying a practice, or saying “the plan is wrong” out loud instead of waiting to get caught.

Fake Agile manages to defeat itself twice over: it designs away the uncertainty teams were supposed to respond to, and then disciplines them for improvising around whatever is left.

Three Key Takeaways

1. Uncertainty is conserved: It’s impossible to eliminate uncertainty, but efforts to eliminate uncertainty simply push it into teams that have been trained not to deal with it.
2. Choose where stability lives: Placing stability in the environment makes you fragile when the market shifts. Building stability into your system’s capacity to absorb change builds true resilience.
3. Agility is the capacity to adapt: Standardization buys consistency, but it costs the team its ability to adapt. A team that isn’t allowed to improvise is just a compliant team.

Agile was never a mechanism to make the world predictable. It is a discipline for staying effective while it isn’t.