Die Unternehmensstruktur für wahre Agilität

Kaum ein größeres Unternehmen kommt heute ohne Daily Stand-ups, Sprints und Kanban-Boards aus. Agil zu arbeiten gilt als selbstverständlich, und doch bleibt die Organisation dahinter in den meisten Fällen eine klassische Hierarchie mit Abteilungen, Budgets und Entscheidungswegen aus der Zeit der Industrialisierung. Dieser Beitrag zeigt, warum wahre Agilität keine Frage der Methode ist, sondern der Unternehmensstruktur: vertikal geschnittene Produktteams, dezentrale Entscheidungen, Führung über Ziele und Software, die die Teams koordiniert.

Agilität ist eine Strukturfrage, keine Methodenfrage

Der Begriff der agilen Arbeitsweise stammt aus der Softwareentwicklung. Weil sich das Endergebnis eines Softwareprojekts im Vorhinein nie exakt festlegen lässt, haben sich selbstorganisierende, funktionsübergreifende Teams als die geeignetste Form erwiesen, gemeinsam an einer Lösung zu arbeiten: adaptive Planung, kurze Iterationen, tägliche Abstimmung über erledigte Aufgaben und Hindernisse, laufendes Feedback der Nutzerinnen und Nutzer. Dieser Ansatz verkürzt Durchlaufzeiten, bringt unterschiedliche Perspektiven an einen Tisch und erhöht die Qualität der Ergebnisse.

Beraterinnen und Berater sowie Managerinnen und Manager haben dieses Vorgehen in den vergangenen zwei Jahrzehnten auf ganze Organisationen übertragen. Seit dem Scientific Management des frühen 20. Jahrhunderts, dem Taylorismus und Fordismus, hat kaum ein Managementansatz so viel Zuspruch erfahren wie das agile Management. Der Grund ist einfach: In einer Welt, in der neue Technologien ganze Branchen innerhalb weniger Jahre umbauen, müssen Unternehmen extrem anpassungsfähig sein. Und Wachstum, das auf der permanenten Veränderung von Strukturen und Rollen beruht, lässt sich mit starren Plänen nicht mehr steuern.

Dass sich das auch wirtschaftlich auszahlt, legt eine Befragung von PA Consulting (2019) unter 500 hochrangigen Führungskräften nahe: Die zehn Prozent finanziell leistungsstärksten Unternehmen der Stichprobe sind mit knapp 30 Prozent höherer Wahrscheinlichkeit agil organisiert.

Und doch beobachten wir in unseren Projekten ein Muster, das ich für das eigentliche Problem halte: Übernommen werden die Rituale, nicht die Struktur. Die Teams halten ihre täglichen Abstimmungen ab, planen in Sprints und führen Retrospektiven durch. Budget, Personalverantwortung und die Entscheidung, was überhaupt gebaut wird, laufen aber weiterhin über Abteilungsgrenzen und Hierarchiestufen. Das Ergebnis sind agile Inseln in einer hierarchischen Organisation. Eine Methode lässt sich in wenigen Wochen einführen. Eine Struktur zu ändern dauert Jahre, und genau deshalb wird dieser Schritt so oft ausgelassen.

Die Bremser: gewachsene Strukturen und alte Software

Organisatorische Agilität bedeutet in vielen Fällen, das Geschäftsmodell grundlegend zu überarbeiten. Dabei werden viele Unternehmen von zwei Dingen ausgebremst: von gewachsenen, starren und komplexen Organisationsstrukturen und von veralteter Software. Beides hängt enger zusammen, als es auf den ersten Blick scheint, denn die Software eines Unternehmens ist über die Jahre entlang seiner Abteilungen gewachsen, und die Abteilungen haben sich um ihre Systeme herum verfestigt.

Ein Beispiel aus der Bankenbranche, das ich in meinem Buch „Das selbstfahrende Unternehmen“ (Springer Gabler 2021) ausführlicher beschreibe: Die wichtigsten Kernbankanwendungen eines Großteils der systemrelevanten Banken in Europa wurden in COBOL oder verwandten Programmiersprachen aus den 1950er Jahren geschrieben. Die Technologie dahinter beruht auf der Lochkarte, die ursprünglich zur Steuerung mechanischer Webstühle entwickelt wurde. Diese Banken arbeiten also mit einem dreistufig weitergeführten System, das auf dem Webstuhl beruht, und versuchen gleichzeitig, nach außen ein Omnichannel-Erlebnis zu bieten: dieselben Informationen und Geschäftsmöglichkeiten am Schalter, am Telefon, auf der Website, in der App und im Messenger. Nach meiner Einschätzung im Buch verfügen etwa 80 Prozent aller Banken über diesen Altbestand. Dass damit keine hohe Agilität entsteht, liegt auf der Hand. Nahezu alle Führungskräfte in den Banken wissen, dass der Weg zur echten Modernität nur über die vollständige Erneuerung der technischen Basis führt. Bis heute ist kaum jemand bereit, diesen Schritt zu setzen.

Ähnliche Szenarien finden sich in anderen traditionellen Branchen. Wie Struktur und Systemlandschaft zusammenspielen müssen, habe ich im Beitrag Enterprise Architecture für selbstfahrende Unternehmen beschrieben. Hier geht es um die andere Seite derselben Medaille: die Organisation.

Vertikaler Produktschnitt statt horizontaler Service-Schichten

Wie eine agile Struktur aussieht, lässt sich am besten an Softwareunternehmen zeigen. Wer sich konsequent an den Erwartungen der Kundinnen und Kunden ausrichtet, entwickelt sich vom IT-Service-Provider zum Digital-Solution-Provider. Nicht die Produktperspektive des Herstellers zählt, sondern die Bedürfnisperspektive der Nutzerinnen und Nutzer: Welches Problem lösen wir? Wer auf diese Frage laufend reagiert, macht seine Services besser, stärkt die Kundenbindung, wird weiterempfohlen und senkt die Akquisitionskosten.

Voraussetzung dafür ist ein vertikaler Produktschnitt. Klassische Organisationen sind horizontal geschnitten: Es gibt je Aufgabe ein abgegrenztes Team, eine Vertriebsleitung, die den Markt kennt, eine Forschungs- und Entwicklungsabteilung, eine Marketingabteilung, ein Rechenzentrum. In den vergangenen Jahrzehnten wurden diese Service-Schichten wie mehrlagige Sandwiches übereinandergelegt, weil sich so bei sehr vielen Mitarbeiterinnen und Mitarbeitern Kostensynergien heben ließen. Der Preis dafür sind Brüche zwischen den Einheiten, Reibungsverluste, machtpolitische Grabenkämpfe und die Neigung jeder Abteilung, eigene Ziele zu entwickeln und eigene Interessen zu verfolgen. Die ganzheitliche Perspektive auf das Produkt und die gemeinsame Vision fehlen.

Beim vertikalen Produktschnitt wird ein Produkt oder Service über seinen gesamten Lebenszyklus von einem Team verantwortet: von der Erhebung der Kundenanforderungen über Prototyp, Test und Betrieb bis zu Lifecycle-Management und Growth Hacking. An der Spitze stehen Produktmanagerinnen und Produktmanager, die mit allen relevanten Akteurinnen und Akteuren im Unternehmen vernetzt sind. Die Zusammenführung von Fachbereich, Entwicklung und IT-Betrieb in einem Team ist als BizDevOps bekannt. Weil die Verantwortung für ganze Produkte nun beim Team liegt, muss dort auch die Entscheidungskompetenz liegen. Diese Dezentralisierung ist der größte Vorteil agiler Organisationen: Entscheidungen fallen dort, wo die Information ist, und das Unternehmen kann praktisch in Echtzeit auf Veränderungen reagieren.

Die Einführung eines vertikalen Produktschnitts ist eine radikale Änderung der Organisationsform, keine Ergänzung. Welches agile Organisationsmodell ein Unternehmen wählt, ist zweitrangig; entscheidend ist, dass Agilität auf allen Ebenen eingeführt wird. Ein Unternehmen, dessen Führungsebene selbst nicht agil arbeitet, wird die Struktur darunter früher oder später wieder in Abteilungen zurückzwingen.

Selbststeuernde Teams, geführt über Ziele

An die Stelle der hierarchischen Organisation mit abgegrenzten Abteilungen treten vielseitig vernetzte, selbststeuernde Teams. In jedem dieser Teams sind fachliche und IT-Expertise vereint; diese interdisziplinären Wirtschaftsinformatikerinnen und Wirtschaftsinformatiker werden zum Motor des Wandels. In der Praxis bewährt es sich, für die Transformationsphase gezielt neue Köpfe zu holen, deren Denken nicht von Jahrzehnten in Abteilungslogik geprägt ist, statt ausschließlich auf Umschulung zu setzen.

Geführt werden diese Teams nicht über Anweisungen, sondern über Ziele und messbare Schlüsselergebnisse (Objectives and Key Results, OKR). Das Ziel gibt die Richtung vor, die Schlüsselergebnisse belegen Erfolg oder Misserfolg. Anders als beim klassischen Management by Objectives werden die Ziele nicht von oben kaskadiert, sondern von jeder Ebene selbst auf den eigenen Aufgabenbereich heruntergebrochen, und sie sind für das gesamte Unternehmen einsehbar. John Doerr hat das Vorgehen 1999 den Gründern von Google vorgestellt; seither definiert dort jede Mitarbeiterin und jeder Mitarbeiter die eigenen Schlüsselergebnisse vierteljährlich (Doerr 2018, „Measure What Matters“). Damit OKR wirken, müssen die Ziele inspirierend sein und die Frage nach dem Warum beantworten. Aus unserer Beratungspraxis wissen wir allerdings auch: OKR eignen sich zur Motivation, nicht zur verbindlichen Steuerung. Die Konzertierung vieler selbststeuernder Teams leisten sie allein nicht.

Führung verändert damit ihren Charakter. Statt des Top-down-Managements bleiben Führungspersönlichkeiten, die im Sinne einer transformationalen Führung durch die authentische Kommunikation ihrer Vision und durch Vorbildwirkung motivieren. Das mittlere Management, das seine Zeit mit dem Aufbereiten von Berichten und Zahlen verbringt, wird nach der These meines Buchs in den kommenden fünf bis zehn Jahren weitgehend von Algorithmen abgelöst, die diese Aufgaben selbstlernend schneller und besser erledigen. Allein dadurch werden die Hierarchien flacher.

Software koordiniert, Menschen führen

Damit die Dezentralisierung nicht im Chaos endet, braucht es auch in der agilen Organisation ein Rahmenwerk. Scrum liefert dafür eine bewährte Grundlage mit klaren Rollen: Der Product Owner trägt die fachliche Verantwortung, definiert die Aufgaben im Backlog und priorisiert sie; der Scrum Master trägt die Prozessverantwortung und räumt Hindernisse aus dem Weg; das Team wählt seine Aufgaben selbst und handelt während der Umsetzung autonom. Was dieses Rahmenwerk im selbstfahrenden Unternehmen von seiner klassischen Form unterscheidet, ist die Rolle der Software.

Die Koordination der vielen Teams übernehmen nicht Koordinationsmeetings, sondern zentrale, vernetzte Softwaresysteme, heute etwa Werkzeuge wie Atlassian Jira. Über Backlogs werden Aufgaben und Anforderungen erfasst, Produktmanagerinnen und Produktmanager bereiten sie für ihre Teams auf, und die zentrale Software stellt im laufenden Betrieb automatisiert sicher, dass alle Teams auf das gemeinsame Ziel ausgerichtet bleiben. Mit jeder Rückmeldung wird diese Software besser werden: Künstliche Intelligenz wird aus den Ergebnissen lernen, Engpässe früher erkennen und Aufgaben treffsicherer verteilen. Im Buch unterscheide ich dafür zwei Zusammenarbeitsmodelle: selbstorganisierende Teams, die selbst entscheiden, wie sie ihre Arbeit erledigen, und softwaregesteuerte Teams, in denen die Software jedem Teammitglied Aufgaben samt Durchführungsanleitung zuweist und die Qualität misst. Beide Formen werden nebeneinander bestehen, je nachdem, ob eine Aufgabe Kreativität und Empathie verlangt oder standardisierbar ist.

Ein Punkt ist mir dabei besonders wichtig, weil er in vielen Transformationen übersehen wird. Die Einführung dieser Organisationsform dauert in großen Unternehmen nach unserer Erfahrung drei bis fünf Jahre und führt erst danach zu einer Leistungssteigerung. Diese Steigerung tritt nur ein, wenn die Abläufe und die Administration radikal automatisiert werden. Andernfalls empfinden die Mitarbeiterinnen und Mitarbeiter die neue Struktur als manueller und aufwendiger als die alte, weil sie die Koordination, die früher die Hierarchie übernahm, nun selbst leisten müssen.

Die wichtigste Zutat für agile Organisationen ist die bedingungslose Automatisierung der Administration.

Genau hier schließt sich der Kreis zum selbstfahrenden Unternehmen. Agile Struktur, Führung über Ziele und koordinierende Software sind keine drei getrennten Vorhaben, sondern drei Seiten desselben Umbaus. Wer die Struktur ändert, ohne die Software zu erneuern, erzeugt Reibung. Wer die Software erneuert, ohne die Struktur zu ändern, zementiert die Abteilungen in neuen Systemen. Wie Algorithmen die klassischen End-to-End-Prozesse ablösen, habe ich im Beitrag Das Ende der Prozesse, hoch leben die Algorithmen beschrieben; die Unternehmensstruktur ist das organisatorische Gegenstück dazu.

Was das für Ihr Unternehmen bedeutet

Aus dieser Analyse ergeben sich fünf Prüffragen, die wir am Beginn jeder Transformation stellen:

• Methode oder Struktur? Prüfen Sie, ob Agilität in Ihrem Unternehmen nur in Ritualen existiert oder auch in Budgets, Personalverantwortung und Entscheidungsrechten. Nur Letzteres verändert die Reaktionsgeschwindigkeit.
• Produkte vertikal schneiden. Wählen Sie ein Produkt oder einen Service und übertragen Sie einem interdisziplinären Team die Verantwortung über den gesamten Lebenszyklus, inklusive Betrieb und Markt.
• Entscheidungen ins Team. Wo die Verantwortung liegt, muss auch die Entscheidungskompetenz liegen. OKR ersetzen die Zielkaskade, und das Top-Management arbeitet nach denselben Regeln.
• Administration automatisieren, bevor Sie skalieren. Koordination, Berichte und die Verteilung von Aufgaben gehören in Software, nicht in Meetings. Ohne diesen Schritt bleibt die neue Struktur ein Mehraufwand.
• Die technische Basis erneuern. Alte Kernsysteme diktieren alte Strukturen. Planen Sie die Erneuerung der Systemlandschaft als Teil der Organisationsentwicklung, nicht als IT-Projekt daneben.

Der nächste Schritt

Das Konzept der agilen Organisation als Bestandteil des selbstfahrenden Unternehmens, mit den Zusammenarbeitsmodellen, Rollen und Führungsinstrumenten, beschreibt mein Buch ausführlich: Zum Buch. Eine Zusammenfassung finden Sie im Beitrag Das selbstfahrende Unternehmen: Zusammenfassung des Buchs. Wenn Sie wissen möchten, wo Ihr Unternehmen zwischen Methodenagilität und Strukturagilität steht, buchen Sie ein Expertengespräch.