Team Flavors vs. Team-Topologies

Team-Topologies ist ein Ansatz, der im gleichnamigen Buch von den Autoren Matthew Skelton und Manuel Pais 2019 veröffentlicht wurde. Es behandelt die Erkenntnis, dass (Software-) Teams besser zusammenarbeiten, wenn die Art der Zusammenarbeit klar definiert wurde.

Die Ansätze aus Team-Topologies und den P4-Team-Flavors sind sehr ähnlich und verfolgen den gleichen Zweck. Mit beiden Ansätzen lassen sich Team-Strukturen modellieren und machen sie damit klar, transparent und entwickelbar

Team-Topologies definiert vier Team-Typen:

  • Stream-aligned-Team: In P4 ist dies das Feature- oder Applikationsteam. Es kreiert eine Applikationen selbst oder mit den von den Modul/Plttform-Teams zugelieferten Modulen und Plattformen, mit Hilfe der Dienstleistungen der Service-Teams. Wenn mehrere solche Teams an der gleichen Applikation arbeiten, heißen diese Feature-Teams.
  • Enabling-Team: In P4 entspricht dies dem Service-Team. Service-Teams sind meist Experten-Teams, die ihre Expertise zur Verfügung stellen, ihre Experten an andere Teams ausleihen oder Teams, die eine spezielle Infrastruktur betreiben und diese für ihre Dienstleistung nutzen (z.B. Testlabore).
  • Complicated-Subsystem-Team, entspricht dem Modul-Team in P4. Modul-Teams haben die Verantwortung für Teile von Systemen, wobei eine Kunden-Lieferantenbeziehung zu einem oder mehreren Applikationsteams besteht. Dies stellt sicher, dass die Module kein Selbstzweck erfüllen, sondern ausschließlich dazu existieren, gute Applikationen zu ermöglichen.
  • Platform-Team, in P4 ebenfalls das Plattform-Team, als spezielle Variante des Modul-Teams. Plattform-Teams stellen , im Gegensatz zu Modul-Teams, komplette Lösungsplattformen oder „Systembaukästen“ zur Verfügung, aber auch immer mit dem Ziel, die Applikationesteams dabei zu unterstützen, dass sie gute Applikationen für die Endkunden bauen.

Darüber hinaus definiert Team-Topologies drei Zusammenarbeitsmodelle:

  • X-as-Service: Ein Team erbringt einem anderen Team eine Dienstleistung oder liefert etwas zu. In P4 wird dies klar unterschieden. Modul- und Plattformteams liefern versionierte Module oder Plattformen zu, Service-Teams erbringen eine Dienstleistung.
  • Collaboration: Die enge Zusammenarbeit von Teams.
  • Facilitating: Ein Team unterstützt oder befähigt ein oder mehrere andere Teams, z.B. durch Coaching. Aus P4-Sicht überschneidet sich dies etwas mit der Erbringung einer Dienstleitung (X-as-Service)

P4 wird bei den Zusammenarbeitsmodellen noch etwas konkreter. Hier gibt es grundsätzlich folgende Möglichkeiten:

  • Ein Team bekommt ein Artefakt als Zulieferung (Wissen, Arbeitsergebnisse, Muster oder Module)
  • Ein Team bekommt eine Dienstleistung als Zulieferung (z.B. eine EMV- oder Akustikmessung)
  • Ein Service-/Experten-Team stellt einen Mitarbeiter für eine bestimmte Zeit einem anderen Team zur Verfügung (Vollzeit im Nucleus oder Teilzeit als Extended-Team-Mitglieder)
  • Zwei oder drei Teams teilen sich Extended-Team-Mitglieder
  • Zwei eng zusammenarbeitende Teams können auf folgende Art kollaborieren (z.B. zwei Feature-Teams, die an der gleichen Applikation arbeiten oder zwei Modulteams, die gegen eine komplexe technische Schnittstelle arbeiten):

Die Art und Weise der Zusammenarbeit zwischen zwei Teams lässt sich spielerisch mit dem Team-Collaboration-Poker definieren.

Fazit: Team-Topologies ist ein lesenswerter Ansatz auch wenn er sich nicht 100%ig mit dem P4-Ansatz deckt. Beide Ansätze unterstützen die pragmatischen Werte Klarheit und Transparenz.


Nächster Artikel: Einführung von P4: Eine agile Reise  |  Zurück zu den FAQ  |  Hauptseite