Die Guillotine soll beweisen, wie ernst es mit der Agilität gemeint ist

Betrachtungen und Gedanken zur Agilität im Konzernumfeld
Bezogen auf die Agilitätsdebatte habe ich drei Vorprägungen: Erstens war ich dabei, als der in der Wüste der Dornbusch brannte. Anfang der 2000er, als sich Agilitätskonzept entwickelt wurde und sich verbreitete, war ich Webentwickler und Teil der Community in der diese Ansätze nicht nur als innovativ, sondern als große Befreiung gefeiert wurden.

Zweitens bin ich ein konservativer Mensch. Grundsätzlich neige ich dazu, hinter Bestehendem Gründe zu vermuten, warum die Dinge genauso geworden sind, wie sie sind. Das heißt nicht, dass das Bestehende sakrosankt ist. Die Welt kann sich mittlerweile verändert haben und die Gründe falsch geworden sein. Aber grundsätzlich halte ich es für richtig, zu verstehen warum die Gegenwart so ist wie sie ist, wenn man sie mit Mehrwert verändern möchte. Und drittens – das hängt womöglich wieder mit dem Konservativem zusammen – reagiere ich sensibel auf etwas, was nach Propaganda riecht und verspricht, genau das eine Wundermittel zu haben, das unter allen nur denkbaren Bedingungen genau die richtige Lösung darstellt. Selbst wenn das für ein einzelnes Problem so sein mag, spätestens bei der Übertragung werde ich kritisch. Ein Hammer ist ein wunderbares Mittel, einen Nagel in die Wand zu schlagen. Aber nur, weil man einen Hammer hat, wird nicht jedes Problem zum Nagel. Suppe löffeln lässt sich mit einem Hammer offensichtlich nicht.

Das alles macht mich gleichwohl nicht generell zum Agilitätskritiker. Anfang der 2000er war Agilität eine Lösung für ein reales Problem: Programmierer, die wussten was sie taten, waren eingebunden in Managementstrukturen, die wenig von IT verstanden und die – zugespitzt ausgedrückt – mit Prozessen und Abläufen aus der Massenproduktion versuchten ihrer Computer-Spezialisten Herr zu werden. Das konnte auf Dauer nicht gut gehen – zumindest nicht zur Zufriedenheit der beteiligten Programmierer. Die Antwort darauf war Agilität: Programmierer nahmen selbst in die Hand, wie sie sich organisieren, in Teams in denen das von der Größe her möglich war und mit der zusätzlichen Verantwortung sich auch selbst über die richtigen Tools, Methoden und Abläufe Gedanken zu machen. Selbstorganisation heißt das im modernen Agilitäts-Slang. Es war aber eigentlich – und man sollte das auch so nennen – Selbstermächtigung oder gar die Emanzipation der (Code-)Arbeiter. Das führte in den Projekten, an denen ich mitwirken durfte, dazu, dass man am Anfang zusammensaß, darüber sprach, wie man zusammenarbeitet, welche Tools man nutzt und wie es laufen wird. Und zwar diejenigen, die es gemacht haben. Keine vorgegebenen Richtliniendokumente aus irgendwelchen Grundsatzabteilung. Das war erfolgreich und hat Spaß gemacht!

Im Zeitverlauf sind natürlich in dieser Freiheit Konventionen entstanden und allgemeine Übung geworden. Mit Scrum gibt es ein ziemlich vollendetes Regelset mit klar beschriebenen Rollen, Aufgaben und Abläufen. Wer Scrum sagt, kann von sich behaupten agil zu sein, ohne jede Regel immer wieder und wieder neuaushandeln zu müssen. Das hat vor allem Sinn, wenn zusammenarbeitende Gruppen flüchtig sind, regelmäßig alte Mitglieder gehen und neue dazukommen. Dann muss nicht jedes Mal in jedem Projekt neu darüber gesprochen werden und neu gelernt werden. Man kennt sein Scrum und wenn nicht, kann man aus Büchern lernen, was die formalen Erwartungen sind. Das ist dann auf jeden Fall schon einmal ein guter Start.

Bei Spotify wurden die Tribes & Chapters und die damit verbundenen Regeln, Konventionen und Abläufe beinahe so sehr expliziert, dass man von einer Kodifizierung sprechen kann – auch dies für sich genommen erfolgreich, kopierbar und für Dritte damit wieder mit einer Offenheit, die einen zügigen Einstieg ermöglicht. Spannend finde ich in diesem Zusammenhang vor allem die Berichte, wie bei Spotify Konventionen erstehen. Grundsätzlich steht es nämlich jedem Squad (ein weiterer Begriff der Spotify-Terminologie) frei, über Programmiersprachen und Tools selbst und unabhängig vom Rest der Organisation zu entscheiden. Ohne eine gewisse Standardisierung würde das aber nicht funktionieren, spätestens beim Wechsel des Squads wird das aufgebaute Know-How wertlos, wenn dadurch nicht sogar der Wechsel unmöglich gemacht würde. Trotz hoher formaler Freiheit entstanden bei Spotify also trotzdem Konventionen, an die sich die Squads – freiwillig – gehalten haben. Wie das ohne Zwang und überlange Grundsatzdiskussionen funktioniert, ist sicherlich ein Thema für Soziologen im Umfang mindestens einer Habilitation (ich würde sie lesen!). Spotify mag da begünstigt gewesen sein, weil es keine lang zurückreichende, belastende Historie gab und das Unternehmen seine Mitarbeiter aus den Besten auswählen kann, die kulturell genau ein solches Klima der freien Entfaltung suchen. Beeindruckend ist es trotzdem.

Eine zweite Entwicklung gab es: Agilität ist nicht eine Überschrift für IT-Projekte geblieben, auch Nicht-IT-Organisationen versuchen sich daran auszurichten. Doch wo beim Kopieren ansetzen? Zwei Möglichkeiten gibt es grundsätzlich: Entweder man kopiert die Methode, den konstituierenden Prozess, gibt also seinen Mitarbeitern Freiheitsgrade, Regeln selbst auszuhandeln, schafft vielleicht noch ein, zwei Hierarchieebenen ab und schaut gespannt, was passiert, wenn man der Kreativität freien Lauf lässt. Alternativ schaut man, welche Regelsets bei anderen erfolgreich sind und kopiert dann nicht die Methode, die dorthin geführt hat, sondern das Ergebnis. Diese vermeintliche Abkürzung ist sicherlich einfacher Top-Down zu exekutieren, und auch für viele weniger auch verwirrend. Diskussionen ohne absehbares Ergebnis und Ziel sind vielen Konzernmitarbeiter ein Graus. Gleichwohl bleibt es ein ziemlich verkorkster Start in Agilität: Die Regeln, die sich in Unternehmen unter anderen Rahmenbedingungen ergeben haben, sind nicht nur wahrscheinlich nicht die besten für das Unternehmen, in das sie übertragen werden sollen, sie sind – keine zwei Unternehmen sind gleich – es mit großer Sicherheit nicht. Ein Konzern mit hunderttausenden Mitarbeitern, Milliardenumsatz und lang zurückreichender Historie ist nicht vergleichbar mit einem wachsenden Softwareunternehmen, das vor nicht allzu langer Zeit noch ein Start-Up war. Es ist ein bisschen wie folgt: Man beobachtet, dass Eskimos sich besonders gut an ihre Lebensbedingungen angepasst haben. Statt sich damit auseinanderzusetzen, wie die Anpassung an das Leben in Kälte und Eis gelungen ist, Lernprozesse und kollektive Flexibilität zu beschreiben, beginnt man, in der Wüste in der man selbst lebt, Iglus aus Eis zu bauen und dicke Robbenfälle zu tragen. Die Evolution („survival of the fittest“!) würde das lösen, man kann aber auch direkt klüger starten.

Also zurück zur ersten Art, der Übertragung der Methode. Selbstermächtigung hat außerhalb von IT einen anderen, schwierigeren Kontext. Ein programmierendes Scrum-Team ist in dem was es tut erst einmal exklusiv. Es gibt keine Konkurrenz, sein Handeln ist Realhandeln und wenn es selbst nichts tut, passiert erstmal gar nichts. Wenn es aber etwas tut, ist das für das Team selbst und für sein Umfeld Wirklichkeit. Das ist in Konzernorganisationen in zwei Grundvoraussetzungen anders: Realhandeln ist kein unmittelbares Resultat der Arbeit eines Teams, es das Ergebnis langer organisatorischer Verdauprozesse. Auch wenn ein agiles Team zu einem bestimmten Ergebnis kommt, wird das bei relevanten Fragen also nicht von diesem Team in Wirklichkeit übersetzt, dafür muss eine gewaltige Organisation bespielt werden. Außerdem versuchen viele unterschiedliche Kräfte den Status Quo, die knappen Ressourcen und vieles mehr ganz langsam in unterschiedliche Richtungen zu ziehen. Wer etwas nach seiner Vorstellung ändern will, ist in der Begründungsnot, aber er ist nicht exklusiv. Andere zerren zeitgleich am gleichen Objekt. Man kann sich hierarchischer Wünsche und Regelverletzungen folglich nicht durch Nicht-Programmieren entziehen. Wenn man da nicht aufpasst, werden Entscheidungen eben von anderen in anderen Meetings herbeigeführt. Der gewaltigen Organisation ist es egal, wer die Tasten drückt. Damit muss man arbeiten.

Das sind Widrigkeiten, doch es macht den Weg nicht verkehrt. Expertenermächtigung ist ein Wert für sich. Teams mit Ende-zu-Ende-Verantwortung für Themen zu finden, bestehend aus Experten, mit selbstausgehandelten Regeln und Abläufe, optimal für die reale Aufgabe, wird zu besseren Ergebnissen führen als das alte Hierarchiemodell. Nur ist das eben härter zu erkämpfen. Es ist dann eine bewusste und deutlich intensivere Aufgabe, diese Ende-zu-Ende-Verantwortung zu erkämpfen (!) und zu verteidigen. Vor allem gegen die weiterhin existierende Hierarchie, die ebenso weiterhin entscheiden will und die auch die Machtmittel besitzt, sich durchzusetzen.

Das wirft eine weitere offene Frage von zentraler Bedeutung auf. Was aus der unteren Ebene der Führungskräfte in einem agilen Unternehmen wird, ist verstanden und programmatisch gesetzt. Sie entwickeln sich mehr zu Coaches und Entwicklern ihrer Ressourcen. Fachlich führen die Expertenteams sich selbst, aber es braucht die kleinen Führungskräfte in der Rolle des Personalentwicklers. Doch was wird aus den höheren Managementebenen? Coaches der Coaches der Coaches? Das ist kein tragfähiges Konzept. Die Organisationsgestaltung haben sie auch aus der Hand gegeben an die Basis, die sich selbst organisiert. Inhaltliche Diskussionen? Da sind sie noch mehr Fremdkörper. Eine Geschäftsführung, die inhaltlich diskutiert, tötet, allein dadurch, dass sie darüber spricht, die Ende-zu-Ende-Verantwortung der Teams, die fachlich befasst sind. Nur das Gerücht, dass ein Vorstand zu einem bestimmten Thema eine bestimmte Position vertreten haben könnte, erstickt die freie Diskussion und Lösungsfindung im Konzern. Wenn der Vorstand sich einmischen könnte, ist es mit der Herrschaft der agilen Teams schlagartig vorbei. Sie wird ersetzt durch vorauseilenden Gehorsam gegenüber den Mächtigen, ohne in Qualität der Diskussion und der Ergebnisse auch nur ansatzweise etwas Ähnliches leisten zu können. Bleibt wenig an konkretem, was das heutige Prestige der Positionen des höheren Managements rechtfertigen würde. Vielleicht ist das aber auch nur die logische Folge: Wo immer jemand ermächtig wird oder sich selbst ermächtigt, verliert natürlicherweise jemand anderes die Macht, die er bisher ausgeübt hat. Demokratie und Liberalismus gibt es auch nicht ohne die rollenden Köpfe von Königen und Diktatoren.

Das mag sich nach einer maßlos radikalen Metapher anhören, soll aber zumindest einmal als symbolisch angemessen begründet werden: Denn die nächste Herausforderung ist es, der Massenorganisation zu vermitteln, dass diesmal wirklich etwas disruptiv anders sein wird. Dass also nicht einfach nur Fachteams jetzt Squads heißen, Abteilungen Chapter und Bereiche Super Chapters, sondern dass diesmal wirklich Selbstermächtigung möglich und erwünscht sein wird. Und: Dass der bisherige hierarchisch geprägte Status Quo weg ist und auch nicht wiederkommen wird, sich zu rächen. Dafür braucht es ein radikales Symbol zur Beglaubigung. Ein solches, das die revolutionäre inhaltliche Botschaft für jeden offenkundig macht, ist noch zu finden.


Kategorie: Unternehmenskultur
Vom 24.11.2018 um 10:46 Uhr

Kommentare
Go to the english version Auf dieser Seite suchen Seiteneinstellungen