Effiziente DevOps-Teams: Teamschnitte, Kommunikation und kognitive Last

Im letzten Artikel haben wir die verschiedenen Team-Topologien und ihre Aufgaben beleuchtet. Jetzt geht es darum, wie diese Strukturen sinnvoll eingesetzt werden können und was für einen guten Teamschnitt wichtig ist.

Kognitive Last

Das treibende Modell des Ansatzes der Team-Topologien ist die zu verwaltende kognitive Last der Teams. Diese Last wird maßgeblich durch die Kommunikationsbeziehungen und Zusammenarbeitsmodi der Teams mitbestimmt, siehe auch Abb. 1. Wir unterscheiden drei Arten kognitiver Last:

Intrinsische kognitive Last beschreibt die Last, die den durch ein Team anzuwendenden Methodiken naturgemäß innewohnt, also beispielsweise die Expertise eines Programmierers im Hinblick auf eine Programmiersprache der Anwendung. Hier sorgt insbesondere das Konzept des „Enablement”-Teams für Entlastung.

Extrinsische (oder auch orthogonale) kognitive Last beschreibt die Last, die sich aus der Einbettung der durch ein Team anzuwendenden Methodiken in die Umgebung ergibt, also beispielsweise die Komplexität einzusetzender Hilfswerkzeuge oder tiefgreifende technische Details des Aufsetzens einer Produktumgebung. Hier sorgt insbesondere das Konzept des „Platform”-Teams für Entlastung.

Fachliche (oder auch domänenbezogene) kognitive Last schließlich beschreibt jene Last, die sich aus der durch ein Team zu bearbeitenden (Fach-)Domäne ergibt und die den Schwerpunkt der Konzentration des Teams auf sich ziehen sollte.

Das „Complicated-Subsystem”-Team kann je nach konkretem Anwendungsfall mehr der Reduzierung der extrinsischen oder der intrinsischen Last zugeordnet werden, wobei dies in geringerem Maße auch für die anderen beiden unterstützenden Team-Topologien gilt, da beispielsweise auch eine Plattform dazu dienen kann, Aufgaben durch eine bessere Abstraktion hinsichtlich ihrer intrinsischen Last zu erleichtern.

Abb. 1: Kommunikationsbeziehungen zwischen Teams

Teamschnitt

Um Kommunikations- und Planungsoverhead vertretbar zu halten, hat sich eine natürliche Obergrenze der Größe eines Teams von circa fünf bis neun Mitgliedern bewährt, jenseits der die Kommunikationsaufwände erfahrungsgemäß unerschwinglich werden. Ein Lösungsansatz ist die Aufteilung großer Vorhaben auf mehrere parallele „Stream-Aligned”-Teams auf, indem beispielsweise große monolithische Anwendungen, die für ein einzelnes „Stream-Aligned“-Team von sieben Personen zu umfangreich wären, auf kleinere, möglichst voneinander unabhängige Komponenten aufgeteilt werden. Zusätzlich sieht das Prinzip der Team-Topologien eine hierarchische Gliederung vor, sodass beispielsweise ein „Platform”-Team eine umfangreiche Plattform verwalten, deren Entwicklung jedoch an mehrere dafür zuständige „Stream-Aligned”-Teams delegieren sowie auf eine zugrunde liegende Plattform aufsetzen lassen kann.

Kommunikationsmodi

Vervollständigt wird das Konzept der Team-Topologien, die Knoten eines Inter-Team-Kommunikationsgraphen entsprechen, durch eine Systematik dreier Arten von Kommunikationsbeziehungen: „Collaboration”, also die enge Zusammenarbeit zweier Teams; „X-as-a-Service”, also die Bereitstellung einer Dienstleistung durch ein Team für andere Teams; und „Facilitating”, also die Bereitstellung einer Hilfestellung durch ein Team für ein anderes Team bezogen auf eine Problemstellung. „Collaboration” ist dabei vor allem vorgesehen als in der Regel zeitlich begrenztes Inkaufnehmen eines erhöhten Kommunikationsaufwands und eines Verschwimmens der Abgrenzung der beiden Teams voneinander für eine zügige Erforschung neuer Ansätze. „X-as-a-Service” bezeichnet hingegen eine langfristig ausgelegte 1:N-Beziehung, die durch klar definierte Schnittstellen getrieben wird und dadurch niedrige Kommunikationsaufwände ermöglicht. „Facilitating” wiederum ist ebenso wie die „Collaboration” zeitlich begrenzt, grenzt im Gegensatz dazu jedoch klar ein lehrendes Team von einem lernenden Team ab und zielt auf einen moderaten Kommunikationsaufwand ab.

Es liegt nahe, dass „Stream-Aligned”-Teams mit „Complicated-Subsystem”-Teams und „Platform”-Teams meist eine „X-as-a-Service”-Beziehung eingehen, während „Enablement”-Teams eher als Teil von „Facilitating”-Beziehungen auftreten und „Stream-Aligned”-Teams zueinander bei Bedarf den „Collaboration”-Modus wählen. Darüber hinaus kann eine „Collaboration” zwischen einem „Stream-Aligned-Team” und einem „Complicated-Subsystem-Team” oder einem „Platform-Team” sinnvoll sein zur initialen Definition der Komponente oder Plattform, ebenso wie zwischen einem „Enablement”-Team und einem anderen Team bei der Erarbeitung neuer Themenfelder.

Erspüren von Anpassungsbedarfen

Diese Systematik der Team-Topologien und ihrer Kommunikationsmodi ermöglicht eine gezielte Strukturierung der Inter-Team-Kommunikation im Hinblick auf das Gesetz von Conway zur Erreichung der gewünschten Systemarchitektur, die Angleichung der tatsächlichen kognitiven Last auf die Teamkapazität und den gleichermaßen effizienten wie effektiven Einsatz von Kommunikationsaufwänden. Das Definieren der Kommunikationsstruktur einer Organisation ist jedoch keine einmalige Aufgabe. Ändern sich Voraussetzungen, die einer gewählten Struktur zugrunde liegen, so muss auch die Struktur dem geänderten Bedarf angepasst werden - entweder temporär oder dauerhaft. Daher muss eine Organisation solche Anpassungsbedarfe aktiv erspüren und systematisch darauf reagieren.

Fazit und Ausblick

Wir haben betrachtet, wie die Art der Teamschnitte und vor allem der Kommunikationsformen und der Zusammenarbeit zwischen diesen Teams auf die kognitive Last der Mitarbeiter einwirkt. Durch gute Zusammenarbeitsmodi, bei denen bestimmte Grunddienste als Service angeboten werden und andere Dienste zuarbeiten, können wir die Stream-aligned Teams ideal entlasten. Das ermöglicht flüssige Wertströme mit kontinuierlichen Fortschritten.

In unserem nächsten Artikel gehen wir zu den Begrifflichkeiten von „API-Ops“ über und beleuchten die Schnittmengen und Zusammenhänge zu DevOps sowie eingesetzte Werkzeuge.