Team Topologies

Kleine und simple Systeme sind ein wertvolles Ziel, Lehman's laws of software evolution zeigt uns aber, dass dies nicht für erfolgreiche Systeme gilt, denn der Druck neue Funktionen einzubauen und sich neuen Anforderungen anzupassen, wird dieses System automatisch degenerieren.

Buchempfehlung

Das hier vorgestellte Konzept Team Topologies stammt aus dem zugehörigen Buch von Matthew Skelton und Manuel Pais. Die hier verwendeten Bildern stammen ebenfalls aus dem Buch.

Die Team Topologies versucht Conways Law Rechnung zu tragen und durch eigenständig, unabhängigen Teams Systeme zu entwickeln, welche für einen schnellen Veränderungsfluss ausgelegt sind.

Hörempfehlung

In software-architektur.tv wurde das Thema bereits mehrfach besprochen. Dort ist auch ein sehr informatives Schaubild erarbeitet worden.

Das Konzept der Team Topologies besteht aus 4 Teamtypen und 3 Interaktionsmodi.
Pasted image 20240416191308.png

Zusammen mit gut gesetzten Systemgrenzen und Teaminteraktion, sind die folgenden 4 Teamarten alles, was man benötigt, um eine effektive Organisationsstruktur für den Flow zu erstellen: SAT, ET, CST und PT.

Pasted image 20240423080532.jpg

Sie sollten als eine Art Magnet für die Teams funktionieren. Die Teams sollten also danach streben, eine der 4 Teamtypen zu entsprechen. Dies reduziert die Ambiguität in der Organisation und erleichtert somit auch die Kommunikation. Als Startpunkt fungiert das Stream-aligned Team und nur wenn wirklich nötig bis zu 2 Complicated Sub-system Teams.

Wo sind die Ops und Support Teams?

Es gibt keine. Die Teams der 4 Typen sind cross-funktional und leben genau so lange, wie ihre erstellten Systeme. Es gibt keine Handover zu einem separaten Team. Sogar die SRE (Site Reliability Engineering) Teams, welche die Stabilität der Systeme erhöhen sollen, sind in den Typen enthalten. Die Stream-aligned Teams folgen der guten Auslieferungspraxis (CI/CD) und sind so für den Betrieb verantwortlich.

Wozu Team Topologies?

Die unten genannten Organisationsproblemen stammen daraus, dass man Conways Law ignoriert hat beim Entwurf der Teamstrukturen. Verfolgt man einen Team-first Ansatz mit klaren Aufträgen und der Förderung von wichtigen Interaktionsmuster, welche den Arbeitsfluss und strategische Anpassungsfähigkeit priorisieren, die kognitive Belastung bewusst limitieren und Conways Law bei der Erstellung von Softwarearchitekturen berücksichtigen, kann man diese Probleme lösen und eine Teamstruktur als Schlüsselunterscheider für den zukünftigen Erfolg aufbauen.
Es ist das Ziel der Team Topologies, die Organisation zu befähigen, anpassungsfähig aufzustellen und dynamisch den richtigen Ort und Zeit zu finden, wann Kollaboration benötigt wird im Arbeitsfluss und wann es besser ist, sich zu fokussieren und den Kommunikationsüberschuss zu reduzieren.

Probleme mit Organisationsdiagrammen

Viele Organisationen strukturieren ihre Angestellten und Teams so, dass sie kontraproduktiv zur modernen Softwareentwicklung sind. Der Einfluss von Organisationsentwürfe auf Softwarearchitektur ist zu beachten. Sie setzen zu sehr auf die Diagramme und Matrizen, um Arbeit aufzuteilen und zu kontrollieren und scheitern damit die notwendigen Bedingungen aufzubauen, um Innovation zu fördern und dennoch schnell Änderungen auszuliefern.
Um in der heutigen Zeit zu bestehen, brauchen Organisation stabile, effektive Teammuster und -interaktionen. Sie müssen in selbstständige, eigenverantwortliche, fähige Teams als Grundlage für Agilität und Anpassungsfähigkeit investieren.
Es muss aufgehört werden, die Menschen in Teams als auswechselbare Individuen zu sehen, welche nur dem "richtigen" Prozess folgen und das "richtige" Tool einsetzen müssen, um erfolgreich zu sein. Um Menschen intrinsisch zu motivieren und ihnen eine realistische Chance zu geben, ihre beste Arbeit zu leisten, müssen wir die Menschen und Technologie als eine einzige Mensch-Computer- / Kohlenstoff-Silizium soziotechnisches Ökosystem verstehen.
Team Topologies ist ein adaptives Modell für Technologie-Organisationen, welche ein Design für das Business erlaubt, um Geschwindigkeit und Stabilität zu erreichen.

Das Denken in Organigramme ist das Problem

In den meisten Unternehmen unterscheidet sich die gelebte Kommunikationsstrukturen drastisch zum Organigramm. Ein realistisches Bild würde dann entstehen, wenn das erwartete Organigramm und die echten, notwendigen Kommunikationen betrachtet werden würde. So kann die Distanz zur echten Arbeit erkannt und bessere Arbeitsprozesse für die wirkliche Arbeit identifiziert werden. Tiefgreifende Entscheidungen anhand des Organigramms ignorieren deren Effekte auf- und abwärts und sind meist auch nur lokaler Natur. Diese lokalen Änderungen optimieren nicht zwangsläufig die Entwicklungsgeschwindigkeit, obwohl sie das Organigramm verbessert. Es wird sich nicht auf den Arbeitsfluss konzentriert, sondern die reale Arbeit und die notwendigen Verantwortlichkeiten werden getrennt.

Was kommt nach den Organigrammen

Es gibt 3 verschiedene organisatorische Strukturen in jeder Organisation nach Niels Pflaeging - Organize for Complexity:

5 Daumenregeln nach Naomi Stanford - Guide to Organisation Design: Creating High-Performing and Adaptable Enterprises

  1. Entwerfe, wenn es einen dringenden Grund gibt
  2. Entwickle Entscheidungsoptionen bereits im Entwurf
  3. Wähle den richtigen Zeitpunkt für den Entwurf
  4. Suche nach Hinweisen die aufzeigen, dass Dinge falsch angeordnet sind
  5. Bleibe wachsam in der Zukunft