Kitabı oku: «Agile Organisation – Methoden, Prozesse und Strukturen im digitalen VUCA-Zeitalter», sayfa 7
Integrierte Feedback- und Lernschleifen
Das beschriebene iterativ-inkrementelle Vorgehen ist eng verbunden mit dem kontinuierlichen Lernen als weiteres wesentliches Charakteristikum agiler Organisation. Die Qualität und mithin die Überlebensfähigkeit einer lernenden Organisation85 ist abhängig von den Möglichkeiten und den Fähigkeiten ihrer Organisationsmitglieder, sich selbstorganisiert und eigenverantwortlich zu entwickeln (vgl. auch den Beitrag von HARTMANN). Es gilt: „The purpose of an organization is to enable ordinary human beings to do extraordinary things.”86
In einem dynamischen und komplexen Umfeld erfolgt die Entwicklung bewusst empirisch in kleinen Schritten. Versuch und Irrtum, Feedback und Reflexion sind fest in der agilen Philosophie verankert und folglich auch Teil agiler Organisation. Auf diese Weise kann sich ein Unternehmen schnell und flexibel auf neue Situationen einstellen. Agile Ansätze wie Scrum, Lean Startup oder OKR (vgl. Kapitel 6) haben daher auch immer integrierte Feedback- und Lernschleifen, die die Akteure dazu anhalten, ihre Annahmen über Kundenbedürfnisse, Produkterfordernisse, Prozessaktivitäten und die eigene Zusammenarbeit in kurzzyklischen Iterationen zu reflektieren und ggf. anzupassen (z. B. Reviews und Retrospektiven).
Da es in sozialen Systemen oft an kausalen Ursache-Wirkungszusammenhängen mangelt, empfiehlt sich eine ergebnisoffene, hypothesengeleitete Herangehensweise. Dies erfordert die Bereitschaft, in Alternativen zu denken und (nur) vorläufige Annahmen zu treffen (Hypothesen) über das, was ist oder was (zukünftig) sein könnte. Hypothesen konstruieren eine Wirklichkeit, die als Grundlage für Entscheidungen dient. Sie sind regelmäßig zu überprüfen und im Bedarfsfall umzuformulieren, zu ergänzen, zu erweitern oder auch wieder aufzuheben (iterativ und inkrementell). Das gemeinsame Bilden von Hypothesen eröffnet neue Perspektiven („Mehrbrillenprinzip“) und unterstützt somit die Objektivität im Prozess.87 Durch das Überprüfen von Hypothesen wird sich schrittweise an eine Problemlösung herangetastet. Ausprobieren und experimentieren ist ausdrücklich erlaubt – getreu der agilen Philosophie: Fail early, fail fast, fail often, fail better!88
Agilität impliziert somit eine konstruktive Fehler- bzw. Lernkultur. Wenn in diesem Zusammenhang von Fehlern die Rede ist, dann sind damit nicht solche gemeint, von denen man zum Zeitpunkt einer Entscheidung bereits hätte wissen müssen, die also vermeidbar gewesen wären. Der Irrtum als Synonym für den hier benutzten Fehlerbegriff scheint daher geeigneter. Denn ein Irrtum liegt vor, wenn sich eine Annahme oder Hypothese zum Zeitpunkt einer Entscheidung später als Fehleinschätzung herausstellt. Agile Unternehmen lernen also vielmehr aus Irrtümern als aus Fehlern, denn letztere sind im engeren Sinne Verschwendung, und die gilt es bekanntlich zu vermeiden. Das bedeutet jedoch nicht, dass jeder Fehler zu sanktionieren ist oder diejenigen, die ihn begangen haben, abgestraft werden sollten. Mit vermeidbaren Fehlern umzugehen hat etwas mit einem wertschätzenden Umgang zu tun, unabhängig von Methode oder Organisationsform. Ebenso geht es nicht darum, die eine richtige Hypothese zu finden oder zu bestätigen, sondern durch eine Vielfalt von Hypothesen auch zu einer Vielfalt von Perspektiven und Möglichkeiten zu gelangen, denn frei nach NIKLAS LUHMANN führt „jede Problemlösung auch zu Lösungsproblemen.“89
Viele agile Praktiken und Ansätze basieren auf dieser Vorgehensweise. Prägend ist allen voran der PDCA-Zyklus oder DEMING-Kreis mit seinen vier Phasen „Plan - Do - Check - Act“, für hypothesengeleitetes und erfahrungsbasiertes kontinuierliches Lernen und Verbessern.90 In agilen Prozessen werden einzelne, kundenrelevante Anforderungen geplant bzw. Hypothesen dazu aufgestellt (Plan), dann in kurzen Zyklen fokussiert umgesetzt bzw. getestet (Do), dazu jeweils möglichst messbares Kundenfeedback eingeholt (Check) und daraus gelernt, was wie gut funktioniert. Was empirisch belegt funktioniert, wird gefestigt, alles andere wird in den nächsten Iterationen angepasst (Act bzw. begrifflich treffender Adapt91 oder auch Learn92). Über diese Vorgehenslogik findet eine kontinuierliche Anpassung, Weiterentwicklung und Leistungssteigerung statt (vgl. Abbildung 18). Die Vorgehenslogik kann sowohl für die Optimierung des Produkts (Arbeit im System), als auch für die Optimierung der Arbeitsteilung und Koordination, d. h. der Organisation (Arbeit am System), genutzt werden.
Abb. 18: Iterative Feedback- und Lernschleifen im PDCA-Zyklus
Um zu testen, ob „Same Day Delivery“ auf positives Kundenfeedback stößt, ging man bei ZALANDO einen pragmatischen Weg. Täglich wurden im Logistikzentrum nahe der Berliner Zentrale 30 bestellte Sendungen herausgegriffen, in Autos gepackt und noch am selben Tag ausgeliefert. Sogar die Chefs schlüpften in die Rolle des Paketboten. Die ZALANDO-Mitarbeiter erhielten dadurch schnell direktes Feedback von ihren Kunden und konnten die logistischen Anforderungen eines solchen Angebots selbstständig erheben. „Wir hätten auch ein paar Hundert Leute abstellen können, die einen großen Projektplan entwerfen, wie ZALANDO innerhalb der nächsten zwei Jahre das Thema „Same Day Delivery“ aufrollt, … aber wenn wir dann am Ende feststellen, dass wir das falsche Problem gelöst haben, sind jede Menge Ressourcen verbrannt. Immer wenn wir eine … Möglichkeit erkennen … ist es für uns der logische nächste Schritt, das möglichst schnell auszuprobieren“, sagt DANIEL SCHNEIDER, Head of Onsite Customer Journey.93 Diese „trial and error“- bzw. „safe enough to try“-Mentalität sorgt für ein hohes Tempo und ist ein wesentliches Grundprinzip agiler Betriebssysteme, wie z. B. Holacracy (vgl. Kapitel 8.3).
Ein solches agiles, hypothesengeleitetes Vorgehen bedeutet auch, dass bloßes Kopieren zu kurz greift. Einfach „skippen“, eine Abkürzung nehmen oder Prozesse und Arbeitsweisen von anderen abkupfern, das kann auf Dauer nicht funktionieren. „Wir sind doch schon agil“, heißt es dann oft nach gefühlten 4-5 Sprints. Es ist, als wolle man den eigenen Film vorspulen, um schneller zum Ende zu kommen, und verdrängt dabei, dass man den eigenen Film nicht versteht. Am Ende ist man genauso schlau wie zuvor. Von außen betrachtet heißt es dann häufig abschätzig (vgl. Kapitel 2.2 und 9): „Ihr verwechselt doing agile mit being agile.“
Fokussierung
Ein wichtiger Aspekt beim iterativen Vorgehen und schrittweisen Lernen ist die Priorisierung von Aufgaben und die Fokussierung in den einzelnen Iterationen (Sprints) auf die dringlichen und wichtigen kundenrelevanten Anforderungen. Agile Ansätze versuchen nicht, in einem „großen Wurf“ die 100 %-perfekte Lösung zu erstellen, sondern gehen in kleinen Schritten und fokussierten Hypothesen vor. Man möchte der Gefahr aus dem Weg gehen, sich im komplexen Ganzen zu verlieren. Mangelnde Kundenorientierung durch intransparente Strukturen, lange Entscheidungswege und folglich wenig effiziente oder uneffektive Prozesse, soll vermieden werden. Getreu dem Motto „done is better than perfect“ konzentrieren sich agile Unternehmen auf die wichtigen und dringlichen Aufgaben. Es gilt: „stop starting – start finishing!“ Dadurch können sie schneller liefern (in Form von Prototypen, Produktinkrementen und Minimal Viable Products, vgl. Kapitel 6), erhalten früher Kundenfeedback und können diese Erkenntnisse nutzen, um nachfolgende Iterationen und Inkremente inhaltlich und prozessual an die neuen Bedingungen zu adaptieren.
So gelang es beispielweise der STADTSPARKASSE DÜSSELDORF, ein agiles Projekt mit mehr als 60 Mitarbeitenden auf die Beine zu stellen, die innerhalb kürzester Zeit ein Corona-Soforthilfeprogramm entwickelten, mit dem Ziel, Firmenkunden schnell und unbürokratisch Liquidität zu verschaffen. Aufgrund der aktuellen Krisensituation hatte das Vorhaben hohe Priorität. Die Projektteams verständigten sich darauf, eine funktionierende und schnelle Lösung einer perfekten vorzuziehen. Prozesse und Abstimmungsrunden konnten dadurch enorm verkürzt werden, mit dem Ergebnis, dass eine Erstversion bereits nach 26 Stunden vorlag, die Liveschaltung nach 59 Stunden erfolgte und die ersten Kreditanträge bereits nach 99 Stunden ausgezahlt werden konnten.94
Organisiert wird idealerweise nur so viel, wie es die kundenorientierte Ausrichtung des Wertstroms erfordert. Die agilen Teams (vgl. Kapitel 4.3) erhalten weitreichende Kompetenzen und Priorisierungswerkzeuge, damit sie Aufgaben eigenverantwortlich einschätzen und transparent bewerten können. Im Mittelpunkt steht dabei stets der Kundennutzen, der in Relation zum korrespondierenden Umsetzungsaufwand den Return on Investment darstellt. Die Handelnden sind dadurch in der Lage, den Fokus auf die Fertigstellung der wertschöpfenden „Features“ zu richten. Wenn zu viele Aufgaben gleichzeitig auf dem Tisch liegen, dann sind zwar alle beschäftigt, ein funktionales Ergebnis für den Kunden lässt aber oft auf sich warten, wenn ständig zwischen Aufgaben hin und her gesprungen wird und man sich verzettelt. Es ist daher wichtig, sich auf die Fertigstellung und Lieferung der Inkremente zu konzentrieren. „Work in Process/Progress“-Limits (WIP-Limits, vgl. Kapitel 6.2) beispielsweise disziplinieren die Handelnden dabei, priorisierte Aufgaben zuerst fertigzustellen, bevor mit neuen begonnen werden kann.
Pull-Prinzip
Die Auswahl der in der nächsten Iteration fokussiert zu bearbeitenden Anforderungen und die Verteilung der Arbeit erfolgt in agilen Organisationen nicht wie in klassisch-hierarchischen Systemen zentral nach dem sogenannten Push-Prinzip, bei dem Aufträge „top down“ – von oben nach unten – in das System „gedrückt“ werden (vgl. Kapitel 3). Denn hier drohen Kapazitätsengpässe und personelle Überlastungen – sowohl an der Spitze, durch ein Zuviel an Entscheidungszentralisation, als auch an der Basis, durch das Input-getriebene „pushen“ von Aufträgen.
Stattdessen dominiert in agilen Prozessen das umgekehrte Pull-Prinzip. Hierbei werden die Aufträge von den operativ ausführenden Akteuren in den agilen Teams „gezogen“. Steuerung und Arbeitsteilung erfolgen eigenverantwortlich und selbstorganisiert. Dadurch sollten nur so viele Aufträge angenommen werden, wie Ressourcen und Personalkapazitäten zu gegebenen Zeitpunkten vorhanden sind. Wenn dies gelingt, kann es in agilen Organisationen idealtypisch nicht zu einer Überlastung kommen (vgl. zum Pull-Prinzip ausführlich die Kanban-Methode in Kapitel 6.2).
Hier tritt auch wieder der enge Bezug zu den Lean-Ansätzen (vgl. Kap. 2.2) in den Vordergrund, die mit dem sogenannten Just-in-Time-Prinzip und One-Piece-Flow-Konzept einen perfekt aufeinander abgestimmten und synchronisierten Arbeitsfluss anstreben, bei dem Werkstücke ohne Unterbrechung und Liegezeiten über den gesamten Produktionsprozess bis zu deren Fertigstellung durch einen Mitarbeiter oder ein Team begleitet werden.95 Übertragen auf die agile Organisation bedeutet diese Vorgehensweise, dass die Mitarbeiter eines Entwicklungs- oder Produktionsprozesses alle anfallenden Aufgaben beherrschen, diese selbstständig koordinieren, selbstorganisiert verrichten, und dadurch für den Gesamtprozess und das Ergebnis (-Inkrement) Verantwortung übernehmen.
Zusammenfassend lässt sich für Kapitel 4.2 festhalten, dass agile Prozesse danach streben, in einem inkrementellen, auf jeweils einzelne Aspekte fokussierten und von Kundenfeedback geprägten Lernprozess, eine möglichst optimal zum wahren Kundenbedürfnis passende Lösung zu entwickeln. Die Aufgaben bzw. Aktivitäten werden dabei nicht fremdorganisiert vorgegeben, sondern von den operativ verantwortlichen Menschen bzw. Teams selbst „gezogen“.
4.3 Agile Strukturgestaltung
Auch im Hinblick auf die Gestaltung von Strukturen gibt es einige typische Charakteristika einer agilen Organisation, die im Folgenden vorgestellt werden. Wie diese in konkreten Strukturansätzen angewendet bzw. umgesetzt werden, wird dann später in Kapitel 8 erläutert.
Cross-funktionale Teams
Was TOYOTA in den sechziger Jahren eingeführt hat, versuchen andere bis heute: autonome Teams, die Probleme schneller lösen als funktionale Spezialisten oder Arbeitsgruppen.96 Für viele Experten und Managementberater sind funktionierende Teamstrukturen das wichtigste Merkmal einer erfolgreichen Unternehmens- und Organisationsentwicklung. JEFF SUTHERLAND, der Erfinder von Scrum, formuliert bespielhaft: „[T]eams are what makes the world go ‘round.”97
Weil agile Teams eine Themenstellung umfassend bearbeiten sollen, müssen auch alle benötigten Kompetenzen und Perspektiven im Team vertreten sein. Dafür braucht es Vertreter verschiedener fachlicher Funktionen, weshalb von cross-funktionalen Teams gesprochen wird.98
Deshalb bilden beispielsweise Krankenhäuser interdisziplinäre Case-Teams, die sich auf den Therapieerfolg ihrer Patienten ausrichten. Banken bilden cross-funktionale Teams, um den digitalen Vertrieb für Privatkunden zu positionieren. Stadtwerke besetzen ihre ÖPNV-Teams für die Steuerung und Organisation des öffentlichen Personennahverkehrs interdisziplinär mit Programmierern, Produktmanagern, Business-Analysten und Verkehrsplanern. Dabei müssen keinesfalls immer alle Unternehmensfunktionen enthalten sein, aber die für die konkrete Problemstellung relevanten. Das heißt, wenn z. B. ein Chatbot für den Kundenservice gebaut werden soll, dann sollte zwingend ein Mitarbeiter aus dem Kundenservice im Team sein. Genauso muss ein Vertriebler eingebunden sein, wenn ein neues Vertriebssystem entwickelt wird.
Bei der Zusammenstellung der Teams gilt die Regel: Das Team muss (im Hinblick auf die nötigen Kompetenzen und Perspektiven) so groß wie nötig sein, aber (im Hinblick auf die Koordination) so klein wie möglich. Um schnell handlungs- und anpassungsfähig zu sein, sind agile Teams, mit typischerweise maximal 9 Personen, relativ klein.
Ein wichtiger Erfolgsfaktor agiler Teams ist daher auch die Kompetenz der Teammitglieder. Agilität ist keine Abkehr vom Leistungsprinzip, kein Bällebad, Ponyhof oder „Ringelpiez mit Anfassen“, sondern fordernd und anstrengend. Agile Teams müssen leisten. Dafür braucht es gute bzw. exzellente Leute.
Der Streaming-Anbieter NETFLIX beispielsweise ist sehr agil aufgestellt und setzt auf ausgeprägte Entscheidungsfreiheit. CEO REED HASTINGS äußert häufig und gerne, dass er kaum Entscheidungen trifft bzw. treffen muss. Aber er erläutert auch, dass es ein wesentliches Element der Erfolgsgeschichte von NETFLIX ist, dass nach der Dotcom-Krise von einer Familienkultur, bei der man das schlechte Benehmen eines Bruders toleriert, zur Leistungskultur einer Fußballmannschaft gewechselt wurde. Man will lieber 10 Top-Spieler als 20 Durchschnittsspieler haben. Jeder darf auch mal einen Elfmeter verschießen, aber wer nicht angemessen „kicken“ kann bzw. das Team nicht weiterbringt, ist in einem anderen Unternehmen besser aufgehoben.99
Damit die Zusammenarbeit in gemischten Teams funktioniert, sind sogenannte „T-Shaped Profiles“ hilfreich. Diese Kompetenzprofile beschreiben ein breites, interdisziplinäres Basisverständnis (bei möglichst allen Teammitgliedern), kombiniert mit mindestens einer tiefen Fachexpertise (die bei den einzelnen Teammitgliedern unterschiedlich ist). In Summe decken solche Teams dann ein größeres Kompetenzfeld ab als homogene, funktional-fokussierte Teams (vgl. Abbildung 19).
Abb. 19: T-Shaped Kompetenzprofil
Solche kleinen, interdisziplinären, kompetent besetzten und autonomen Teams sind prädestiniert dafür, komplexe Aufgabenstellungen iterativ und inkrementell zu lösen.100 Als hierarchiearme Strukturen sind sie relativ gut in der Lage, Veränderungen zu antizipieren, um flexibel darauf zu reagieren. Für Routinetätigkeiten, wie z. B. im Einkauf, im Rechnungswesen oder der Anlagenwartung, wo es üblich ist, klar determinierte Prozesse mit fachlicher Expertise immer wieder auf die gleiche Art und Weise standardisiert abzuarbeiten, sind agile Teams dagegen weniger geeignet.
RIGBY et al. nennen folgende Voraussetzungen für erfolgreiche agile Teams:101
Das Team muss sich auf eine Geschäftschance mit hohem Potenzial konzentrieren,
es muss für die konkreten Ergebnisse verantwortlich sein,
es muss das nötige Vertrauen, klare Entscheidungsbefugnisse und ausreichend Ressourcen bekommen, um selbstorganisiert arbeiten zu können,
es muss entschlossen sein, agile Werte zu leben und agile Methoden anzuwenden,
es muss in der Lage sein, eng mit dem Kunden zusammen zu arbeiten,
es muss fähig sein, schnell Prototypen zu fertigen und enge Feedbackschleifen zu fahren,
es muss von Topmanagern unterstützt werden, die Hindernisse aus dem Weg räumen und dafür Sorge tragen, dass die Ergebnisse der Teamarbeit auch verwendet werden.
Wichtig für den Erfolg ist es auch, die Teamautonomie so zu dosieren, dass operativer Wildwuchs vermieden und kreative Freiräume geschaffen werden können. Auf diese Weise funktionieren z. B. OP-Teams im Krankenhaus und Teams im Flugzeug-Cockpit. Bei Mannschaften im Teamsport ist es ähnlich. Eine Basketball-Mannschaft hat einen Spielmacher, Flügel- und Center-Spieler. Sie spielen genau auf der Position, die sie am besten beherrschen, können sich aber auch gegenseitig aushelfen und sich neu sortieren, falls es mal „knapp“ werden sollte. Und alle folgen einer gemeinsamen Strategie und dem Ziel, dieses Spiel zu gewinnen und die Saison erfolgreich abzuschließen. Vor diesem Hintergrund kommt dem Thema Führung – auch bzw. gerade in agilen Teams – eine große Bedeutung zu. Führungskräfte sind gut beraten, wenn sie ihre Leadership-Aufgabe trotz autonomer Teamstrukturen weiterhin wahrnehmen (vgl. Kapitel 9 und die Beiträge von HARTMANN und SCHULLER/FUCKER).
Modularisierung
Agile Teams agieren weitgehend als autonome Einheiten bzw. Module, mit möglichst klar abgegrenzten Gestaltungs- und Verantwortungsbereichen.102 Die crossfunktionale Zusammenstellung dient dazu, dass die Teams möglichst ein ganzes Produkt(teil) oder einen kompletten Kunde-zu-Kunde- bzw. End-to-end-Prozess (vgl. Kapitel 4.2) abbilden, sodass die Kundenausrichtung nicht unter unnötigen internen Schnittstellen leidet. In agilen Strukturen wird auch gerne die Entwicklung (Development) mit dem Betrieb (Operations) zu einem „DevOps“-Modul verbunden, statt in getrennten Silos gegliedert. Dadurch ist es reibungsloser, d. h. abstimmungsärmer möglich, Weiterentwicklungen in den laufenden Betriebsprozess einzubauen.
Die organisatorischen Einheiten in agilen Systemen bilden sich dementsprechend primär nach Objekten, anstatt funktional nach Verrichtungen. Die Objekte können ähnlich wie bei der divisionalen Organisationsstruktur z. B. Produkte, Kundengruppen, Regionen oder auch Technologien sein (vgl. Kapitel 3.3). In agilen Strukturansätzen (vgl. Kapitel 8) werden solche Module häufig als Kreise dargestellt, in Abgrenzung zu den Kästchen in klassischen Organigrammen.
Die Module können unabhängig voneinander entwickeln, produzieren und testen. Die Modularisierung ermöglicht eine höhere Flexibilität und erlaubt einen stärkeren Fokus durch die schnittstellenarme Organisation der einzelnen Einheiten. Ein Vergleich zwischen monolithischen und modularisierten Systemen zeigt, dass die Zerlegung eines Gesamtsystems in kleinere schnittstellenarme Einheiten höhere Geschwindigkeiten und Flexibilität ermöglicht. Während in monolithischen Systemen die Entwicklung und das Testen einzelner Services oder Funktionalitäten (Features) jedes Mal den Aufbau des kompletten Prototyps als Gesamtsystem mit dem vollen Funktionsumfang erfordert, erlaubt ein modulbasiertes Vorgehen die kontinuierliche und parallele Entwicklung und Verbesserung einzelner Inkremente (vgl. auch den Beitrag von BREHM).
Modulbasierte Ansätze finden sich z. B. in sogenannten Micro-Services wie sie von AMAZON oder NETFLIX eingesetzt werden, um ihre Online-Dienstleistungen bereitzustellen. Nach dem Prinzip der Funktionsbindung stellt ein Micro-Service bzw. ein Modul immer eine fachliche Einheit dar, sodass sich Anforderungen jeweils nur auf einen Micro-Service beziehen.103 Module müssen also so voneinander abgegrenzt werden, dass sie möglichst wenig Schnittstellen untereinander haben und unabhängig gestaltet werden können. Durch diese Entkoppelung können Teams parallel und losgelöst voneinander arbeiten. Die Integration einzelner Module wird durch entsprechende Plattformen bzw. Infrastrukturen sichergestellt, das sind Standardschnittstellen, die die Kompatibilität verschiedener Baugruppen oder Module gewährleisten. Das Modulkonzept macht sich auch die Industrie zunutze, denn zunehmende Dynamik, steigender Zeitdruck und lange Zuliefererketten, beispielsweise im Maschinen- und Anlagenbau, erfordern flexiblere Prozesse, damit sich Entwicklungs- und Herstellungszeiten nicht unnötig in die Länge ziehen. Es gilt daher, die System- oder Produktarchitektur in überschaubare und abgrenzbare Module mit klar definierten Schnittstellen zu zerlegen („Plug & Play-Struktur“). Jedes Modulteam erhält dadurch seine eigene End-to-end-Sicht, die ziel- und ergebnisorientierte Ausrichtung der Tätigkeiten lässt sich leichter herstellen – die Identifikation mit dem eigenen Handeln wird gestärkt, was wiederum positiv auf das selbstorganisierte und eigenverantwortliche Verhalten der Akteure ausstrahlt.
Verändert sich die Ausrichtung in den Modulen, beispielsweise aufgrund neuer technologischer Anforderungen bzw. sich ändernder Kundenerwartungen, dann sind Anpassungen auf der Handlungsebene leichter nachzuvollziehen und können schneller umgesetzt werden. Reaktionsfähigkeit und -geschwindigkeit sind in solchen Systemen typischerweise höher als in funktional ausgerichteten Strukturen, in denen Veränderungen und Anpassungen lange Entscheidungswege nach sich ziehen, die zudem oftmals getrennt von den ausführenden Tätigkeiten auf der Handlungsebene über verschiedene hierarchische Leitungsebenen laufen.
Die eigentlichen Auslöser oder Beweggründe einer Entscheidung oder der Entscheidungskette drohen in hierarchischen Systemen zu verwässern – sie bleiben oft denjenigen verschlossen, die diese Entscheidungen letztlich umsetzen sollen. Die strukturell herbeigeführte Trennung zwischen Entscheidung und ausführender Handlung, die ursprünglich dazu diente, Systeme transparenter, steuerbarer und damit effizienter zu machen, erzeugt in der VUCA-Welt das Gegenteil. Hinzu kommt, dass die Einstellungs- und Verhaltensakzeptanz der Akteure permanent strapaziert wird, wenn die Änderungen nicht nachvollziehbar sind und wiederholt erklärt werden müssen. Der Anteil an offenen und verdeckten Opponenten ist in hierarchischen Strukturen daher fast zwangsläufig höher als in agilen Strukturen, in denen Entscheidung und ausführende Handlung – „Denken und Machen“ – eigenverantwortlich und selbstorganisiert erfolgen und dort stattfinden, wo der Objektbezug, der direkte Markt- bzw. Kundenkontakt, besteht.
Ein Beispiel für autonome Module liefert auch BUURTZORG, ein niederländischer Anbieter ambulanter Pflege.104 Das Unternehmen ist in über 900 sich selbst organisierende, agile Teams bzw. autonome Module aufgeteilt, mit je 12 Pflegekräften. Jedes Team hat ein Gebiet mit 10.000 Einwohnern und entscheidet eigenverantwortlich über Kundenakquise/-betreuung, Raummietungen und Mitarbeiterrekrutierung, sowie die zugehörigen Zeitpläne und Budgets. Zur internen Koordination haben die Teams bei BUURTZORG jeweils gleichartige Rollen, wie Planer, Entwickler, Haus- und Schatzmeister, Leistungskontrolleur und Mentor. Diese werden von den Pflegekräften in Teilzeit übernommen. Alle Mitarbeiter werden darin geschult, Entscheidungen in der Gruppe zu treffen, Konflikte zu lösen und sich gegenseitig zu coachen. Dadurch sind die Teams sehr autonom und können sich schnell an Veränderungen und spezifische Kundenbedürfnisse anpassen. Die Fluktuation ist nur halb so hoch wie bei den Wettbewerbern, die Kundenzufriedenheit um 30% höher. Zur Sicherung der Koordination und Effizienz gibt es zwar eine Zentrale, diese umfasst aber nur 50 Verwaltungsmitarbeiter (insb. in der IT), 36 Coaches und 2 Direktoren. Die Gemeinkosten liegen 2/3 unter dem Durchschnitt der Wettbewerber.
Wenn Produkte bzw. End-to-end-Prozesse die Zusammenarbeit von mehreren agilen Teams bzw. Modulen erfordern, bedarf es aber (nach wie vor) entsprechender Koordinationsstrukturen, die einerseits eine integrierte Gesamtleistung gewährleisten, andererseits den agilen Teams eine möglichst große Autonomie ermöglichen. Wie dies aussehen kann, erläutert beispielsweise Kapitel 8.2 am SPOTIFY-Modell.
