Professional

Why do so many Agile transformations fail?

Automatic translation · View original

Topic illustration: Why do so many Agile transformations fail?

Why do so many Agile transformations fail?

It's not Agile. It's how you're understanding it.

Why do so many Agile transformations fail?

It's not Agile. It's how you're understanding it.

I've seen companies obsessed with doing it "right": perfect dailies, measured sprints, flawless boards…

And yet, decisions are still slow, political, and disconnected from value.

That's not agility. It's optimized bureaucracy.

We keep applying an old logic to new problems: — Adam Smith divided the work — Frederick Taylor turned it into a system — Henry Ford scaled it

And now we want to be agile… without questioning that foundation.

Result: Fordism with sticky notes.

A lot of process. Little thinking.

Here is the difference that makes all the difference:

  • Technical management: executing the framework well
  • Expert management: questioning whether the framework makes sense

Most organizations stay at the first one. Because the second requires judgement, conflict, and taking on risk.

And this shows up very clearly in one pattern: — teams that deliver more… — but contribute less value.

And no, AI is not going to fix this.

Because the problem isn't a lack of answers. It's the difficulty of asking good questions in uncertain contexts.

If your team measures velocity but doesn't improve decisions, you're not being agile.

You're covering up inefficiency.

Real agility begins when you stop asking: "Are we doing Scrum well?"

and start asking yourself: "Does what we're doing make sense?"

That shift is uncomfortable. That's why almost nobody does it.

Is your organization executing Agile… or actually thinking?

Inspired by the talk I gave on November 30 at #CAS23:
How to apply philosophical principles to agile management.
📺Video
Source →
Share:

Comments (1)

Log in to your Scrum Manager area to comment


Avatar
Juan Tatay Galvany ★
18 May 2026 17:20

I love it
Result: Fordism with sticky notes.
A lot of process. Little thinking.
Here's the difference that makes all the difference:
Technical management: executing the framework well
Expert management: questioning whether the framework makes sense
Most organizations stop at the first one. Because the second requires judgement, conflict, and taking on risk.
And this shows up very clearly in one pattern: — teams that deliver more… — but contribute less value.
And no, AI is not going to fix this.
Because the problem isn't a lack of answers. It's the difficulty of asking good questions in uncertain contexts.

Automatic translation · View original

Reply Reactions