Reteaming für schnelleren Flow: Eine Case Study

Wie gestaltet man Teams so, dass sie sich kontinuierlich weiterentwickeln können und dabei den Wertstrom im Unternehmen maximieren? Diese Frage stellt sich früher oder später in jedem wachsenden Softwareunternehmen. Denn in vielen Organisationen sind Teams das Fundament, auf dem Unternehmen ihr gesamtes Organisationsdesign aufbauen. In dieser Case Study stelle ich dar, wie wir für Pirate Ship einen partizipativen Ansatz gewählt haben, um genau diese Herausforderung zu meistern.

Gemeinsam mit Susanne Kaiser, den deutschen Gründern von Pirate Ship und den Entwicklungsteams haben wir den von Susanne entwickelten Ansatz von Architecture for Flow in die Praxis umgesetzt und einen Re-Organisationsprozess begleitet, der die Teams aktiv in alle Entscheidungen einbezogen hat. Die Ergebnisse und Learnings aus diesem Prozess teile ich in diesem Artikel.

Was euch in dieser Case Study erwartet:

• Wie wir Architecture for Flow als ganzheitlichen Ansatz für die Team-Reorganisation genutzt haben.
• Welche Workshops und Formate sich bei der partizipativen Neugestaltung von Teams bewährt haben.
• Wie wir mit Self-Selection und Konsent-Entscheidungen gearbeitet haben.
• Welche Learnings sich für ähnliche Reorganisationsprozesse ableiten lassen.

Pirate Ship ist ein 2014 gegründetes Unternehmen, das eine cloudbasierte Versandsoftware für kleine und mittlere Unternehmen anbietet um, Versand für sie so einfach und günstig wie möglich zu machen. Das Besondere: Die Software ist kostenlos nutzbar, das Geschäftsmodell basiert auf Partnerschaften mit Versanddienstleistern.

Das Unternehmen operiert von zwei Standorten aus: das Stammhaus mit Customer Support, Marketing, Finance und Partnermanagement ist in den USA. Die Softwareentwicklung ist in Hamburg angesiedelt, wo mittlerweile rund 30 Entwickler*innen beschäftigt sind.
Der große Wachstumsschub begann 2021. Bis dahin hatte die Hamburger Entwicklungsabteilung in einem einzigen Team gearbeitet - mit dem sprichwörtlichen Spirit einer Startup-Crew: wenig Struktur, viel Freiraum, alle arbeiten an allen Themen. Als das Team geteilt wurde und 2022 zusätzlich ein Infrastruktur-Team entstand, bedeutete das besonders für die "erste Crew" einen deutlichen Kulturwandel. Doch die bisherige Form hatte ihre Grenzen erreicht.

2023 zeichnete sich ab, dass weiteres Wachstum bevorstand. Die bestehenden Teams erreichten ihre Limits - sowohl was die Größe der Aufgabenbereiche als auch die Arbeitslast betraf. Die beiden deutschen Gründer & Geschäftsführer wollten dieses Mal einen anderen Weg gehen: Die neue Team-Struktur sollte nachhaltig und flexibel sein, um auch künftiges Wachstum zu ermöglichen. Ich begleite die deutsche Organisation und ihre Geschäftsführer als Beraterin und Sparringspartnerin und empfahl an diesem Punkt die Zusammenarbeit mit Susanne Kaiser als Expertin für Team Topologies, Domain Driven Design und Wardley Mapping und ihren daraus entwickelten Ansatz Architecture for Flow.

2023 gab es drei Feature-Teams und ein Infrastruktur-Team. Im Zentrum stand ein über die Jahre gewachsener PHP-Monolith. Die Teams kämpften mit mehreren Herausforderungen:

• Überlastung: Die Teams waren an ihrer Kapazitätsgrenze
• Zu große Domains: Die Teams mussten zu viele verschiedene Aufgaben bewältigen, was zu
• Wissensilos führte und den Wissensaustausch erschwerte
• Unklares Ownership: Besonders bei teamübergreifend genutzten Komponenten waren
• Zuständigkeiten oft unklar oder hingen historisch an einzelnen Personen
• Entwicklungs-Engpässe: Diese machten weiteres Wachstum notwendig

Zwar arbeitete Pirate Ship bereits mit vertikal geschnittenen, cross-funktionalen Teams, doch die ersten Team-Teilungen waren ohne tiefgehende Analyse der Domain erfolgt - ein pragmatischer Ansatz, der angesichts der genannten Herausforderungen an seine Grenzen stieß. Diesmal sollte es anders laufen: Das Ziel war nicht nur, zehn neue Entwickler*innen zu integrieren, sondern vor allem eine nachhaltige Teamstruktur zu schaffen. Durch eine gründliche Analyse der Domain sollten Teams entstehen, die trotz des komplexen Monolithen eigenständig und effektiv Wert liefern können. Die Beschränkung auf maximal sieben Personen pro Team sollte dabei eine enge Zusammenarbeit ermöglichen und der Entstehung neuer Wissensilos vorbeugen.

Ein wichtiger Kontext für unseren Ansatz: Pirate Ship pflegt eine sehr beteiligungsorientierte Kultur. Die Teams arbeiten agil und sind für ihre Arbeitsprozesse selbst verantwortlich. Sie arbeiten mit Quartalszielen, und es gibt neben den Teams selbstgesteuerte Arbeitsgruppen für Bereiche wie Recruiting, Onboarding oder DevOps.

In einer Welt schneller Veränderungen und wachsender Unsicherheiten müssen sich Organisationen kontinuierlich anpassen, um wettbewerbsfähig zu bleiben. Doch wie gestaltet man Systeme, die sich im ständigen Wandel weiterentwickeln und gedeihen können? Der von Susanne Kaiser entwickelte Ansatz Architecture for Flow bietet hierfür einen ganzheitlichen Ansatz, der Geschäftsstrategie, Softwarearchitektur und Teamorganisation verbindet.

Die Stärke von Architecture for Flow liegt in der Verbindung dieser drei Ansätze:

• Wardley Maps helfen uns, die strategische Landschaft zu verstehen und Wertschöpfungsketten zu identifizieren.
• Domain Driven Design hilft uns, diese Wertströme in handhabbare Bounded Contexts zu übersetzen.
• Team Topologies gibt uns die Werkzeuge, um Teams optimal um diese Bounded Contexts herum zu organisieren.

Bei Pirate Ship hat uns dieser kombinierte Ansatz geholfen, zu einer adaptiven Organisation zu kommen, die nicht nur schnell und nachhaltig auf Veränderungen reagieren, sondern auch ihr weiteres Wachstum bewusst gestalten kann.

Wardley Mapping ist ein von Simon Wardley entwickeltes Framework zur Geschäftsstrategie. Im Zentrum steht die Wardley Map - eine visuelle Darstellung der Geschäftslandschaft einer Organisation. Diese Map ist eine Art Landkarte, die zwei zentrale Dimensionen hat:

• Die vertikale Achse zeigt die Wertschöpfungskette inklusive Sichtbarkeit: Ganz oben als Anker der Wardley Map stehen die Nutzer*innen und ihre Bedürfnisse, darunter alle Komponenten, die zur Erfüllung dieser Bedürfnisse beitragen
• Die horizontale Achse zeigt den Evolutionsgrad der Komponenten:
  • Genesis: Völlig neue, innovative Komponenten
  • Custom Built: Speziell entwickelte Lösungen
  • Product: Verfügbare Produkte oder Open-Source-Lösungen
  • Commodity: Standardisierte Dienste

Diese Visualisierung hilft Organisationen bei wichtigen strategischen Entscheidungen: Wo müssen wir selbst entwickeln? Wo können wir fertige Produkte nutzen? Was sollten wir auslagern?

Domain-Driven Design (DDD) ist mehr als nur ein technischer Ansatz - es ist eine Sammlung von Konzepten und Praktiken, die dabei helfen, komplexe Geschäftsbereiche (Domains) zu verstehen und in Software abzubilden. Zentral dabei ist die enge Zusammenarbeit zwischen Fachexpert*innen und Entwicklungsteams, um eine gemeinsame Sprache und ein gemeinsames Verständnis zu entwickeln.

DDD unterscheidet drei Arten von Domänen:

1. Core Domain: Der Bereich, der den wesentlichen Wettbewerbsvorteil liefert. Bei Pirate Ship ist dies beispielsweise die intelligente Versandabwicklung. Diese Domain sollte intern entwickelt werden.
2. Supporting Subdomains: Bereiche, die das Kerngeschäft unterstützen, aber keinen direkten Wettbewerbsvorteil bieten. Zum Beispiel die Auswertung von Versandstatistiken. Diese können durch bestehende Lösungen abgedeckt oder mit geringerem Aufwand intern entwickelt werden.
3. Generic Subdomains: Standardfunktionen, die jedes Unternehmen braucht, wie etwa Benutzer-Authentifizierung. Hier sollte man meist auf bestehende Lösungen zurückgreifen.

Ein weiteres wichtiges Konzept sind Bounded Contexts: Sie definieren klare Grenzen, innerhalb derer ein bestimmtes fachliches Modell gilt. Dies hilft nicht nur bei der technischen Strukturierung, diese Bounded Contexts eignen sich auch hervorragend zur Identifizierung von Teamgrenzen. In der Praxis führt dies zu klareren Verantwortlichkeiten und reduzierter Komplexität.

Ein leichtgewichiges Format zur Erkundung der Domänen und Identifizierung von Bounded Contexts ist die Workshop-Methode EventStorming. Im Rahmen von EventStorming-Sessions visualisieren Teams gemeinsam ihre Geschäftsprozesse, indem sie alle wichtigen Geschäftsereignisse (Domain Events) auf einem großen Board anordnen. Die Methode ist besonders effektiv, weil sie Entwicklungsteams und Fachexpert*innen auf Augenhöhe zusammenbringt und durch ihre visuelle Natur hilft, Muster und natürliche Grenzen in der Domain zu erkennen.

Team Topologies ist ein Konzept für die Organisation von Software-Entwicklungsteams, entwickelt von Matthew Skelton und Manuel Pais. Der Ansatz zielt darauf ab, schnelle und nachhaltige Wertschöpfung zu ermöglichen, indem Teams und ihre Interaktionen so gestaltet werden, dass sie sich auf ihre Kernaufgaben konzentrieren können. Dafür definiert das Framework vier Team-Typen und drei Interaktionsmodi, die zusammen eine adaptive Organisation ermöglichen, in der Teams unabhängig voneinander Wert liefern können.

Die vier grundlegenden Teamtypen sind:

1. Stream-aligned Teams: Diese Teams sind das Herzstück der Organisation. Sie sind auf einen kontinuierlichen Strom von Arbeit ausgerichtet und für bestimmte Geschäftsfunktionen end-to-end verantwortlich.
2. Platform Teams: Sie stellen interne Plattformen als Self-Service-Produkte bereit, die von Stream-aligned Teams genutzt werden können. Dies reduziert Abhängigkeiten und beschleunigt die Entwicklung.
3. Enabling Teams: Diese Teams fungieren als interne Beratungseinheit und helfen anderen Teams dabei, neue Fähigkeiten aufzubauen. Sie sind besonders wichtig in Phasen der Veränderung.
4. Complicated-Subsystem Teams: Sie kümmern sich um spezialisierte Komponenten, die besonderes Fachwissen erfordern.

Damit diese Teams effektiv zusammenarbeiten können, definiert Team Topologies drei zentrale Interaktionsmodi:

• Collaboration: Enge, zeitlich begrenzte Zusammenarbeit, ideal für Innovation und Exploration
• X-as-a-Service: Ein Team nutzt die Services eines anderen Teams
• Facilitation: Aktive Unterstützung beim Aufbau neuer Fähigkeiten

Mit diesem methodischen Fundament im Gepäck machten wir uns an die praktische Umsetzung bei Pirate Ship. Die Herausforderung lag nun darin, diese theoretischen Konzepte in einen Transformationsprozess zu übersetzen, der sowohl die Domänen-Komplexität als auch die menschlichen Aspekte der Reorganisation berücksichtigt. Wie wir dies in der Praxis angegangen sind, beschreibe ich im Folgenden.

Die Reorganisation bei Pirate Ship folgte einem organischen, dreiphasigen Prozess. Statt einer radikalen Umstrukturierung verfolgten wir einen evolutionären Ansatz: Die bestehenden Teams sollten als Keimzellen für neue Teams dienen. Diese "Zellteilung" ermöglichte es uns, das vorhandene Domänenwissen zu bewahren und den Übergabeaufwand zu minimieren.

Den Auftakt bildete eine Workshop-Reihe mit Susanne zu Wardley Mapping, Domain Driven Design und Team Topologies. Diese Workshops hatten drei zentrale Ziele:

1. Methodisches Fundament schaffen: Alle Teams erhielten Training in den drei Kernmethoden
2. Domänenverständnis vertiefen: Die Teams analysierten ihre Geschäftsbereiche, die Business Domain und die Softwarearchitektur
3. Zukunftsbilder entwickeln: Die Teams erarbeiteten gemeinsam Ideen für mögliche Bounded Contexts

Ein Kernbestandteil dieser Phase waren EventStorming-Sessions. Beim EventStorming visualisieren Teams gemeinsam ihre Geschäftsprozesse, indem sie alle Domain Events (wichtige Geschäftsereignisse) auf einer großen Wandfläche oder einem digitalen Board anordnen. Bei Pirate Ship arbeitete Susanne dafür intensiv mit Miro-Boards, da die Workshops überwiegend remote stattfanden.

Das Ergebnis dieser Phase war noch keine finale Struktur, sondern eher ein Kaleidoskop verschiedener Perspektiven: Jedes Team hatte mehrere Optionen für mögliche Bounded Contexts und deren Gruppierung identifiziert. Diese Vielfalt an Sichtweisen erwies sich später als wertvoll für die Gestaltung der endgültigen Struktur.

Zwei Teams starteten in die Zellteilungsphase. Die Ausgangslage war klar:

• Die Teams waren bereits über ihre optimale Größe hinaus gewachsen
• Die Arbeitslast hatte kritische Levels erreicht
• Die Produktstrategie sah weiteres Wachstum in diesen Bereichen vor

Für die Zellteilungs-Workshops entwickelten wir einen Blueprint, der sich als sehr effektive Grundlage für die 2-tägigen Workshops erwies. Ein Team-Workshop fand komplett remote statt, das andere Team traf sich vor Ort.

1. Hopes & Fears

• Offenes Ansprechen und Dokumentieren von Hoffnungen und Befürchtungen
• Schafft psychologische Sicherheit für den Veränderungsprozess

2. Domain-Aufteilung

• Vorstellung eines initialen Vorschlags durch den CTO - basierend aus den in Phase 1 entwickelten Bounded Context und den sich darin abzeichnenden Mustern
• Vorstellung der Produktstrategie für den Bereich. Dies half dabei, die Arbeitslast der identifizierten Bounded Contexts ausgewogen auf zwei Teams zu verteilen.
• Diskussion und Anpassung des Vorschlags im Konsentverfahren

3. Skill-Mapping

• Definition der benötigten Fähigkeiten für die neuen Teams
• Analyse der vorhandenen und noch benötigten Kompetenzen

4. Rahmenbedingungen klären

• Anzahl geplanter Neueinstellungen, Vorgaben zur Teamgröße
• Welche Erwartungen gibt es von Seiten des Unternehmens und der Geschäftsführung an die Teams?

5. Self-Selection

• Die Teammitglieder teilen sich nach dem Self-Selection-Prinzip auf. Wir haben die Entscheidung für das Wunsch-Team verdeckt auf Post-Its festgehalten.
• Check: Passt die Verteilung was die Skills angeht oder sind Anpassungen notwendig?
• Konsent-basierte Entscheidungsfindung

6. Nächste Schritte

• Definition konkreter nächster Schritte
• Erstellung einer groben Timeline

Ein interessanter Aspekt: Die beiden Teams wählten unterschiedliche Zeitpläne für ihre Zellteilung. Das erste Team startete bereits wenige Wochen nach dem Workshop in der neuen Konstellation, da neue Teammitglieder bereits gefunden waren. Das zweite Team entschied sich, die Teilung erst nach dem Onboarding der neu eingestellten Kolleg*innen durchzuführen.

Nach drei Monaten führten wir eine Cross-Team-Retrospektive durch. Dabei zeigte sich, dass wir viele der ursprünglichen Herausforderungen erfolgreich adressieren konnten:

Die wichtigsten Verbesserungen:

• Die Überlastung der Teams wurde durch kleinere, fokussiertere Einheiten reduziert
• Die zu großen Domains wurden erfolgreich aufgeteilt, was zu weniger Context Switches (und damit weniger kognitiver Überlastung) führte
• Das unklare Ownership wurde zumindest in Teilen durch klar definierte Zuständigkeiten ersetzt
• Die Teams konnten sich tiefer in ihre jeweiligen Fachbereiche einarbeiten

Neue Herausforderungen:

• Technische Grenzen: Der historisch gewachsene PHP-Monolith bildete die neue Domänenstruktur nicht optimal ab
• Notwendige Investitionen: Es zeigte sich erhöhter Bedarf an Refactoring-Arbeit
• Wissenstransfer: Die Übergabe von Domain-Wissen brauchte mehr Struktur als ursprünglich angenommen
• Shared Components: Bei teamübergreifend genutzten Komponenten entstanden neue Abstimmungsbedarfe

Der letzte Punkt führte direkt zu Phase 3: Fokussierung auf geteilte Komponenten.

Eine zentrale Erkenntnis aus den Zellteilungen war der Bedarf nach klaren Zuständigkeiten für teamübergreifend genutzte Komponenten. Während wir für domänenspezifische Komponenten klare Verantwortlichkeiten geschaffen hatten, gab es bei den Shared Components noch Unklarheiten.

Die Ausgangssituation

Mehrere Komponenten werden von verschiedenen Teams genutzt, zum Beispiel:

• Frontend-Komponenten
• Datenbank-Adapter
• Monitoring-Lösungen
• ...

Die Verantwortlichkeiten für diese Komponenten waren historisch gewachsen und oft an einzelne Personen gebunden. Dies führte zu mehreren Problemen:

• Unklare Zuständigkeiten
• Abhängigkeiten zwischen Teams
• Verzögerungen bei Änderungen
• Wissen liegt bei einzelnen Entwickler*innen

Der Weg zum Platform Team

Mit den Platform Teams haben wir ein Konzept aus Team Topologies aufgegriffen. Platform Teams haben eine besondere Rolle: Sie stellen anderen Teams Dienste als Self-Service-Plattformen zur Verfügung. Das reduziert Abhängigkeiten und beschleunigt die Entwicklung.
Für die Konzeption des Platform Teams haben Susanne und ich einen weiteren Workshop geplant.

Vorbereitung:

• Asynchrone Bestandsaufnahme aller geteilten Komponenten
• Sammlung aktueller Zuständigkeiten
• Offene Einladung an alle Interessierten (Dabei waren letztlich fast 20 Teilnehmende)

1. Hopes & Fears

• Erwartungen und Bedenken bezüglich der Etablierung eines Platform Teams

2. Status Quo Analysis

• Mapping aktueller Pain Points
• Inventur geteilter Komponenten
• Identifikation von Abhängigkeiten

3. User Needs der Stream-aligned Teams

• Was brauchen die Teams von einer Plattform?
• Welche Services sind kritisch?
• Welche Anforderungen gibt es an Self-Service-Komponenten?

4. Team Design

• Entwicklung verschiedener Team-Konstellationen
• Diskussion der Optionen
• Konsent-basierte Entscheidung

5. Transition Planning

• Wie kommen wir dorthin?
• Welche Fragen müssen als nächstes geklärt werden (z. B. Zahl der Neueinstellungen)?

Wo nötig gab es im Workshop kurze Recaps zu User Value, Value Chain & Wardley Mapping - die initialen Workshops der Teams dazu lagen zu diesem Zeitpunkt bereits einige Monate zurück.

Ergebnisse und nächste Schritte

Der Workshop führte zu konkreten Ergebnissen:

• Vision für die erste Iteration des Platform Teams
• Priorisierte Liste von Platform Services
• Grober Implementierungsplan

Besonders wertvoll war die gemeinsame Erarbeitung der Lösung: Alle Beteiligten konnten ihre Perspektiven einbringen und an der Gestaltung mitwirken. Dies schuf eine breite Akzeptanz für das neue Platform Team.

Die tatsächliche Etablierung des Platform Teams läuft zum Zeitpunkt der Veröffentlichung dieses Artikels noch. Ein wichtiger Aspekt: Dies ist kein abgeschlossener Prozess, sondern der Beginn einer kontinuierlichen Evolution. Das Platform Team wird sich weiterentwickeln, basierend auf den Bedürfnissen der Stream-aligned Teams und den Learnings aus der Praxis.

Nach mehreren Jahren Erfahrung mit Team-Reorganisationen - sowohl als Team-Mitglied, Tech Lead als auch als Beraterin - haben sich aus meiner Sicht bei Pirate Ship einige Erfolgsfaktoren besonders deutlich gezeigt:

Ein grundlegendes Verständnis der Domain ist der wichtigste Faktor für eine erfolgreiche Reorganisation. Das mag selbstverständlich klingen, wird in der Praxis aber häufig vernachlässigt. Oft werden Teams neu strukturiert, ohne die zugrundeliegende Komplexität der Domäne wirklich zu durchdringen. Bei komplexen Produkten und über Jahre gewachsenen Architekturen rächt sich dieser Ansatz: Teams bleiben durch Abhängigkeiten aneinander gebunden und können nicht unabhängig voneinander Wert liefern.

Ein entscheidender Erfolgsfaktor bei Pirate Ship war die durchgehende Unterstützung durch das Leadership-Team. Die deutschen Gründer und Geschäftsführer haben den Prozess nicht nur initiiert, sondern aktiv mitgetragen:

• Sie stellten die notwendigen Ressourcen und Zeit für Workshops und Reorganisation zur Verfügung
• Sie gaben klare Rahmenbedingungen vor, ließen aber innerhalb dieser Grenzen den Teams die Freiheit zur Selbstorganisation
• Sie waren bei kritischen Workshops präsent und ansprechbar, ohne den partizipativen Prozess zu dominieren

Diese Balance zwischen strategischer Orientierung und Vertrauen zeigte sich in drei zentralen Leitplanken:

• Team Topologies als Orientierungsrahmen: Die Entscheidung, die Organisation nach den Prinzipien von Team Topologies mit Stream-aligned Teams und Platform Teams auszurichten
• Maximale Teamgröße: Teams sollten nicht größer als sieben Personen werden, um effektive Zusammenarbeit zu ermöglichen
• Recruiting: Die Teambildung erfolgte durch Self-Selection, während die Geschäftsführung den Rahmen für Neueinstellungen setzte

Ein wichtiges Learning für künftige Reorganisationen: Der zeitliche Rahmen für die Umsetzung sollte von Anfang an klarer definiert werden. Bei Pirate Ship konnten die Teams selbst über den Zeitpunkt ihrer Zellteilung entscheiden, was einerseits Flexibilität ermöglichte, andererseits aber auch zu Unsicherheiten im Gesamtprozess führte.

Die Investition in einen partizipativen Prozess braucht Zeit - Zeit, die sich aber mehrfach auszahlt:

• Bessere Lösungen: Die Einbeziehung unterschiedlicher Perspektiven ermöglicht es, die komplexe Domäne in ihrer ganzen Tiefe zu erfassen. Teams bringen ihr spezifisches Wissen ein - von technischen Details bis zu Geschäftsprozessen - was zu fundierteren Strukturen führt, die der tatsächlichen Komplexität gerecht werden
• Höhere Akzeptanz: Wenn Teams die neue Struktur mitgestalten, tragen sie die Veränderung aktiv mit
• Nachhaltiger Wandel: Das gemeinsam erarbeitete Verständnis bildet eine solide Basis für künftige Anpassungen

Damit Partizipation nicht zur Lähmung führt, haben sich bei Pirate Ship mehrere Praktiken bewährt:

• Konsent statt Konsens: Während Konsens bedeutet, dass alle aktiv zustimmen müssen, reicht beim Konsent-Prinzip aus, dass niemand einen schwerwiegenden Einwand hat. Dies beschleunigt Entscheidungen, ohne die Beteiligung zu vernachlässigen. Ein schwerwiegender Einwand bedeutet dabei, dass die Person begründen kann, warum die Entscheidung dem Team oder der Organisation schaden würde.
• Klare Rahmenbedingungen: Frühzeitige Klärung von Grenzen und Möglichkeiten mit dem Leadership
• Vorbereitete Entscheidungsvorlagen: Sie dienen als Diskussionsgrundlage und beschleunigen den Prozess.

Die kontinuierliche Arbeit mit visuellen Modellen - sei es in Miro-Boards oder anderen Formaten - hat sich als unverzichtbar erwiesen:

• Sie macht komplexe Zusammenhänge greifbar.
• Sie schafft eine gemeinsame Sprache.
• Sie dokumentiert Entscheidungen und deren Grundlagen.
• Sie dient als Basis für weitere Diskussionen und Anpassungen.

Das Konzept der Zellteilung hat sich in unserem Fall als evolutionärer Ansatz der Team-Reorganisation und Teilung bewährt. Statt eines radikalen Umbruchs ermöglicht dieser organische Prozess, dass bestehendes Domain-Wissen innerhalb der Teams erhalten bleibt und weitergegeben werden kann. Die schrittweise Teilung reduziert zudem den Aufwand für Wissenstransfer und Übergaben deutlich, da nicht das gesamte Know-how auf einmal neu verteilt werden muss. Dieser evolutionäre Weg erlaubt es Organisationen - sofern dies zur Geschwindigkeit des Wachstums passt - , in einem gesunden Tempo zu wachsen. Die Teams können sich evolutionär entwickeln und das Unternehmen kann seine Kapazitäten behutsam erweitern, während es gleichzeitig seine fachliche Expertise bewahrt.

Eine zentrale Erkenntnis aus dem Prozess bei Pirate Ship: Mit jedem Schritt wird Veränderung leichter. Die erste Team-Teilung war besonders herausfordernd – vor allem für die "erste Crew". Für ein Unternehmen in der Pionierphase bedeutet die Erkenntnis, dass nicht mehr alle in einem Team arbeiten können, einen wichtigen Entwicklungsschritt. Es ist der Abschied von der Startup-Phase, in der alle alles machen und Strukturen eher informell sind.

Doch mit jeder weiteren Teilung wächst das Vertrauen in die eigene Veränderungsfähigkeit. Die Organisation lernt aus ihren Erfahrungen, entwickelt Routinen und gewinnt Sicherheit. Was beim ersten Mal noch zäh und schwer erscheint, wird zunehmend zu einem natürlichen Prozess der Weiterentwicklung. Inzwischen hat ein Team sogar von sich aus einen weiteren Zellteilungsprozess angestoßen.

Die Erfahrungen bei Pirate Ship zeigen: Reorganisation ist kein einmaliges Projekt mit definiertem Ende, sondern ein kontinuierlicher Prozess. Teams und Organisationen entwickeln sich permanent weiter - sei es durch neue Produktanforderungen, technologische Veränderungen oder personelles Wachstum.

Architecture for Flow hat uns dabei einen wertvollen Rahmen geboten, der sich flexibel an verschiedene Situationen anpassen lässt. Besonders die Kombination aus methodischer Fundierung durch Wardley Mapping, DDD und Team Topologies einerseits und echter Partizipation andererseits hat sich bewährt. Sie ermöglicht es, auch komplexe Veränderungen Schritt für Schritt anzugehen.

Ein besonders wichtiger Aspekt bei Pirate Ship: Die Reorganisation ist auf der Ebene der Softwarearchitektur noch nicht abgeschlossen. Während die Teams bereits nach den neuen Domain-Grenzen organisiert sind, spiegelt die gewachsene Architektur des Monolithen diese Struktur noch nicht komplett wider. Teams und Architektur sind aktuell nicht optimal aufeinander abgestimmt. Der Prozess des Refactorings - also der schrittweisen Anpassung der Softwarearchitektur an die neue Teamstruktur - erfordert Zeit und Geduld. Auch hier zeigt sich die Bedeutung des Leadership-Supports: Die Bereitschaft, in diese technische Transformation zu investieren und den Teams die notwendige Zeit für diesen Umbau zu geben, ist essenziell für den langfristigen Erfolg der Reorganisation.

Bei Pirate Ship wird auch deutlich, was passiert, wenn die Teams selbst Initiative ergreifen: Sie schlagen Anpassungen vor und gestalten ihre Arbeitsbereiche aktiv mit. Das bestätigt Peter Senges Einsicht: "People don't resist change, they resist being changed." Wenn Teams die Möglichkeit haben, Veränderung mitzugestalten, eröffnet das den Raum für nachhaltige Lösungen und organisationales Lernen.

Artikel & Bücher

• Brandolini, Alberto: Introducing EventStorming, 2021.
• Evans, Eric: Domain-Driven Design: Tackling Complexity in the Heart of Software, 2023.
• Kaiser, Susanne: Adaptive, Socio-Technical Systems with Architecture for Flow: Wardley Maps, DDD, and Team Topologies, https://www.infoq.com/articles/adaptive-socio-technical-systems-flow/, 2023.
• Pais, Manuel and Skelton, Matthew: Team Topologies. Organizing Business and Technology Teams for Fast Flow, 2019.
• Vernon, Vaughn, Domain-Driven Design Distilled, 2016.

Webseiten & Online-Ressourcen

• Learn Wardley Mapping, https://learnwardleymapping.com
• EventStorming, https://www.eventstorming.com/
• Domain-Driven Design Starter Modelling Process, https://github.com/ddd-crew/ddd-starter-modelling-process