Eine Umgebung des Vertrauens ist eine der vielen versteckten Annahmen der ursprünglichen Formulierung, was agiles Arbeiten heißt. Unternehmensumgebungen, die dafür bekannt sind, interne Machtkämpfe zu fördern, können agile Transformationen somit nur durch ganz grundlegende Veränderungen umsetzen.

Ich persönlich mag es, Hierarchien zu reduzieren oder ganz abzuschaffen, wenn es möglich ist, denn Hierarchien haben eine natürliche Tendenz, sich in positiven Feedbackschleifen auszubreiten. Jede gegebene Hierarchie bläht sich eher weiter auf als das Gegenteil. Auf der anderen Seite ist es klug zu verstehen, was ein Hilfsmittel macht, bevor man es loswird. Hier werde ich mich darauf konzentrieren, was Hierarchien zur Kommunikation mit Blick auf agile Arbeitsmethoden beitragen.

Hierarchien ermöglichen eine indirekte und/oder vermittelte Kommunikation über multiplexe Kanäle. Anstatt 100 Mitarbeiter miteinander reden zu lassen, ist es sinnvoller, sie in 10er Teams aufzuteilen und 10 Teamleiter miteinander reden zu lassen. Teamleiter sind dazu da, Informationen zwischen Menschen zu filtern, die nicht unbedingt zusammenarbeiten. Das hält Informationen sicher und reduziert die "Sprechzeit".

Hierarchien sind gut darin, nach oben zu skalieren, aber schlecht darin, nach unten zu skalieren. Das ist eine der Hauptbeobachtungen, die überhaupt erst zur agilen Bewegung geführt hat. Die Menschen dachten, dass vielleicht nicht jedes einzelne Projekt ein bürokratisches Ungetüm sein muss, und dass einige Projekte tatsächlich klein genug sind, dass Bürokratie mehr schadet als hilft.

Die agilen Prinzipien sind dazu da, Hierarchien abzuschaffen. Die Abschaffung der hierarchischen Kommunikation hat zur Folge, dass wir eine direkte und offene Kommunikation haben. Das macht die umittelbare und offene Kommunikation zwischen den Mitarbeitern zu einer der Grundannahmen der agilen Entwicklung. Das ist leichter gesagt als getan, denn direkte und offene Kommunikation muss auf gegenseitigem Vertrauen beruhen. In erster Linie das Vertrauen in die Menschen, dass sensible Informationen sicher und die Kommunikationskanäle nicht blockiert sind.

Für praktische Zwecke bedeutet Vertrauen, dass das beobachtete und das unbeobachtete Verhalten eines Akteurs nicht zu unterschiedlich sind. Diese Art von Vertrauen baut sich mit der Zeit auf, da die Menschen die Möglichkeit haben, regelmäßig die Ergebnisse des unbeobachteten Verhaltens ihrer Kollegen zu beobachten. Der Aufbau eines vertrauensvollen Arbeitsumfeldes erfordert gegenseitiges persönliches Engagement von allen Mitarbeitern.

"Gegenseitiges persönliches Engagement von allen Coworkern", bedeutet mathematisch gesehen einen vollständig verbundenen Graphen, der n*(n-1)/2 Kanten hat. Bei 100 Mitarbeitern wären das 4950 gleichzeitige Kommunikationen. Das führt zurück zu dem Grund, warum wir bürokratische Strukturen haben, die es vielen Menschen ermöglichen, zusammen zu arbeiten. Wenn du die Mitarbeiter in "Teams mit Quadratwurzel" einteilst, ist die Anzahl der Kommunikationen ((n^0.5)*((n^0.5)-1)/2)*((n^0.5)+1) (elf Graphen mit je 10 Leuten, wobei der elfte das Lead-Team ist), was 495 Kommunikationen erzeugt. (ursprüngliche Anzahl geteilt durch die Quadratwurzel der ursprünglichen Bevölkerung) Was drastisch weniger ist.

 

Two graphic with different connected dot

 

(Ein Nebeneffekt: Vertrauensbeziehungen und bürokratische Beziehungen schließen sich gegenseitig aus, sie haben einfach eine ganz andere Art der Kommunikation. Das ist einer der Gründe, warum agile Teams und bürokratische Teams schwer zu synchronisieren sind. Sie können Informationen einfach nicht auf eine Art und Weise abrufen, die für den anderen angenehm ist).

Basierend NUR auf den gegebenen Informationen ist die Auswahl einer Methodik für ein bestimmtes Projekt trivial. Vertrauen skaliert nicht nach oben und Bürokratie skaliert nicht nach unten. Es gibt eine unscharfe Grauzone in der Mitte, in der man sich hinsetzen und über die jeweiligen Vorteile beider Methoden nachdenken muss, aber das wird bereits ausführlich an anderen Stellen diskutiert. (Ich empfehle eine Google-Suche.)

Manchmal geht es furchtbar schief!

Statt der Auswahl zwischen agilen und bürokratischen Methoden interessieren mich eher die Menschen, die Vertrauensbeziehungen in leviathanisch große Organisationen schmuggeln, die mit byzantinischen Bürokratien besser dran sind. "WIE? WARUM sollte irgendjemand unmotivierten, gelangweilten Habenwirimmersogemacht-Kollegen vertrauen? Geschweige denn den Haien in der Chefetage?" Ich kann mir vorstellen, dass Du nun entsetzt grübelst. "Vertrauensbeziehungen sind in agilen Prozessen eingebettet." ist das Wie und "Sie wissen es eigentlich nicht besser, agile Adoption ist an diesem Punkt meist ein Cargo-Kult*." ist das Warum.

Nun behaupte ich nicht, dass riesige Organisationen nichts Vorteilhaftes haben können. Ich bin mir sicher, dass wir dort Wege finden können, agile Ideen zu nutzen. Einige vorgeschlagene agile Lösungen sind explizit als "works at a scale" gekennzeichnet. Ich habe sie nicht ausprobiert und ich sollte sie nicht öffentlich kommentieren, ohne sie selbst ausprobiert zu haben. Stattdessen fordere ich Dich auf, Dich selbst über sie zu informieren und Dir Deine eigene Meinung zu bilden. Ich schlage einfach vor, dass die gut etablierte erste Generation von agilen Methoden (ich werde keine Namen nennen, aber die Leser werden wissen, von welchen ich spreche) aus größeren Organisationen herausgehalten werden sollte.

Was in der Praxis passiert, ist eher ein Durcheinander. Irgendjemand Wichtiges hört irgendwo, dass agile Methoden die Produktivität erhöhen werden, indem sie “deadweight” (also eine träge bis tote Eigenmasse) loswerden. "Deadweight" ist die Bürokratie, die die Mitarbeiter in ihren endlosen Zellenbetrieben zumindest halbwegs organisiert hält. Die Vertrauensbeziehungen sind schwer aufzubauen, weil große Unternehmen immer eine Geschichte von Konzern-Fehden mitbringen und die Leute von einer Position des Grolls ausgehen, was das genaue Gegenteil von Vertrauen ist. Die Bürokratie kämpft mit Zähnen und Klauen gegen ihren eigenen Stellenabbau, denn in einer idealen agilen Welt sind alle mittleren Manager arbeitslos. Und am Ende werden die Strapazen des Bürokratieabbaus und vielleicht sogar die Neuerfindung der bestehenden Bürokratie auf eine agile Transformation geschoben, die nie stattgefunden hat. Vielleicht hat sie sogar nie begonnen.

 

Lass uns zwei Beispiele von großen Organisationen mit Vertrauensproblemen betrachten.

Beispiel A

Hypothetische Holdinggesellschaft A produziert und vertreibt Hardware in Massen. Sie besitzen viele kleinere Unternehmen in der gleichen Branche. Hardware-Prozesse sind schwer zu transformieren und zu vereinheitlichen, daher sind viele der Tochterunternehmen im Grunde unabhängig und stehen ziemlich in Konkurrenz zueinander und zu Unternehmen A.

Die Beziehungen zwischen den Unternehmen im Ökosystem werden durch Vertragsverhandlungen geregelt, die massive geschäftliche Reibungen verursachen, und die Produktentwicklungen verlangsamen. 

Die Holdinggesellschaft A kümmert sich eigentlich nicht um die Software, die in der verkauften Hardware läuft. Sie ist nur dazu da, Hardware-Einheiten besser verkaufbar zu machen. Deshalb beschließ sie, zumindest die Softwarekosten zu senken, indem sie agile Softwareentwicklungspraktiken einführ, um Firmensilos einzureißen und Softwaremitarbeiter zu vereinheitlichen. Es geht darum, eine einzige gemeinsame Software für alle Hardware-Produkte zu entwickeln und mit den vorhandenen Personalressourcen schneller voranzukommen. Arbeitskräfte aus mehreren antagonistischen Unternehmen, die zunächst ihrem direkten Arbeitgeber gegenüber loyal sind, werden zusammengelegt, um an dem gemeinsamen Projekt zu arbeiten und müssen ohne Vorgesetzte miteinander reden. Die antagonistischen Unternehmen werden gezwungen, sich an das Endergebnis anzupassen.

Dabei passiert folgendes:

  • Das Management wird ein einheitliches Tooling fordern, um einen umfassenden Überblick über alle Vorgänge zu erhalten, um den Einheiten genau Kredit/Schulden zuzuweisen. Das liegt daran, dass die realen Budgets der Unternehmen getrennt sind und Verluste nicht "sozialisiert" werden.
  • Das Management wird die Verwendung umfangreicher Spezifikationen verlangen, um sicherzustellen, dass keine der Tochtergesellschaften das Projekt unterwandert, um ausschließlich sich selbst zu nutzen. Denn Software-Mitarbeiter haben den Anreiz, sich zuerst um ihre lokale Hardware zu kümmern.
  • Das Management wird jede Abweichung von den Spezifikationen sehr misstrauisch betrachten und jeden Versuch, davon abzuweichen, stark behindern.

Ungefähr 75% des agilen Manifests sind gerade durch den Papierschredder gegangen, weil die Leute sich nicht gegenseitig vertrauen werden.

Beispiel B

Die hypothetische Holdinggesellschaft B verwaltet Infrastruktur und musste durch den Kauf kleinerer Infrastrukturunternehmen aus verschiedenen Regionen wachsen. Sie besitzen mehrere geographisch verteilte Tochtergesellschaften. Das sind eine Menge Mitarbeiter, die nominell zum gleichen Ökosystem gehören, aber wahrscheinlich nicht einmal eine gemeinsame Sprache sprechen.

Die Holdinggesellschaft B beschließt, auf den Globalisierungszug aufzuspringen und geografisch durchgehende Dienstleistungen anzubieten. Analoge Organisationssilos in den Tochtergesellschaften werden angewiesen, nahtlos aneinander anzuschließen, die Leute fangen an, auf Englisch zu mailen und merken schnell, dass jede Kultur eine andere Art hat, die "Realität zu interpretieren" und sie alle aneinander vorbeireden.

Dann passiert folgendes:

  • Das globale Management entscheidet sich für einen festen Werkzeugkasten, um die geschäftlichen Interaktionen rund um ihre eigenen bevorzugten Geschäftspraktiken zu vereinheitlichen. Das auferlegte Toolkit wird nicht zu geografisch entfernten Geschäftspraktiken passen.
  • Das Management wird eine umfangreiche und übermäßig ausführliche Dokumentation verlangen, um sicherzustellen, dass nichts in der Übersetzung aufgrund von kulturellen Annahmen verloren geht.
  • Das Management wird sehr sensibel auf Abweichungen reagieren und davon ausgehen, dass jede Abweichung in erster Linie ein Missverständnis der gemeinsamen Dokumentation ist.

Etwa 75% des agilen Manifests sind wieder im Schredder gelandet, weil die Leute sich gegenseitig nicht trauen können.

Diskussion der Beispiele

Das erste Beispiel ist einfach zu diskutieren. Es herrscht offener Unwille im Projekt. Es wird mit dem Finger auf andere gezeigt, unabhängig von Erfolg und Misserfolg des Projekts. Jeder wird mehr damit beschäftigt sein, “den eigenen Hintern an die Wand zu bekommen” als mit gemeinsamen Ergebnissen. Das Konversionsprojekt ist zum Scheitern verurteilt, solange die Geschäftsvorgänge zwischen den Unternehmen nicht zuerst geändert werden, um sicherzustellen, dass alle gemeinsam scheitern oder erfolgreich sind. Wenn eine Änderung der sozialen Geschäftspraktiken nicht möglich ist, ist es am besten, die bestehenden Methoden in Ruhe zu lassen.

Das zweite Beispiel ist kompliziert zu erklären, weil die Sprache kompliziert ist. Auf der anderen Seite sind Menschen in der Lage zu kooperieren und Sprachprobleme zu lösen, also ist die Lösung eher "hands off". Bevor ein Transformationsprojekt stattfindet, sollten sich Teams, die unterschiedlichen Kulturen angehören, Zeit nehmen, um sich gegenseitig zu erklären, wie ihre jeweiligen Systeme funktionieren. Durch Diskussionen wird schließlich ein gemeinsames Verständnis erreicht werden. Dies wird nicht sofort zu einer optimalen Lösung und einer gemeinsame Basis führen, aber es wird alle nachfolgenden Diskussionen viel einfacher machen.

Lösungen

Eine offensichtliche Lösung ist, große Organisationen in mehrere lose gekoppelte Teams mit unabhängigen Budgets und Zeitplänen aufzuteilen. Microservices als solche sind ein guter Weg, um eine Umgebung zu schaffen, die der Vertrauensbildung förderlich ist. Wenn Deine große Hierarchie einen monolithischen Aufbua unterhält, erlaubt dir das Aufbrechen des Monolithen in Microservices, die Hierarchie auch in kleinere, in sich geschlossene Gruppen aufzubrechen. Die Gruppen können dann Vertrauen in sich selbst aufbauen und sich in Richtung Agilität bewegen, während sie ihre Microservices aufrechterhalten. Vorausgesetzt, dass die lose Kopplung irgendwie genau richtig gemacht wird, müssen die einzelnen Teams nicht einmal eine gemeinsame Methodik zwischen sich haben. Einige von ihnen können sich sogar dafür entscheiden, intern das Wasserfall- Prizip weiterzuführen. Natürlich wirst Du Berater und Coaches brauchen, die Dich während des Übergangs begleiten *zwinkerzwinker*.

Auch wir Berater sollten wohl bessere Werkzeuge und Methoden entwickeln, um das Vorhandensein und Fehlen von Vertrauen zu erkennen. Ich muss z.B. einige Zeit mit einem Projektteam arbeiten und persönliche Interaktionen bei der Aufgabenverteilung und Schuldzuweisung beobachten, um sicher zu entscheiden, ob sie ein vertrauensvolles Umfeld haben oder nicht.
*Über Cargo-Kulte:

Du solltest vielleicht besser in Wikipedia über Cargo-Kulte lesen, aber ich werde eine kurze Erklärung schreiben, indem ich einige sehr komplexe Phänomene grob vereinfache.

Der Cargo-Kult ist eine Religion, die sich in einer vorindustriellen Gesellschaft entwickelt, wenn sie auf die fehlplatzierten Produkte einer industrialisierten Gesellschaft stoßen und diese fehlplatzierte Fracht (Cargo) für göttlich oder magisch halten. Wenn die Cargo-Kultisten schließlich die Landebahnen entdecken, auf denen die Flugzeuge, die die Fracht transportieren, landen, beobachten sie die täglichen Abläufe der Soldaten/Arbeiter dort und simulieren sie, um selbst Flugzeuge anzuziehen. Schließlich kreieren sie Rituale, die beobachtete Verhaltensweisen der industrialisierten Gesellschaften kopieren, aber da sie den Grund nicht verstehen, wirkt es planlos und fehl am Platz.

Cargo Cult Programming ist, wenn Programmierer ein ähnliches Verhalten an den Tag legen, indem sie blindlings Code kopieren oder Abhängigkeiten nutzen, ohne die Eignung richtig zu prüfen.

Im übertragenen Sinne wäre Cargo Cult Agile Transformation das blinde Übernehmen von Ritualen der agilen Transformation, die bei einem Konkurrenten "funktioniert" haben, ohne die Gründe oder Ergebnisse von Agile überhaupt richtig zu verstehen.