Skalierte Agilität – wie Teams effizient orchestriert werden (Teil II)

Komplexe Softwaresysteme für große Unternehmen wirklich agil zu entwickeln, stellt uns vor Herausforderungen auf vielen Ebenen: kulturell, organisatorisch, finanziell, infrastrukturell oder architektonisch. In unserer Blogserie betrachten wir verschiedene Probleme der skalierten Agilität aus ganzheitlicher Unternehmenssicht und versuchen, praktische Verbesserungsvorschläge zu geben.

Die skalierte agile Entwicklung erfordert, dass viele Teams auf ein gemeinsames Ziel hinarbeiten. Eine optimale Teamstruktur minimiert Kommunikations- und Abstimmungsaufwand und verkürzt so die Time to Market – die Dauer zwischen Idee und Lieferung. Aber gibt es überhaupt eine optimale Teamstruktur? Leider lautet die Antwort: normalerweise nicht. Aber es gibt vielversprechende Bausteine und Heuristiken, die wir nutzen können, wie wir in Teil 1 dieses Artikels gesehen haben.

In Teil II des Artikels geht es nun darum, diese Bausteine in der Praxis anzuwenden und zu verstehen, wie dadurch die Effizienz der Teamorchestrierung tatsächlich verbessert werden kann.

Wir haben gelernt: Für eine effiziente Teamorchestrierung benötigen wir die Unterstützung durch eine modulare Geschäfts- und Systemarchitektur. Anregungen für die Ausrichtung von Architektur, Wertströmen und Teamtopologie in der Praxis finden sich im Buch „Team Topologies“ von Matthew Skelton und Manuel Pais. Mit ihren vier standardisierten und klar definierten Teamtypen können alle in der Praxis relevanten Teamstrukturen aufgebaut werden.

Teamtopologie, Architektur und Wertströme gemeinsam beeinflussen den Wertfluss (Quelle: Eigene Darstellung/metafinanz).

Zur Erinnerung: Die vier Teamkategorien sind

• Stream-Aligned Team
• Platform Team
• Enabling Team
• Complicated Subsystem Team

Die Vorteile dieser Teamkategorien und ihre (hier nicht näher beschriebenen) Interaction Patterns liegen auf der Hand: Sie dienen dem einheitlichen Verständnis der Fähigkeiten, Bedürfnisse und Verhaltensweisen von Teams. Zudem erlauben sie, Teamstrukturen leichter an veränderte Bedingungen anzupassen. Vor allem aber sind sie das Bindeglied zwischen Wertstrom und Architektur.

Teamstruktur auf Basis der Teamkategorien (Quelle: Eigene Darstellung/metafinanz).

Teamkategorien in der Praxis

Auf architektonischer Seite sind ebenfalls Veränderungen vorgenommen worden. Das Backend wurde modularisiert und die Business-Funktionalitäten konsequent in Customer-Facing-Komponenten sowie unterstützende Bibliotheken unterschieden. Erstere bilden direkt die Wertströme ab, letztere stellen technische Querschnittsfunktionalitäten zur Verfügung und regeln die Kommunikation zum Backend.

Cluster definieren, Teams orchestrieren

Auf dieser Basis können wir nun Cluster definieren und Teams effizient orchestrieren. Die notwendigen Synchronisierungs- und Planungs-Events werden dabei leichtgewichtiger sein als bislang. Innerhalb der Cluster (z.B. ARTs) wird es nur vergleichsweise wenige horizontale Abhängigkeiten geben, die etwa im Rahmen von „PI Plannings“ betrachtet werden müssen. Und auch in der Vertikalen können Synchronisierungen und Planungen beispielsweise in „Platform Sync“ Events, gegebenenfalls in geringerer Frequenz, behandelt werden.

Acht Schritte zur effizienten Teamorchestrierung

Abschließend kombinieren wir die obigen Konzepte zu einem pragmatischen heuristischen Verfahren:

Fazit

Als Fazit wollen wir die folgenden Punkte festhalten:

• Agilität bedeutet nicht, schneller zu arbeiten, sondern sich auf die Wertschöpfung zu konzentrieren und durch optimierte Organisation und Abläufe weniger zu warten. Eine intelligente Teamtopologie und Organisationsstruktur sind der Schlüssel zu diesem Ziel.
• Sowohl Wertströme als auch eine modulare Architektur müssen von Anfang an berücksichtigt werden, um eine effiziente Teamtopologie aufzubauen.
• Die von Skelton und Pais definierten Teamkategorien bieten einen großartigen Rahmen, um die Teamstruktur flexibel an Wertströme und Architektur auszurichten.
• Cluster (ARTs, Tribes) und ihre zugehörigen Orchestrierungs-Events (Planung und Synchronisation) sollten erst am Ende des oben beschriebenen Prozesses und so schlank wie möglich definiert werden, um so den Wertfluss maximieren zu können.

Co-Autor: Stefan Hanslmaier (Allianz – XING)

Quelle Titelbild: AdobeStock/C.Castilla