Aha-Erlebnis mit Org Topologies: Warum wir ohne „Second Agile Wave” nicht wirklich agil arbeiten.

Einige behaupten „Agilität ist tot!“. 

Bekannt ist, dass viele agile Transformationen scheitern bzw. aus Sicht der Sponsoren nicht die erwartete Wirkung haben, nicht das erwartete Ergebnis bringen oder aus Perspektive der Teammitglieder als Cargo Cult erlebt werden, ohne Perspektive auf Verbesserung.

Warum ist das so?

Ist das, was wir in unzufriedenen Organisationen sehen, denn überhaupt Agilität? Wird hier gegebenenfalls eine gescheiterte agile Transformation als tot bezeichnet, obwohl sie nie agil war?

First Agile Wave: „Agile Teams”

Für viele Organisationen bedeutet „agile Transformation“ die Bildung „agiler Teams“ in der Hoffnung, dass damit alles besser wird. Dabei wird sich viel zu oft fast ausschließlich auf einzelne Teams konzentriert, anstatt den kompletten Wertestrom im Blick zu behalten und auch auf die Abhängigkeiten zwischen den einzelnen Teams zu achten.

Es ist aber unmöglich, einen höheren Grad an Agilität zu erreichen, ohne dass man die Organisation als ganzheitliches System und dessen Wechselwirkungen betrachtet.

Aus Sicht der Sponsoren ist es wichtig, dass die Organisation Wert liefert und flexibel auf Kundenwünsche reagiert. Die Erwartungshaltung der Teams geht oft in die Richtung, unnötige Meetings und Prozesse loswerden zu können und sich mehr auf die Wertschöpfung zu konzentrieren.

Second Agile Wave: Autonome Teams mit eigener Wertschöpfung

Um mehr Wert liefern zu können, benötigen wir wachsende Autonomie auf Teamebene. Das hat zur Folge, dass Abhängigkeiten nicht durch immer „bessere“ Prozesse gemanagt werden dürfen, sondern, dass immer mehr Teams in die Lage versetzt werden müssen, unabhängig von anderen Teams Wert für den Kunden liefern zu können. Wovon letztlich beide Parteien profitieren.

Hier startet die „Second Agile Wave“. Es geht nicht mehr darum, viele „agile“ Teams zu haben, sondern autonome Einheiten mit möglichst breitem Produktverständnis zu etablieren. Der Ansatz der Org Topologies™ hilft uns zu identifizieren, wo wir mit unserer Transformation aktuell stehen, was unser Zielbild ist und wie wir dorthin kommen. 

Der Ansatz von Org Topologies™

Org Topologies™ definiert ein Modell mit 16 Team-Typen und den folgenden beiden Entwicklungsachsen:

• Completeness of Skills
• Scope of Work

Completeness of Skills zielt auf die zunehmende technische Unabhängigkeit der Teams ab. Teams sollen in die Lage versetzt werden, über den gesamten Technologie-Stack Lösungen umzusetzen, Ergebnisse schneller und in einem konstanten Fluss End-to-End zu liefern.
„End-to-End“ bedeutet, dass Teams keine blockierenden Abhängigkeiten untereinander haben (kein Warten, keine Übergaben, keine unklaren Verantwortlichkeiten). 
Wir sehen, dass sich Unternehmen am meisten auf diese Dimension konzentrieren: die Schaffung besserer Teams.

Scope of Work bezieht sich auf eine produktorientierte Ausrichtung der Teams. Je breiter die Teams bzgl. Produktorientierung aufgestellt sind, desto geringer sind die „Switching Costs” für die Organisation. D.h. die Teams können sich viel schneller und mit weniger Hürden an neue Prioritäten oder Anforderungen anpassen, da sie im besten Fall das ganze Produkt schon kennen. Kennen Sie nur einen Teil oder nur einzelne Features, sind die Transaktionskosten oder Nachteile für die Organisation deutlich höher, da sich die Teams unter Umständen oft erst in ein Thema einarbeiten müssen, das sie noch nicht kennen.

Entlang dieser beiden Entwicklungsachsen sind nun 16 verschiedene Team-Typen in einer Matrix angeordnet. 

Hier sind vier Beispiele aus der Matrix der verschiedenen Team-Typen:

Y1 beschreibt eine Gruppe von Personen, die einzeln oder in Untergruppen Task für Task abarbeiten, ohne irgendeinen Blick auf das Gesamtprodukt zu haben oder zu wissen, wie ihre Tasks auf dieses Produkt oder den Nutzen beim Kunden einzahlen. Das wird in Organisationen dennoch oft als Team bezeichnet.

A2 beschreibt ein Team, das gemeinsam Features (d.h. alle zugehörigen Tasks dazu) umsetzt, aber noch auf andere Teams oder Einzelpersonen angewiesen ist. Alle haben das gleiche Ziel im Auge und es ist verstanden, was das Feature für den Kunden an Mehrwert bringt. A2-Teams haben aber nach wie vor Abhängigkeiten zu anderen Einheiten, um wirklich Wert liefern zu können. Als Beispiel kann hier ein SCRUM-Team dienen, welches seine Aufgaben von einem Business Analysten erhält und außerdem zum Deployment noch auf ein anderes Team angewiesen ist.

C0 beschreibt eine einzelne Person mit einer speziellen Fähigkeit, die aber wiederum das ganze Produkt kennt. In Organisationen trifft das sehr oft auf System-Architekten zu – sie kennen das ganze Produkt/System, haben darin aber eine sehr spezielle Rolle und können alleine gar keinen Wert zum Kunden liefern. Im SAFe-Kontext kann das je nach Komplexität des Produkts der Release Train Engineer oder der Solution Train Engineer sein.

C3 beschreibt ein Team mit kompletten Produktverständnis und den Fähigkeiten, dieses End-to-End umzusetzen. Solche Teams trifft man oft im Kontext von Startups an. Diese können voll autonom arbeiten und haben keine Abhängigkeiten zu anderen Einheiten im Unternehmen.

Die Typen A1, A2, Y1, Y2 werden als „Lower Level Archetypes” bezeichnet und mit der „First Agile Wave” erreicht. Diese Teamtypen sehen wir in Organisationen, in denen von ,gelebter Agilität’ gesprochen wird, aber der Frust über fehlenden Outcome nach wie vor groß ist. 

Wie oben erwähnt, reicht die Verbesserung der Leistung einzelner Teams nicht aus, um ein gutes Kundenerlebnis zu bieten, da sie schnell an systemische Grenzen stoßen, die sie selbst nicht ändern können.
Wir wollen weg vom Abarbeiten einzelner Tasks oder Features hin zu einem breiteren Fokus auf das ganze Produkt in einem Team. Ein zu kleiner Fokus im Team führt zu sehr zu lokalen Optimierungen und lässt das eigentliche Produkt und das Kundenerlebnis ins Hintertreffen geraten.
Teams, die wissen, was der Kunde möchte, die das komplette Produkt verstehen und im Blick haben, fällt es signifikant einfacher, sich auf einen neuen Kundenwunsch anzupassen als Teams, die nur einen kleinen Task davon bearbeiten ohne zu wissen, wozu und in welchem Kontext es vom Kunden gewünscht ist.

Um diesen Zustand zu erreichen, benötigen wir die Weiterentwicklung in der „Second Agile Wave”.

Ist-Stand ermitteln und das passende Ziel finden

Org Topologies™ macht es einfacher zu verstehen, wo eine Organisation und ihre Teams in ihrer agilen Transition „stecken geblieben“ sind und öffnet neue Perspektiven in Bezug darauf, wo man eigentlich hin möchte und was man erreichen möchte.

• Passt mein Org-Chart zu den Zielen meiner agilen Transformation und dem, was ich erreichen möchte? 
• Wo stehen denn meine Teams in ihrer Transformation? 
• Wo haben wir Abhängigkeiten zwischen einzelnen Teams, die wir eigentlich gar nicht haben wollen? 
• Wo entsteht ein hohes Risiko durch Wissen oder Aufgaben, die nur an einzelnen Personen hängen?

All diese Fragen können mit dem Modell von Org Topologies™ analysiert werden, um einen Weg in die „Second Agile Wave“ zu finden.

Vielen Dank an Alexey Krivitsky und Roland Flemm für das sehr inspirierende Training zum Thema. Viel Spaß, komplexes Wissen und viel „Training-from-the-back-of-the-room”.