Agility - The Most Misunderstood Word in Tech

15 years of Agility

"We can do it, we are agile."

If I earned money every time I heard that sentence in a hopeless meeting, I'd retire early, comfortably. Yet the irony is that being agile is often nothing more than a shield leaders raise to justify chaos.

I've never been a blind believer in agility. Scrum, Kanban, Lean; none of them are magic spells. But agility does solve certain problems, and they always come down to the same three forces:

• human vs human
• human vs culture
• human vs context

Agility Is Not a Recipe

Many companies treat agility like a cookbook: follow the steps, bake the cake, collect applause.
But without the right ingredients, trust, communication, psychological safety, your cheesecake collapses.

Sometimes you don't even have enough sugar, but everyone pretends it will "do."

Culture is the real foundation of agility. And culture changes with geography:

• North America praises initiative.
• Europe values stability.
• Southeast Asia prioritizes harmony.

These differences seep into every ceremony, every estimate, every retrospective.

The human mindset is the heaviest variable in the equation. Encouraging initiative feels natural in North America; in Europe, the question is often, "It works, why change it?"

And appointing a project manager or CEO as Scrum Master?
That's like asking the referee to coach the team. The conflict of interest is baked in.

Probably my favorite example: cancelling retrospectives because they’re “too time-consuming,” only to organize one every three months or when the tension in the team is about to explode.

Meetings must have meaning, purpose, and outcomes. Agile ceremonies (or any meeting) really should exist because they solve something, not because the calendar says so.

Teams are not interchangeable. You can gather the most talented people in the league, and still, they may never become champions. History matters. Chemistry matters. Sometimes a single newcomer shifts the entire balance.

Yet I've seen teams march through daily ceremonies with zero emotion, zero intention; just rituals performed out of habit.

"We are agile," they say.

No, they are not.

When Fake Agility Shows

A company can proudly declare itself agile while quietly living in dysfunction:

• recurring overtime
• shifting scopes
• poor specifications
• no estimation
• no reliable velocity
• a declining team mood

Changing these habits is like asking a smoker to quit: possible, but only through willingness, discipline, and a clear understanding of why.

I've had the privilege of working with exceptional agile coaches; empathetic, patient, brilliant. They tailored agility to each team instead of forcing a template.

Their secret weapon was context.

One of them, my mentor François Lachance, often reminded me:

Understand the human behind the behavior, and the process will follow. Context is everything.

He is right.

Being agile is not about ceremonies.
It's about adaptation.

When Reality Hits the Plan

More than once, I've seen release dates announced before requirements were even known.
That's when you see a team's true agility.

And by "team," I mean everyone:

• stakeholders
• product owner
• designers
• business analysts
• QA
• developers
• architects
• ...

On one greenfield project, we survived by slicing the product into MVPs (Minimum Viable Product).
We intentionally postponed technical features (e.g., authentication, permissions) to avoid early slowdowns.
We flagged "nice-to-have" items for future soft releases to keep the scope tight.
We focused on delivering tangible, testable value that users could interact with as early as possible.

It bought us trust, and trust is the oxygen of every agile team.

As a new project lead, I told management:

We will work through MVPs.
We will change how we apply agility.
We will focus on clarity and accuracy, without compromising the final product.

The team hated story points. Not because they didn't work, because they were unfamiliar. So I compromised: planning poker with hours.

Suddenly estimations became debates, debates became decisions, and decisions became ownership.

Slowly, the team saw the value.
Estimation wasn't overhead, it was foresight.

Then came the inevitable realization: we couldn't deliver everything on time.

That moment defined our agility.

• We cut scope
• We redefined MVPs
• We reorganized meetings
• We switched to Kanban
• We worked smarter, and yes, sometimes harder

We even organized overtime "parties," turning a stressful sprint into a collective mission. It wasn't ideal, but it was honest, and it worked. We finished early enough to polish the technical details and ship a release we were proud of.

And the most important thing: the team evolved.

What We Truly Gained

After five months, the team's mindset transformed.

• They estimated with confidence.
• They planned with intention.
• They used agility rather than being used by it.

And in the end, what made me proud wasn't the product we shipped, but the people we became.

We learned to approach problems with agility in the only domains that truly matter:

• humans
• culture
• context