Team Topologies in Auftraggeber-Dienstleister Konstellationen

Prolog

Wir bauen Software. Für Dritte. Unsere Kunden sind etablierte Distanzhändler:innen, Filialist:innen oder Hersteller:innen. Sie stehen in der Herausforderung, die digitale Transformation laufender Geschäftsmodelle und -prozesse zu bestehen. Dazu müssen sie immer wieder kurzfristig auf sich bietende Optionen reagieren. Nach langen Jahren auf privilegierten Märkten werden Anpassung und Umsteuerung plötzlich notwendige Kernkompetenz. Es müssen immer wieder weitreichende Entscheidungen getroffen werden. Economies of scope sind wichtiger als economies of scale.

Als Online-Händler:innen brauchen unsere Kunden hochwertige Software für den E-Commerce. Die schnelle Auslieferung von Features in hoher Qualität ist gefordert. Das muss nicht nur schnell, sondern auch on demand gehen. Das können die Kunden nicht nur aus eigenen Mitteln leisten – sie brauchen externe Dienstleister:innen. Allerdings ist auch für uns die Fähigkeit zur dauernden Anpassung und Umsteuerung notwendige Kernkompetenz. Wir sind als externe Softwareentwickler:innen erfolgreich, wenn wir technische Exzellenz, hohe Reaktionsgeschwindigkeit und tiefes Domänenwissen verbinden können. Hier liegt unser USP.

Wir pflegen selektiv offene und dynamische Beziehungen zum Kunden – der zentrale Prozess ist die Selbstorganisation des Teams mit Blick auf die Situation beim Kunden. Der Kommunikationsgegenstand ist das zu entwickelnde Produkt. All das im Team zu verankern sichert Leistung, Innovation und Reproduktion. Immer dort, wo unsere Kunden diese Struktur aufnehmen und sich ebenfalls anpassen, entstehen besondere Ergebnisse.

Aus unserer Perspektive gilt: Das neuland-Team ist zentraler Ort für unsere Expertise, die Produktion, die Kommunikation mit dem Kunden, für Konsens und Konflikt. Unsere Teams werden im Miteinander mit den Kunden, über Unternehmensgrenzen hinweg, wirksam. Sie funktionieren am besten als Teile von Netzwerken. Team und Ansprechpartner:innen beim Kunden bestimmen die Art und Tiefe der Kooperation flexibel. Die Zusammenarbeit von neuland-Teams und Kunden ist dem Wesen nach Kommunikation.

Unsere zu prüfende These: Team Topologies kann helfen, das spezifische Miteinander zwischen neuland und Kunden anders als bisher zu verhandeln und so gestaltbar zu machen.

Team Topologies - Auslieferung und Flow

Team Topologies ist im Kern eine teamzentrierte Anwendung von Conways Law auf die Softwareentwicklung. Als Einstieg neben dem Buch Matthew Skelton and Manuel Pais (2019) "Team Topologies: Organizing Business and Technology Teams for Fast Flow", IT Revolution sei auf das Video youtu.be/haejb5rzKsM verwiesen.

Es beschreibt die Welt der Softwareentwicklung aus Sicht der Organisationen, die vor den gleichen Herausforderungen stehen wie unsere Kunden. Sie müssen mit ihren Produkten den eigenen Kunden Features anbieten, die in deren Customer Journey Probleme lösen und so Wert stiften. Dieser dauernde Flow von Features bzw. der damit verbundene stetige Flow von Wert und Convenience für die Nutzenden des Onlinehandelangebots wird von ausliefernden Teams getragen. Sie sind dem Gedanken des Auslieferungsflows verpflichtet und optimieren ihre Arbeit in diese Richtung: sie sind Stream Aligned Teams.

Der limitierende Faktor für alle Software entwickelnden Teams ist die zu verarbeitende kognitive Last. Aufgaben, die zu groß für das Team sind, Informationen, die die Verarbeitungskapazität überschreiten, zerstören die Leistungsfähigkeit des Teams und werden bei TT mit dem zentralen Begriff der Cognitive Load beschrieben.

Die kognitive Last bei wissensbasierter Arbeit, wie der Softwareentwicklung, wird in drei Dimensionen differenziert: Erstens eher handwerkliche Basis-Wissenslast, die bewältigt werden muss, um die eigene Aufgabe zu erfüllen (intrinsic / skill). Zweitens die infrastrukturell verursachte Wissenslast, die sich aus dem technisch/organisatorischen System ergibt, in dem das Team sich bewegt (extraneous / mechanism) und – drittens und zentral für uns – die fach-domänenspezifische Wissenslast, ohne die die eigenen Fähigkeiten nicht kundenorientiert eingesetzt werden können (germane / domain focus).

Vereinfacht gesagt soll das kognitive Potenzial des Teams möglichst für die kundenspezifische Fachdomäne genutzt werden, wohingegen das eigene Handwerkszeug möglichst ohne Anstrengung zu beherrschen ist und auch die extern verursachte „Systemlast“ als wenig wertstiftend angesehen wird.

Fast alle unserer Kundenteams sind stream aligned. Dort, wo sie sich strikt an dem jeweiligen Kundennutzen ausrichten (als Vertikale Find, Buy, Decide o. ä.), fokussieren sie schon qua Aufgabenbereich die jeweilige Fachdomäne und liefern dadurch zielgenau, stetig und verlässlich fachlich motivierte Features aus.

Die These: Wenn sich die Teams (und damit in unserem Fall neuland und die Kundenseite) so organisieren, dass sie die kognitive Last für die Entwicklungsteams auf die Fachdomäne konzentrieren, entstehen die optimalen Voraussetzungen für Auslieferungsflows, die, so haben wir oben herausgearbeitet, in unserer Arbeit unabdingbare Voraussetzung für erfolgreiches Gestalten der digitalen Transformation ist.

Sidekick 1: Enabling als Unterstützung im Flow

Die kognitive Last, die sich aus dem eigenen Handwerk ergibt, wird in der Team Topologie durch einen Team Typus adressiert, das Enabling Team.

Auch exzellente und erfahrene Softwareentwickler:innen stehen immer wieder vor der Herausforderung, das eigene Wissen zu ergänzen und à jour zu halten. Die zielgerichtete Reduktion der damit verbundenen Last wird durch wissensvermittelnde Teams gemildert, die bei Bedarf und auf Zeit die jeweils spezifisch nötigen Tweaks des allgemeinen Entwickler:innenhandwerks in die Stream Aligned Teams tragen.

Unterricht, Frage und Antwort, Mitarbeit und Wissenstransfer durch gemeinsames Tun bestimmen die Kommunikation zwischen Stream Aligned Team und Enabling Team. TT verwendet hier die Begriffe der (zeit)intensiven Kollaboration / Facilitating.

In unserer Arbeit sind z. B. die aktuellen Microfrontend-Ansätze, die sich besonders für vertikal geschnittene Softwarearchitekturen und die dort jeweils verantworteten Produkte eignen, Gegenstand von Enabling Teams. Die DDD Schulungen, die wir intern und extern entwickelt haben, bringen ebenfalls ein bestimmtes Applikationsgerüst mit. Auch sie sind beim Kunden als Angebote von Enabling Teams und als Facilitating präsent.

Sidekick 2: Plattform mit Demut als Basis

Teams in großen und komplexen Organisationen müssen einen großen Teil ihrer kognitiven Kapazität auf die Verarbeitung infrastrukturell/organisatorischer Aufgaben verwenden. Tests, Deployments, Freigabeprozesse, technische Auslieferung, Skalierung, Recherche und vieles andere mehr verursachen kognitive Last.
TT adressiert das Problem der extraneous / mechanism Dimension der kognitiven Last mit Hilfe der Platform Teams, die im Kern die Entscheidung über technisch gleichwertige Varianten durch vorgefertigte Komponenten und Verfahren reduzieren. Dabei geht es – und das macht die Aufgabe dieser Teams so heikel – um die thinnest viable platform, also eine Lösung, die sich nicht zum neuen, umfassenden und selber kognitive Last verursachenden Moloch mausert, sondern immer wieder die Reduktion der kognitiven Last der Teams durch extern vorgegebene Muster thematisiert.

Das beste Plattformprodukt ist demnach eines, das nicht auffällt und z. B. nur eine Liste von Services zur Verfügung stellt, die die Stream Aligned Teams nicht nutzen müssen, aber nutzen wollen, weil es ihre Arbeit erleichtert. TT verwendet für diese formalisierte Kommunikation den naheliegenden Begriff API, mit deren Hilfe die komplizierten Systeme in die Produkte der Stream Aligned Teams integriert werden (siehe als Hintergrundinfo u. a. das Video von Jamie Dobson mit Matthew Skelton: youtu.be/NZL7O88xAL4).

An dieser Stelle werden wir unsere Praxis als neuland und unsere Annahmen möglicherweise am deutlichsten zu hinterfragen haben.

Unsere Erwartung (und ebenso die der Kunden) an die Teams ist oft, dass die Plattform zwar initial von einem Team aufgebaut wird, diese dann aber als Skill in die einzelnen Stream Aligned Teams wandern muss. Diese Interpretation des DevOps Satzes “you build it, you run it” scheint uns aktuell mindestens ergänzt werden zu müssen. Auch in der aktuellen Diskussion der Team Topologie Community wird immer mehr darauf verwiesen, dass eine gute Plattform wie ein eigenes Produkt entwickelt und “vermarktet” werden muss. Sie braucht Management und ein eigenes Plattformteam, das auf Dauer wirkt. Als Produkt muss sie sich permanent am gestifteten Wert für die nachfragenden Teams messen lassen und - das gehört dazu - einfach und verlässlich als Service, der über APIs zu nutzen ist, bereitstehen.

Das, was wir als Plattformteams verstanden haben, ist häufig identisch mit den Boards von Architekten oder einem besonders erfahrenen Team, das prototypisch die Plattform entwickelt und zur Verfügung stellt. Hier ist der Wandel durch Team Topologie am sichtbarsten: Die “Teams, die Prototypen entwickeln”, liefern im besten Fall “best practice”, sie geben Beispiel, bauen aber keine Plattform. Den Schritt zur Plattform nicht zu machen belastet im Saldo die ausliefernden Teams stärker, als durch den Wert - der mit dem Wissensaufbau für eigene Lösungen verbundene, spezifische Wert für den Kunden - gerechtfertigt scheint.

Sidekick 3: Complicated Subsystems in eigenen Teams

Eine weitere Möglichkeit, die kognitive Kapazität auf die wertstiftende Fachdomäne zu konzentrieren, ergibt sich, wenn Aufgaben, die von mehreren Stream Aligned Teams erfüllt werden müssen, dem Team nur als Nutzende der entsprechenden Komponenten und Produkte zur Verfügung gestellt werden. Die hinter den „möglichst einfach“ zu implementierenden Funktionen liegenden Systeme sind so komplex, spezialisiert oder sicherheitsempfindlich, dass sie von eigenen Complicated Subsystem Teams betreut werden.

In unserer Arbeit werden komplexe Datensammlungen, -aufbereitungen und -bewertungen im Bereich von data science, sicherheits- und datenschutzrelevanten Funktionen aus der Security und rechtssensiblen Aufgaben, wie die fraud detection, von Complicated Subsystem Teams verantwortet.

Ein Indiz für “geeignete Themen” ist eine Bereitstellung der Dienste als Service und ein entsprechend zugespitztes Skillset der Entwickler:innen im Team, das sich deutlich von dem der Entwickler:innen im Stream Aligned Team unterscheidet.

Risiken bei Plattform und Subsystemen: "Wein und Schlauch"

Die Idee, Plattformfunktionen in das Skillset der Entwicklungsteams zu integrieren, scheint gerade in Kunde-Dienstleisterbeziehungen seinen Reiz zu haben. Die Verantwortung für das von den Dienstleister:innen entwickelte Produkt in toto dem Entwicklungsteam aufzuladen, löst für beide Partner:innen scheinbar viele Probleme. Die Businesseite beim Kunden muss sich nicht weiter um den Aufbau eigener technischer Kapazitäten kümmern und kann sich auf die Formulierung fachlicher Anforderungen beschränken. Die Ansprechpartner:innen für die Technik beim Kunden müssen den Produktgedanken für ihre Plattform nicht leben. Sie können sich darauf beschränken, im eigenen Unternehmen via Anschlusszwang und Vorgabe die eigene Plattformlösung vorzugeben.

Das kann - so nehmen wir es wahr - problematisch werden. Immer dann, wenn beim Kunden die Plattform und das entsprechende Team zum Gravitationszentrum wird, das auf Vorschrift (anstatt auf Wert) setzt und den Gedanken des Produktes nicht lebt, entstehen Friktionen zwischen Plattformseite und den Auslieferungsteams.

Man könnte sagen: In solchen Fällen ist das Fortexistieren alter Muster bei Auftraggeber:innen garantiert.

Auch für die Seite der Dienstleister:innen entstehen Risiken. Denn selbst, wenn es zunächst verführerisch sein mag, unabhängig von der Featureentwicklung auch Betrieb und Maintenance des eigenen Produktes inklusive der Plattformaspekte im eigenen Aufgabenbereich zu behalten, entstehen so doch Insellösungen, ein hoher Aufwand für die Unterhaltung der eigenen Lösung und damit möglicherweise ein "tendenzieller Fall der Featurefertigstellungsrate" - und diese hoch zu halten ist Teil und Ausdruck unseres USPs (s.o.).

Auch die Complicated Subsystem Diskussionen bergen Risiken. In der Diskussion werden diese - sich selbst - oft als “Querschnitt-” oder “Basissysteme” definierenden Lösungen immer wieder als mögliches Einfallstor für falsche Systemschnitte verstanden. Ein Middlewaresystem ist im alten Schnitt vielleicht Querschnitt und allzuständig für die Kommunikation, es ist damit aber kein “complicated subsystem”, das von einem eigenen Team betreut werden muss.

Für uns als Dienstleistende ist die Vergabe des Etiketts “kompliziertes Subsystem” oft ein Zeichen, genauer hinzuschauen, ob dort nicht die technische und organisatorische Struktur per Bezeichnung unverändert gelassen werden soll. Das gilt nicht nur für die Kundenseite. Auch, wenn in unseren Teams Allzuständigkeit und dauernde Kollaboration zwischen Auslieferungsteams eingefordert werden, sind Reflexionen hilfreich. Oft sind dann alte fachliche Fragen nicht zu Ende gedacht oder auf neue fachliche Herausforderungen keine geeigneten Antworten gesucht worden.

Anwendung: Kognitive Last bei neuland-Kundenteams

Im Rahmen eines neuland Get Together im August 2021 wurde in einem Interview / Diskussionsslot der erste Versuch einer Teambefragung verprobt. In einer Runde von 12 Personen aus insgesamt vier (fünf) erfahrenen neuland Kundenteams wurde eine „Cognitive Load Survey” zur Erhebung der kognitiven Last in den Teams und einer anschließenden Diskussion ausprobiert.

Die erste Frage: „Wie hoch schätzen wir die kognitive Last im eigenen Team ein?“

Mit Hilfe einer Daumenwertung wurde ein Wert zwischen auskömmlich, gering, gut beherrschbar und nicht beherrschbar erhoben. Alle Teams haben ihre eigene kognitive Last zwischen beherrschbar und überfordert eingeordnet. Kognitive Last ist für alle Teams eine verständliche und bewertbare Kategorie.
Die zweite Frage versuchte, eine Einschätzung der quantitativen Zusammensetzung der kognitiven Last zu erheben. Dazu wurden in einer Runde Begriffe zu den Inhalten gesammelt, die die kognitive Last der Teams in den genannten drei Bereichen beschreiben können. In einer anschließenden Runde wurden die Stichworte vorgestellt, kommentiert und diskutiert.

Die zweite Frage: „Auf welche Bereiche verteilt sich die kognitive Last?“

Sehr grob sollten dabei “Flächen als Anteile“ eingezeichnet werden.

Bemerkenswert sind:

• die Schärfung des eigenen Handwerkszeugs wird von allen Teams als wichtiger Bestandteil der kognitiven Last angesehen. Die These, dass der Anteil bei zunehmender Erfahrung der Teams weniger wichtig werde, lässt sich hier erstmal nicht bestätigen. Der stete technologische Zuwachs an notwendigem Wissen in unseren Teams könnte sich hier bemerkbar machen.
• die Verteilung zwischen dem organisatorisch / infrastrukturellen Wissen (extraneous) und dem Fachdomänenwissen (germane) variiert stark. Man könnte formulieren: Die Notwendigkeit, sich mit dem von außen aufgebürdeten Wissen zu beschäftigen, geht bei unseren Stream Aligned Teams auf Kosten der Auseinandersetzung mit der Fachdomäne.
• außerdem scheinen alle Teams, die in dieser ersten Exploration einen geringen Anteil ihrer kognitiven Last durch den Bereich der externen Anforderungen verursacht sehen, über Plattformen als Service zu verfügen, die via APIs eingebunden werden können.

Die dritte Frage: „Was verursacht die kognitive Last im Team?“

Im dritten Schritt wurde qualitativ nach Stichworten zur Beschreibung der jeweiligen kognitiven Last gefragt.

Im Bereich Intrinsic fällt auf, dass:

• sobald gleichzeitig Alt- und Neusysteme zu beherrschen sind, die kognitive Last im Bereich Intrinsic hoch wird. Das erscheint trivial, macht jedoch die häufig geäußerte Kritik an Migrationsansätzen im Gegensatz zu Greenfieldprojekten bei größeren Plattformwechseln operationalisierbar.
• moderne Frontend Technologien und Konzepte Aufmerksamkeit fordern.
• Produktlösungen den Aufbau von Spezialwissen für diese (teilweise sehr überalterten) technischen Lösungen erfordern.
• die Architekturverantwortung von den Teams als Bestandteil des eigenen Handwerkszeugs gesehen wird, das es zu beherrschen gilt.

Zwischenergebnis / These: Wir prüfen die Wirksamkeit des Enabling, um unsere Kundenteams gezielt (und auf Zeit) zu unterstützen.

Während wir bisher die Wissensverteilung vor allem als Fringe Benefit der gemeinsamen Arbeit sehen und über eher leichtgewichtige Gilden organisieren, wollen wir mit den Teams die Wirksamkeit gezielten Enablings experimentell testen.

Wir sehen in unserer intrinsisch-technischen Domäne bisher keinen Grund zur Komplexitätsreduktion, um stärker auf standardisierte Kaufprodukte zu setzen. Frameworks und klassische Softwareentwicklung from scratch sind die bessere Basis für unsere Lösungen. Das Mindset der IT-Ingenieur:innen passt u. E. gut zu dem individuellen Anpassungsbedarf der E-Commerce-Software unserer Kunden – aus technischen und fachlichen Gründen.

Im Bereich extraneous erwähnen die Teams insbesondere Technologien und unsichere Abläufe.

Zwischenergebnis / These: Plattformthemen scheinen uns gut durch eine thinnest viable platform adressiert zu werden. Diese muss verlässlich verabredet und möglichst benutzerfreundlich sein. Eine Plattformlösung, die als Produkt entwickelt wird und mit der man nur durch eine API zu tun hat, ist dabei nicht zwingend an einen Serviceprovider gebunden. Sie muss die Aufgabe erfüllen, für die am featureflow orientierten Teams optimale Bedingungen zu schaffen. Das, und nicht die Zahl der Buchstaben im Kurznamen des jeweiligen Anbieters, sollte im Vordergrund der Lösung stehen.

Für complicated subsystems sehen wir standardisierte Lösungen mit klarer Serviceorientierung als sinnvolle Ausgangspunkte an. Die Teams, die sich bei uns darum kümmern, müssen aber in den Code dieser Produkte eingreifen können. Dies gilt insbesondere für die „politisch wichtigen“ Security Themen, die technisch zwar gut beherrschbar sind, aber extern stark unter Beobachtung stehen. Die Problematik der Complicated Subsystems als strukturkonservative Chiffre ist weiter oben bereits angeführt worden.

Die Stichworte im Bereich domain zeigen die Notwendigkeit, die eigenen Modelle des E-Commerce auf die besonderen Anforderungen des Kunden zu übertragen.

Zwischenergebnis / These: Für die Optimierung der kognitiven Last im Bereich der Fachdomäne ist eine intensive Kollaboration zwischen der Fach- (oder Business-) Ebene und dem Team wichtig.

Diese Kommunikation wird möglichst dauerhaft sein und in beide Richtungen laufen. Sie muss neue Themen aufnehmen und diskutierbar machen. Die Rolle eines Product Owners, so wie wir sie verstehen, bündelt und strukturiert diese Kommunikation. Diese Rolle zu verabreden und auszufüllen ist eine Aufgabe, die seitens des Kunden und neulands ernstgenommen werden muss. Wie sie mit der Entwicklungsarbeit des Teams zu synchronisieren ist, werden wir – anknüpfend an unsere vorhandenen Rollen – ebenfalls mit den Teams diskutieren.

Nächste Schritte

In den Teams werden Gesprächsrunden zur TT durchgeführt. Dabei sollen zunächst die o. g. Thesen verprobt und die Begriffe weiter angewendet werden.

Danach werden wir die grafische Darstellung der TT für die betreffenden Teams erarbeiten und auf dieser Grundlage in die Diskussion mit der Kundenseite treten. Unser Ziel ist die Optimierung des Flows, oder doch zumindest der Einstieg in eine Diskussion darüber und die am besten geeignete Struktur.

Wir sind auf die Ergebnisse gespannt und berichten weiter.