Team Topologies: ein neuer Zugang zur optimalen Organisation von Software-Entwicklungs-Teams

Thank you to SQ-Magazin for allowing us to republish the article.

You can find the original article here.

TEAM TOPOLOGIES

EIN NEUER ZUGANG ZUR OPTIMALEN ORGANISATION VON SOFTWARE-ENTWICKLUNGS-TEAMS

by Robert Ruzitschka

Robert Ruzitschka arbeitet bei der Raiffeisen Bank International als DevOps Guild Lead und Agile Engineering Coach.

@DevOpsBob1

Die Frage nach der idealen Organisationsform von Teams für eine effiziente Software-Entwicklung ist kein neues Thema.

Herkömmliche Organisationsstrukturen sind nicht mehr adäquat, selbstbestimmten Teams zur Arbeit im “Flow” zu verhelfen.

Die Erkenntnisse der letzten Jahre aus der Kognitionsforschung über die neurologischen Hintergründe der sozialen Interaktion (siehe die Arbeiten von Dunbar, „Dunbar’s law“) basierend auf den kognitiven Kapazitäten von Menschen haben zu einer neuern Qualität der Diskussion über die optimale Größe von Teams geführt.

Zusätzlich ist das Verständnis von Software-Entwicklung generell einem fundamentalen Wandel unterzogen. Ging man früher von einem “fabriksähnlichem” Fertigungsprozess für Software aus (manifestiert in einem starren Wasserfallprozess), so versteht man in den letzten zwei Jahrzehnten Software-Entwicklung immer mehr als kreativen und Experiment-basierten Prozess.

In diesem Kontext gewinnen Konzepte wie Flow (siehe M. Csikszentmihalyi) und intrinsische Motivation (Dan Pink) an Bedeutung.

Berücksichtigt man dazu noch die Erkenntnisse von Mel Conway und anderen, nach denen die Architektur eines Systems durch die Architektur der Organisation determiniert ist (siehe Conway’s Law), so steht fest, dass die Art der Teamorganisation und der Zusammenarbeit von Teams untereinander von zentraler Wichtigkeit ist.

Matthew Skelton und Manuel Pais haben mit ihrem Buch “Team Topologies” eine ausgezeichnete Beschreibung der Herausforderungen moderner Enterprise IT vorgelegt und bieten ein Modell an, das in vielen Fällen als Vorlage für eine effiziente Organisation herangezogen werden kann. Dieses Modell besteht im Wesentlichen aus vier verschiedenen Typen von Teams und legt großes Augenmerk auf die Art der Interaktion zwischen den Teams, ein Aspekt, der vielfach vernachlässigt wird. Die Kernkonzepte dieses Modells werden in den folgenden Abschnitten dargestellt.

AUTONOME TEAMS SIND DER KERN

In der agilen Produkt-Entwicklung hat sich über die Jahre ein klares Best-Practice-Modell etabliert: Kleine Teams, die eigenständig für ein bestimmtes Software-Produkt oder eine bestimmte Produktfunktionalität ver- antwortlich sind. Das inkludiert sowohl die Definition der Anforderungen als auch Design, Entwicklung und Betrieb der Software. Diese Teams (7+-2 Personen) verbinden idealerweise Flexibilität mit Effektivität. Durch die geringe Anzahl der Team-Mitglieder ist der Austausch von Informationen zwanglos möglich, Zusammenarbeit kann ohne definierte Strukturen funktionieren. Die Autonomie der Teams schafft Entscheidungsspielraum für die Mitarbeiter und ist damit auch ein wichtiger Faktor für die Mitarbeiter-Motivation, die aus der Selbstbestimmtheit erwächst.

Aus diesen Gründen bleibt auch in größeren Organisationen das autonome Produkt-Team die Kern-Zelle der Organisation (Skelton/Pais verwenden hier übrigens den Ausdruck „Stream Aligned Teams“, da ein Team nicht notwendigerweise ein vollständiges Produkt verantwortet). Allerdings stellen sich mit zunehmender Größe der Teams und der Produkte entscheidende Herausforderungen, unter anderem:

1. Wie organisiert man eine effiziente Zusammenarbeit zwischen mehreren Teams ohne, dass es zu Abhängigkeiten kommt, die die Teams blockieren?

2. Gibt es Team-Aufgaben, die sinnvollerweise zentralisiert werden können?

3. Wo ist die Grenze zwischen Autonomie der Teams und einer notwendigen Standardisierung?

MENTALE KAPAZITÄT

Die Möglichkeiten der effektiven Kommunikation im Team beschränken, wie oben beschrieben, die mögliche Team-größe. Damit ist aber logischerweise auch eine obere Grenze in Bezug auf die möglichen Aufgaben des Teams definiert. Neben der Entwicklung von neuem Kundennutzen (der für das Unternehmen wichtigsten Aufgabe) muss ein autonomes Team auch noch vielfältige andere Aufgaben bewältigen. Beispiele sind der Aufbau und die Betreuung einer CI/CD Pipeline, die Verwaltung der Applikationsumgebungen und natürlich auch die Beherrschung der notwendigen Technologien und Tools. Alle dies reduziert die Innovationskapazität des Teams.

Eine gewisse Standardisierung redu- ziert die sogenannte „Kognitive Last“, die durch Tätigkeiten erzeugt wird, die keinen Kundennutzen erzeugen. Diese standardisierten Services können dann zentral zur Verfügung gestellt werden. Dabei ist allerdings zu beachten, dass eine Zentralisierung die Autonomie der Teams in Bezug auf Toolund Technologie-Auswahl einschränkt und daher mit Augenmaß durchgeführt werden muss.

Ähnliches gilt im Bereich des Lernens und Experimentierens. Die kontinuierliche Erweiterung der Fähigkeiten und des Problemverständnisses sind wichtige Treiber für die Innovationsfähigkeit von Teams, aber es dient wohl weder Kunden noch Unternehmen, wenn jedes Team für sich neu lernt, etwa Basisinfrastruktur und eine Entwicklungs-Toolchain aufzusetzen.

PLATTFORM-TEAM ZU HILFE

Ein effektiver Weg, spezifische Aufgaben zu zentralisieren, sind Plattform-Teams.

Die Gefahr bei derartigen Teams ist, dass sie zu einer Abhängigkeit für die Produkt-Teams werden. Dies lässt sich nicht vollständig vermeiden, es muss aber unter allen Umständen versucht werden, Abhängigkeiten so gering wie möglich zu halten. Folgendes ist zu berücksichtigen:

1. Die Funktionalität, die das Plattform-Team zur Verfügung stellt, ist so schlank wie möglich. Das Team reflektiert immer wieder, was wirklich für die Produkt-Teams relevant ist. Dies erfordert kontinuierliche Kooperation und Kommunikation zwischen Plattform und Produkt-Teams.

2. Services können von den Produkt-Teams „as a Service“ konsumiert werden. Es sind keine manuellen Prozesse notwendig, die Produkt-Teams können die Services eigenständig konfigurieren. APIs beispielsweise sind detailliert und verständlich dokumentiert, es gibt How-Tos, FAQs etc..

3. Die angebotenen Services haben eine ausgezeichnete Verfügbarkeit und Skalierbarkeit, skaliert wird im besten Fall automatisch nach Bedarf.

Mit diesen Maßnahmen kann sicher- gestellt werden, dass Produkt-Teams nicht auf das Plattform-Team „warten“ müssen um neue Funktionalität zu entwickeln und nicht in ihrer Innovationskraft gebremst werden.

Plattform-Teams haben selbst alle Eigenschaften eines Produkt-Teams. Der Kunde in diesem Fall ist Unternehmens-intern, aber sonst gibt kaum Unterschiede.

Zentral ist die Interaktion mit den anderen Teams unter Benutzung des „X as a Service“-Patterns. Nur so können Abhängigkeiten möglichst gering gehalten werden.

WIR BRAUCHEN MEHR HILFE!

In manchen Fällen benötigen Produkt-Teams andere Formen der Unterstützung, um zum Beispiel neue Technologien schneller zu lernen oder technische Entscheidungen zu treffen, die eine Menge an Erfahrung, Wissen und Experimenten benötigen. Die Aneignung dieser Expertise und dieser Erfahrung erfordert üblicherweise beträchtlichen Aufwand – im Übrigen oft mehr als ursprünglich gedacht.

Hier können spezialisierte „Enabling-Teams“ effizient unterstützen. Enabling-Teams kann man sich als technische Consultants vorstellen, aber mit einem starken Fokus auf Zusammenarbeit. Ziel von Enabling-Teams muss es sein, in einem überschaubaren Zeitraum die Produkt-Teams so zu unterstützen und zu trainieren, dass nach dieser Zeit keine weitere Hilfe mehr nötig ist. Es muss also wie bei den Plattform-Teams unter allen Umständen vermieden werden, dass eine längerfristige Abhängigkeit entsteht.

Der Erfolg des Enabling-Teams wird daran gemessen, ob nach einer bestimmten Zeit das betreute Produkt-Team autonomer, effektiver und freier agieren kann.

Das Haupt-Interaktionsmuster von Enabling-Teams mit Produkt-Teams ist also eine zeitlich begrenzte und thematisch klar definierte aktive Zusammenarbeit mit dem Ziel der Unterstützung („Enabling“).

JETZT WIRD ES KOMPLIZIERT ...

In manchen Fällen gibt es Software-Komponenten, deren Entwicklung tiefes und spezialisiertes Know-How aller Team-Mitglieder benötigt. Beispiele für solche Komponenten wären etwa Video Codecs, Algorithmen zur Sprachoder Bilderkennung, die Echtzeitaggregierung von Finanztransaktionen und Ähnliches. Skelton und Pais nennen diese Teams „Complicated-Subsystem-Teams“.

Es ist wichtig zu verstehen, dass der Grund für die Existenz eines derartigen Teams nicht die grundsätzliche Wiederverwendbarkeit der Software-Komponente ist, sondern die Komplexität des zu lösenden technischen Problems. Daraus folgt auch, dass es in einem Unternehmen normalerweise nur eine geringe Anzahl derartiger Teams gibt.

Zusammengefasst kann man sagen, dass die Aufgabe des Complicated-Subsystem-Teams darin besteht, die kognitive Last eines oder mehrerer Produkt-Teams zu reduzieren, in dem hochspezialisierte Aufgaben für diese übernommen werden.

Auch die Complicated-Subsystem-Teams müssen durch kontinuierliche Abstimmung mit den Produkt-Teams sicherstellen, dass die neuen Funktionen ihres Systems entsprechend den Bedürfnissen der Produkt-Teams priorisiert werden.

Aus technischer Sicht ist das bevorzugte Interaktions-Pattern „X as a Service“. Auch hier gilt: Abhängigkeiten sind möglichst zu vermeiden, die Produkt-Teams dürfen nicht gebremst werden.

FAZIT – FOCUS ON FAST FLOW

Autonome Agile Teams sind in vielen Unternehmen erfolgreich. Skelton und Pais stellen ein überzeugendes Modell vor, das diesen Produkt-Teams erlaubt, sich auf ihre Hauptaufgabe - nämlich Kundennutzen zu liefern - zu konzentrieren. Das Konzept der kognitiven Last erklärt nachvollziehbar die Not- wendigkeit der Interaktion mit anderen Typen von Teams.

Von zentraler Wichtigkeit ist auch  die Art der Interaktion zwischen den Teams, immer geht es darum, möglichst wenige Abhängigkeiten zu erzeugen, um die wichtige Autonomie der Produkt-Teams nicht einzuschränken. Ohne Zweifel haben Skelton und Pais mit ihrem Buch einen wichtigen Beitrag zur Diskussion über die optimale Organisation von Software-Entwicklung geliefert.

REFERENZEN

M. Skelton, M. Pais: “Team Topologies”, IT Revolution Press 2019

Dan Pink: “Drive”, Riverhead Books 2011

Melvin Conway: “How Do Committees Invent? Design Organization Criteria.” Datamation, 1968

Mihalyi Czikszentmihaly: “Flow: The Psychology of Optimal Experience”, Harper and Row, 1990

Team APIs: https://github.com/TeamTopologies/Team-API-template