Fast unzählige agile Rahmenwerke und Methoden schießen wie Pilze aus dem Boden. Darunter seit einiger Zeit auch Team Topologies, welches wir uns im folgenden Beitrag näher anschauen.

Abbildung Team Topologies auf einen Blick

Inhalt:

Einleitung

Während Agilität mit dem de-facto Standard Scrum auf Teamebene oftmals relativ leicht umzusetzen ist, stellt skalierte Agilität Organisationen regelmäßig vor größere Herausforderungen. Viele Frameworks wie etwa SAFe oder LeSS liefern interessante Ansätze hierfür. Jedoch scheitern Organisationen regelmäßig bei der Einführung aufgrund heterogener Teams, Anforderungen und Produktlandschaften. So ist beispielsweise ein Team, welches den Checkout-Prozess eines Onlineshops verantwortet, ganz anders zu betrachten als das Team, welches die interne Cloudplattform oder einen Data Lake entwickelt.

Matthew Skelton und Manuel Pais beschreiben 2019 in ihrem Buch Team Topologies einen Ansatz, wie man die verschiedenen Teams und Anforderungen klassifizieren und insbesondere die Zusammenarbeit und Schnittstellen dieser bewusst steuern und managen kann. Dies ermöglicht:

  • Klare Verantwortlichkeiten, denn jede Teamkategorie hat klar definierte Aufgaben und Ziele, was die Effizienz und den Fokus erhöht.
  • Verbesserte Zusammenarbeit durch das bewusste Design der Team-Schnittstellen und Kommunikationswege werden Missverständnisse reduziert und die Zusammenarbeit gefördert.
  • Schnellere Anpassung, denn sogenannte Enabling Teams können anderen Teams helfen, neue Technologien und Praktiken zeitnah zu übernehmen, was die Innovationskraft der gesamten Organisation steigert.
  • Optimierte Ressourcennutzung beispielsweise durch Plattform-Teams, die eine gemeinsame Infrastruktur bereitstellen, sodass andere Teams sich auf die Entwicklung von Mehrwert-Funktionen konzentrieren können.

Auf diese Weise bietet Team Topologies eine praxisnahe und flexible Methode, um skaliertes Agilitätsmanagement in komplexen Organisationsstrukturen zu implementieren und nachhaltig zu verankern.

Grundideen

Team Topologies bietet also eine Art Blaupause für die Entwicklung von Organisationen über die Zeit und unter sich verändernden Bedingungen. Moderne Organisationsprinzipien werden gefördert und Softwareänderungen können schneller umgesetzt werden. Die Grundideen werden wir uns nachfolgend näher anschauen:

  1. Conways Law
  2. Team First
  3. Vier grundlegende Topologien
  4. Team-Interaktionsmodi
  5. Organisatorisches Gespür
  6. Topologieentwicklung
  7. Team-API

Conways Law

»Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.« – Melvin E. Conway

Bereits 1968 veröffentlicht, hat Conways Law sich unserer Wahrnehmung nach in den vergangenen 10-15 Jahren im Zuge von Agilisierung, Microservices & Co. fest in der Organisationsentwicklung technischer Einheiten etabliert. Etwas anders formuliert sagt es, dass die Organisationsstruktur und die Kommunikationswege zwischen den betreffenden Teams in der Systemarchitektur adaptiert werden, wie folgende Grafik verdeutlicht:

Abbildung Conways Law

Das Team Topologies Conways Law als erste ihrer Grundideen aufgreift, zeigt, dass bewährte Praktiken aus der Organisation von Softwareentwicklungsvorhaben unter dem Begriff zusammengefasst werden.

Team First

Bei Team Topologies wird ein Team als eine stabile Gruppe von Menschen betrachtet, die am gleichen Ziel arbeiten. Verantwortlichkeiten werden keinen Einzelpersonen zugewiesen, sondern Teams.

Die Anzahl der Teammitglieder ist entscheidend, um Vertrauen zu bilden. Ein effektives Team umfasst laut Team Topologies 7 bis 9 Personen.

Bis eine einigermaßen geschlossene Einheit entsteht, dauert es bis zu drei Monate. Es ist deshalb kaum sinnvoll, Teams nach Abschluss eines Projekts, an dem sie ein halbes Jahr gearbeitet haben, neu zu strukturieren. Die emotionale Anpassung an die Arbeitsgewohnheiten und Sichtweisen neuer Kollegen hat einen gravierenden Einfluss auf die Leistung. Nur wenn das Vertrauen in eine Organisation hoch ist, ist ein Teamwechsel einmal im Jahr ohne negative Auswirkungen möglich.

Die Autoren betonen, dass es wichtig ist, die kognitiven Fähigkeiten des Teams zu maximieren, dabei fokussieren sie auf die Arbeitsumgebung, den Führungsstil, und die Minimierung von Ablenkungen. John Sweller bezeichnet kognitive Belastung mit:

»Die Gesamtmenge an geistiger Anstrengung, die im Arbeitsgedächtnis aufgewendet wird.«

Abbildung Cognitive Load

Drei Arten der kognitiven Belastung werden benannt:

  • Intrinsische bezieht sich auf die Faktoren, die für die Lösung der Aufgabe bedeutend sind.
    • Beispiel: Wie kreieren wir eine neue Methode?
  • Externe bezieht sich auf die Voraussetzungen, in der die Aufgabe ausgeführt wird.
    • Beispiel: Wie konfigurieren wir diesen Service?
  • Lernbezogene bezieht sich auf Inhalte, die erlernt werden müssen, um die Aufgabe zu lösen.
    • Beispiel: Wie funktionieren Bank Transfers?

Durch den Team-First-Ansatz soll Mitarbeitern die Möglichkeit gegeben werden, in einer Organisation erfolgreich zu sein. Anstatt ein dickes Fell oder Belastbarkeit zu benötigen, um in einer Organisation zu überleben, haben Mitarbeiter in einer Team-First-Organisation den Raum und die Unterstützung, ihre Fähigkeiten und Praktiken zu entwickeln.

Teamtypen

Die Vielfalt der Teamtypen in Organisationen kann sehr verwirrend sein, daher werden diese auf vier Haupttypen reduziert:

Stream-aligned Team: Das Team, das auf die Geschäftsveränderung ausgerichtet ist, mit einem funktionsübergreifenden Kompetenzmix und der Fähigkeit, signifikante Inkremente zu liefern, ohne auf ein anderes Team warten zu müssen.

Enabling-Team: Das Team, das andere Teams bei der Einführung und Änderung von Software im Rahmen einer Übergangs- oder Lernphase unterstützt. Complicated-subsystem Team: Das Team mit einer besonderen Aufgabe für ein Subsystem, das zu kompliziert ist, als dass es von einem normalen Stream-ausgerichteten Team oder Plattformteam bearbeitet werden könnte. Optional und nur dann verwendet, wenn es wirklich notwendig ist.

Complicated-subsystem Team: Das Team mit einer besonderen Aufgabe für ein Subsystem, das zu kompliziert ist, als dass es von einem normalen Stream-ausgerichteten Team oder Plattformteam bearbeitet werden könnte. Optional und nur dann verwendet, wenn es wirklich notwendig ist.

Plattform Team: Das Team, das an der zugrunde liegenden Plattform arbeitet und Stream-ausgerichtete Teams bei der Bereitstellung unterstützt. Die Plattform vereinfacht komplexe Technologie und reduziert die kognitive Belastung für Teams.

Nehmen wir hier nochmal als Beispiel ein klassisches Unternehmen aus dem e-Commerce Bereich. Hierbei könnten Beispiele für die Team-Topologien wie folgt aussehen:

  • Ein Stream-aligned Team könnte den gesamten Checkout-Prozess des Onlineshops verantworten, einschließlich der Integration neuer Payment-Dienstleister und der UX-Optimierung.
  • Das Unternehmen möchte verstärkt die Vorteile der Cloud-native Entwicklung nutzen. Ein Enabling Team könnte hierbei bei der Einführung der Technologie und notwendigen Architekturmuster helfen, beispielsweise durch Schulungen, Bereitstellung von Prototypen oder Definition von Architekturpattern.
  • Als complicated-subsystem-Team entwickelt eine Gruppe von Spezialisten einen hochspezialisierten Empfehlungsalgorithmus, welcher Kundinnen und Kunden passgenaue Produktempfehlungen zur Verfügung stellt.
  • Unser fiktives Unternehmen hat direkt zwei Plattform-Teams, welche zum einen die interne Developer-Cloudplattform und zum anderen einen Unternehmensweiten Data-Lake zur Verfügung stellen.

Abbildung der vier Teamtypen und drei Interaktionsmodi

Team-Interaktionsmodi

Ineffektivität wird in vielen Organisationen durch schlecht definierte Interaktionen verursacht. Laut TeamTopologies läuft die Beziehung zwischen den Teams auf zwei Dinge hinaus: Wird durch die Zusammenarbeit mit einem anderen Team ein Ziel erreicht oder bietet es dem Team einen Service an. Auf diese Weise werden drei Möglichkeiten festgelegt, wie Teams interagieren können:

Zusammenarbeit: enge Zusammenarbeit mit anderen Teams. Dies ist besonders nützlich, wenn Teams neue Technologien oder Techniken erforschen. Die Zusammenarbeit ermöglicht die schnelle Entdeckung neuer Dinge, da kostspielige Übergaben vermieden werden. Am besten verwendet, wenn ein hohes Maß an Anpassungsfähigkeit zwischen zwei Teams erforderlich ist.

X-as-a-Service: etwas mit minimaler Zusammenarbeit nutzen oder bereitstellen. Dieser Interaktionsmodus kann die Liefergeschwindigkeit erhöhen. Team A braucht etwas, um seinen Wert zu liefern, Team B hat eine Dienstleistung ohne großen Aufwand bereitgestellt. Es sind keine langwierigen Gespräche, Besprechungen oder Vorbereitungen erforderlich.

Unterstützen: Einem anderen Team helfen und umgekehrt, Hindernisse zu beseitigen. Der unterstützende Interaktionsmodus eignet sich am besten in Situationen, in denen ein Team die Hilfe eines anderen benötigt. Das Enabling Team versetzt zum Beispiel ein anderes Team in die Lage, effektiver zu sein, schneller zu lernen, eine neue Technologie besser zu verstehen oder Hindernisse zu entdecken und zu beseitigen. Domain-Driven Design kann hier ein gutes Hilfsmittel sein.

Bei dieser Grundidee von Team Topologies sieht man wieder sehr schön die Entlehnung aus bewährten Praktiken der Organisation von Softwareentwicklung, diesemal aus den Vorgehensweisen des Doamin-driven Design wie z.B. Core Domain, Shared Kernel und Customer-Supplier

Organisatorisches Gespür

Organisatorisches Gespür meint, Situationen zu erkennen und sich entsprechend anzupassen. Unternehmen müssen flexibel sein, um sich an Veränderungen anzupassen. Dazu gehört die Anpassung der Struktur und Abläufe. Eine Organisation sollte in der Lage sein, die richtigen Teamstrukturen und Interaktionsmodi anzuwenden. Woran erkennt man also, dass eine Organisation sich weiterentwickeln muss?

1) Die Software wird für ein Team zu komplex. Während am Anfang jeder ein umfassendes Verständnis davon hat, was vor sich geht, wird das immer schwieriger. Dadurch verlagert sich der Fokus von echten Prioritäten auf den Versuch, Leute zu finden, die kompetent genug sind, um ein bestimmtes Problem zu lösen.

2) Die Lieferfrequenz verlangsamt sich. Die Teammitglieder sehen, dass eine Lieferung mehr Zeit und mehr Schritte erfordert. Um dies zu vermeiden, müssen Teams autonom sein und dürfen nicht darauf warten, dass andere Teams eine neue Infrastruktur erstellen.

3) Mehrere Geschäftsdienste basieren auf einer großen Anzahl zugrunde liegender Dienste. In einigen Sektoren wie Finanzen, Versicherungen, Regierung usw. können hochrangige Dienste auf Dienste auf niedrigerem Niveau angewiesen sein. Die Lösung könnte darin bestehen, die Dienste auf niedrigerer Ebene zu “plattformisieren” und für jeden Dienst auf hoher Ebene Stream-ausgerichtete Teams einzusetzen.

Eine weitere Sache ist die Organisationswahrnehmung, also die Fähigkeit einer Organisation, eine Situation zu erspüren – diese Fähigkeit ist entscheidend für das Überleben der Organisation. Einige der Dinge, die eine Organisation „spüren“ muss, sind:

  • Müssen die Teaminteraktionsmodi geändert werden?
  • Was behindert den Arbeitsfluss für ein bestimmtes Team?
  • Sollen wir ein bestimmtes Tool bauen oder können wir es von einem Anbieter bekommen?

Topologieentwicklung

Sobald eine Organisation auf neue Herausforderungen reagiert, ist davon auszugehen, dass Teams untereinander anders als zuvor interagieren werden. Dies kann bedeuten, dass Teams neu strukturiert oder neu zusammengesetzt werden, um spezifische Probleme anzugehen oder neue Technologien zu implementieren. Gleichzeitig können sich die Arbeitsabläufe und Prozesse ändern, um die Zusammenarbeit zwischen den Teams zu verbessern. Das übergeordnete Ziel besteht darin, sicherzustellen, dass die Teams flexibel genug sind, um sich an veränderte Anforderungen anzupassen, und dass ihre Interaktionen effektiv sind, um die Ziele der Organisation zu erreichen. Dies erfordert eine kontinuierliche Bewertung und Anpassung der Teamstrukturen und -interaktionen im Einklang mit den sich ändernden Anforderungen und Zielen der Organisation.

Team-API

Eine Beschreibung der Interaktionen mit dem jeweiligen Team, beispielsweise zu:

  • Code und Versionierung,
  • Wiki und Dokumentation,
  • Praktiken und Prinzipien,
  • Kommunikation,
  • Arbeitsinformationen
  • …

Ziel ist es, anderen Teams transparent und in einem einfachen Überblick zu zeigen, an was, wie, mit wem das Team arbeitet.

Ein gutes Beispiel für eine Team API hat Github veröffentlicht:

Abbildung einer Team-API von Github

Fazit

Die sieben Grundideen von Team Topologies basieren auf bewährten Praktiken der Organisation von Softwareentwicklungsvorhaben und bieten Möglichkeiten, die Effektivität der Teamarbeit in Unternehmen zu steigern.

Die Fähigkeit zur Flexibilität und Anpassungsfähigkeit, denn durch die Strukturierung von Teams können Unternehmen schnell auf Veränderungen reagieren und neue Anforderungen integrieren.

Das Übertragen von Verantwortlichkeiten an eigenständige Teams fördert die Autonomie und Eigenverantwortung, beschleunigt die Entscheidungsfindung und fördert agile Reaktionen auf Herausforderungen (siehe 3. Grundidee).

Ferner ermöglicht Team Topologies die Bildung hochspezialisierter Teams, die sich auf bestimmte Aufgaben oder Technologien konzentrieren können, um so die Entwicklung von Expertise zu fördern und die Effizienz zu steigern. Besonders dieser Punkt kann sich aber zu einer großen Herausforderung entwickeln. Wenn spezialisierte Teams in ihren eigenen Bereichen isoliert arbeiten und den Informationsaustausch behindern, können Kommunikationsbarrieren entstehen. Das Entstehen von Silos innerhalb des Unternehmens, wenn einzelne Teams isoliert arbeiten und der Gesamtüberblick über Projekte verloren geht, steigt. Dies kann die Synergien zwischen den Teams behindern und die Effizienz beeinträchtigen. Zunehmende Komplexität und Koordination, wenn eine Vielzahl spezialisierter Teams gleichzeitig agiert. Die Koordination der Teams kann schwierig werden und erfordert eine klare Fokussierung auf gemeinsame Ziele.

Nicht nur Team Topologies, sondern auch alle anderen Frameworks und Methoden berücksichtigen kaum Führungsskills. Selbstorganisierte Teams oder nicht, letztendlich trägt mindestens einer die Verantwortung über das Inkrement. Themen wie z.B. Psychologische Sicherheit, Servant Leadership treten in den Hintergrund, wenn – wie fast immer – der Druck hoch ist. Dies wirkt sich unmittelbar auf die Produktivität der Teams aus. Leader-Mindset beginnt mit Empathie.

Matthew Skelton und Manuel Pais laden in ihren Auftritten und Veranstaltungen dazu ein, Erfahrungen mit ihnen zu teilen, um Team Topologies kontinuierlich weiterzuentwickeln – Organisationsentwicklung ist eben nie “fertig”…