Initiating change with blueprint or from scratch: finding the middle ground?

I’ve come across Marcus Raitner’s article, stating that using blueprint in agile transformation is not a good idea.

Laptop and people at work

"Copying Spotify or simply implementing any other blueprint of an agile organization is a fundamental mistake. Not because the models themselves were poor, but because implementing a model of an agile organization that has been chosen or developed by a few managers, experts or consultants from top to bottom contradicts the essential principle of self-organization.”

I’m convinced he’s right.

And on the other hand, I get that there’s a reason why some companies want blueprints. Especially the big ones. They don’t want to waste time to reinvent the wheel, or to put hundreds or thousands of people into uncertainty for a long period of time, or having them to endlessly discuss how to organize themselves.

There’s nothing wrong about blueprint. We all need a starting point, and the best possible. We want to use the wisdom of those who’ve taken action before us. Something clear to begin with.

I’m also convinced that it can be a right move, even if it means starting with a model crafted by a few and then implemented top-down.

The problem arises if nothing is done to ensure the blueprint then evolves clearly and rapidly, adjusting to the company’s context and people, and through people.

And we are seeing this problem happening with Agile/Scrum too (link to second article).

At some point, people need to be able to shape the organization where they’re at, or things will get stuck.

That’s why for me and at Clarity we are in favour of a balanced solution : using a blueprint for organizing self-organization… That means giving clear and rigorous rules framing how teams self-organize themselves, then letting self-organizing unfold in those teams according to those rules, and finally modifying those rules as needed, as more insight is gathered about how people want this to be done.

by François Flamion