Warum Agilität an der Firmenkultur scheitert – und umgekehrt
Große Konzerne schauen zunehmend neidisch auf kleine Start-ups: Flache Hierarchien und der Verzicht auf formelle Prozesse resultieren in erstaunlicher Produktivität und der fehlende und bremsende Überbau an Bürokratie ermöglicht eine beachtliche Geschwindigkeit, Innovation und Kreativität.
Geschwindigkeit, Innovation und Kreativität: Genau die Dinge, die man im Konzern so schmerzlich vermisst. Es ist also nur logisch, dass man sich davon eine Scheibe abschneiden möchte. Wo die plumpe Imitation einer Start-up-Mentalität scheitert oder erst gar nicht in Frage kommt, hallt alsbald das Zauberwort agil durch die Flure. Denn die Konkurrenz ist selbstverständlich schon erfolgreich agil, jeder Berater liefert auf Anfrage im Handumdrehen fertige, hochskalierte agile Wollmilchsäue und selbst der Haus- und Hofdienstleister hat schon lange Erfahrung damit, wurde aber bisher einfach nie danach gefragt. Also schreibt man sich "agil" auf die Fahne, lässt Schwärme selbsternannter Evangelisten auf die Mannschaft los und ab geht die Reise in eine rosige Zukunft.
Doch der Weg des agilen Erfolgs ist gesäumt von gescheiterten Projekten, frustrierten Mitarbeitern, Widerstand, Grabenkriegen, verbranntem Geld und verschwendeter Zeit. Warum tun sich große Unternehmen so schwer mit der selbstindoktrinierten Startup-Mentalität?
Aus umfangreicher und schmerzhafter eigener Erfahrung gibt es meiner Meinung nach zwei Gründe dafür, die immer im Zusammenhang auftreten:
- Sie sind einfach nicht dafür gemacht
- Sie wollen agil sein statt agil zu werden
Warum große Unternehmen nicht dafür gemacht sind
Große Unternehmen sind groß, weil sie es perfektioniert haben, sich auf Effizienz zu trimmen. Alles muss möglichst mit wenig Aufwand (Kosten) funktionieren – also vereinheitlicht und standardisiert, jeder Individualität möglichst tiefgehend beraubt und natürlich skalierbar sein. Wachstum ist die Prämisse, Skalierung das alles beherrschende Paradigma. Tatsächlich aber ist Effizienz heute nicht unbedingt mehr nur ein Vorteil: "Es geht nicht nur mehr darum, möglichst effizient das immer gleiche Problem zu lösen, sondern aus immer neuen Probleme das wichtigste zu identifizieren (Effektivität) und dieses dann effizient zu lösen. Es ist also primär Effektivität gefragt und erst sekundär Effizienz. Zudem wird Effizienz nicht mehr zwangsläufig mit Standardisierung erreicht, sondern viel mehr mit Kreativität entlang der Frage: Wie können wir bestehendes Wissen im Unternehmen nutzen, um ein neues Problem zu lösen?" (Ari Byland) [1]
Skalierung – die zweite Paradedisziplin der großen Unternehmen – hat Begleiterscheinungen, die dem agilen Mindset nicht zuträglich sind. Skalierung (und Wachstum) erfordern nun mal Rollen und Prozesse, Vorschriften, Hierarchien, Gehaltsstufen, Zielvereinbarungen, Jahresgespräche, Growth Planning und Learning Paths.
De facto mündet ein Unternehmen, egal womit es sein Geld verdient, ab einer bestimmten Größe in einer Organisation mit mehreren, sich überschneidenden Silos.
Das Problem an diesen Silos ist, dass sie jeder aufkeimenden Agilität den Todesstoß versetzen: Sie wurden installiert um Zuständigkeiten und Verantwortungen zu verankern, sowohl in personeller als auch fachlicher Hinsicht. Sie unterliegen Budgets, dienen zur Abbildung von Performance, regeln Fort- und Weiterbildung und sind der Grundpfeiler all dessen, was sich im Dunstkreis des Begriffs "Skalieren" bewegt. Aber alleine schon das Thema "Budget" bedeutet das sichere Aus für Agilität: "Budgeting is built on two fundamental assumptions: the future is predictable, and that people can’t be trusted. It doesn’t get more un-Agile." (Bjarte Bogsnes) [2]
Budgetierung und ihr Erfüllungsgehilfe, die estimates, basieren also auf der Annahme, dass die Zukunft vorhersehbar oder zumindest einschätzbar ist. Agile Methodiken hingegen sind unter anderem deswegen entstanden, weil das mit dem "Schätzen und Planen" oft irgendwie nicht besonders gut funktioniert hatte und man stattdessen lieber schnell auf Veränderungen reagieren können wollte.
Der Begriff "Leadership" ist im Kopf und dem Herzen der Leute verankert
Ein weiterer Umstand, den Silos mit sich bringen (oder aus dem sie resultieren) ist: Das Management. Natürlich gibt es in agilen Organisationen auch eine Art der "Führung". Aber es gibt einen entscheidenden Unterschied: Während eine klassische Matrix-Organisation Manager hat, jeder mit einer eigenen Zuständigkeit und Verantwortung, kennt die agile Organisation lediglich den Begriff Leadership. Und der ist weniger in einem Organigramm verankert, als im Kopf und dem Herzen der Leute, die jemandem folgen, weil sie ihm vertrauen. Jemand, der statt ein Projekt zu managen die Menschen dahinter darin unterstützt, das Beste aus sich herauszuholen, der sie motiviert und fördert, anstatt ihnen Vorschriften zu machen und Entscheidungen an ihrer Stelle zu treffen.
In Summe führen alle Eigenschaften der Silos letztlich zu Effekten, die genau das Gegenteil von Agilität bedeuten, denn sie :
- erhöhen die Abhängigkeiten beim eigenständigen Lösen von Problemen,
- erschweren gemeinschaftliches und lösungsorientiertes Handeln, besonders über die Grenzen des Teams bzw. Projekts hinaus,
- begrenzen Kommunikation und Wissensaustausch,
- schränken Denken, Kreativität und Innovation ein,
- verhindern Lernen und Weiterentwicklung über das Tagesgeschäft hinaus und
- führen zu Amtsstuben-Mentalität, Routine und Abstumpfung.
Ein lebensfeindlicheres Umfeld für Agilität ist nur schwer denkbar.
Sollte man trotzdem versuchen, agil zu sein, ohne auf die altbewährten Silos zu verzichten (und die damit verbundenen Prozesse und Rollen), steht man vor einem viel größeren – aber oft versteckten – Problem. Es ist weder technisch noch fachlich, durch Prozesse oder gar den Verzicht auf selbige zu lösen, denn es ist kultureller Natur: Eine Änderung der Arbeitsweise im Unternehmen wird und kann per se nicht funktionieren, solange kein dazu passender Wechsel der Firmenkultur stattfindet. Mehr noch müsste in Wahrheit erst der kulturelle Wechsel vollzogen, gelebt und mit neuen Werten untermauert werden. Erst dann, aber dann aus Überzeugung, wird der Wechsel zur neuen Arbeitsweise gelingen!
Wer Agilität im Kleinen schon nicht richtig auf die Reihe bekommt, wird dank Skalierung grandiosen Schiffbruch erleiden
Dass die traditionellen Werte der alten Firmenkultur so lange und tief in der Firmen-DNA verankert waren, führt auch dazu, dass nach dem versuchten Wechsel zur agilen Arbeitsweise oft nur sehr wenig Zeit vergeht (wenn überhaupt) bevor die Rufe nach einer Skalierung des agilen Modells laut werden. Aber nun birgt Skalierung eine neue Gefahr: Die noch vorhandenen, eher kleinen Reibungsverluste in den Prozessen werden ebenfalls skaliert – und zwar bis zu einem Punkt, wo sich Blockaden ergeben, die man früher gar nicht kannte. Anders gesagt: Wer Agilität im Kleinen schon nicht richtig auf die Reihe bekommt, wird dank Skalierung grandiosen Schiffbruch erleiden.
Der Preis für erfolgreiches agiles Arbeiten ist hoch: Gefühlter Kontrollverlust. Konzentration auf das Wesentliche, wobei das Team entscheidet, was wesentlich ist. Vielen Kollegen, besonders denen im nahezu überflüssig werdenden mittleren Projektmanagement, ist dieser Preis zu hoch und so wird versucht, das eingesetzte agile Framework so "anzupassen", dass es zu den etablierten Silos und Prozessen passt. Das noch fragil-agile Rahmenwerk wird aufgebrochen, umgebaut und wieder zusammengesetzt. Was daraus entsteht, wird im Fachjargon als "frankengile" bezeichnet. Ein Geschöpf, das von außen agil aussieht, sich im Inneren jedoch wie eine typische, klassische Delivery verhält. Da fühlt man sich wohl, das kennt man. Und das nun wiedererkannte Delivery-Modell kann natürlich im Handumdrehen skaliert werden.
Leider ist das aber wie der Versuch, an einem neuen Flugzeug die Flügel zu kürzen, damit es in den existierenden Hangar passt. Das schicke neue Teil steht in der Garage bereit und alle am Boden sind zufrieden. Abheben wird das Gefährt jedoch nie.
Alle Versuche, agile Methoden zu skalieren, enden für gewöhnlich in einem Mischmasch aus Chaos, Gängelung und Willkür, der nicht besser funktioniert als vorher, aber dafür – weil skaliert – jetzt mehr Menschen frustriert. Oder sie enden in einem Moloch von Framework, bei dem man sich fragt, was daran jetzt eigentlich agil sein soll.
Es wird Zeit, den Mythos vom Heilsbringer des "scaled agile" zu zerstören
Gibt es also keinen Ausweg aus diesem Dilemma, dass agiles Vorgehen nicht zu einem großen Unternehmen passt? Doch: Aber die logische Konsequenz und die sich daraus ergebenden Notwendigkeiten sind für große Unternehmen schlichtweg nicht machbar: "Don’t scale agile... descale your organization." (Henrik Kniberg) [3]
Diese Aussage stammt tatsächlich von niemand geringerem als Henrik Kniberg, einem Pionier agiler Methodiken und einem der federführenden Beteiligten bei der Ausgestaltung des berühmten Spotify-Modell [4]. Knibergs retrospektive Einschätzungen zu seiner eigenen Veröffentlichung wurden bereits häufig kommentiert und analysiert – nicht zuletzt auch, um daraus ableiten zu können, warum das Skalieren von agilen Methodiken in die Dimensionen von Unternehmen nicht gelingen will. Bemerkenswert finde ich dabei das folgende Zitat aus einem Artikel von Anthony Mersino, der Knibergs Aussage kommentiert und es auf den Punkt gebracht hat: "It isn’t about changing agile to fit your company, it is changing your organization to achieve business agility." [5]
Wenn man nun überlegt, welche Konsequenzen sich aus dieser Aussage ergeben, fällt auf, dass wir uns im Kreis gedreht haben und wieder am Punkt Firmenkultur angekommen sind: Agile Prinzipien und die organische Firmenkultur großer Unternehmen passen nicht zusammen.
Bevor wir zum zweiten Punkt übergehen, sei mir aus gegebenem Anlaß hier noch eine Anmerkung zum Spotify-Modell gestattet: Es wird Zeit, den Mythos vom Heilsbringer des scaled agile zu zerstören: Wie Kniberg selber mehrfach berichtet hat, war es niemals als Modell oder Framework für skaliertes agiles Arbeiten gedacht, sondern lediglich eine Beschreibung der Modifikationen und Erweiterungen existierender agiler Frameworks für den Einsatz beim Kunden Spotify[6]. Leider entwickelte das Thema eine solche Eigendynamik, dass es ihm von ausgehungerten Skalierungsgläubigen aus den Händen gerissen wurde, die dann prompt Squads, Tribes und Guilds in ihren und anderen Unternehmen installierten, um dann darauf zu warten, dass sich der sicher geglaubte Erfolg einstellen würde. Leider hat das fast in keinem Fall besonders gut funktioniert, noch nicht einmal bei Spotify selbst, wie viele Beteiligte seither berichtet haben [7].
Und ganz ehrlich: immer wenn ich einen Blick auf die visuelle Darstellung des Spotify-Modells werfe, erkenne ich darin nichts anderes als eine mehrfach verschachtelte Matrix-Organisation:
Warum es ein Problem ist, "Agil zu sein" statt "Agil werden" zu wollen
Agilität lebt von der ständigen Selbstanalyse und der darauf basierenden Anpassung an sich verändernde interne oder externe Faktoren. Die Grundlage dafür sind zwei fundamentale Fähigkeiten:
- Das Vertrauen darauf, dass die beteiligten Akteure selber in der Lage sind, zu entscheiden, was das Beste in der aktuellen Situation ist und ihnen den kreativen Freiraum (auch zeitlich) dafür einzuräumen.
- Scheitern erlauben! Vielmehr noch, das Scheitern als positives Ereignis zu akzeptieren, um daraus lernen und sich wieder neuer (besser) verändern zu können. Im Grunde ist Scheitern die eine entscheidende Erfahrung, die das Verbessern überhaupt erst ermöglicht.
In den meisten Unternehmen sind kreativer Freiraum und der Mut zum Scheitern allerdings keine core values. Und dieses Bewusstsein zu schaffen ist eine elementare Hürde und der einzig wahre Grund, warum Agilität an Firmenkultur scheitert und umgekehrt.
Ja, das klingt zugegebenermaßen nach völlig planlosem Chaos
Das Irrwitzige daran ist, das das Scheitern der Agilität im Unternehmen selbst wieder ein Scheitern ist, aus dem die Unternehmen nichts lernen. Und wieder: weil Scheitern nicht als Chance zur Verbesserung, sondern als Versagen gesehen wird. Und so geht es immer und immer weiter; ein Teufelskreis aus dem Unternehmen nur durch einen Kulturwechsel ausbrechen können. Dieser Kulturwechsel erfordert bestimmte Fähigkeiten bei allen Beteiligten. Bei manchen müssen diese Fähigkeiten erst noch erweckt, bei anderen vielleicht nur gefördert werden. Bei allen aber müssen sie auf Dauer gecoacht werden. Dieser unbedingt nötige Entwicklungsprozess kann nicht eingespart oder übersprungen werden, indem man sich einfach der Weisheit anderer bedient und zu einem beliebigen agilen Framework aus dem Beraterregal greift.
Fazit
Wie kann ein solcher Wechsel gelingen? Oder, um es mit Knibergs Worten zu formulieren, wie "de-skaliert" man ein Unternehmen? Grob gesagt, indem man den disruptiven Charakter des agilen Arbeitens wörtlich nimmt und die Silos abbaut, die ein skaliertes Unternehmen ausmachen. Und das idealerweise auch gleich agil: Indem man klein anfängt, ausprobiert, scheitert und sich kontinuierlich verbessert. Also nicht, indem ein Plan zentralistisch schritt- und stufenweise befolgt wird, sondern indem man ein wenig Kontrolle aus der Hand gibt, die Leute (aber bitte unbedingt betreut) ausprobieren und sich offen über die Ergebnisse austauschen lässt. Ja, das klingt zugegebenermaßen nach völlig planlosem Chaos, ist aber nichts anderes als die berühmte grüne Wiese auf der man ausprobieren kann. Wichtig ist hierbei, dass man nicht nur an einer einzigen Stelle einen Versuch startet, sondern mehrere Teams parallel von der Leine lässt. Diese sollten inhaltlich nicht von zu identischer Natur sein, um den Eindruck von Wettbewerb zu vermeiden und es sollten nicht zu viele Teams sein, um eine konstante und dedizierte Betreuung durch agile Coaches gewährleisten zu können.
Auf der Reise zum agilen Unternehmen lege ich folgende Punkte als Reiselektüre an’s Herz:
- Agilität (Kreativität und Innovation) braucht Freiheit
- Freiheit erlauben bedeutet Kontrolle abgeben
- Sowohl zeitlich als auch finanziell
- Aber: Experimentelle Tätigkeiten über (großzügiges) Timeboxing steuern
- Wissenstransfer nicht fordern, sondern fördern
- Vom JourFix / Statusmeeting hin zu Learning Lunch, Brown Bag, Dashboards
- Spikes, Hackathons, Pairing, "public" Demos im Kollegenkreis
- Wikis statt Intranet, InnerSource statt Abschottung
- Scheitern akzeptieren (...und aus den Fehlern lernen)
- Veränderung feiern statt fürchten
- "Tue falsches – und rede darüber!"
- Leadership statt Management
- Potentiale erkennen, wecken, fördern
- in Teams und Menschen
- Möglichkeiten schaffen, statt Anweisungen zu erteilen
- Starkes persönliches Coaching statt starrer Lernpfade
- Ein Leader arbeitet für sein Team, nicht umgekehrt!
Dies sind nur einige Methoden, keine vollständige Liste, keine Checkpoints die man nacheinander abhakt. Sehen Sie es als Zutatenliste und entwickeln Sie Ihr eigenes Rezept daraus. Und bitte denken Sie immer daran, dass dies ein Entwicklungsprozess ist, kein Meilensteinplan. Freuen Sie sich über Erfolge und feiern Sie Fehlschläge als Erkenntnis, dass Ihr Rezept noch nicht jedem mundet. Ein Sternekoch zu sein bedeutet nicht, die Rezepte anderer erfolgreicher Köche zu servieren. Kurzfristig kann man damit zwar erfolgreich sein, um langfristig an der Spitze zu bleiben helfen aber nur Kreativität und Innovation. Und diese beiden Zutaten sind teuer – denn sie brauchen den Mut zum Scheitern und die Beharrlichkeit, es immer wieder neu zu versuchen.
- Ari Byland, 2020: Neue Unternehmenskultur — Weshalb?
- Bjarte Bogsnes, 2021: Agile transformation and the elephant in the room - why traditional budgeting is the antithesis of Agile and what to do about it
- Youtube: Hendrik Kniberg: Scaling Agile @ Spotify with Henrik Kniberg
- Hendrik Kniberg: Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds
- Anthony Mersino: There Is No Spotify Model for Scaling Agile
- Hendrik Kniberg: No, I didn’t invent the Spotify model
- Jeremiah Lee: Failed #SquadGoals
- ScalingAgile@Spotify