Team Topologien in adaptiven Organisationen

“If change is happening on the outside faster than on the inside the end is in sight.” – G.E. Welch

“Organisationen, die Systeme entwerfen, […] sind darauf beschränkt, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.” – Melvin E. Conway.

Mit diesen zwei Zitaten sind die Herausforderungen moderner IT-Organisationen beschrieben: die Notwendigkeit zur Veränderung und zur permanenten Anpassung an neue Gegebenheiten steigt: seien es neue Wünsche des Marktes, gestiegene Anforderungen an die Produkte oder sich wandelnde technologische Grundlagen. Weiterhin scheint die Komplexität der Produkte nur eine Richtung zu kennen: alles wird mächtiger, integrierter, abhängiger, geschäftskritischer und komplexer, so dass es immer schwieriger und wichtiger wird, diese komplexen Strukturen zu überblicken und im Griff zu behalten.

Zugleich sind aber die Strukturen einer Organisation und die Struktur der Produkte, die sie hervorbringt, nicht voneinander trennbar: sie beeinflussen und bedingen sich gegenseitig. Das führt unmittelbar zu zwei höchst schwierigen Fragen: welche Organisationsstruktur ist für uns und unser Produkt in der gegenwärtigen Situation geeignet? Und wie sollte sich die Organisation weiterentwickeln bzw. adaptieren? Wie sollte sie in drei Monaten, sechs Monaten, zwei Jahren aussehen? Flexibilität allein ist nicht ausreichend: sie muss auch auf Ziele gelenkt und kanalisiert werden. Eine mögliche Antwort liefern Team Topologien und der zeitliche Verlauf der Zusammenarbeit verschiedener Teamtypen.

Motivation zur Veränderung

Neben dem Ziel, auf das die Flexibilität gelenkt wird, sind die zugrundeliegende Motivation und das Erkennen der Notwendigkeit zur Veränderung relevant. An welchen Stellen wird diese sichtbar? Eine Adaption in der Arbeitsweise einer Organisation oder deren Struktur geht der Prozess des Wunsches nach Veränderung voraus. Dieser kann seinen Ursprung beispielsweise im Wachstum der Organisation haben. Das Softwareprodukt, das entwickelt wird, sprengt die Grenzen in denen es in einem Team entwickelt werden kann. Bekannt ist in diesem Zusammenhang das Zwei-Pizza-Paradigma: Ein Team sollte nur so groß sein, dass zwei Pizzen zum Mittagessen ausreichen. Das spricht für Teamgrößen zwischen sieben und neun Personen. Der Anthropologe Robin Dunbar hat in seinen Studien die Zahl 15 als Grenze für die Anzahl an Personen erkannt, zu der eine Person tiefes Vertrauen aufbauen kann.

Ein gutes Beispiel ist die sinkende Kadenz in der Entwicklungsgeschwindigkeit und dem Bereitstellen neuer Funktionen in einem Softwareprodukt für den Kunden. Entsteht eine zunehmende Abhängigkeit einzelner Teams, so dass diese nicht mehr unabhängig agieren können, verlangsamt sich der gesamte Prozess. Die Analyse von Kommunikationspfaden in einer Softwarearchitektur lässt dabei aufschlussreiche Rückschlüsse auf die Organisation zu. Ergibt sich in der Architektur kein “sauberes” Bild, ist dies ein guter Anlass, um auf die Struktur der Organisation zu blicken.

Conway’s Law

Jede Organisation hat sichtbare Strukturen, unter anderem dargestellt in einem Organigramm mit Abteilungen. Das gleiche gilt auch für Applikationen, deren Struktur als Architektur bezeichnet wird. Diese beiden Strukturen sind sehr wichtig, da sie wichtige Grenzen ziehen und die Funktionsweise der Organisation und der Applikation beeinflussen. Der Informatiker Melvin E. Conway hat bereits vor einem halben Jahrhundert festgestellt, dass der Entwurf von Systemen durch die Kommunikationsstrukturen der umsetzenden Organisationen vorbestimmt ist. Sehr schön wird das in der nach ihm benannten Gesetzmäßigkeit beschrieben: “Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.” Man kann das etwas salopper in die Aussage “You always ship your org chart” überführen. Übersetzt ins Deutsche: „Organisationen, die Systeme entwerfen, […] sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.“ Oder noch einfacher: die Strukturen der Organisation finden sich stets in ihren Produkten wieder. Wenn die Organisationen kompliziert gestaltet sind, sind auch die durch sie erarbeiteten Produkte kompliziert.

Es ist daher von großer Bedeutung, sich mit dem Zusammenspiel von Organisation und Architektur zu befassen. Organisationen verändern sich permanent. Getrieben durch Marktveränderungen, Globalisierung, geändertes Kaufverhalten und vielen anderen Umständen müssen die internen Strukturen, Produktportfolios und Prozesse regelmäßig angepasst werden. In einer IT-Landschaft mit monolithischen Altsystemen fehlt es häufig an der notwendigen Flexibilität, auf die genannten Veränderungen schnell zu reagieren. Für mehr Flexibilität strebt die IT seit Jahren nach mehr Modularisierung. Entscheidend für den Erfolg einer IT-Organisation ist ihre schnelle Anpassungsfähigkeit an sich verändernde Rahmenbedingungen. Will man also Software mit moderner Architektur erschaffen, so muss man sicherstellen, dass die Organisation dazu nicht im Widerspruch steht. Man muss es so streng sagen: moderne Architektur auf Basis alter Organisation wird schlicht nicht funktionieren. Viele IT-Projekte scheitern an dieser Problematik.

Abbildung 1: Praxisbeispiel Conway’s Law

Ein Beispiel für diese Gesetzmäßigkeit ist die Umsetzung einer einfachen Anwendung. Die Softwarearchitektur ist unvermeidlich ein Abbild der Organisations- und Kommunikationsstruktur. Denkt man seine Organisation unterschiedlich, werden auch andere Architekturelemente sichtbar. Die Abbildung verdeutlicht das: denkt man rein technologisch, ergeben sich rein technisch abgegrenzte Teams. Denkt man umgekehrt in Funktionalitäten, werden entsprechend funktional gegliederte (und in sich vermutlich cross-funktionale) Teams erkennbar. Diese interne Strukturierung hat Auswirkungen auf die Kundenbeziehung: ist eine in Schichten gegliederte Organisation ausreichend in der Lage, die Bedürfnisse des Kunden zu erkennen und auf sie zu reagieren?

Manuel Pais und Matthew Skelton haben in ihrem Buch Team Topologies¹ versucht, Organisationsformen und ihre Effekte systematisch zu ergründen. In der Folge verwenden wir der einfachen Übertragbarkeit halber ihre Begriffe.

Die vier Typen von Team Topologien

Viele IT-Organisationen verändern ihren Aufbau mehr in Richtung einer Teamorganisation. Für das Erstellen und Betreiben von modernen Applikationen sind dabei im Prinzip nur vier unterschiedliche Typen von Teams notwendig. Die Organisation kann diese vier Typen als Zielpunkt von Organisationsveränderungen nutzen, d.h. alle Teams (und Projekte und Abteilungen) entwickeln sich jeweils in Richtung einer der folgenden Teamtypen.

Abbildung 2: 4 Typen der Team Topologien²

Stream-Aligned Team

Stream-Aligned Teams richten sich an Wertströmen aus. Diese Wertströme beziehen sich entweder auf Bereiche bzw. Arbeitsgebiete des Business oder betreffen organisatorische Fähigkeiten. Konkret kann das ein bestimmtes Produkt oder Service sein, eine Menge von Eigenschaften in einem Produkt oder eine ausgewählte Persona.

Stream-Aligned Teams bilden die Basis einer Organisation und die anderen drei Teamtypen unterstützen diese Teams mit unterschiedlichen Aktivitäten. Als Folge ihrer Aufgabe sind Stream-Aligned Teams näher an den Wünschen und Anforderungen der Kunden und bekommen von diesen direkt Feedback. Die Mehrzahl von Teams in einer Organisation wird Stream-Aligned sein.

Enabling Team

Enabling Teams unterstützen Stream-Aligned Teams beim Aufbau von Fähigkeiten und der erfolgreichen Anwendung von Methoden. Sie setzen sich aus Spezialisten für bestimmte technische oder produktbezogene Bereiche zusammen. Diese Spezialistenteams arbeiten beispielsweise beratend oder lehrend mit den Stream-Aligned Teams zusammen. Durch ihre Arbeit erhalten die Stream-Aligned Teams Freiraum für die wertschöpfende Arbeit.

Enabling Teams sehen ihre Aufgabe darin, einerseits immer bei Innovationen vorne zu sein und andererseits sich selbst durch eine effektive Zusammenarbeit im Team und nach außen überflüssig zu machen. Für neue Technologien erarbeiten sie Wissen durch Experimente und Forschungsarbeit. Sie versuchen vorausschauend die Bedürfnisse der Stream-Aligned Teams zu verstehen und regelmäßige Kontrollpunkte mit ihnen zu etablieren. Sie arbeiten immer wieder die Notwendigkeit in den Teams für permanentes Lernen heraus.

Complicated-Subsystem Team

Complicated-Subsystem Teams sind für die Entwicklung und die Wartung von Teilen der Applikationen verantwortlich, die ein ausgeprägtes Spezialistenwissen benötigen. Auch diese Art von Team unterstützt die Stream-Aligned Teams, nämlich durch Reduzierung der kognitiven Last. Sie beherrschen wichtige Systeme, deren Verfügbarkeit und Weiterentwicklung sie den Stream-Aligned Teams abnehmen.

Durch die Arbeit der Complicated-Subsystem Teams wird die Liefergeschwindigkeit und -qualität der betreuten Subsysteme erhöht. Sie priorisieren ihre Arbeit anhand der Anforderungen der Stream-Aligned Teams und arbeiten mit diesen insbesondere in der Anfangs- und Entwicklungsphase eng zusammen.

Platform Team

Platform Teams reduzieren die Arbeitslast der Stream-Aligned Teams durch Übernahme von unterstützenden oder Infrastrukturaufgaben wie Monitoring oder Deployment. Sie arbeiten eng mit den Stream-Aligned Teams zusammen und fokussieren stark auf Verwendbarkeit und Verlässlichkeit ihrer unterstützenden Services.

Die Platform Teams legen großen Wert auf Benutzerfreundlichkeit und Zuverlässigkeit ihrer Services. Sie überprüfen das regelmäßig mit internen Assessments. Für ihre Services nutzen sie wenn möglich auch Services anderer Platform Teams.

Zusammenarbeit von Teams

Im Zusammenspiel einzelner Teams ergeben sich anhand der Ausprägungen mehrere Varianten der Zusammenarbeit. Unterschieden wird hier zwischen der unterstützenden Tätigkeit – dem Facilitating Mode -, dem X-as-a-Service Modell und einer direkten Zusammenarbeit.

Im Facilitating Mode unterstützt und ergänzt ein Enabling Team ein anderes Team um Herausforderungen zu begegnen und dies Team beispielsweise zu beschleunigen, da das Enabling Team gewisse Kompetenzen mitbringt, die in dem Team anderweitig nicht vorhanden sind. Entsprechend findet sich das Enabling-Team üblicherweise in der Zusammenarbeit mit anderen Teams in der unterstützenden Tätigkeit und nur gelegentlich in der direkten Zusammenarbeit.

Ein weiteres, häufig anzutreffendes Paradigma in der Zusammenarbeit sind definierte Schnittstellen – hier befinden wir uns bei der Zusammenarbeit dann in der Bereitstellung – es wird vom X-as-a-Service Modell der Zusammenarbeit gesprochen. Durch die Schnittstellen gibt es klare Verantwortlichkeiten, insbesondere deshalb ist es essentiell für das effektive Zusammenarbeiten im X-as-a-Service Modell, dass die Schnittstellen sauber und eindeutig definiert sind. Eine direkte Zusammenarbeit hilft anfangs, um diese Schnittstellen zu etablieren. Direkte Zusammenarbeit ist ansonsten meistens bei Stream-Aligned Teams anzufinden. Stream-Aligned Teams befinden sich untereinander üblicherweise in der direkten Zusammenarbeit. Die Abbildung 3 und die Tabelle 1 stellen das nochmals grafisch und in der Übersicht dar.

Abbildung 3: Modus der Zusammenarbeit der 4 Teamtypen

Tabelle 1: Gegenüberstellung der Teamtypen und der unterschiedlichen Arten der Zusammenarbeit

Zeitlicher Verlauf der Zusammenarbeit verschiedener Teamtypen

Diese vier Team-Typen und insbesondere die drei Zusammenarbeits-Typen bilden ein sehr wirksames Koordinatensystem, um zu beschreiben, in welchem Zustand sich eine Organisation befindet. Weiterhin kann man daraus eine Ziel-Konstellation ableiten, die man für besonders geeignet hält, um die Ziele von Autonomie und der Vermeidung kognitiver Last zu erreichen. Und damit kann man vor Allem auch zeitliche Verläufe dieser Konstellationen formulieren.

Beispielsweise mag es ein Stream-Aligned Team A geben, das Verantwortung für einen bestimmten Wertstrom übernimmt. Dieses Team benötigt vielleicht Unterstützung durch ein Enabling Team B (sagen wir, einem Team von Kubernetes-Fachleuten), um sich mit dieser für sie neuen Technologie vertraut zu machen.

Diese Beziehung zwischen den beiden Teams muss sich aber sicherlich über die Zeit wandeln: die Abhängigkeit von Team B, das am Anfang natürlich sehr wichtig ist, um fachliche Lücken in Team A zu schließen, darf nicht dauerhaft bestehen. Sollte dieser Zustand nämlich permanent werden, so hat man hinderliche Abhängigkeiten zwischen diesen Teams geschaffen, die beiderseits die Autonomie einschränken. So würde für allerhand organisatorische Verwerfungen gesorgt: Team A kann seine Aufgabe nicht ohne Team B erfüllen, und Team B steht anderen Teams nicht zur Verfügung. In der Lesart von Team Topologies bedeutet das also, dass eine zunächst bestehende Zusammenarbeit im Facilitating Mode ein Ende nehmen muss: Team A baut die nötigen Kenntnisse und Erfahrungen soweit auf, dass es auf eigenen Füßen stehen kann.

Ein anderes Beispiel: Team A entwirft gemeinsam mit einem Complicated-Subsystem Team C (einem Team von Machine Learning Spezialisten) ein neues Produkt, das als solches maschinelles Lernen einsetzt. Zunächst muss dieses Produkt richtig verstanden werden, wozu beide Teams eng zusammenarbeiten: Collaboration Mode. Nach einer Weile, mit zunehmender Klarheit der technischen Umsetzung, der Rollen, Aufgaben und Bedürfnisse müssen sich diese beiden Teams aber wieder voneinander lösen, so dass jedes autonom seine Aufgaben vorantreiben kann. Von einer Kollaborations-Beziehung sollte also allmählich zu einer Dienstleister/Kunde-Beziehung gefunden werden: Team C stellt Schnittstellen bereit, auf die das Produkt von Team A zugreifen kann, ohne dass dazu aktive Zusammenarbeit der beiden Teams nötig ist. Ziel ist also ein Übergang zu einem X-as-a-service Modell der Zusammenarbeit.

Fazit

Diese Klarheit in der Formulierung von Zielen, Ist- und Sollzuständen ist der große Nutzen eines solchen Koordinatensystems wie z.B. demjenigen in Team Topologies. Es erlaubt die Sichtbarmachung, Beschreibung, Diskussion des Zustandes einer Organisation, und seinen geplanten, zielgerichteten Wandel über die Zeit.

Viele von uns haben bestimmt schon seit langem ein Bauchgefühl, dass eine solche systematische und strukturierte Betrachtung notwendig ist. Die fortschreitende Integration von Fähigkeiten und Verantwortlichkeiten in crossfunktionale Teams verstärkt diese Notwendigkeit noch. Außerdem verlangt sie ein Verständnis vom Wandel über die Zeit – der sich zudem noch beschleunigt, getrieben von Kräften innerhalb und außerhalb der Organisation. Eine Diskussion über diese Strukturen und die sie formenden Kräfte ist schon lange notwendig und rückt endlich in den verdienten Fokus.

Hinweise:

Interessieren Sie sich für weitere Erfahrungen aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

[1] Team Topologies: Organizing Business and Technology Teams for Fast Flow; ISBN: 978-1942788812
[2] Nutzung der Abbildung mit freundlicher Genehmigung der Autoren

Dies ist ein Best of Blog 2021 Beitrag. Hier können Sie sich die besten Beiträge aus 2021 herunterladen.

Dieser Beitrag ist ein gemeinsames Werk von Dierk Söllner, Felix Kronlage-Dammers und Luca Ingianni.

Dierk Söllner hat weitere Beiträge im t2informatik Blog veröffentlicht, u.a.:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.