Sie wollen oder sollen agil arbeiten? Sie haben selbst Lust darauf? Jetzt haben Sie noch ein paar Fragen? Sie sind nicht allein. Ich bin zum Beispiel kürzlich gefragt worden:

Wie können agile Teilprozesse implementiert werden, wenn nicht die ganze Organisation agil arbeitet?

Agile Prozesse lassen sich nicht implementieren.

Zumindest dann nicht, wenn es wirklich darum gehen soll, die Dinge anders, nämlich flexibel marktnäher, risikoärmer, innovativer und profitabler, kurz also: agiler anzugehen.

Das Wort „implementieren“ entstammt

einem schon länger sehr weit verbreiteten maschinenhaften Weltverständnis, also unserer prozesshaften Kultur (die ihren Ausgang in der ersten Industrialisierungwelle hat und von manch einem als zwanghaft empfunden wird).

Diesem Verständnis nach funktionieren Organisationen (und Menschen, eigentlich aber die ganze Welt und alle ihre Phänomene) nach mehr oder weniger einfachen Ursache-Wirkungs-Prinzipien, eher also wie Maschinen. Deshalb sprechen wir z.B. von „Ressourcen“ oder „Zahnrädchen“ im großen „Getriebe des Unternehmens“.

Dieses Weltbild ist deshalb weit verbreitet, weil ein solches Organisieren, Arbeiten, Sprechen und Handeln im Massenproduktionsgeschäft des 20. Jahrhunderts DAS Erfolgsmuster schlechthin war.

Und das ist es für viele Business-Prozesse noch heute.

Agilität hat diese Weltsicht allerdings hinter sich gelassen.

Nicht etwa deshalb, weil auf dieses Weltbild aufbauende Organisationsmuster per se schlecht oder schlechter wären. Sondern deshalb, weil sie für viele heutige unternehmerischen Herausforderungen nicht mehr hilfreich sind.

Und mehr noch: Sie verhindern sogar unseren Erfolg.

Denn es geht eben heute immer weniger um Massenproduktion und immer stärker um individualisierte, angepasste, sehr sehr marktnahe, schnell verfügbare und in die breite getragene Services und Dienstleistungen.

Agile Arbeitsweisen bringen ganz offensichtlich

sehr viel Methodisches und sogar sehr stark Prozesshaftes mit sich. Umso mehr ist – unbedingt! – hervorzuheben:

Bei Agilität handelt es sich eben genau nicht um standardisierte Strukuren oder Abläufe, die es irgendwie zu „implementieren“ gilt. Es handelt sich um Arbeitsrahmen, die jede Organisation mit den für sie hilfreichen und passenden Abläufen und Prozessen zu füllen hat.

Dabei werden Organisationen eher als „Organismen“ verstanden.

Das komplexe (im Gegensatz zu: komplizierte), adaptive, eben lernend-anpassende Element in der Zusammenarbeit und im Zusammenleben wird dadurch anerkannt. Und dies vor allem anderen (natürlich) in den Produktions- und Kundenbeziehungen.

DESHALB ist Agilität die Organisationsform der Stunde. Denn anders als ihre hierarchische, prozessgetriebene, maschinenhafte, tendenziell zwanghafte Schwester namens „Command-and-Control“ kümmert sie sich um die wandelnden, eher kreativeren und somit eben auch nicht mehr so sehr vorhersagbaren Geschäftsfälle, die uns nun schon länger und im vernetzten Informationszeitalter immer mehr umtreiben werden.

Es lässt sich also nicht oft und laut genug hervorheben:

Es geht immer weniger um stabile Massenproduktion, die wir ja wirklich aus dem Effeff beherrschen (und umgekehrt).

Allerspätestens (!) seit Google und Amazon geht es eben immer mehr um: Services, Services, SERVICES! Und die lassen sich mit den Mitteln der Massenproduktion alleine schlecht bis gar nicht organisieren.

Allerdings – und das gehört auch zur Wahrheit – auch nicht ohne sie. (Siehe Video von John Kotter unten.)

Wie ist das also mit der Implementierung von agilen Teilprozessen?

Natürlich ist möglich, dass auch einzelne Teile einer Organisation agil werden. Aber muss das denn sein?

Wäre vorher nicht vernünftiger zu klären, wo Ihnen Agilität kurz-, mittel- und langfristig am meisten helfen kann? Um danach die nötigen Schritte einzuleiten?

Das hätte den Vorteil, dass man nicht einen Großteil der Belegschaft mit dem typischen Umstrukturierungsgedöns tyrannisieren und die üblichen Kollateralschäden mitfinanzieren müsste („Wer nicht agil wird, fliegt!“). Ist doch auch so schon viel Aufregung drin, wenn die Dinge nicht mehr so rund laufen.

Warum also kopflos noch mehr Stress machen, indem man etwas zwanghaft zu oktroieren (oder: „implementieren“) versucht, was sich nur adaptieren lässt? Ach so, da fällt mir ein: In diesem Spiel geht es übrigens auch sehr oft einfach nur um Macht…

Weiterlesen

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…

Agile Teilprozesse implementieren – geht das?Is It Possible to Implement Agile in Parts?