Identifikation von Team-Grenzen

Michael Plöd

Wir werden zuerst einmal kurz betrachten, was zentrale Eigenschaften eines autonomen, cross-funktional aufgestellten Teams sind, um schließlich im Hauptteil verschiedene Techniken kennenzulernen, mit denen man die Grenzen dieser Teams entdecken kann. Dazu zählen: Bruchflächen (Fracture Planes) aus Team Topologies, Domain-Driven Design und Independent Service Heuristics.

Was sind autonome, cross-funktionale Teams

In der heutigen dynamischen Geschäftswelt sind autonome, cross-funktionale Teams zu einem Schlüsselinstrument für den Erfolg von Unternehmen geworden. Diese Teams zeichnen sich durch eine Vielzahl von Eigenschaften aus, die sie zu einer effektiven und flexiblen Einheit machen.

Vielfältige Fähigkeiten und Kompetenzen: Ein cross-funktionales Team setzt sich aus Mitgliedern mit unterschiedlichen Fähigkeiten und Fachkenntnissen zusammen. Dies ermöglicht es, verschiedene Perspektiven und Lösungsansätze zu integrieren, was zu kreativeren und umfassenderen Lösungen führt.

Selbststeuerung und Autonomie: Autonome Teams haben die Befugnis, Entscheidungen auf operativer Ebene zu treffen. Sie sind in der Lage, Ziele zu setzen, Prioritäten festzulegen und Arbeitsabläufe zu planen, ohne ständige externe Anleitung. Dies führt zu schnelleren Reaktionszeiten und einer agileren Arbeitsweise.

Schnelle Anpassungsfähigkeit an Veränderungen: Aufgrund ihrer Flexibilität und Entscheidungsbefugnis sind autonome Teams besser in der Lage, sich an sich ändernde Umstände anzupassen. Sie können schnell neue Prioritäten setzen und Ressourcen neu zuweisen, um den Anforderungen gerecht zu werden.

Kontinuierliche Lernbereitschaft: Autonome Teams sind bestrebt, sich weiterzuentwickeln und zu verbessern. Sie sind offen für Feedback und nutzen regelmäßig die Möglichkeit zur Weiterbildung, um ihre Fähigkeiten zu erweitern.

Zusätzlich zu diesen Eigenschaften ist es wichtig, den Bezug zu Stream-aligned Teams aus dem Team Topologies-Ansatz herzustellen. Stream-aligned Teams sind darauf spezialisiert, bestimmte Geschäftsströme zu bedienen. Sie agieren als Enabler für die schnelle und effiziente Entwicklung von Microservices-Architekturen.

Die enge Verknüpfung von autonomen, cross-funktionalen Teams und Stream-aligned Teams in (beispielsweise) Microservices-Architekturen ermöglicht eine optimale Ausnutzung der Vorteile beider Ansätze. Cross-funktionale Teams bringen die Vielfalt der Fähigkeiten und die Autonomie ein, die für die Entwicklung und Wartung von Microservices entscheidend sind. Stream-aligned Teams sorgen dafür, dass die entwickelten Services nahtlos in die Geschäftsprozesse integriert werden.

Insgesamt sind autonome, cross-funktionale Stream-aligned Teams ein Schlüssel zur Steigerung der Innovationskraft und Wettbewerbsfähigkeit eines Unternehmens in der Ära moderner Software-Architekturen. Durch die Kombination von vielfältigen Kompetenzen, Selbststeuerung und klaren Kommunikationsstrukturen schaffen sie eine agile Arbeitsumgebung, die sich schnell an Veränderungen anpassen kann und so den langfristigen Erfolg sicherstellt.

Identifikation von Team-Grenzen

Die Kerneigenschaften dieser Teams und deren Vorteile sind meist nachvollziehbar, weitaus schwieriger ist es jedoch passende Grenzen zu finden innerhalb derer Teams: • den Großteil Ihrer Entwurfsentscheidungen treffen können, ohne sich dabei mit anderen Teams koordinieren zu müssen • die fachliche und technische Komplexität ihrer Zuständigkeitsgrenze erlernen und beherrschen können • qualitativ hochwertige Software liefern können • den Freiraum haben neue Themen zu explorieren und zu verproben

Inzwischen haben sich in dazu verschiedene Vorgehensweisen und Techniken etabliert, die sich auch miteinander kombinieren lassen: • Bruchflächen aus Team Topologies • Bounded Contexts aus Domain-driven Design • Independent Service Heuristics

Im Folgenden werden diese Techniken vorgestellt.

Team Topologies Bruchflächen

Dem Buch Team Topologies von Matthew Skelton und Manuels Pais, welches seit Ende 2023 auch in einer deutschen Fassung vorliegt, entsprang die Idee der Stream-aligned Teams. Neben der Vorstellung von vier fundamentalen Team-Arten und drei grundlegenden Modi der Interaktion zwischen Teams lieferte das Buch auch eine Vorgehensweise für den Schnitt von Team-Grenzen: die Bruchflächen (Fracture Planes im englischen Original).

Bei Bruchflächen handelt es sich um verschiedenste Treiber für den Schnitt von Teams. Team Topologies definiert Bruchflächen wie folgt:

Team Topologies sieht explizit eine Kombination der Bruchflächen vor und ermutigt, den Schnitt eines Teams aus dem Blickwinkel unterschiedlicher Bruchflächen zu beobachten. Bei der folgenden Auflistung der Bruchflächen fällt schon eine Verbindung zu der zweiten Vorgehensweise dieses Artikels auf:

• Bounded Contexts, die an Domänen angelehnt sind
• Performance Isolierung
• User Personas
• Änderungskadenz
• Regulatorische Compliance
• Teamstandort
• Risiko
• Technologie

Domain-driven Design Bounded Contexts

Bounded Contexts sind ein zentrales Element des strategischen Domain-driven Designs. Die Idee wurde im Jahre 2003 von Eric Evans in seinem Buch „Domain-driven Design - Tackling Complexity in Software“ beschrieben. Einen Bounded Context kann man als Grenze um ein (fachliches) Modell verstehen, welches in einer konsistenten Sprache ausgedrückt und auf einen bestimmten Zweck zugeschnitten ist. Es handelt sich somit um eine Modularisierungsstrategie für komplexe Software-Systeme, die an einer entscheidenden Stelle mit dem klassischen, auf Wiederverwendung ausgerichteten System-Design bricht: Der Fokus bei der Modellierung von Bounded Contexts liegt auf Spezialisierung von Modellen, die eine bestimmte Sache - den Zweck - bestmöglich abbilden sollen. Ist dieses Modell dann noch wieder verwendbar, würde niemand aus der DDD-Community etwas dagegen haben. Aber ebenso wäre es ohne Einschränkungen vertretbar, wenn das Modell nicht wiederverwendbar wäre. Bounded Contexts sind im Umfeld von Team Topologies das präferierte Mittel der Wahl, um Grenzen für Teams zu identifizieren. Es ist ratsam, mit Bounded Contexts zu starten, um danach die anderen Bruchflächen zum Nachschärfen der Grenzen zu nutzen.

Die Vorgehensweisen für das Design von Bounded Contexts greifen in der Regel ineinander und werden üblicherweise zusammen verwendet. Sehr verbreitet sind hierbei Heuristiken aus den folgenden Methoden / Ideen:

• BigPicture EventStorming
• Bounded Context Design Canvas
• Ubiquitous Language

BigPicture EventStorming ist eine Methode der kollaborativen Modellierung, die von Alberto Brandolini erfunden und in einem Buch beschrieben wurde. Bei der Workshop-Methode geht es darum, eine Domain unter Zuhilfenahme fachlicher Ereignisse zu explorieren. Diese Ereignisse nennt man Domain Events und sie werden auf orangenen Sticky Notes festgehalten. Ein Domain Event enthält immer ein Verb in Vergangenheitsform. Diese Events werden auf einer Wandfläche gesammelt und dann sortiert. Schließlich geht es daran, sogenannte Pivotal Events und Swimlanes zu identifizieren. Pivotal Events sind Ereignisse, die eine besondere Prominenz haben, die wichtig sind und die Veränderungen darstellen. So wären im Bereich einer Baufinanzierung für Privatkund:innen beispielsweise „Antrag eingereicht“ oder „Kreditentscheidung positiv getroffen“ Kandidaten für solche Pivotal Events. Diese werden in der Regel durch vertikale Striche, meist mit Artist Tape, markiert. Swimlanes hingegen sind Bereiche mit denen parallellaufende Prozesse oder Abzweigungen markiert werden. Die Modellierungsfläche sollte nach der Identifikation von Pivotal Events und Swimlanes in etwa wie folgt aussehen:

Auf dieser Basis kann man nun mit zwei Fragestellungen und Heuristiken arbeiten:

• Ein Pivotal Event liegt an der Grenze eines Bounded Contexts (oder eine Subdomain)
• Swimlanes können Treiber für das Aufsplitten von Bounded Context Kandidaten sein

In einem nächsten Schritt sollte man sich noch fragen, welche der bereits markierten Bereiche zusammengehörig sind. Zusammengehörigkeit kann dabei unter der Berücksichtigung von sprachlichen Facetten oder durch Betrachtung fachlicher Regeln eruiert werden. Im Hinblick auf die sprachlichen Facetten geht es um Terminologie und die Bedeutung von Begriffen. Wir sollten uns fragen, ob ein Wort in Bereich A und B die gleiche oder eine unterschiedliche Bedeutung hat. Das Gleiche gilt für Abkürzungen. So gibt es beispielsweise im Banking den Begriff FX. Dieser kann einerseits Foreign Exchange Trading, also den Handel mit Währungen oder Fixed Interest Rates, also feste Zinsen bedeuten. In diesem Fall liegen Unterschiede vor und man sollte diese fachlichen Bereiche wohl besser trennen.

Des Weiteren kommt es im Zusammenhang mit Swimlanes häufiger vor, dass diese keinen der Domäne zuträglichen fachlichen Zweck erfüllen oderer eine eher untergeordnete Rolle spielt. In diesem Fall ist es ratsam, am EventStorming Board nach anderen Events zu suchen, die von einer solchen Swimlane abhängen, aber die den eigentlichen Zweck repräsentieren. Jeder Bounded Context sollte einen klar benennbaren fachlichen Zweck haben.

Eine gute Hilfestellung im Hinblick auf die Fragestellungen rund um das Design von Bounded Contexts ist die von Nick Tune erfundene und inzwischen von der DDD-Crew auf GitHub unter eine Creative Commons Lizenz weiterentwickelte Bounded Context Design Canvas. Die Canvas sieht wie folgt aus:

Mithilfe dieser Technik werden Sie dabei unterstützt, jederzeit sämtliche relevanten Fragen beim Bounded Context Design auf dem Schirm zu haben. Des Weiteren ist eine vollständig ausgefüllte Canvas eine sehr gute Dokumentation.

Wie bereits weiter oben erwähnt, sind Bounded Contexts die favorisierte Bruchfläche für das Design von Team-Grenzen. Man sollte jedoch hier nicht haltmachen, sondern den aktuellen Entwurf noch anhand der anderen Bruchflächen gegenprüfen und bei Bedarf nachjustieren.

Die weiteren Bruchflächen

Eine weitere interessante Bruchfläche wird von Team Topologies Performance Isolierung genannt. Hierbei geht es darum zu identifizieren, ob es im Gesamtsystem Bereiche gibt, die besondere Anforderungen in den Bereichen Laufzeit-Performance und Skalierbarkeit haben. Ich empfehle jedoch, diese Bruchfläche ganzheitlich zu interpretieren und erweitere den Betrachtungsfokus auf die Qualitätsanforderungen. Neben Laufzeit-Performance und Skalierbarkeit werden hierbei beispielsweise Themen wie Verfügbarkeit, UX oder Security mit in die Betrachtung mit aufgenommen. Beispielsweise muss ein Formular für die Erfassung von Krediten 24/7 mit hoher Verfügbarkeit bereitgestellt werden, während Prozesse im Backoffice meist nur zu üblichen Arbeitszeiten während Werktagen (12/5) verfügbar sein müssen.

Insbesondere im Hinblick auf UX und Verfügbarkeit kann die Bruchfläche User Personas wertvolle Einblicke liefern. Verschiedene Nutzergruppen haben unterschiedliche Bedürfnisse an die Nutzbarkeit eines Systems. Expert:innen arbeiten beispielsweise lieber mit komplexeren Masken, die sie mit Tastatur-Shortcuts bedienen während unerfahrene Nutzer:innen einfache Wizards favorisieren, die sie durch eine Anwendung navigieren. In solchen Situationen ist es also sinnvoll, Subsysteme für bestimmte User Personas abzuspalten.

Eine weitere Perspektive zur Verfeinerung des Team-Schnitts kann die Änderungskadenz sein. Jedes größere System wird Teilbereiche haben, die sich häufig ändern und andere, welche eher selten bis gar nicht angepasst werden müssen. Auch hier mag eine Trennung sinnvoll erscheinen. Jedoch ist zu empfehlen, diese Bruchfläche noch um eine Betrachtung der Release-Geschwindigkeit zu erweitern. Wie schnell müssen neuen Anforderungen in welchen Bereichen in Produktion geliefert werden.

Die Bruchfläche des Risikos adressiert die Hypothese, dass es innerhalb eines komplexen Systems unterschiedliche Bereiche mit divergierenden Risiken gibt. Das Risiko bezieht sich dabei auf Facetten wie Ausfallwahrscheinlichkeit, Änderungsrisiken, Anzahl von Nutzer:innen oder den Einfluss eines Teilbereichs auf den Abschluss von Geschäften.

Ein besonderes Risiko stellt die regulatorische Compliance dar, so diese in Team Topologies extra als gesonderte Bruchfläche ausgewiesen wurde. Diese Bruchfläche ist vor allem in stark regulierten Branchen wie dem Bank- oder dem Versicherungswesen von Interesse. Regulatoren verlangen von Unternehmen Mechanismen für die Auditierung, die Dokumentation, das Testen und die Auslieferung von Software, die in den Geltungsbereich dieser Vorschriften fällt, sei es für Kreditkartenzahlungen, dem Reporting von Transaktionen oder dem Abschluss von Geschäften. Andererseits sollte die Einhaltung regulatorischer Anforderungen nicht auf Teile des Systems angewandt werden, die nicht so kritisch sind. Die Abspaltung von Teilbereichen innerhalb eines Monolithen, die in den Geltungsbereich von Regulierungen fallen, ist eine passende Bruchfläche.

Auch die Location der Mitglieder eines Teams stellt eine Bruchfläche dar. Teams, die geografisch verteilt sind und in verschiedenen Zeitzonen arbeiten, sind natürlich nicht an einem gemeinsamen Standort. Aber auch Teams, deren Mitglieder im selben Bürogebäude auf verschiedenen Etagen oder in verschiedenen Räumlichkeiten arbeiten, können als geografisch getrennt betrachtet werden. Ist es nicht möglich, ein Team entweder komplett remote oder an einer gemeinsamen Location arbeiten zu lassen, kann es sinnvoll sein, das System so aufzuteilen, dass die Teams klar zugeordnete Locations haben.

Die letzte, und in meinen Augen kritischste, Bruchfläche stellt Technologie dar. Bei dieser Option werden Teams und Teilbereiche eines Systems nach verwendeten Technologien und den entsprechenden Skills geschnitten. Ich rate jedoch dringend dazu, diese Bruchfläche nur in sehr begründeten Ausnahmefällen zu verwenden, da durch einen Schnitt nach Technologie eine echte fachliche Ende-zu-Ende-Verantwortung nicht erreicht werden kann.

Independent Service Heuristics

Wenn wir Organisationen für einen schnellen Arbeitsfluss entwerfen, müssen wir effektive Grenzen zwischen den verschiedenen Streams finden. Techniken wie Domain-driven Design (DDD) sind dafür sehr leistungsfähig, können aber ziemlich aufwendig und schwer zu erlernen sein. Ein leichtgewichtiger Zwischenansatz ist die Frage: "Könnte dieses Ding als Cloud-gehosteter (SaaS) Service oder Produkt betrieben werden?

Independent Service Heuristics, kurz ISH, decken viele typische Situationen in moderner Software ab, aber nicht alle. Er soll das Gespräch anregen und einen Denkrahmen bieten, aber nicht als perfektes „Allheilmittel“ dienen.

Sie können Independent Service Heuristics verwenden, indem Sie ihre Erkenntnisse aus den vorherigen Schritten aufgreifen und kollaborativ im Team folgende Fragen mit ja, nein oder vielleicht beantworten:

Sinn-Prüfung: Könnte es logisch sinnvoll sein, diese Sache „als Service“ anzubieten?

Marke: Könnten Sie sich vorstellen, diese Sache als öffentlichen Cloud Service (wie MopsBankRetailBaufi.com) zu vermarkten?

Einnahmen/Kunden: Könnte diese Sache als rentabler Cloud Service in Bezug auf Einnahmen und Kunden verwaltet werden?

Kostenverfolgung: Könnte das Unternehmen derzeit die Kosten und Investitionen in diese Sache getrennt von ähnlichen Dingen verfolgen?

Daten: Ist es möglich, die Eingabedaten (aus anderen Quellen), die diese Sache benötigt, klar zu definieren?

User-Personas: Könnte diese Sache eine kleine/gut definierte Gruppe von Benutzertypen oder Kunden (User-Personas) haben?

Teams: Könnte ein Team oder eine Reihe von Teams einen Service auf der Grundlage dieser Sache effektiv aufbauen und betreiben?

Abhängigkeiten: Wäre dieses Team in der Lage, den größten Teil der Zeit unabhängig von anderen Teams zu agieren, um seine Ziele zu erreichen?

Impact/Wertschöpfung: Würde der Umfang dieser Aufgabe für ein Team eine wirkungsvolle und interessante Herausforderung darstellen?

Produktentscheidungen: Wäre das Team, das an dieser Sache arbeitet, in der Lage, seine eigene Produkt-Roadmap und die Produktrichtung zu bestimmen?

Es ist dringend dazu anraten, dass jede Person in einem ISH-Workshop diese Fragen für sich selbst beantwortet. Selten wird es zu einem eindeutigen Meinungsbild kommen, anstelle dessen wird sich erfahrungsgemäß eher eine Tendenz abzeichnen. Anbei ein anonymisiertes Bild der Anwendung von Independent Service Heuristics aus einem Workshop: