Den Teams zur Hilfe: Wie können Teams so entlastet werden, damit sie sich maximal auf ihre Hauptaufgaben konzentrieren? Wie von allem unnötigen Ballast befreit und maximal unterstützt? Ein Werkzeug der Team Topologies um das zu erreichen, ist das Enabling Team.
Aus einem Guss. Das Konzept der Team Topologies lässt sich aus einem Grundgedanken ableiten. Das ist etwas besonderes. Vier Werte sind es, die das Agile Manifest bilden, flankiert von zwölf Prinzipien. Scrum braucht drei Rollen, vier Meetings und drei Artefakte, um sich darzustellen. Für Team Topologies reicht es den Grundgedanken zu verstehen. Alles andere ist abgeleitet, Schlussfolgerung.
Der Grundgedanke: Ein Team arbeitet dann optimal, wenn es seine gesamte Kapazität in die Lösung fachlicher Probleme investieren kann. Alles weitere - Streams, Team Cognitive Load, Team Types, Team Interaction Modes - sind Ableitungen, Antworten auf die Frage: Was muss ich tun, um den optimalen Zustand herzustellen?
Ein Beispiel
Eine kurzes Fallbeispiel soll die Grundgedanken illustrieren. Ein Softwareentwicklungsteam eines Handelsunternehmens erstellt Berichte, die dem Einkauf dienen, seine Praktiken zu optimieren: Welcher Artikel läuft in welchem Segment gut, welche Größen verkaufen sich, welche nicht? Das Team arbeitet sehr langsam. Die Unterstützung, die sich der Einkauf wünscht, bleibt aus, weil die Umsetzung der jeweiligen Ideen zu lange auf sich warten läßt.
Team Topologies zur Hilfe. Werkzeug eins: der Stream. Es zeigt sich, dass das Team nicht über alle Daten verfügt, die es braucht, sondern dass es auf das Produkt- und das Warenkorb-Team warten muss. Diese nehmen die Anforderungen des Einkaufsbericht-Teams entgegen, planen sie ein und realisieren sie gemäß ihrer Prioritäten. Das geht mal schnell und dauert auch mal sehr lange. Das Werkzeug des Streams besagt: Teams sollten so geschnitten sein, dass sie eine Fachlichkeit alleine verantworten und bearbeiten können. Mit Hilfe dieses Werkzeuges werden die Verantwortlichkeiten umorganisiert. Das Berichtsteam bekommt Zugriff auf die Rohdaten für Produkte und Warenkörbe und kann so selber seine Anforderungen auf ihnen realisieren, ohne mit Produkt- und Warenkorb-Team zu sprechen.
Das Team wird schneller. Aber nicht schnell genug. Werkzeug zwei: Team Cognitive Load. Es zeigt sich, dass das Team viel Zeit in den Betrieb des Datenbankservers stecken muss. Aufgrund der großen Datenmengen entstehen immer wieder Engpässe. In der Sprache der Team Cognitive Load heißt das fremde oder auch “extraneous” Belastung. Eine kognitive Belastung in einem Bereich, der für die Arbeit des Teams keine Hilfe darstellt. Team Topologies bringt auch das Werkzeug für die Beseitigung der Last mit: ein Plattform-Team, wenn es sich um eine Datenbank handelt, die von mehreren Teams genutzt wird, ein Complicated-Subsystem-Team, wenn ein spezieller Datenbankserver nur für den Anwendungsfall des Berichtsteams betrieben werden muss. Der Betrieb wird an dieses Team übergeben. Die Datenbank steht durch eine API (Werkzeug Nummer vier: Team Interaction Types) weiterhin zur Verfügung, die Probleme des alltäglichen Betriebs werden vom Plattform-Team gelöst.
Wieder schneller. Immer noch nicht schnell genug. Es zeigt sich, dass das Berichtsteam zwar die fachliche Problematik genau verstanden hat, die Übersetzung in performante SQL-Abfrage aber äußerst kompliziert ist. Diese Problematik lässt sich nicht outsourcen (siehe Plattform-Team). Tiefe Kenntnisse in der Abfragesprache SQL sind essentiell für das Handwerkszeug des Teams, obwohl sie nur ein Mittel sind, um die eigentlichen Probleme des Teams zu lösen. Werkzeug Nummer zwei - Team Cognitive Load - weiß auch hier Abhilfe. Intrinsische kognitive Belastung heißt der Mangel an SQL-Expertise im Team- Topologies-Sprech: Kognitive Belastungen, die aus der eigentlichen Aufgabe erwachsen, aber nicht die eigentliche Aufgabe darstellen. Jede Java-Programmiererin muss wissen, wie man eine Klasse schreibt, aber dieses Wissen ist nicht der Kern ihrer Arbeit. Für diesen Fall rät Werkzeug Nummer drei - Team Types - zum Enabling Team. Dieses besitzt die handwerkliche Expertise, welches dem Berichtsteam fehlt, und vermittelt ihm durch zeitweilige Unterstützung die Kenntnisse, die es beim Lösen seiner Fachprobleme braucht.
Jetzt ist das Team optimal aufgestellt. Es hat alles, was es zur Lösung seiner fachlichen Aufgaben braucht (stream-aligned), es hat fremde Komplexität an ein anderes Team (Plattform-Team) abgegeben und handwerkliche Schwächen durch Unterstützung (Enabling-Team) ausgeglichen. Es kann sich mit maximaler Kapazität der originären Komplexität seiner Fachdomäne widmen.
Enabling Teams
Womit wir beim Thema wären. Den Grundgedanken beschrieb bereits der Artikel Team Topologies in Auftraggeber-Dienstleister Konstellationen. In die Welt der Plattform-Teams wird der Artikel Team Topologies V - Platform as a Product und in die der Complicated Subsystems der Artikel Team Topologies VI - Complicated Subsystems einführen. Bleiben noch die Enabling Teams für diesen Artikel.
Stream-Aligned Teams stehen vor dem Widerspruch, den größtmöglichen Anteil ihrer Zeit in die Entwicklung der Software ihrer Domäne zu stecken und dabei die modernsten Werkzeugen und die fortgeschrittensten Methoden zu benutzen. Die Evaluation von Werkzeugen, also die Auswahl der passendsten für eine Domäne, ist eine zeitraubende Tätigkeit. Der Aufwand für dieses Suchen wird gerne unterschätzt. (Um den Faktor 10 bis 15 wie die Autoren von Team Topologies anmerken.) Deshalb ist es die Aufgabe eines Enabling Teams, als Forschende im Feld der neuen Werkzeuge und Methoden unterwegs zu sein und die Spreu vom Weizen zu trennen. Dafür gilt es, den Kontakt zur Community zu pflegen und neue Werkzeuge praktisch zu erproben. Dabei entstehen Einschätzungen der verschiedenen Werkzeuge, handwerkliches Vermögen in der Handhabung der Neuerungen und auch Walking Skeletons, wie eine schmale Build-Pipeline, die den Teams zur Verfügung gestellt werden werden können.
In dieser Aufgabenstellung lauert aber auch eine Gefahr. Es entstehen Enabling Teams, in denen neuerungs-affine Nerds ihr Hobby frönen und über den Niederungen der tatsächlichen Teamprobleme schweben. Team Topologies versucht dem vorzubeugen. Man habe sich für den Namen ‘Enabling’ entschieden, in der Vergangenheit hätten solche Teams ‘Innovation’ oder ‘Architektur’ geheißen, aber das hätte einen falschen Fokus ausgedrückt. Im Namen ‘Enabling’ sei der direkte Fokus auf die Unterstützung ausgedrückt. Die richtige Haltung der Teammitglieder sei ‘Servant Leadership’ - also dienendes Führen im Gegensatz zu einem Führen, das die Richtung weist. Für die spezielle Art der Interaktion zwischen Stream-aligned Teams und Enabling Teams entwickelt Team Topologies einen Begriff: Facilitation - die Unterstützung, Erleichterung der Arbeit eines Teams. Facilitation zieht seine Berechtigung nur aus der Arbeit des Teams, das unterstützt wird. Es gilt Lücken in der Arbeit des Teams zu schließen, Probleme zu adressieren und Kapazitäten für die zu bearbeitenden Aufgaben aufzubauen. Dabei sei es wesentlich, dass das unterstützende Team keine Aufgaben des stream-aligned Teams übernehme, sondern diesem nur bei der Realisierung seiner Aufgaben helfe. Es sei Erfahrung nötig, um diese ‘distanzierte’ Art der Unterstützung zu gewährleisten und Aufgaben nicht an Stelle des unterstützten Teams zu lösen.
Einem Architektur-Team widmen die Autoren von Team Topologies eine besondere Betrachtung. Sie raten solch ein Team nur als Teilzeit-Team einzurichten. Alle Architekt:innen sollten auch in Teams verankert sein und dort einen wesentlichen Teil ihrer Zeit mit dem Lösen konkreter Domänenprobleme verbringen. Das erde die Architekturentscheidungen des Teams.
Enabling auf neuland-art
Wie sieht die Arbeit von Enabling Teams konkret bei neuland aus? Ohne den Namen zu kennen und länger als es in Team Topologies vorgeschlagen wurde, haben sich in unseren Teams Muster etabliert, die das adressieren, was dann unter dem Namen Enabling Team verhandelt wurde. Ein typisches Muster ist es, dass ein:e Expert:in oder ein kleines Team von Fachleuten in einer technischen Fragestellung ein Team unterstützt. Meist beginnt es mit einem Auftakt-Workshop, einer Druckbetankung in der Fachfrage. Danach begleitet jemand aus dem Team das Stream-aligned Team, das bei neuland eher Vertikalen- oder Domänen-Team heißt. Das Fachthema wird mit Unterstützung zum Bestandteil der normalen Rituale (Planings, Estimates, …) und oftmals zunächst im Pairing mit dem oder der Expert:in realisiert. Nach einer Zeit zieht er oder sie sich zurück. Das Thema lebt dann in einer Gilde (der neuland-Ausdruck für eine Community of Practice) weiter, sodass die unterschiedlichen Vertikalen-Teams dort ihre Erfahrungen mit der nicht-funktionalen Problematik austauschen können. Die Moderation der Gilden wird häufig von einem Mitglied der Enabling Teams bestritten.
Welche Fragen sind es, die von diesen Enabling Teams bearbeitet werden? In der initialen Phase eines neuen Projektes sind es oft Fragen der Infrastruktur. Der Aufbau der eigenen Umgebung, die Arbeit mit der API der Cloud, die Modellierung der Infrastruktur in Code. Beim Aufbau einer neuen Applikation rücken Fragen der Modellierung in den Vordergrund. Hier sind es Themen wie Hexagonale Architektur und Domain-driven Design (DDD), die behandelt werden. Sehr oft starten wir mit einem zweitägigen Workshop zum Thema DDD, der auch die Isolation der Domäne in einem Hexagon zum Gegenstand hat. Die präzisen Instrumente des DDD werden in einer Gilde geschult, in die alle Beteiligten ihre jeweiligen Modellierungsfragen einbringen. Wenn die initiale Phase abgeschlossen ist, aber möglichst früh, beschäftigen sich die Teams mit Security. Die Grundfrage, die von Expert:innen in die Teams getragen wird, ist, wie Security nicht zu einem Add-On verkommt, sondern zu einem originären Bestandteil jedes Features werden kann. Die Workshops im Team werden mit Diskussionen in einer entsprechenden Gilde flankiert.
Ein offenes Problem ist, wie auch Data Science zu einem integralen Bestandteil der Arbeit von Stream-Aligned Teams werden kann. Im Augenblick hat Data Science oftmals den Charakter, nur von einem Complicated-Subsystem Team bearbeitet werden zu können. (Dabei wäre dann aber nicht das Subsystem complicated, sondern die fachliche Dimension - eigentlich ein Widerspruch.) Es steht die These im Raum, dass Data Science nur dann für Stream-Aligned Teams von Wert ist, wenn diese das Agile-Fluency-Stadium Optimize erreicht haben, anders gesagt: Wenn diese Teams selber entscheiden, welche Fachlichkeit sie entwickeln. Aber das ist Thema für einen anderen Artikel.
Weitere Artikel der Team Topologie-Reihe:
Team Topologies in Auftraggeber-Dienstleister Konstellation
