- Advertisement -spot_img
HomeAllgemeinTeam Topologies Ein neuer Zugang zur optimalen Organisation von Software-Entwicklungs-Teams

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

- Advertisement -spot_img

Autor: Robert Ruzitschka

Wir kann die Zusammenarbeit und Innovationskraft von Teams innerhalb der Software-Entwicklung gestärkt werden? In diesen Artikel erhalten Sie einen Einblick in das Modell der “Team Topologies”, das als Vorlage für eine effiziente Organisation von Teams herangezogen werden kann.

Die Frage nach der idealen Organisationsform von Teams für eine effiziente Software-Entwicklung ist kein neues Thema. Die Erkenntnisse der letzten Jahre aus der Kognitions-forschung ü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 neueren 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 “fabrikähnlichen” 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 der Flow (siehe M. Csikszentmihalyi) und die 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), steht fest, dass die Art der Teamorganisation und der Zusammenarbeit von Teams untereinander von zentraler Wichtigkeit ist.

Herkömmliche Organisationsstrukturen sind nicht mehr adäquat, selbstbestimmten Teams zur Arbeit im Flow zu verhelfen. Mathew 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 verantwortlich 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 Teamgröße. Damit ist aber auch eine obere Grenze in Bezug auf die möglichen Aufgaben des Teams definiert. Neben der Entwicklung eines neuen Kundennutzens (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 die Beherrschung der notwendigen Technologien und Tools.

Alle dies reduziert die Innovationskapazität des Teams. Eine gewisse Standardisierung reduziert 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 Tool- und 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 sichergestellt 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.

Was sind Enabling-Teams?

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 Produktteam 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 Sprach- oder 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 SoftwareKomponente 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, indem hoch-spezialisierte 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 ProduktTeams 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 Notwendigkeit 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

Bitte melden Sie sich an oder erstellen Sie ein Konto, um diesen Inhalt weiter zu lesen.

Der Herausgeber des SQ Magazins (die iSQI GmbH) verpflichtet sich, Ihre Privatsphäre zu schützen und zu respektieren. Wir verwenden Ihre persönlichen Daten nur zur Verwaltung Ihres Kontos und zur Bereitstellung der von Ihnen angeforderten Produkte und Dienstleistungen. Von Zeit zu Zeit möchten wir Sie über unsere Produkte und Dienstleistungen sowie andere Inhalte, die für Sie von Interesse sein könnten, informieren.
Sie können diese Benachrichtigungen jederzeit abbestellen. Weitere Informationen zum Abbestellen, zu unseren Datenschutzverfahren und dazu, wie wir Ihre Privatsphäre schützen und respektieren, finden Sie in unserer Datenschutzrichtlinie.
Artikel teilen
Redaktion
Redaktion
Die SQ-Magazin Redaktion ist Ihr Ansprechpartner für alle Fragen, Anregungen und Ideen rund um das SQ-Magazin. Kontaktieren Sie uns gern unter redaktion@sq-magazin.de Wir freuen uns auf Ihre Nachricht!
- Advertisement -Certified DevOps Portfolio
Neueste Artikel
Weitere interessante Artikel
- Advertisement -spot_img
[js-disqus]