Innovative agile Teamkonzepte E-Book

Stefan Roock

• Herausgeber: dpunkt.verlag
• Kategorie: Fachliteratur
• Sprache: Deutsch

Seitenzahl: 157

Veröffentlichungsjahr: 2025

Beschreibung

Fluide Teamstrukturen – Abhängigkeiten neu gedacht - Die Entwicklung optimieren, indem Teams gut und immer wieder neu geschnitten sowie übergreifende Funktionalitäten und Abhängigkeiten immer besser organisiert werden - Beschreibt innovative Konzepte wie Floating Teams, Mission Teams und den Agile Descaling Cycle sowie deren Zusammenspiel - Bietet wertvolles Know-how für die Organisationsentwicklung   Agile Entwicklung hat ihren Ursprung in dem Gedanken »ein Team, ein Produkt«. Dass mehrere Teams gemeinsam ein Produkt entwickeln, war in den Anfangsjahren unüblich. Inzwischen haben sich die Verhältnisse umgekehrt, es ist eher die Regel als die Ausnahme, dass mehrere Teams gemeinsam ein Produkt entwickeln. Es gibt verschiedene Skalierungsframeworks, die definieren, wie die Entwicklung mit mehreren Teams organisiert werden kann. Ihr Einsatz birgt jedoch immer die Gefahr des Dogmatismus und der Schwerfälligkeit. Mitunter fühlt sich skalierte »Agilität« eher nach der »Behörde für Agilität« an. Stefan Roock zeigt anhand einer fiktiven Geschichte, wie die Entwicklung mit mehreren Teams so optimiert werden kann, dass sie den Namen »agil« wirklich verdient. Die Geschichte beschreibt, wie Teams gut und immer wieder neu geschnitten sowie übergreifende Funktionalitäten und Abhängigkeiten immer besser organisiert werden. Außerdem werden in der Geschichte innovative Konzepte, Denkansätze und Erkenntnisse vorgestellt, wie Teams jenseits des klassischen Dogmas »klein, langfristig stabil« aufgebaut werden können. Den Abschluss bildet eine ausführliche Zusammenfassung dieser Konzepte und Denkansätze, die auch unabhängig von der Geschichte gelesen werden kann.  Die Inhalte des Buches sind auch dann anwendbar, wenn man sich an Kanban oder Extreme Programming orientiert oder einen komplett eigenen Ansatz verfolgt. Wichtig ist lediglich, dass iterativ-inkrementell gearbeitet wird.  

Leseprobe

»Damit das Mögliche entsteht, muß immer wieder das Unmögliche versucht werden.«

H. Hesse

Stefan Roock (it-agile) will eine bessere Arbeitswelt schaffen, in der Kunden von den Produkten und Services begeistert sind, Mitarbeitende ihre Arbeitsbedingungen lieben und Unternehmen erfolgreich sind. Er unterstützt Menschen und Unternehmen dabei, ihre Potenziale für dieses Ideal zu entfalten.

Seit 1999 ist Stefan maßgeblich an der Verbreitung und Weiterentwicklung neuer Arbeits- und Organisationsansätze (agil, Scrum, Kanban etc.) im deutschsprachigen Raum beteiligt. Zunächst als Entwickler in agilen Teams, später als Scrum Master/Agile Coach und Product Owner. Seitdem hat er sein Verständnis dessen, was für begeisternde Produkte und Arbeitsbedingungen notwendig ist, kontinuierlich weiterentwickelt. Hervorragende Produkte entstehen nicht dadurch, dass Teams Anforderungen »agil« umsetzen. Stattdessen müssen Teams gemeinsam und im direkten Kundenkontakt Produkte und Services gestalten.

Stefan ist regelmäßiger Sprecher auf Konferenzen, bei User Groups und in Unternehmen. Außerdem hat er zahlreiche Bücher und Artikel veröffentlicht.

Copyright und Urheberrechte:Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Stefan Roock

Innovative agile Teamkonzepte

Mehr Flow und Geschwindigkeit in der Produktentwicklung

Stefan Roock

[email protected]

Lektorat: Christa Preisendanz, Sandra Bollenbacher

Lektoratsassistenz: Julia Griebel

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: Frank Heidt

Herstellung: Stefanie Weidner, Frank Heidt

Umschlaggestaltung: Eva Hepper, Silke Braun

Bibliografische Information der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print

978-3-98889-037-5

PDF

978-3-98890-220-7

ePub

978-3-98890-221-4

1. Auflage 2025

Copyright © 2025 dpunkt.verlag GmbH

Wieblinger Weg 17 · 69123 Heidelberg

E-Mail: [email protected]

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Weiter darf der Inhalt nicht zur Entwicklung, zum Training oder zur Anreicherung von KI-Systemen, insbesondere generativen KI-Systemen, verwendet werden. Die Nutzung für Text- und Data Mining ist untersagt.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

Den vielen Menschen, die in den letzten 25 Jahren zu den Erfahrungen beigetragen haben, auf denen dieses Buch beruht, sei herzlich gedankt.

Vorwort

Ein Team, ein Softwareprodukt – das ist der Kontext, in dem agile Softwareentwicklung entstanden ist. So weit die Folklore und so weit auch die Beschreibungen von z. B. Scrum oder Extreme Programming (XP).

Und so habe ich es auch lange dargestellt: »Lasst uns erst mal verstehen, wie das Ganze mit einem Team funktioniert. Danach sehen wir uns an, wie man es auf mehrere Teams skalieren kann.«

Mit der Zeit wurde es aber immer unüblicher, dass ein Team allein ein Produkt entwickelte. Die Frage, ob man immer mehr Leute brauchte, weil es so kompliziert wurde, oder ob es so kompliziert wurde, weil man so viele Leute hatte, wird sich vermutlich nie beantworten lassen.

Festzuhalten ist, dass die Menschen in den Unternehmen immer weniger mit der Unterscheidung »nicht skaliert« und »skaliert« etwas anfangen konnten. Sie hatten nicht erlebt, dass etwas Sinnvolles von nur einem Team entwickelt werden konnte.

Da passt es gut ins Bild, dass vor allem in Konzernen das Scaled Agile Framework® (SAFe®) gerne verwendet wird. Schließlich liefert es Antworten auf alle möglichen Fragen rund um die Organisation mehrerer Teams. Doch sind diese Antworten immer nützlich?

Ich nehme jedenfalls wahr, dass sich viele »agile« Implementierungen eher wie die »Behörde für Agilität« (Danke an Henning Wolf für dieses geflügelte Wort) anfühlen. Ist das eine unausweichliche Konsequenz, die quasi der Trägheit der Masse geschuldet ist?

Dazu lohnt sich ein Blick zurück in die Anfänge der Agilität. So beschränkt auf das Ein-Team-Szenario, wie es erscheint, war Agilität selbst in den Anfängen nicht. Feature Driven Development und Crystal haben bereits sehr früh die Frage der Zusammenarbeit vieler Menschen adressiert. Und auch viele der frühen Scrum- und XP-Entwicklungen fanden mit mehreren Teams statt. Die dort verwendeten Koordinationsansätze sind nur nicht in die Beschreibungen von Scrum und XP eingeflossen. Vermutlich erschien das Feld der Möglichkeiten zu groß, als dass man bestimmte Techniken vorschreiben wollte. Aus demselben Grund finden sich in Scrum auch keine Angaben über zu verwendende Entwicklungspraktiken wie z. B. testgetriebene Entwicklung. Stattdessen sollte jedes Team selbst herausfinden, was am besten für den jeweiligen Kontext geeignet ist.

Dieser Ansatz hat nach meiner Erfahrung gut funktioniert. Wir haben bereits mit einer zweistelligen Anzahl von Teams an einem Produkt gearbeitet, bevor es Skalierungsframeworks wie LeSS oder SAFe® gab. Mit Inspect & Adapt haben wir verschiedene Techniken zur Koordination ausprobiert und für den Kontext passende Ansätze gefunden und kontinuierlich weiterentwickelt. Vor diesem Hintergrund möchte ich einen Beitrag dazu leisten, dass wir wieder zu dieser Haltung zurückfinden, statt Blaupausen zu implementieren und in Verwaltungstätigkeiten unterzugehen. In den letzten Jahren gab es eine Reihe spannender Erkenntnisse und Ansätze, die dabei – insbesondere im Multiteam-Szenario – helfen können.

Ich hatte angefangen, diese Ansätze rein sachlich zu beschreiben und hoffte, daraus ein 15-seitiges PDF machen zu können. Damit bin ich krachend gescheitert. Zum einen reichen 15 Seiten vorne und hinten nicht aus. Zum anderen sind einige der Ideen noch nicht so häufig verwendet worden, dass sie sich genau beschreiben ließen. Außerdem habe ich bemerkt, dass eine genaue Beschreibung der Techniken dazu einladen könnte, diese als Blaupause zu implementieren. Ich will aber keine neuen Frameworks in die Welt setzen, sondern das Nachdenken über die Zusammenarbeit von Teams verändern.

Daher habe ich meine Strategie geändert und entschieden, die Inhalte als Geschichte zu verpacken. Sie ist zu lang für eine Kurzgeschichte und zu kurz für einen Roman. Die Geschichte ist in vier Episoden unterteilt. In der ersten Episode lernen wir den Kontext und wichtige Akteure kennen. Die zweite Episode fokussiert auf das Abhängigkeitsmanagement und wie dieses effizienter gestaltet werden kann. Die dritte Episode thematisiert, wie man Abhängigkeiten reduzieren kann, indem man über gänzlich andere Teamstrukturen nachdenkt. Die vierte Episode ist der Epilog. Hier findet die Geschichte ihren vorläufigen Abschluss.

In der Geschichte kommen Begriffe aus dem Scrum-Framework vor, obwohl die Geschichte und die dargestellten Konzepte nicht Scrum-spezifisch sind. Einige der Konzepte passen tatsächlich gar nicht ins Scrum-Framework. Ich habe trotzdem Begriffe wie Product Owner, Product Backlog, Sprint und Scrum of Scrums verwendet, weil sie so bekannt und üblich sind. Allgemeinere Begriffe zu verwenden, fühlte sich in der Geschichte unnatürlich und umständlich an.

In der Geschichte kommen einige wenige Fachtermini vor, die dort nicht erklärt werden (z.B. Domain-Driven Design, Team Topologies, Branches) – es erschien mir unpassend, dass die Protagonisten sich Konzepte erklären, die in ihrem Kontext klar sind. Erklärungen finden sich in Kapitel 5 sowie im Glossar.

Die Inhalte der Geschichte funktionieren auch dann, wenn man sich an Kanban oder Extreme Programming orientiert oder einen komplett eigenen Ansatz verwendet. Wichtig ist lediglich, dass iterativ-inkrementell gearbeitet wird.

Im Anschluss an die Geschichte finden sich in Kapitel 5 Anmerkungen zu den einzelnen Episoden. Ich habe dort versucht, darzustellen, woher die ganzen Ideen und Impulse stammen, die sich in der Geschichte wiederfinden. Ich wünschte, es wäre anders, aber das meiste habe ich mir nicht selbst ausgedacht.

Den Abschluss bildet eine Zusammenfassung der Konzepte und Denkansätze der Geschichte. Diese Zusammenfassung kann unabhängig von der Geschichte gelesen werden. Dadurch ergeben sich notwendigerweise Wiederholungen von Konzepten, die in der Geschichte vorkommen.

Danksagung

Ich danke Dr. Adam Melski, Jens Himmelreich und meinem Bruder Arne Roock für das Feedback zu ersten Fassungen der Geschichte. Christa Preisendanz vom dpunkt.verlag danke ich für ihr Feedback und das wie immer großartige Lektorat des Buches.

Inhaltsverzeichnis

1Episode 1: Prolog

1.1Wir sind zu langsam

1.2Dabei haben wir doch alles richtig gemacht

2Episode 2: Abhängigkeiten managen

2.1Abhängigkeitsgraphen

2.2Verlässlich unverlässliche Planung

2.3Die Sache mit den Bussen

2.4Verhalten sich Teams wie Busse?

2.5Übergreifende Priorisierung

2.6Weniger Stop and Go

2.7Es reicht noch nicht

2.8Blockaden lösen

2.9Iterationen verkürzen

2.10Work in Progress

2.11Koordinationsprinzipien

3Episode 3: Abhängigkeiten beseitigen

3.1Alle gemeinsam kann verdammt anspruchsvoll sein

3.2Mobile Teams

3.3T-Shaped Skill Sets für Teams

3.4Statische Teams vs. mobile Teams

3.5Voraussetzungen für mobile Teams

3.6USA, wir kommen: Nur ein Katzensprung entfernt

3.7Aber wo ist die Wertschöpfung, wo der Flow?

3.8Abhängigkeiten in die ganze Welt

3.9Mission Teams

3.10(K)ein Projektteam?

3.11Mission Teams besetzen

3.12Strukturen und Ziele – wer ist Schwanz, wer Hund?

3.13Hochperformante Teams brauchen motivierende Ziele

3.14Ziele mit mehreren Teams

3.15Wachsendes Mission Team

3.16Floating Teams

3.17Floating Teams zum Fliegen kriegen

3.18Voraussetzungen für Floating Teams

3.19Teamstruktur-Prinzipien

3.20Agile Descaling Cycle

4Episode 4: Epilog

Anmerkungen zu den Episoden

5Wenn man auf den Schultern von Giganten steht …

5.1Anmerkungen zu Episode 1

5.2Anmerkungen zu Episode 2

5.3Anmerkungen zu Episode 3

Konzepte und Zusammenfassung

6Die Konzepte der Geschichte

6.1Der Agile Descaling Cycle

6.2Kohäsion maximieren: Produktstruktur

6.2.1Arbeiten mit der Produktstruktur

6.2.2Plattformen

6.3Kohäsion maximieren: Teamschnitt innerhalb eines Produkts

6.4Koordinieren: Umgang mit Abhängigkeiten

6.4.1Probleme der Etappenplanung

6.4.2Etappen verkürzen

6.4.3Etappen abschaffen

6.4.4Technische Fähigkeiten der Teams

6.5Kohäsion maximieren: Unterschiedliche Teamansätze

6.5.1Statische Teams

6.5.2Mobile Teams

6.5.3Mission Teams

6.5.4Floating Teams

7Zusammenfassung und Abschluss

Anhang

Glossar

Literatur

Index

1Episode 1: Prolog

1.1Wir sind zu langsam

»Wir müssen schneller werden!«, definiert Catherine als Ziel für die Produktentwicklung. Sie ist die Gründerin und Geschäftsführerin von CatDate, einer Dating-Plattform für Katzen. Letztlich ist CatDate einfach nur eine Webanwendung, mit der Katzenzüchter nach Katern für ihre Rassekatzen suchen können. Catherine findet die Darstellung als Dating-Plattform witzig.

Florence kann mit dieser Art von Humor wenig anfangen. Sie muss aber zugestehen, dass es bei den Kunden gut ankommt. Florence ist erst seit Kurzem bei CatDate. Sie wurde eingestellt, um zusammen mit Rob, dem Leiter der Produktentwicklung, die Entwicklung wieder in Schwung zu bringen.

»Ich fühle mich hier manchmal wie in der Behörde für Agilität!«, fährt Catherine fort. Florence fällt auf, dass Catherine ganz schön viele Ausrufezeichen beim Sprechen verwendet. Rob sieht betreten zu Boden. Er kann Catherines Frust gut nachvollziehen. Schnell sind sie schon lange nicht mehr. Gleichzeitig ist er sich keines Fehlers bewusst. Sie haben alles so organisiert, wie es in dem Business üblich ist. Ist es einfach die unvermeidliche Trägheit der Masse, die mit dem Wachstum des Unternehmens einhergeht? Immerhin ist er seit der Einstellung von Florence mit dem Problem nicht mehr allein.

Florence ist sich sicher, dass es gute Gründe für Catherines Unzufriedenheit gibt. Sie weiß aus ihrer Vergangenheit aber auch, dass es schwierig werden könnte, unter dem Schlagwort »schneller werden« eine echte Veränderung zu bewirken. Die Problembeschreibung ist noch zu allgemein und kann zu unterschiedlich interpretiert werden. Daher steigt sie in das bisher sehr einseitig verlaufende Gespräch ein: »Ich kann deinen Frust gut nachvollziehen, Catherine. Um schnell voranzukommen, hilft es meiner Erfahrung nach, wenn wir die Problemsituation sehr klar formulieren. Du sagst, wir müssen schneller werden.«

»Das sollte doch wohl klar sein!«, poltert Catherine.

»Dir ist klar, was du meinst, aber möglicherweise nicht allen anderen. Was wird denn besser, wenn wir schneller werden?«, fragt Florence.

»Unser Geschäft hier in Deutschland läuft so lala. Wir können davon die Gehälter bezahlen, aber große Sprünge sind nicht drin. Natürlich hätte ich für meine Idee und das ganze Herzblut, das ich in die Firma gesteckt habe, irgendwann gern Gewinne gesehen. Und gleichzeitig würden relevante Gewinne auch Stabilität mit sich bringen. Wir würden nicht jedes Mal in Hektik verfallen, nur weil mal ein Quartal etwas schlechter läuft. Wir haben schon Ideen, wie wir das Business entwickeln wollen, um das zu erreichen. So möchte ich unseren Service auch im Ausland anbieten, zunächst in den USA. Denn dort gibt es sehr viele Katzenbesitzer und eine sehr rege Katzenzucht-Community.« Catherine merkt, wie ihre Begeisterung für die Katzenzucht und ihre Geschäftsidee sie von der eigentlichen Frage ablenkt, und konzentriert sich wieder auf ihr Anliegen. »Und damit wir diese Pläne umsetzen können, brauchen wir mehr Wumms. In unserem aktuellen Zustand schaffen wir es gerade so eben, dass wir uns um Deutschland kümmern. Da können wir nicht noch neue Märkte erschließen. Gleichzeitig reichen die Gewinne nicht aus, um nennenswert zusätzliche Leute einzustellen. Wir müssen also mit der existierenden Truppe umsetzungsfähiger werden.«

»Okay, verstanden«, folgert Florence. »Mehr Wumms bedeutet also, dass wir, um dieses Ziel zu erreichen, die erforderlichen Funktionalitäten viel schneller umsetzen und liefern müssen, als wir das heute können. Jetzt ist nicht nur klar, was erreicht werden soll, sondern auch warum. Und dieses Warum hat nicht nur damit zu tun, dass die Besitzerin reich wird.«

»Was als Seiteneffekt aber durchaus auch schön wäre«, sagt Catherine schmunzelnd.

Florence schreibt auf einem Flipchart auf, was sie verstanden hat:

Die (geringen) Gewinne aus dem Deutschlandgeschäft reichen nicht aus, um langfristig finanzielle Stabilität und Sicherheit herzustellen.

Wir glauben, dass zusätzliche internationale Märkte wie die USA diese finanzielle Sicherheit schaffen können.

Wir können mit der aktuellen Geschwindigkeit keine internationalen Märkte erschließen und haben nicht die finanziellen Mittel, um zusätzliche Leute einzustellen.

Daher müssen wir mit den vorhandenen Mitarbeitenden schneller und mehr liefern.

»Habe ich das so richtig verstanden?«, fragt sie Catherine. Diese bejaht die Frage und auch Rob signalisiert, dass er verstanden hat. »Dann wäre das unser Auftrag«, beschließt Florence.

Rob murmelt so leise, dass Florence und Catherine ihn nicht hören können: »Auch wenn wir keine Ahnung haben, wie wir das Kunststück hinkriegen sollen.«

1.2Dabei haben wir doch alles richtig gemacht

Am nächsten Tag reflektiert Florence die Situation für sich. Sie hatte sich bereits einen Überblick über die Situation in der Entwicklung verschafft, als sie zu CatDate kam. Es gibt sechs Entwicklungsteams bei CatDate:

Customer (CU) stellt die Funktionalität rund um die Kunden zur Verfügung. Anbieter von Paarungspartnern sowie Suchende können sich Accounts anlegen und ihre Kundendaten verwalten. Das Team verantwortet außerdem die ganze Funktionalität rund um das Login.

Offer Management (OM) kümmert sich darum, dass Besitzer von Rassekatzen ihre Kater als Paarungspartner anbieten können.

Cat (CA) sorgt für die Speicherung und Anzeige der Katzendaten.

Search (SE) entwickelt die Suche inklusive der Benutzungsoberfläche.

Search Result (SR) sorgt dafür, dass die Suchergebnisse dargestellt werden.

Monetization (MO) ist ein frisch aufgebautes Team, das sich um die Monetarisierung kümmern soll. Bisher haben die Katzenzüchter kostenpflichtige Abos abgeschlossen. Catherine möchte, dass weitere Umsatzquellen erschlossen werden, z. B. über Werbung.

Alle Teams bestehen aus fünf bis acht Mitgliedern und haben jeweils einen Product Owner.

Florence visualisiert die Situation. Vor der Coronapandemie hätte sie das auf einem Flipchart und mit Haftnotizen gemacht. Jetzt wählt sie ein elektronisches Whiteboard – schließlich arbeiten die Menschen bei CatDate nicht mehr regelmäßig im Büro.

Abb. 1–1Teamschnitt nach Customer Journey

Es ist Sache der Teams, eine für sie passende Arbeitsweise zu finden. Wenn Teams entscheiden, dass sie vollständig im Büro arbeiten wollen, ist das genauso in Ordnung, wie wenn sie beschließen, komplett remote zu arbeiten. In den meisten Teams hat sie Hybrid-Situationen gesehen. Sie hat sich direkt nach ihrer Einstellung gefragt, ob die vermeintliche Langsamkeit der Teams durch das Remote-Arbeiten verursacht sein könnte. Ihre Nachforschungen haben aber schnell ergeben, dass die Geschwindigkeit der Teams heute ungefähr so hoch ist wie vor der Coronapandemie. Das Problem der Trägheit war nur in den Hintergrund getreten, weil man unter den Corona-Bedingungen überhaupt irgendwie das Unternehmen am Laufen halten musste.

Die Teamstruktur, die Florence visualisiert hat, folgt der Idee, die Teams nach der Customer Journey zu schneiden. Zuerst müssen die Kunden Accounts anlegen, dann werden sie Angebote erstellen, in deren Verlauf Katzen angelegt werden. Die Angebote werden dann durchsucht und die Suchergebnisse angezeigt. Die Monetarisierung liegt ein Stück quer dazu, da die Monetarisierung durch das Abomodell etwas mit den Kunden zu tun hat und durch die angedachte Werbung auch mit den Suchergebnissen. Nach Florence’ Erfahrung sollte das aber kein Problem darstellen. Wichtig ist, dass jedes Team Funktionalität von Ende zu Ende verantwortet, also von der Benutzungsoberfläche bis hin zur Datenhaltung. Außerdem ist es nützlich, wenn Informationen zwischen den Produktkomponenten nur in eine Richtung fließen. Das reduziert Abhängigkeiten und ist durch die Orientierung an der Customer Journey gegeben.

Neben der Orientierung an der Customer Journey gibt es alternative Muster zum Teamschnitt, z. B. Domain-Driven Design oder Team Topologies. Im vorliegenden Fall würden diese Ansätze aber zu sehr ähnlichen Teams führen, sodass Florence diese Themen zunächst nicht vertiefen will.

Die Teams sind selbstorganisiert und gut ausgestattet mit qualifizierten Teammitgliedern, Hardware und Softwarelizenzen. Im Großen und Ganzen ist hier alles nach dem aktuellen Stand der Kunst organisiert. Und trotzdem geht es Catherine nicht schnell genug. Nach Florence’ erstem Eindruck sind die Teams hier auch nicht langsamer als in den Unternehmen, in denen sie in den letzten Jahren gearbeitet hat.

Catherines Frust bringt Florence aber zum Nachdenken. Ist das, was sie vorgefunden hat, tatsächlich gut genug oder ist sie selbst nur über die Jahre abgestumpft? Hat sie sich zu sehr mit der »Realität« arrangiert und ihre eigenen Ambitionen über Bord geworfen?

Ihr fällt ein, dass in ihrer Anfangszeit oft eine andere Energie innerhalb und rund um die Teams herrschte. Die Teams schienen ihr früher auch schneller zu sein. Da konnte ein Team allein noch viel mehr bewirken. Inzwischen hat sich die Entwicklungswelt deutlich verändert. Heute sind die Softwaresysteme viel größer und komplexer und können nicht mehr von einem Team allein entwickelt werden. Die damit einhergehenden Abhängigkeiten führen natürlich zu einer größeren Trägheit. Florence denkt an die Trägheit der Masse und bekommt direkt schlechte Laune. Sie fragt sich immer wieder, ob man so viele Leute braucht, weil die Entwicklung so kompliziert ist, oder ob die Entwicklung erst durch die vielen Leute so kompliziert geworden ist. Sie weiß, dass sie diese Frage schon mal irgendwo gelesen hat, kann sich aber nicht mehr an den Autor erinnern. Das sollte sie mal recherchieren. Ein weiterer Punkt auf ihrer »Frau müsste mal«-Liste.

Florence, fokussiere dich, ermahnt sie sich. Du hast gerade über die guten alten Zeiten nachgedacht, als Teams noch hochperformant waren und einen echten Unterschied machen konnten. Da steckt noch irgendeine Erkenntnis drin, die sie aber noch nicht greifen kann.

2Episode 2: Abhängigkeiten managen

2.1Abhängigkeitsgraphen