Mit flexiblen Teams Agilität skalieren

Spätestens seit Bruce Tuckman und seinem Modell der Team-Phasen gilt es als erstrebenswert Teams möglichst lange stabil, das heißt unverändert, zu halten. In der Softwareentwicklung sind solche Teams typischerweise verantwortlich für bestimmte technische Komponenten. Ich werde sie hier „Komponenten-Teams“ nennen.

Vorteile stabiler Teams

Durch die Stabilität werden solche Teams sehr effizient in drei Bereichen:

• Sozial: Die einzelnen Teammitglieder können sich gut aufeinander einstellen und eine gemeinsame Arbeitsweise entwickeln.
• Fachlich: Aufgrund der Spezialisierung wird das Team ein sehr tiefes Wissen in seiner fachlichen Domäne aufbauen.
• Technisch: Aus der festen Zuordnung zu Komponenten ergibt sich ein über die Zeit anwachsendes, tiefes Spezialwissen über die verwendeten Technologien.

Aus dieser Sicht haben stabile Komponenten-Teams wichtige Vorteile, wenn man genau ein Team betrachtet.

Skalieren stabile Teams?

Betrachten wir nun aber eine größere Organisation, in der mehrere stabile Teams einzelne Komponenten eines größeren Produkts verantworten. Um ein solches Produkt um neue Features zu erweitern, müssen mehrere Teams an ihren jeweiligen Komponenten Änderungen vornehmen. 

Hier können verschiedene Probleme auftreten:

• Cost of Delay: Wenn mehrere Teams zu einem übergreifenden Feature etwas beitragen müssen, so kann der Nutzen des Features in der Regel erst dann realisiert werden, wenn das letzte Team geliefert hat. Diese Verzögerung verursacht daher Verzugskosten, die sogenannten Cost of Delay.
• Lokale Optimierungen: Wenn ein Team “seine” Komponenten verantwortet, befördert das auch immer ein gewisses Silodenken. Teams werden dazu tendieren eher ihre eigenen Komponenten zu optimieren anstatt größere übergreifende, aber potenziell wirkungsvollere Innovationen umzusetzen. Dies ist einerseits dem lokalen Spezialwissen geschuldet, andererseits aber auch den potenziellen sozialen Reibungen einer Zusammenarbeit mit anderen Teams. 
• Ungleiche Auslastung: Dadurch, dass Komponenten-Teams bestimmte Komponenten verantworten, hängt ihre Auslastung davon ab, wie viele Änderungen gerade an den jeweiligen Komponenten erforderlich sind. Dies kann zu ungleichen Auslastungen führen, bei denen sich ein Team fast langweilt, während von einem anderen die erfolgreiche Umsetzung mehrerer Features abhängt. Dies wiederum führt leicht zu Überlastung und sozialen Spannungen zwischen Teams. Weiterhin erhöht eine ungleiche Auslastung die Cost of Delay bei überlasteten Teams und führt zu mehr lokalen Optimierungen bei Teams in Unterlast.

Zusammengefasst werden die vorhandenen Mitarbeiter nicht optimal für die Umsetzung der wichtigsten Anforderungen eingesetzt: Vorhaben werden nach Teams priorisiert anstatt Teams nach den Vorhaben auszurichten. Es wird lokal optimiert anstatt global innoviert.

Wie kann man Agilität über mehrere Teams skalieren?

Durch ein alternatives Modell lassen sich diese Effekte vermeiden. Bei Zalando haben wir in der Product Offer Platform (POP) ein Modell eingeführt, das die Teams nach den Aufgaben ausrichtet, anstatt anders herum: das Missions-Modell. 

Mit klassischen Komponenten-Teams werden Vorhaben nach Teams priorisiert anstatt Teams nach den Vorhaben auszurichten. Es wird lokal optimiert anstatt global innoviert.

Die vormals bestehenden drei stabilen Komponenten-Teams haben wir aufgelöst. Aus allen Mitarbeitern formen wir flexibel Teams, die Ende-zu-Ende an Business-Zielen arbeiten: Missionen. Ist das Ziel erreicht und somit die Mission abgeschlossen, löst sich das jeweilige Team auf und kann andere Missionen unterstützen oder eine neue starten.

Lebenszyklus eines Missions-Teams

Wie sieht das Arbeiten in Missions-Teams im Detail aus?

Im Missions-Modell formen wir flexibel Teams, die Ende-zu-Ende an Business-Zielen arbeiten.

Eine Voraussetzung ist ein priorisierter Backlog von Business-Zielen, die wir erreichen wollen. Bei Zalando nennen wir ihn den „Missions-Backlog“. Die am höchsten priorisierten Einträge müssen vom Produktmanagement schon so weit vorbereitet sein, dass Entwickler anfangen können daran zu arbeiten. Mit diesen Voraussetzungen ist der Lebenszyklus einer Mission wie folgt:

1. Zunächst müssen laufende Missionen enden, so dass ausreichend Kollegen frei werden um eine (oder mehrere) neue Missionen starten zu können. Dann stellen die Produktmanager die neue Mission dem gesamten Bereich vor: ihr Ziel, die vorläufigen Meilensteine, die groben Arbeitspakete und wie viele Kollegen mit welchem Wissen benötigt werden.
2. Im nächsten Schritt äußern die Mitarbeiter ihre Wünsche in welcher Mission sie arbeiten möchten. 
3. Basierend auf diesen Wünschen, dem für die Mission nötigen Wissen und den in den individuellen Mitarbeitergesprächen vereinbarten Entwicklungszielen entscheidet dann die Führungskraft der Mitarbeiter, wer tatsächlich in welcher Mission arbeiten soll – das Missions-Team entsteht. 
4. Nun kann die Mission starten. Dabei arbeitet das Team Ende-zu-Ende an allen Komponenten im Bereich, die nötig sind um das Ziel zu erreichen. Es ist nicht wie sonst verantwortlich für das isolierte Abarbeiten einzelner Tickets an einzelnen Komponenten, sondern – und das ist der große Unterschied zu Komponenten-Teams – für das Erreichen des Missions-Ziels.
5. Ist dieses Ziel erreicht, löst sich das Missions-Team auf und neue Missionen können starten. 

Was hierbei besonders wichtig ist: 

• Es gibt keinen festen Takt der Missionen – der Übergang ist rollierend. Wenn die Erreichung eines Zieles länger dauert als gedacht (so etwas soll ja vorkommen), läuft die Mission länger. Das Wichtigste ist das Erreichen des Zieles und nicht der Prozess an sich.
• Es ist meist nicht sinnvoll eine Mission am ersten Tag mit der vollen Teamstärke zu  starten und sie endet auch nicht am letzten Tag in voller Besetzung. Stattdessen gibt es typischerweise  Ramp-up- und Ramp-down-Phasen. Dadurch überlappen sich Missionen zeitlich etwas.

Hier eine Übersicht welche konkreten Missionen wir in der Product Offer Platform umgesetzt haben und wie sie aufeinander folgten. Die Grafik zeigt, wie zu jedem Zeitpunkt Software-Entwickler auf Missionen verteilt waren. Die Höhe der Flächen gibt dabei den Anteil der Entwickler an, die zu dem Zeitpunkt in der Mission gearbeitet haben.

Die folgende Beschreibung willkürlich ausgewählter Missionen soll sie etwas anschaulicher machen:

• Sneakers Release Calendar hatte das Ziel eine Vorschau auf zukünftig erhältliche, begehrte Sneakers zu schaffen, die vor allem sogenannte „Sneakerheads“ begeistert.
• Assortment A/B Testing war eine Mission, mit der wir auf Plattform-Ebene die Fähigkeit schufen, quantitativ zu testen, welchen Effekt die Verfügbarkeit oder Nichtverfügbarkeit von bestimmten Teilen des Sortiments für unsere Kunden hat.
• Im Rahmen der Mission Lounge CZ halfen wir Zalando Lounge in Tschechien einzuführen.
• Die Mission Cyber Week diente dazu, uns technisch auf die Cyber Week und Black Friday vorzubereiten, während derer wir ein Vielfaches der üblichen Menge an Produktangebotsdaten zuverlässig und schnell verarbeiten müssen (wir erstellten ungefähr 3 Milliarden Produktangebote während dieser Zeit).

Herausforderungen einer flexiblen Team-Struktur

Wenn technische Komponenten nicht mehr von einem festen Team gepflegt werden, so bringt dies jedoch unmittelbar Schwierigkeiten und neue Herausforderungen mit sich. Zuallererst steht die langfristige Qualität der Software in Frage. Wenn Teams nicht mehr für Komponenten verantwortlich sind, aber möglichst schnell ein Business-Ziel erreichen wollen, steigt die Gefahr, dass die Softwarequalität über die Zeit abbaut und zu einem Problem wird. Das haben wir in unserem Modell auf mehrere Arten adressiert:

• Unser Missions-Modell basiert auf mehreren Prinzipien. Eines davon lautet, dass eine Mission jede technische Komponente, die sie verändert, mindestens in der Qualität hinterlassen muss, in der sie sie vorfindet. Das lässt sich zum Beispiel über Softwaremetriken wie Code Coverage und Ähnliches messen.
• Für jede Mission ist am Ende eine Abschlussphase vorgesehen. Diese Zeit ist explizit dafür da “aufzuräumen” und Dinge gerade zu ziehen, die noch nicht sauber abgeschlossen waren.
• Zusätzlich haben wir doch Verantwortung für einzelne Komponenten festgelegt: Analog zur Open-Source-Softwareentwicklung gibt es bei uns eine Maintainer-Struktur – orthogonal zur flexiblen Missions-Struktur. Die Kollegen, die sich mit einer Komponente am besten auskennen, sind deren Maintainer und helfen deren Codequalität hoch zu halten – zusätzlich zu ihrer Arbeit in einer Mission. Ein Maintainer prüft zum Beispiel jede Code-Änderung, die eine Mission an der Komponente vornehmen möchte,  und muss sie erst freigeben. Ein Maintainer kümmert sich auch darum verwendete Bibliotheken zu aktualisieren, wenn etwa eine Sicherheitsschwachstelle entdeckt wurde und unmittelbar geschlossen werden muss. Über die Maintainer-Rolle wird Verantwortung für Komponenten in unserem Modell abgebildet.

Wenn technische Komponenten nicht mehr von einem festen Team gepflegt werden, steht die langfristige Qualität der Software in Frage – wenn man nicht gegensteuert.

Was ebenfalls eine Herausforderung war, ist die Wissensverteilung, da idealerweise alle Mitarbeiter an allen Komponenten arbeiten können sollen. Gerade bei der Einführung des Modells wurden schnell Defizite in der bisherigen Wissensverteilung und Dokumentation sichtbar. Im Lauf der Zeit änderte sich dies jedoch in einen Vorteil, da die so sichtbar gemachten Probleme gelöst und das Wissen besser verteilt wurde.

Vorteile des Missions-Modells

Nachdem das Missions-Modell einige Umstellungen mit sich bringt, stellt sich die Frage, welche Vorteile ein Unternehmen davon hat:

• Impact: Teams werden auf die Prioritäten zugeschnitten und nicht Prioritäten auf verfügbare Teams. Das Missions-Modell stellt sicher, dass an den wichtigsten Themen gearbeitet wird.
• Verringerte Cost of Delay: Dadurch, dass Vorhaben von einem Team Ende-zu-Ende umgesetzt werden, gibt es kein Warten auf das letzte Puzzleteil von Team X. Statt dessen geht das Feature so schnell wie möglich live.
• Klarer Fokus: Teams müssen nicht eine Unmenge unzusammenhängender Storys umsetzen, sondern arbeiten auf ein klares Ziel hin.
• Flexibilität: Wenn Prioritäten im Missions-Backlog wechseln und etwas plötzlich dringend wird, kann es sofort angegangen werden, sobald die Kapazität für eine neue Mission frei geworden ist. Ohne Missions-Backlog müsste für ein dringendes übergreifendes Vorhaben für alle beteiligten Teams deren individueller Backlog neu priorisiert werden. 

In diesem Sinne skaliert das Missions-Modell Agilität über ein einzelnes Team hinaus.

Bei der Einführung des Missions-Modells wurden schnell Defizite in der bisherigen Wissensverteilung und Dokumentation sichtbar.

Allerdings kommt das Modell nicht nur dem Unternehmen zu Gute. Für die Mitarbeiter selbst hat es ebenfalls schlagkräftige Vorteile:

• Ganz nach Dan Pink adressiert das Missions-Modell die drei Hauptpfeiler von Motivation: 
  • Autonomy: Mitarbeiter nehmen selbst Einfluss darauf, woran sie arbeiten.
  • Purpose: Sie suchen durch diese Wahl mit aus, an welchen Zielen sie arbeiten und welchen Impact sie erzeugen. 
  • Mastery: Mitarbeiter können so ebenfalls beeinflussen, mit welchen Technologien sie arbeiten und somit neues Wissen aufbauen. 
• Durch den Fokus auf ein Business-Ziel stellen wir tatsächlich eine deutlich stärkere Identifikation der Entwickler mit dem jeweiligen Thema fest: Sie übernehmen viel mehr Verantwortung auch über ihren Bereich hinaus und treiben die Themen ganzheitlich zum Erfolg. Das ist ein ganz anderer Arbeitsmodus als das stumpfe Abarbeiten beliebiger Tickets aka. User Stories.
• Das oben erwähnte Thema “Mastery” wird im Modell noch weitergehend dadurch unterstützt, dass Entwickler die Möglichkeit haben Neues zu lernen (was auf dem Arbeitsmarkt essenziell ist), anstatt jahrelang an den selben Komponenten mit denselben Technologien zu arbeiten.

Führung im Missions-Modell

Einige Aspekte der Führung sind es wert im Missions-Modell gesondert betrachtet zu werden.

Trennung von fachlicher und disziplinarischer Führung

Wie in meinem Artikel “Verflixte Hierarchie” beschrieben, gibt es unterschiedliche Arten von Führung. Im Missions-Modell sind die fachliche und die disziplinarische besonders zu beachten:

• Disziplinarische Führung kümmert sich um die langfristige Entwicklung der Mitarbeiter – die disziplinarische Führungskraft sollte deshalb so weit wie möglich konstant bleiben um langfristig Wirkung entfalten zu können.
• Fachliche Führung hängt vom jeweiligen Problem ab und wechselt deshalb dynamisch mit den aktuell wichtigsten Themen im Team. Wer sich am besten auskennt, sollte fachlich führen.

Die fachliche Führung muss natürlich innerhalb des Team liegen, da in diesem die fachlichen Themen bearbeitet werden. Der oder die jeweils Erfahrensten im jeweiligen Thema sollten die fachliche Führung wahrnehmen. Hierfür bedarf es keiner formellen „Ernennung“.

Die disziplinarische Führung hingegen kann im Missions-Modell nicht bei jemandem aus dem Team verortet werden (z. B. einem Team Lead), da sich durch die dynamische Teamzusammensetzung regelmäßig ändert, wer mit wem zusammenarbeitet.

Fachliche und disziplinarische Führung müssen deshalb zwingend getrennt werden. 

Unsere Team Leads in der Product Offer Platform bei Zalando etwa kümmern sich um die persönliche Entwicklung einzelner Mitarbeiter (disziplinarische Führung) und arbeiten in Missionen mit. Sie führen die Mission aus der Team-Lead-Rolle heraus aber nicht fachlich. Ihre Mitarbeiter können gleichzeitig in anderen Missionen arbeiten als sie selbst. 

Im abgebildeten Beispiel gibt es drei Missions-Teams. Mitarbeiter mit „Hut auf“ sind die disziplinarisch Vorgesetzten der anderen Mitarbeiter mit der gleichen Farbe und durch einen Strich verbunden.

• Im linken Missions-Team arbeitet gar keine disziplinarische Führungskraft.
• Im mittleren Team arbeitet eine Führungskraft, die aber nur einen Mitarbeiter in der eigenen Mission disziplinarisch führt.
• Im rechten Team arbeiten zwei Führungskräfte, von denen eine keinen Mitarbeiter aus dieser Mission führt.

Fachliche und disziplinarische Führung müssen in einer flexiblen Teamstruktur zwingend getrennt werden.

Aber kann es funktionieren, dass die Führungskraft nicht im selben Team arbeitet wie der Mitarbeiter?

Das geht, denn disziplinarische Führung soll sich um die langfristige Entwicklung eines Mitarbeiters kümmern und nicht um operatives Micro-Management. Als ich noch in der Beratung tätig war, hat mich meine disziplinarische Führungskraft im Extremfall während des gesamten Jahres nie direkt bei der Arbeit erlebt, da ich auf einem Projekt bei einem Kunden war und sie woanders. Dennoch funktioniert auch hier Führung – sie braucht nur andere Instrumente, zum Beispiel systematisches Einholen von Feedback zu meiner Arbeit von Menschen, mit denen ich unmittelbar zusammenarbeite. Und natürlich: Gelegentlich arbeiten im Missions-Modell auch Führungskraft und Mitarbeiter gemeinsam in einer Mission.

Kann es funktionieren, dass die Führungskraft nicht im selben Team arbeitet wie der Mitarbeiter?

Transparenz und Entscheidungen

Es gibt also formell keine fachliche Führungskraft in den Missionen. Die disziplinarischen Führungskräfte, die in Missionen arbeiten, haben fachlich das gleiche Mitspracherecht wie alle anderen. Fachliche Führung entsteht informell durch Kompetenz. 

In diesem Zusammenhang wurde ich schon mehrfach gefragt: “Wer stellt dann sicher, dass das Team nicht ‘faulenzt’?” Zunächst war ich irritiert über solch einen Irrglauben an die Notwendigkeit und Wirksamkeit von formaler fachlicher Führung. Aber ich habe dennoch zwei, wie ich finde, gute Antworten: 

1. Zum einen schaffen wir eine hohe Transparenz über den Status der einzelnen Missionen. Wir haben ein wöchentliches Meeting – das sogenannte “Portfolio-Meeting”. Aus jeder Mission müssen der Product Manager und ein Entwickler teilnehmen. Darüberhinaus kann auch jeder sonst das Meeting besuchen, der Interesse hat. Jede Mission berichtet darin über den Fortschritt, über auftretende Schwierigkeiten und auch über potenzielle Verschiebungen von Meilensteinen oder andere Verzögerungen. Jegliche Probleme werden unmittelbar sichtbar und können adressiert werden. 
2. Zum anderen bin ich überzeugt, dass jeder Kollege den intrinsischen Drang hat etwas zu erreichen. Im Missions-Modell wird das noch deutlicher spürbar, da die Entwickler auf Business-Ziele mit klar definierter Auswirkung hinarbeiten, für die sie sich selbst gemeldet haben. Ich habe deshalb noch nie erlebt, dass ein Team “gefaulenzt” hätte. Es kommt eher vor, dass unvorhergesehene Schwierigkeiten auftauchen oder das Team sich in einem Problem festgefahren hat. Hier kann dann übergeordnete Führung unterstützend helfen.

Der Glaube an die Notwendigkeit und Wirksamkeit von formaler fachlicher Führung ist ein Irrglauben.

Eine zweite Frage, die mir wegen der Trennung von disziplinarischer und fachlicher Führung oft gestellt wird, ist folgende: “Wer stellt denn sicher, dass das Team keine falschen Entscheidungen trifft (z. B. architektonisch oder technisch)?” Auch hier überrascht mich der Irrglaube, dass formal verankerte fachliche Führung dies immer verhindern könne. Aber auch hier gibt es zwei Antworten:

1. In erster Linie treffen die Missions-Teams technologische und architektonische Entscheidungen selbst. Wenn sie übergreifende Auswirkungen haben oder das Team nicht sicher ist, tauscht es sich selbstverständlich mit fachlich versierten Kollegen aus, die evtl. gerade in einem anderen Missions-Team arbeiten.
2. Darüber hinaus haben wir einen Architekten im Bereich, der einerseits einen Überblick über alle laufenden und anstehenden Missionen und deren architektonische Implikationen hat. Er ist in der Phase des Solution Design ohnehin involviert, wenn es nicht um rein lokale Themen geht. Andererseits beziehen die Teams ihn selbst aktiv in Entscheidungen mit ein, da dies immer hilfreich ist.

Man kann also auch hier den Teams vertrauen, dass sie das Fachwissen selbst haben oder den Austausch und Unterstützung suchen, wenn dies nötig ist.

Agile Teams skalieren!

Wir verwenden das Missions-Modell nun schon seit über einem Jahr und profitieren deutlich davon: Wir können größere und übergreifende Themen wesentlich leichter umsetzen und schneller den Nutzen erzielen. Dadurch wird generell der Wert unserer Arbeit höher, weil wir weniger lokal optimieren und mehr global innovieren. Wir haben auch harte Fakten, die dies bezeugen: Unsere Cycle Times sind gesunken und die Mitarbeiterzufriedenheit signifikant gestiegen. 

Heißt das nun, dass man eine Organisation in Komponenten-Teams sofort auf das Missions-Modell umstellen sollte?

Das tut es nicht! Aber warum? 

Der wichtigste Unterschied des Modells aus meiner Sicht ist nicht der Prozess, sondern sind die Kultur und das Mindset. Während Entwickler im Komponenten-Modell für “ihre” Komponenten zuständig sind und mit den gleichen Kollegen und den gleichen Technologien User Stories abarbeiten, müssen sie sich hier darauf einlassen mit wechselnden Kollegen sogar eventuell unbekannte Komponenten anzupassen um ein größeres Vorhaben so weit umzusetzen, dass ein signifikanter Nutzen für die Endkunden entsteht.  

Eine flexible Teamstruktur ist keine Frage des Prozesses, sondern der Kultur und des Mindsets.

Kultur und Mindset ändern sich nicht abrupt, sondern nur über längere Zeit. Wir sind auch nicht abrupt auf dieses Modell umgestiegen. Als wir noch im Komponenten-Modell arbeiteten, haben wir bei sehr ungleicher Auslastung der Teams bereits Kollegen zeitweise oder für länger in ein überlastetes Team wechseln lassen – freiwillig. Wir haben außerdem in längeren Zeitabständen die grundsätzliche Teamstruktur angepasst. Der Kontakt zwischen den Teams war deshalb intensiver und die Entwickler kannten sich schon – genau wie den Wechsel zwischen Teams, wenngleich eher selten. Insofern war der Schritt für uns ein kleinerer.

Als Fazit bleibt: Das flexible Missions-Modell erlaubt es agile Vorgehensweisen jenseits einzelner Teams zu skalieren. Fachliche und disziplinarische Führung müssen dafür getrennt werden. Im Ergebnis kann man übergreifend klarer priorisieren, besser fokussieren und größere Vorhaben umsetzen anstatt nur lokal zu optimieren. Entwickler werden zufriedener und engagierter, indem sie beeinflussen, woran sie arbeiten und wie sie sich weiterentwickeln. Der Wechsel zu diesem Modell erfordert Zeit, da es eine Kulturveränderung braucht. Es lohnt sich jedoch für alle Beteiligten!