Probleme mit Agilität in Konzernen: Agil sein muss man auch wollen
(Bild: Pexels)
Ein Erfahrungsbericht von Marvin Engel veröffentlicht am
Ansätze wie das Spotify-Modell sollen großen Firmen helfen, agil zu werden. Wer aber erwartet, dass man es überstülpen kann und dann ist alles gut, der irrt sich.
Das erste Prinzip im Agilen Manifest lautet: "Individuen und Interaktionen über Werkzeuge und Prozesse". Gerade große Unternehmen tun sich mit diesem Prinzip aber schwer. Denn oft sind diese Organisationen über Jahre gewachsen und es gibt für alles und jedes einen Prozess: Onboarding, Offboarding, Beantragung von Zugängen, Software, Hardware, Personaldaten, Abrechnungen und vieles mehr. Wenn diese Prozesse überhaupt digital laufen, kann man sich als neue Mitarbeiterin oder neuer Mitarbeiter schon glücklich schätzen.
Zugegeben: Teilweise haben diese komplizierten Prozesse sogar rechtliche Gründe. Andererseits machen sie es aber schwer, eine reine Agilität zu etablieren. Zu sperrig ist der Umgang mit Veränderung, zu festgefahren die Struktur. Als jemand, der seit Jahren beruflich Firmen auf Agilität umgestellt hat, kann ich sagen: Das ist eine echte Herausforderung. Agilität lebt vom möglichst prozessfreien Handeln. Wie lassen sich also starre und über Jahrzehnte gewachsene Prozesse und Agilität in großen Unternehmen miteinander vereinen?
Es gibt nicht die eine Agilität
Aus meiner Sicht beginnt das Problem schon mit der Erwartungshaltung. Firmen fragen mich oft als erstes: Wie sieht Agilität in Reinform aus und wie können wir das möglichst schnell erreichen? Meine Antwort - und sie mag für viele unbefriedigend sein - ist immer, dass es diese eine Agilität gar nicht gibt. Nicht einmal die Verfasser des Agilen Manifests haben das behauptet. Auch sie wussten, dass die Arbeitsumstände 2021 andere sein würden als 2001. So wird zum Beispiel der Scrum Guide, der Leitfaden für das beliebteste aller agilen Frameworks, regelmäßig aktualisiert, weil sich die Rahmenbedingungen verändern.
Auf eine anfängliche Begeisterung für die agile Transformation folgt deshalb häufig die Ernüchterung, dass es sich doch nicht um die ultimative Weisheit handelt, die sich schnell etablieren lässt. Agiles Arbeiten ist - wie jede andere Form von Transformation - auch einfach harte Arbeit. Besonders in großen Unternehmen.
Allerdings gibt es Vorbilder und Modelle, die eine Antwort für Konzerne gefunden haben wollen. Eines dieser Beispiele ist das Spotify-Modell.
Skalieren wie bei Spotify - das Modell in der Theorie
Spotify hat es als Unternehmen geschafft, die eigene Art der agilen Organisation in ein international anerkanntes Modell zu überführen. Dabei werden verschiedene Levels und Abteilungen in sogenannte Tribes, Squads, Gilden und Chapter eingeteilt. Das soll vor allem für einen guten Kommunikationsfluss sorgen und dazu beitragen, dass sich verschiedene Teams regelmäßig untereinander austauschen und einander helfen.
Das Modell hat eine gewisse Berühmtheit erlangt. Zum einen natürlich, weil Spotify zum größten Musikdienst der Welt aufgestiegen ist, zum anderen, weil viele große Unternehmen wie die ING oder die Commerzbank das Modell bei sich implementiert haben. Das Spotify-Modell ist darauf ausgelegt, Agilität in sehr große Organisationen zu bringen.
Was passiert in Tribes, Squads, Chapters und Gilden?
In dem Modell ist die Belegschaft in unterschiedliche Gruppe unterteilt, die sich zum Teil überschneiden. Ich habe dieses Modell bereits mehrfach in Unternehmen eingeführt und bin dabei immer wieder auf Widerstände und Probleme gestoßen. Die Idee dahinter ist aber gut und sieht konkret so aus:
Squad: Ein Squad ist das arbeitende Team und die kleinste Einheit im Spotify-Modell. Es besteht aus mehreren Mitgliedern mit verschiedenen Kompetenzen. Nehmen wir zur Veranschaulichung an, es bestehe aus einem Frontend-Entwickler, einem Backend-Entwickler, einem Product Owner, einem Architekten und einem Business-Analysten. Das Squad trifft sich täglich und arbeitet auch räumlich dicht beieinander. In Zeiten von Corona oder bei internationalen Teams gibt es beispielsweise eigene Teams- oder Slack-Channels, in denen nur die Squad-Mitglieder miteinander sprechen. Die Entwicklungen des Squads sollten sich in der Ausrichtung des Tribes wiederfinden.
Tribe: Ein Tribe besteht aus mehreren Squads. Er kann eine thematische Einordnung haben, wie etwa ein Navigations-Tribe, ein Shop-Tribe oder ein Premium-Tribe - je nachdem, was entwickelt wird oder wie sich Teams sinnvoll unter einem Thema zusammenschließen lassen. Ein Tribe gibt in seiner Daseinsform das grobe Thema für die Squads wieder. Zum Beispiel könnte ein Squad im Shop-Tribe an einem besseren Checkout-Prozess im Onlineshop arbeiten.
Chapter: Ein Chapter erstreckt sich über mehrere Squads, hier kommen gleiche Kompetenzen, also Experten mit den gleichen Fachgebieten, aus verschiedenen Squads zusammen. In unserem Beispiel gäbe es ein Frontend- und ein Backend-Chapter, ein Architekten- und ein Business-Analysten-Chapter. Probleme, die nicht innerhalb eines Squads gelöst werden können, können hier diskutiert werden. Zum Beispiel könnte sich das Backend-Chapter eine effizientere Art und Weise für Datenspeicherung überlegen.
Gilde: In einer Gilde können sich für ein spezielles Problem bestimmte Personen aus den Squads zusammenschließen. Altmodisch könnte man eine Gilde auch als Arbeitsgruppe bezeichnen. Es kann aber auch regelmäßige Gildentreffen geben, die sich um bestimmte Squad-übergreifende Themen kümmern. In meinem Beispiel könnte eine Gilde gebildet werden, um interne Onboarding-Prozesse für neue Mitarbeiter zu verbessern.
Ich habe in großen Organisationen gearbeitet, in denen das Spotify-Modell als Vorbild für die agile Skalierung angewandt wurde. Ein Problem, das bei dieser Form der Organisation immer wieder auftrat, war, dass einige Beteiligte sich nicht vom Hierarchiedenken verabschieden konnten.
Dieses Festhalten an bestehenden Verhältnissen war eines von vier Hauptproblemen, die in solchen Projekten immer wieder vorkamen.
1. Squads sollten auf Augenhöhe mit den Tribes sein, sind es aber in der Praxis oftmals nicht.
Dass die Squads eigenständig ihre Arbeitspakete bestimmen, ist für die Verantwortlichen des Tribes mitunter ein großes Problem - kommen doch von ihnen und vom höheren Management die umzusetzenden Inhalte. Die Tribes stehen zumindest formal an der Spitze, in ehemals hierarchischen Strukturen werden sie daher oft als Chefs angesehen.
Sie geben die Richtung vor, während die Squads "nur" die ausführenden Abteilungen sind. In einem Transformationsprozess, den ich begleiten durfte, wurden ehemalige Programmverantwortliche plötzlich als Tribe-Leads eingesetzt. Sie kamen nur schwer davon los, ihre Untergebenen anzuweisen und mit Command & Control zu führen. Statt mit einer Vision die Richtung vorzugeben, bestimmten sie kleinteilig die zu liefernden Inhalte.
Meine Aufgabe bestand zu einem großen Teil darin, dafür zu sorgen, dass die Squads trotz thematischer Vorgaben ihre Eigenständigkeit bewahrten. Zudem arbeitete ich daran, hierarchisches Denken aufzulösen. Ich habe den Fall erlebt, dass mein Squad die Priorisierung der Entwicklungsaufgaben anders auslegte als vom Tribe-Lead vorgegeben; wir mussten dann gemeinsam einen für alle Seiten akzeptablen Zeitplan erstellen, so dass die Vorgaben zwar erfüllt, das Squad aber möglichst eigenständig planen konnte. Das ist häufig ein Balanceakt, der viel Fingerspitzengefühl erfordert.
2. Ziele von Großprojekten werden oft nicht ausreichend kommuniziert.
Die Fokussierung auf ein gemeinsames Ziel ist bei Agilität extrem wichtig: Was soll mit der Entwicklung schlussendlich erreicht werden? Arbeitet das Squad an diesem Ziel, sollte es weitgehend selbstbestimmt entscheiden, wie der Weg dorthin aussieht.
Dabei ist es völlig verständlich, dass ein Unternehmen einer Gruppe von 500 Personen nicht plötzlich ohne Einschränkungen oder Vorgaben erlaubt, in kleinen Teams hundertprozentig eigenverantwortlich zu arbeiten - zu viel Geld, das monatlich investiert wird, für zu wenig Kontrolle, die ausgeübt werden kann. Tatsächlich wird agile Freiheit von Mitarbeitern manchmal missverstanden, so dass Manager oft Angst haben, ihre Teams alleine arbeiten zu lassen.
Umgekehrt wissen die Teams häufig nicht, an welchen Zielen sie genau eigenständig arbeiten sollen. Wer liefert was und wann? Wie viel Investment muss ein Unternehmen tätigen, bis die geforderten Funktionen, Features, Tools, Entwicklungen fertiggestellt werden können? Und: Wer achtet darauf, dass einzelne Squads nicht in eine völlig falsche Richtung gehen? All dies sind Fragen, die gerade am Anfang einer agilen Transformation schwer zu beantworten sind. Ich rate daher dazu, die Vorgaben der großen Ziele, also was eigentlich erreicht werden soll, immer wieder in die Teams zu tragen.
"Wie oft sollen wir das denn noch sagen?"
Diese Aufforderung kann, wie in meinem Fall, dazu führen, dass das höhere Management fragt, wie oft sie ihre Ziele denn noch erklären sollten, langsam müssten es doch alle verstanden haben! Und wenn nicht, mögen sie die großen Ziele doch bitte untereinander teilen oder die angefügten Präsentationen lesen.
Ich erkläre ihnen dann, dass diese Methoden nicht funktionieren. Gerade große Teams und Gruppen brauchen immer wieder Anlässe, bei denen ihnen das große Ziel erklärt wird - ob täglich im Daily oder einmal die Woche in einem Status. Man könnte fast sagen: Je häufiger das große Ziel erklärt wird, je genauer dieses Ziel verstanden wird, desto besser und eigenständiger wird von allen Teammitgliedern genau in diese Richtung gearbeitet.
Oder um es mit einer Metapher zu sagen: Wenn ich weiß, dass ich nach Rom laufen soll, kenne ich den Weg oder die Wege dorthin vielleicht nicht genau, ich kenne aber das Ziel. An jeder Station, an jedem Bahnhof kann ich mich daher immer in Richtung Rom orientieren. Das hat weniger mit Vorgaben zu tun, sondern mit notwendiger Richtungsweisung.
Wenn die Teams die Richtung kennen, können sie schneller und eigenständiger dorthin gelangen. Es erstaunt mich immer wieder, wie eigenständig Teams arbeiten, wenn sie das große Ziel ihrer Bemühungen verstanden haben.
Ein anderes Problem in großen Unternehmen ist, dass die Umstellung auf agil oft schnell erfolgen soll. Die Wahrheit ist nach meiner Erfahrung aber: Es ist schwer, zäh und es dauert seine Zeit. Sind Unternehmen nicht bereit, dieses Investment zu tätigen, ist die Hoffnung meist schon am Anfang verloren. Eine übers Knie gebrochene Agilität hat zumindest in meinen Projekten noch nie vollends funktioniert.
Um einen agilen Transformationsprozess anzustoßen, ist es wichtig, dass das Topmanagement des Unternehmens bereit ist, das Risiko dieses Vorhabens mitzutragen. Zeitlich und finanziell. Denn sobald die Verantwortung an das mittlere Management übergeben wird, wird dieses alles dafür tun, den Status Quo zu halten und eine Art Scheinagilität zu etablieren. Dabei bleiben die Führungskräfte in ihrer hierarchischen Position und die Teams werden selten zu selbständigem Arbeiten entwickelt. Der Grund dafür ist die Angst, Fehler zu machen, die die eigene Position gefährden könnten.
4. Ein neues Modell ist kein Ersatz für eine etablierte Fehlerkultur.
Es muss eine Fehlerkultur etabliert werden, bei denen alle Mitarbeiter ohne Angst, offen und ehrlich Fehler begehen und ansprechen können. Ich habe oft die große Sorge wahrgenommen, dass Fehler die eigene, hart erarbeitete Position im Unternehmen in Frage stellen. Schaffen es Unternehmen, eine positive Fehlerkultur zu etablieren, ist ein wesentlicher Grundstein für agile Transformation gelegt.
Es gibt zahlreiche Möglichkeiten und Wege, eine Fehlerkultur zu etablieren. Ich rate dazu, sich bei diesem Prozess Hilfe von außen zu holen. Denn die Aufgabe ist schwerer, als sie sich anhören mag.
Groß denken und im Kleinen anfangen
Für unsere Weiterentwicklung brauchen wir Menschen, die Großes denken können. Wir brauchen Visionäre, die scheinbar Unglaubliches erreichen wollen, weil sie an etwas glauben und für dieses Ziel hart arbeiten. Lange wurde Elon Musk mit seinen Marsplänen belächelt - bis seine erste bemannte SpaceX-Rakete dann tatsächlich gestartet ist. Aber auch diese Menschen stehen morgens auf und brauchen einen Kaffee. Es ist also nicht unmöglich; viele kleine Schritte können am Ende zum Ziel führen.
Übertragen auf Agilität in großen Unternehmen heißt das: Ich plädiere dafür, dort nicht mit dem Hammer alles bisher Geschaffene zu zerschlagen und möglichst schnell ein wackeliges agiles Gebilde in die Mitte von Projekten zu setzen. Nur weil es ein erfolgreiches Beispiel wie das Spotify-Modell gibt, muss es nicht sofort funktionieren. Als Agiler Coach und Berater für Unternehmen habe ich nicht selten am eigenen Ast gesägt, wenn ich gesagt habe, dass wir im Kleinen mit der Agilität beginnen sollten. Es wird zu oft zu viel gewollt und sich dann darüber gewundert, dass Agilität nicht funktioniert. Das bringt diese Konzepte eher in Verruf.
Ein Kanban-Board in unseren täglichen Status-Meetings an die Wand zu werfen oder ein "Backlog" zu pflegen, in dem wir Dinge auf die lange Bank schieben können - das löst keines der Probleme, die Unternehmen mit Agilität haben. In erster Linie muss das viel gepriesene und inflationär verwendete "agile Mindset" in den obersten Chefetagen vorhanden sein. Wenn diese Manager an ihrer Befehlskette festhalten und Führung als Machtposition wahrnehmen, bringt auch das beste Modell der Welt nicht den gewünschten Erfolg. Eine große, gewachsene Organisation von heute auf morgen in einen agilen Modus versetzen zu wollen, führt meist zum Gegenteil, nämlich zu Frust und zu "Anti-Agilität".
Eine nachhaltige Kulturveränderung ist tatsächlich möglich!
Ich erkläre die Notwendigkeit für kleine, aber stetige Schritte meist so: Als untrainierte Person laufen wir ja auch nicht von heute auf morgen einen Marathon in Bestzeit, selbst wenn wir es mit aller Gewalt versuchen. Vermutlich erleiden wir einen Herzkasper im ersten Drittel des Weges - und wirklich Spaß macht so ein Gewaltlauf auch nicht. Deshalb muss Agilität behutsam und verantwortungsvoll in Unternehmen getragen werden. Das Training muss konstant und stetig sein. Mitarbeiter müssen abgeholt und mitgenommen werden. Das klingt nach Coach-Plattitüde, ist aber der Alltag, den ich wahrnehme.
Prozesse müssen umgestellt und abgeschafft werden, Hierarchien müssen aufgebrochen und verändert werden. Eine andere Art des Denkens muss in die Köpfe aller Beteiligten gebracht und die agilen Werte müssen nachhaltig verstanden werden. Das alles braucht Zeit und ja, das kostet auch Geld. Leider bekomme ich in meinem Job oft nicht mehr als ein paar Monate für dieses Vorhaben. Für eine nachhaltige Kulturveränderung, die entgegen der Meinung vieler möglich ist, ist eigentlich deutlich mehr Zeit nötig.
Marvin Engel ist selbständiger IT-Projektmanager, Coach, Berater und Trainer. Für Golem.de schreibt er seit 2018 Artikel aus seiner Berufspraxis. Seit Herbst 2020 berät er auch über die Plattform Shifoo von Golem.de IT-Profis in beruflichen Fragen.