You are supposed to work Agile? You fancy it yourself? Now you have a few more questions? You’re not alone. For instance, I’ve recently been asked:

How can Agile sub-processes be implemented if the whole organization is not Agile?

Agile processes cannot be implemented.

At least not if the goal really is to approach things differently, that is, flexibly closer to the market, less risky, more innovative, and more profitable, in short: more Agile.

“To implement” comes from

a machine-based understanding of the world that has been around for a very long time, within our process-based culture (which has its origins in the first phase of industrialization and which is perceived by some as compulsive).

According to this conception, organizations (and people, but actually the whole world and all its phenomena) function according to more or less simple cause-effect principles, more like machines. That is why we for example speak of “resources” or “gears” in the big “enterprise gearbox”.

This worldview is widely shared because of such organizing, working, talking, and acting was THE success pattern par excellence in the mass production business of the 20th century

And it still is for many business processes today.

Agility, however, has moved beyond this worldview.

Not because organizational patterns built on this worldview are bad or worse per se. But rather because it is no longer helpful for many of today’s business challenges.

And even more: They prevent us from being successful

Because today it is just less and less about mass production and more and more about individualized, customized, very very close to the market, quickly available and carried into the broad services.

Agile working methods clearly involve

very much methodological and even very strongly processual approaches. All the more it is – by all means! – to emphasize:

Agile is precisely NOT about standardized structures or processes that somehow have to be “implemented”. It is about frameworks that each organization has to fill with the workflows and processes that are helpful and appropriate for them.

With this, organizations are more commonly viewed as “organisms.”

The complex (as opposed to complicated), adaptive, actually learning-adapting element in cooperation and living together is thus recognized.

Above all else (of course), this is in production and customer relationships.

THIS is WHY Agile is so popular as an organizational form these days. Because unlike its hierarchical, process-driven, machine-like, somewhat coercive sister called “command-and-control”, it takes care of the changing, rather more creative and so no longer predictable business cases that have been driving us for some time now and will continue to do so in the connected information age

It cannot be emphasized often and loudly enough:

It is less and less about stable mass production, which we actually know by heart (and vice versa)..

Since Google and Amazon at the latest (!), it is more and more about Services, Services, SERVICES! And they can not be organized with the means of mass production. At least not alone.

(See this video by John Kotter below.)

So what is it about implementing Agile sub-processes?

Of course, individual parts of an organization CAN become Agile. But is that necessary?

Wouldn’t it be more reasonable to clarify first where Agile can help you most in the short, medium, and long term? In order to then take the necessary steps?

This way, you wouldn’t have to bully a large part of the workforce with the typical restructuring nonsense and pay for the usual collateral damage (“If you don’t become Agile, you’re fired!”). When things aren’t running so smoothly anymore, there’s plenty of uproar in it even as it is.

So why mindlessly cause even more stress by trying to obsessively impose (or: “implement”) something that can only be adapted? Oh, that reminds me: In this game, by the way, it is also very often simply about power…

Is It Possible to Implement Agile in Parts?