Agile Not Fragile

When did you last hear some significant capability was required to be delivered by yesterday? Chances are, not too long back… Speed is now normative across organizations and industries.

Also, enthusiasm for moving fast is synonymous with being Agile. “No need to be perfect” is the corridor chant. Occasionally, this fervor is accompanied with the badge of Bias for Action worn with pride.

⚖️ Progress Over Perfection?

So, it’s a choice now, is it? Between moving fast vs dawdling? That’s the way it’s being made out to be — Progress over Perfection.

Truth be told, this isn’t that binary a decision. There’s limited merit in choosing between dispensing with planning altogether on one hand and being stuck in an infinitesimal planning loop on the other. As with most things in life (and business), the balance lies closer to the middle.

Let’s bust a myth right here:

🚨 The Agile many of us have been conned into believing isn’t really Agile. It’s more like Fragile.

🚍 FrAgile: Boarding the First Bus

A typified FrAgile approach is one where the intent is to get off the blocks quickly. In this belief system, not much is sought in terms of collecting information — the incentive is to demonstrate that action has been initiated.

This is the equivalent of boarding the first bus that arrives, regardless of where it’s headed.

As the Cheshire Cat says to Alice (in Wonderland):

“If you don’t know where you’re going, any road will take you there.”

Nobody I know has willfully made this choice. And yet, FrAgile practices are commonplace across projects. How did we end up here?

🧱 The Waterfall Hangover

The trigger was the rejection of the stodgy and unyielding Waterfall model. Historically held onto tightly by technology project managers (yes, we’ve been guilty), we demanded complete, upfront requirements and wielded “Change Request” processes like blunt weapons.

Ironically, the model meant to reduce uncertainty ended up driving delays and overruns.

“Measure with a Micrometer,

Mark with a Chalk,

Cut with an Axe.”

Large Waterfall projects became the poster child for how inaccuracy looked. So, between Fragile and Waterfall, are we now stuck?

🛠️ The Case for True Agile

Of course not.

The way ahead is with True(r) Agile.

In my experience, True Agile is a balancing act, and its practice demands the decision maker possess:

– Experience – to distinguish between long-term and short-term decisions

– Experimentation – gumption to walk new paths

– Endgame Focus – objectivity in decision-making

At its very core, Agile in an enterprise program is about managing a bimodal delivery.

🚪 One-Way vs Two-Way Doors

No program is monolithic. Each comprises multiple threads that converge to a shared outcome. A single speed won’t suit all.

An experienced program manager will modularize — without losing sight of the overall goal — and determine which project tracks go through:

– One-way doors (irreversible, high-stakes decisions)

– Two-way doors (reversible, iterative decisions)

These choices are influenced by:

– Size of investment and risk appetite

– Cost of opportunity between different delivery modes

– Cultural acceptance of imperfection

🍳 The Chef’s Touch

As in a kitchen, it’s the deftness of the chef’s hands that turns raw ingredients into a dish. Likewise, project delivery in capable hands is not about formulae but about experience, experimentation, and endgame focus.

🧊 Final Word

Footnote – Fragile projects can look deceptively Agile at first. They appear nimble but stretch like elastic over time. These are not projects. They are screensavers.

Fragile projects can look deceptively Agile at first. They appear nimble but stretch like elastic over time. These are not projects. They are screensavers.

Choose your model wisely. Avoid the lure of believing planning is unnecessary.