Digitalisierung Agilisieren in ungewissen Zeiten

Es heißt seit langem, durch Globalisierung und Digitalisierung sei die Welt VUCA geworden: volatile, uncertain, complex und ambiguous. Wer erfolgreich sein wolle, müsse daher agil sein: in höchstem Maße anpassungsfähig an sich stetig verändernde Umweltbedingungen. Wie immer, wenn ein Managementtrend zum unwidersprochenen Mainstream wird, ist ein Distanz wahrender Blick gefragt. Lesen sie worauf es ankommt.

Mit der COVID-19 Pandemie haben wir jetzt das erste Mal eine wirklich unbestrittene VUCA Situation, einen realen Lackmustest. Wir senden Mitarbeiter ins Homeoffice und die (noch) weit verbreiteten direkten Management Methoden können nicht mehr angewandt werden. Führung auf Distanz, selbstorganisierte Teams, kurze Reaktionszeiten, „Fahren auf Sicht“, pragmatische Entscheidungen und schnelles Lernen ist angesagt. Merkmale, die das agile Management für sich beansprucht. Höchste Zeit also die agile Transformation nicht nur in einigen wenigen Bereichen, sondern flächendeckend zu wagen?

Agiles, post-heroisches Management

Agilität, die Fähigkeit schnell und flexibel auf äußere Veränderungen zu reagieren, wünscht sich jedes Unternehmen. Eine agile Organisation ist eher in der Lage, sich flexibel an veränderte Umwelt- und Marktverhältnisse anzupassen als eine klassische Organisation.

Voraussetzung des Erfolgs ist aber eine von der Führung gewollte kulturelle Veränderung im Unternehmen zu mehr Dezentralisierung, Entscheidungsfreiheit und Selbstorganisation, bei gleichzeitiger Kenntnis der Grenzen dieses Denkmodells.

Agilität ist kein neues Thema, sondern existiert bereits seit vielen Jahrzehnten in unterschiedlichen Facetten und Ausprägungen. Schon Charles Darwin stellte in seiner Evolutionslehre fest: “it is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change” – ein Naturgesetz, das ohne Weiteres auf die Unternehmenswelt übetragbar ist.

Populär wurde Agilität aber durch das agile Manifest (2001), das von einer Gruppe renommierter Softwareentwickler formuliert wurde. Es postuliert 4 Werte und 12 agile Grundprinzipien (siehe Abbildung 1 und 2), die inkompatibel mit der etablierten Managementpraxis dieser Zeit waren.

Abbildung 1: Das agile Manifest hat eine Wertverschiebung im Managementdenken ausgelöst

Dieser Protest gegen Bürokratie in der Softwareentwicklung adressierte sowohl die kleinteilige Arbeitsteilung (Analysten, Planer, Kodierer, Manager und Tester) als auch die Vorgehensweise (klassische Wasserfallmethode und Projektmanagement). Die Regel waren Planungsfehler (Elfenbeintürme) die zu massiven Zeit- und Kostenüberschreitungen und unzufriedenen Kunden führten. Die Autoren bevorzugten eindeutig die Arbeit in kleinen, erfahrenen Teams, und der Erfolg bei komplexen Projekten gab ihnen Recht.

Abbildung 2: Die 12 agilen Prinzipien führten eine andere Form von Management in die etablierte Praxis ein

Dies war die Geburtsstunde einer Vielzahl post-heroischer^[1], agiler Führungsverfahren^[2], die sich in Folge durch Integration etablierter Methoden^[3] noch weiter ausdifferenziert haben. Diese Verfahren haben sich bewährt, wenn

• der Kern der Wertschöpfung in der kreativen, komplexen Problemlösung besteht (historisch: Softwareentwicklung und IT Deployment),
• das Problem in einer kleinen erfahrenen Gruppe abgebildet werden konnte,
• volatile Umwelteinflüsse existierten^[4],
• das Risiko des (finanziellen) Untergangs nicht das alles beherrschende Thema war, und
• das Lernen im Team durch regelmäßige, handfeste, nachprüfbare Zwischenergebnisse in einem kurzen, festen Zeittakt ermöglicht wurde.

Kreative Inseln in den Organisationen und iteratives, schrittweises Vorgehen bei Problemlösungen war per se nichts neues, aber die neuen Verfahren haben die vorher gelebte Praxis das erste Mal in einen industriell managebaren und kontrollierten Rahmen gebracht. Agile Methoden sind damit für eine bestimmte Klasse von Problemen dem klassischen Projektmanagement vorzuziehen (Siehe Abbildung 3).

Abbildung 3 Agile (Projekt-)Organisationen haben sich gegenüber klassischen Projektverfahren bewährt, wenn ein hohes Maß externer Instabilität vorliegt und die Reaktions- und Improvisationsfähigkeit eines Umsetzungsteams wertvoller ist als ein striktes Risikogeleitetes, plangetriebenes Vorgehen.

Seitdem hat das agile Denken in der Breite hohes Interesse, gemäß dem Motto erzeugt “If you can make it here, you can make it everywhere”. Die übermäßige Bürokratisierung von Arbeitsprozessen scheint weit verbreitet.^[5]. Auch das US-Militär^[6] berichtet, das die im letzten Jahrhundert etablierten Führungsstrukturen in den heutigen Konflikten nicht mehr funktionieren und Dezentralisierung und Agilisierung benötigen. Die Anwendung von agilen Methoden eignet sich aber nicht für alle Situationen in einem Unternehmen, schon gar nicht in Geschäften, die über optimierte und sich ständig wiederholende Prozesse funktionieren. Niemand will agile Experimente bei seiner Gehaltsüberweisung oder der nächsten Herz-Operation.

Agilität überall? Bitte nicht!

Selbst Benchmarks bei den Besten finden nirgendwo eine vollständig agil operierende Organisation. Im Gegenteil, es ist immer ein synchronisiertes Zusammenspiel von Selbstorganisation und Risikomanagement. Das intelligente Zusammenspiel ermöglicht erst die vielgepriesene agile Organisation (siehe Abbildung 4.)

Abbildung 4: In komplexen Situationen ergänzt das agile Projektmanagement die versagenden klasssichen Methoden. Es ist die Aufgabe des Organisationsdesigns diese Methoden so zu verknüpfen, das eine leistungsfähige agile Organisation entsteht.

Man übersieht leicht, dass auch die heutigen Vorbilder – die digitalen Champions im Silicon Valley – bei weitem nicht überall agil arbeiten. Sie arbeiten in hybriden Organisationen, denn jedes Geschäft muss

• operative Agilität: „Flexibilität im Machen“,
• operative Exzellenz: „Die sichere Umsetzung von Verpflichtungen zum Kunden und zum Eigentümer“ und
• strategische Resilienz: „Das Geschäft funktioniert auch bei Abweichungen von Prognosen“

sinnvoll miteinander kombinieren. Diese Ziele sind vom Wesen her unvereinbar und finden erst im erfolgreich durchgeführten Organisationsdesign Ihre Lösung! Praktisch mag ein kleiner Nukleus kreativer Software Mitarbeiter im Valley agile Freiheiten genießen, aber niemand würde ein neues Rechenzentrum agil bauen oder auf die Effizienz der klassischen top-down Steuerung im Vertriebsmanagement verzichten. Insbesondere in diesen klassischen Bereichen ist das Silicon Valley sehr viel disziplinierter, durchsetzungsstärker und konservativer als viele Unternehmen der Old Economy.

Abbildung 5 Die Organisation von Unternehmen orientiert sich immer an Ihren Kernprozessen. Diese extrahieren Einkommen aus Transaktionen für den Kunden und sind langfristig wertstiftend und Kulturbestimmend für das Unternehmen.

Jedes Unternehmen führt in Ihrem Kern einen Primärprozess aus, der schlicht eine Kundennachfrage befriedigt und über diese Transaktion Geld verdient (siehe Abbildung 5). In der Folge bestimmen damit die Kundenanforderungen auch das Vorgehen. Beispiele:

• Ein Bäcker muss ab 6:00 die Brötchen im Regal haben, sonst verprellt er die Kunden. Der Weg dorthin ist nicht agil, sondern durch eine klassische Rückwärtsplanung der Produktion gekennzeichnet.
• Der Kapitän eines Windjammers hat ein klares Ziel vor Augen, aber die Etmale[7] seiner Fahrt plant er von Tag zu Tag neu, je nachdem wie viele Seemeilen er geschafft hat, wie hoch die Abdrift war etc. Aus diesem Grund agiert er von Natur aus agiler, plant seine Reise in Etappen und bleibt beim Sturm auch mal im Hafen.
• Ein IT-Unternehmen, das im Kundenprojekt ein Problem löst und in Ihrem existierenden Rechenzentrum abbildet, ist zu einem hohen Maß auf Kundennähe angewiesen. Man lernt agil, “on the way”, da in vielen Fällen die Kunden Ihre Bedürfnisse gar nicht so genau spezifizieren können.
• Dasselbe IT-Unternehmen wird aber beim Bau eines Rechenzentrums eher zum Bauunternehmer. 1.) Das Risiko des Untergangs muss gemanagt werden, was zu eine hohen initialen Planungs- und Analysephase führt, die alles andere als agil ist. 2.) In der Regel sind viele Subunternehmer beteiligt, die alle klassisch koordiniert werden müssen. Aus diesem Grund ist hier ein klassischer Ansatz geeigneter.

Diese Beispiele zeigen, dass Agilität selektiv eingesetzt werden sollte, um wertschöpfend zu sein. Leider sind die Einsatzgebiete selten so klar umrissen, wie in diesen einfachen Beispielen.

Was tun?

Etwas provokant könnte man fragen „agilisiert ihr noch … oder scheitert ihr schon?“. Es gibt eine Reihe typischer Fehler, die immer wieder gemacht werden. Um das zu vermeiden sollten folgende 3 Grundsätze befolgt werden:

#1 Die richtigen Themen wählen

Einmalige Aufgabenstellungen in einem instabilen Umfeld (siehe Abb. 2) sind besonders geeignet, mit einem agilen Ansatz bearbeitet zu werden.

#2 Die richtigen Voraussetzungen schaffen

Es gibt eine Reihe typischer Fehler, die man relativ einfach vermeiden kann:

• Der Aufbau von agilen Teams ohne ausreichende Qualifikation und Erfahrung führt in der Regel immer zum Misserfolg. Damit sind nicht nur die methodischen, sondern insbesondere auch die fachlichen Fähigkeiten gemeint.
• Wenn interne Laufzeiten bei Zwischenschritten der Projekte sehr viel länger als zwei bis drei Monate sind, wird sich in agilen Teams kaum ein selbstorganisierender Lerneffekt und keine Performanzsteigerung einstellen. Hier sind eher klassische oder hybride Methoden des Projektmanagements angesagt.
• Die agilen Teams brauchen auch klare organisatorische Abgrenzung und Selbstständigkeit. Das Verhältnis sollte den Charakter eines Auftraggebers und Auftragnehmers haben. Häufig mangelt es aber gerade an einem dedizierten „Product Owner“, der die Rolle des Auftraggebers gegenüber den agilen Teams übernimmt und fürausgewogene „Checks and Balances“ sorgt.

# 3 Die richtige Führung etablieren

Auch ein agiles selbstorganisiertes Team braucht Führung! Die oft zitierte Behauptung, Agilität passt zu den Bedürfnissen des heutigen Menschen, bezweifeln wir stark. Wir glauben nicht, dass Menschen in hoch-volatilen Zeiten (z.B. dem dreißigjährigen Krieg) weniger agil waren als die Menschen heute. Es gibt aber Einflüsse:

• Die Mitarbeiter heute sind weitaus gebildeter als noch vor 20 Jahren. Dies muss man berücksichtigen.
• Die Generation Z mag zudem keine Hierarchien und wird sich nicht im gleichen Umfang mit Gehalt motivieren lassen wie ältere Generationen. Sie will „Sinn“ in dem was sie tut.

Unabhängig von den oben beschriebenen Aspekten und der Freiheit „im Kleinen“ die Entscheidung von gestern aufgrund neuer Erkenntnisse zu revidieren, muss das übergeordnete Ziel immer eindeutig und klar sein! Um in dem Bild des Windjammerkapitäns zu bleiben: es muss beim Start der Reise klar sein ob das Ziel Kap Hoorn oder die Nord-West-Passage ist. Damit ist das Vorgehen auf dem Top-Level immer „klassisch“ und das Gesamtsystem „hybrid“.

Führungssysteme müssen aber mehr Freiräume gewähren als vor zwanzig Jahren, ohne die kritischen, risikobelasteten Elemente des Geschäfts zu vernachlässigen. Führung muss die Mitarbeiterqualitäten entsprechend selektieren, pflegen und Fehlanpassungen vermeiden. Dieser Verantwortung muss Führung gerecht werden und darf nicht vernachlässigt werden.

Fazit

Unternehmen agiler zu machen – so generisch formuliert – ist unbestritten sinnvoll. Allerdings bedarf es in der konkreten Umsetzung einer Reihe von detaillierten Ausgestaltungen der Erfolgsvoraussetzungen. Hierbei spielt die Führung eine zentrale Rolle, meist ist sie noch zu einseitig „klassisch“ aufgestellt. Für die erfolgreiche organisatorische Transformation zu mehr Agilität im Unternehmen sollten insbesondere die Führungsmodelle und -prozesse durchgängig auf die spezifischen Bedarfe abgestimmt werden.

[1] vgl. Dirk Baecker “Postheroisches Management”, Berlin, Merve, 1994; Dirk Baecker “Postheroische Führung”, Heidelberg, Springer, 2015

[2] z.B. Scrum, Extreme Programming, LeSS, RUP, Nexus, SAFe und dem Holocracy- und Spotify-Führungssystem

[3] z.B. des Lean Management (Kanban, Visual Management) oder dem Design-Thinking (ein unter Designern seit langem praktiziertem Vorgehen).

[4] Hierzu zählt auch die Zusammenarbeit mit Kunden und Stakeholdern, die Ihre Projektwünsche nicht artikulieren können und häufige Spezifikationsänderungen erzwingen.

[5] Lawrence Freedman betitelt in seinem Geschichtswerk die Historie des Managements nicht umsonst als “Strategy from above” (Lawrence Freedman: “Strategy – A history”. Oxford University Press, 2013)

[6] General Stanley McChrystal, “Team of Teams”, New York, Penguin Random House, 2015

[7]  Ein Etmal (aus dem Mittelniederdeutschen: Etmal = wiederkehrende Periode) ist die von einem Schiff von Mittag zu Mittag zurückgelegte Wegstrecke.