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. 
Lebenszyklus einer Mission: 
1. Vorstellung anstehender Missionen durch einen Product Manager
2. Mitarbeiter benennen ihre bevorzugte Mission
3. Disziplinarische Führungskraft (mit "Hut auf") ordnet Mitarbeiter zu Missionen zu
4. Missions-Team startet
5. Team löst sich nach Erreichen des Zieles wieder auf
Lebenszyklus einer Mission

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.

Übersicht über die verschiedenen Missionen im Zeitverlauf.
Verteilung der Missionen im Zeitablauf

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. 

Verdeutlichung der möglichen Konstellationen disziplinarischer Führung im Missions-Modell.
Disziplinarische Führung im Missions-Modell

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? 

Abbildung eines menschlichen Gehirns

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!

Wenn du einen Rechtschreibfehler findest, benachrichtige mich bitte, indem du den Text auswählst und dann Strg + Eingabetaste drückst.

Diesen Beitrag teilen:

9 Gedanken zu „Mit flexiblen Teams Agilität skalieren

  1. Hi Jan, toller Artikel.

    Folgende Fragen und Anmerkungen:

    1. Am Anfang gehst du auf Tuckmans Teamphasen ein. Tuckman war Psychologe und die Phasen beziehen sich auf das soziale Miteinander. Mit jedem Zu- und Abgang gehen die Phasen wieder von vorne los. Ich entnehme dem Ende des Artikels, dass das Vermischen der 3 Teams bereits länger im Gange war und es sich eher um eine große Gruppe handelte, die sich bereits gut kannte. Eventuell schon durch die Phasen gegangen ist. Andernfalls stelle ich mir die Reibungsverluste doch recht hoch vor.

    2. In dem distribution Graph sieht man recht deutlich, dass aus 3 Teams maximal 3 Missionen geworden sind. Bezieht sich die „Skalierung“ dann nur auf das Vermeiden der CoD?

    Grundsätzlich wirkt es auf mich, als wenn ein +-15 Mann starkes Team sich ständig 3 Themen gleichzeitig widmet, mit einer flexibel wechselnden Arbeits- und Aufgabenverteilung. Das erfordert einen sehr hohen Grad an Vertrauen, Fachkompetenz und Selbstdisziplin bei den Mitgliedern. Falls dem so ist, bin ich schon sehr neidisch auf Deine Leute. 😉

    Beste Grüße
    Dirk

    P.S. nächstes mal aber auf English!

    1. Hallo Dirk,

      vielen Dank für dein Feedback!

      Was ich dazu sagen kann:

      1. Du hast vollkommen Recht. Tatsächlich kann man den ganzen Bereich als ein großes Team verstehen und das war und ist auch mein Ziel. Dennoch durchlaufen die Mitarbeiter jeder einzelnen neuen Mission auch wieder die Teamphasen. Da sie das aber regelmäßig tun und die Kollegen vorher schon miteinander gearbeitet haben, kommen sie schneller durch die Phasen. Natürlich kostet das immer etwas Zeit. Andererseits durchlaufen Komponententeams die Teamphasen unter Umständen auch von neuem, wenn nur ein Mitarbeiter das Team verlässt oder hinzu kommt.
      2. Mit „Skalierung“ meine ich vor allem, dass die agile Arbeitsweise aus dem Silo eines einzelnen Teams herausgehoben wurde, d. h. wir arbeiten in einem größeren Kontext an den jeweils wichtigsten Themen, reduzieren Abstimmungs- und Übergabeaufwände und können somit in einer größeren Organisation effizienter arbeiten.
      Deine Zusammenfassung zu dem 15-Personenteam trifft es ganz gut. Genau das Vertrauen mussten wir erst aufbauen, das Wissen verteilen und an der Disziplin im Sinne von übergreifend vereinbarten Arbeitsweisen arbeiten wir natürlich noch immer. Das Beste daran ist allerdings, dass es den Mitgliedern auch die beschriebenen Vorteile bringt und diese sehr geschätzt werden.

      Viele Grüße!
      Jan

  2. Jetzt mal ehrlich: Wie unterscheidet sich das von dir beschriebene Modell von der klassischen Matrixstruktur jeder beliebigen Agentur, mit all ihren Nachteilen? Ich denke, ich könnte „Missions-Teams“ zwanglos in „Projekt-Teams“ umbenennen, die ihre Mitarbeitenden aus den Fach-Abteilungen ausleihen, und würde damit meinen Punkt vielleicht etwas klarer machen.

    Gerade, wenn ich lese, dass Teams wachsen und schrumpfen, je nach Bedarf, weiß ich aus 20+ Jahren Agenturerfahrung, dass sofort das Auslastungsthema auf der Agenda steht inkl. allen Versuchungen, die mit ihm einhergehen: bspw. 50% der Zeit eines Mitarbeitenden zu buchen. Mehr braucht man von dem/der in dieser Phase der Mission halt noch nicht…

    Vielleicht könntest du kurz beschreiben, ob und wie sich das von dir beschriebene Modell von der Agentur-Matrix unterscheidet?

    1. Hallo Rainer,

      danke für deinen Kommentar! Das ist eine sehr interessante Sichtweise und ich gebe dir Recht, dass die Modelle sehr ähnlich sind.
      Ich habe zwar nie in einer Agentur gearbeitet, aber lange genug in der Beratung, wo das Modell fast identisch ist. In diesen Fällen geht es typischerweise primär um Auslastung, fakturierbare Leistungen etc., selten um Produktentwicklung oder agile Führung. Insofern ist das gar nicht meine Zielgruppe. Meine Zielgruppe sind die Unternehmungen, die als Kern ihres Geschäfts inhouse langlebige digitale Produkte entwickeln. Diese Unternehmungen sind typischerweise ganz anders strukturiert: wesentlich statischer und funktionaler. Aus diesem Kontext heraus tun sie sich oftmals damit schwer dynamischere Strukturen zu wagen. Während einer Berater*in oder Agenturmitarbeiter*in klar ist, dass sie, sobald sie „Kapazität haben“ auf das nächste Projekt gesetzt werden, ist bei Mitarbeiter*innen, die jahrelang das selbe Softwaresystem betreuen, eine solche Flexibilität teilweise undenkbar. Insofern ist die Ausgangslage diametral entgegengesetzt und deshalb ist der Ansatz für statische Organisationen ein Mehrwert.
      Ein paar Unterschiede sehe ich außerdem:
      1. Während in der Agentur-/Beratungswelt Mitarbeiter*innen meiner Erfahrung nach auf das nächste Projekt gesetzt werden, auf das sie passen, haben die Mitarbeiter*innen bei Inhouse-Entwicklung eine echte Auswahl.
      2. Während sich im Agentur-/Beratungsgeschäft das nötige Domänenwissen für jedes Projekt unterscheidet, ist das Wissen in der eigenen Produktentwicklung wesentlich beständiger (was auch typischerweise zu den statischen Strukturen geführt hat).
      3. Während Agenturmitarbeiter*innen/Berater*innen selten ein digitales Produkt, an dem sie einmal mitgewirkt haben, wiedersehen, ist das bei Inhouse-Produktentwicklung auch mit flexiblen Teams sehr wahrscheinlich so.

      Abstrakter gesehen ist der wichtigste Unterschied: Agenturen sind im Projektgeschäft, Unternehmen mit eigenen digitalen Produkten im Produktgeschäft. Was mein Artikel dann vielleicht aus deiner Sichtweise zeigen sollte: Wie flexiblere Ansätze aus der Projektwelt in einer Produktmanagement-Welt helfen können.

      Hilft das?

      Viele Grüße!
      Jan

      1. Danke für die ausführlich Antwort, Jan! Deinen zentralen Punkt habe ich, glaube ich, verstanden: dass Produktorganisation eher mehr Flexibilität brauchen, während Projektorganisationen (bspw. Agenturen) mehr Stabilität brauchen. Wie so oft liegt die Wahrheit also möglicherweise in der Mitte.

        Einen Punkt sehe ich noch. Je stabiler/starrer Teams sind, desto mehr Druck habe ich, das Geschäft im Rahmen meiner Möglichkeiten so zu steuern, dass diese Teams auch sinnvolle Arbeit zu tun haben. Aus Agentursicht ist das ein wünschenswerter Druck, der bspw. zu dem Bemühen führt, stabilere Kundenbeziehungen anzustreben und längerfristige Verträge abzuschließen.

        Wenn ich Teile eines Teams halbwegs kurzfristig wieder „abbestellen“ kann, fällt dieser Druck jedenfalls teilweise weg. Ich entlaste dann auch in einer Produktorganisation mein Produkt wahrscheinlich gerne mal von den Kosten, die das Team erzeugt, wenn ich in den nächsten vier Wochen halt keine Zeit habe, den Product Backlog wieder aufzufüllen. Dann sitzen auf einmal Leute rum, die dann eben anderswo draufgenommen werden, dann stehen sie mir wieder nicht für mein Produkt zur Verfügung, wenn ich den Backlog aufgefüllt habe. Ich gerate so schnell in eine stark fragmentierte Buchungssituation.

        Will sagen: It’s a slippery slope. Aber deinen Grundgedanken kann ich jetzt besser nachvollziehen.

        1. Hallo Reiner,

          ich glaube deine Zusammenfassung trifft es auf den Punkt: mehr Stabilität in Projektorganisationen und mehr Flexibilität in Produktorganisationen.

          Was die starren Teams angeht, so verstehe ich deine Sicht bei Agenturen völlig: stabile Teams über längere Zeit am gleichen Thema arbeiten zu lassen, ist hilfreich (aber oftmals nicht einfach). Bei Agenturen muss die neue Arbeit ja immer erst akquiriert werden, d.h. herangeschafft.
          In Produktorganisationen gibt es dieses Problem meistens nicht: Meiner Erfahrung nach gibt es immer mehr Ideen als Umsetzungskapazität. Da muss man eher darum kämpfen statt neuer Features auch mal in die langfristige technologische Basis investieren zu können. Insofern haben Produktorganisationen typischerweise kein Buchungsproblem, sondern ein Priorisierungsproblem: Was machen meine Teams als nächstes? Wenn man aber einen Ansatz etabliert hat diese Frage methodisch gut zu beantworten, dann arbeiten die Teams auch an den richtigen Themen.

          Viele Grüße!
          Jan

  3. Hallo Jan,
    zunächst vielen Dank für den prägnant verfassten Artikel!
    Ich habe eine Frage zur Aufstellung und Arbeitsweise von eher langfristig gedachten (Missions) Teams. Was sind Faktoren innerhalb des Teams die sich bei stark wachsendem Arbeitsvolumen und höherer Taktrate ändern sollten? Der Kontext auf den ich mich beziehe geht über die ausschließlich zahlenmäßige Vergrößerung des Teams hinaus und bezieht sich ausdrücklich auch auf die Arbeitsweise.
    Solltest du hierzu konkret bereits etwas geschrieben habe, würde ich mich sehr über einen Link freuen.
    Viele Grüße, Jakob

    1. Hallo Jakob,

      vielen Dank für dein Feedback!
      Wenn ich deine Frage richtig verstehe, willst du wissen, wie sich die Teamorganisation ändert, wenn die Anzahl der Themen zunimmt, die bearbeitet werden sollen.

      Zunächst einmal glaube ich, dass es die Aufgabe von Führung ist, Störungen vom Team fernzuhalten, damit es fokussiert gute Arbeit machen kann. Wenn nun die Anzahl der Themen zunimmt, ist das zuerst eine Priorisierungsfrage. Dazu habe ich hier: https://www.agil-gefuehrt.de/wie-rollierende-vorhabenplanung-dabei-hilft-richtig-zu-priorisieren/ einen Ansatz beschrieben. Zentral ist dabei, dass man erst ein neues Thema beginnt, wenn die Kapazität dafür frei wird. In sehr dringenden Fällen kann man dafür laufende Vorhaben abbrechen, aber das sollte die Ausnahme bleiben. Hier: https://www.agil-gefuehrt.de/effiziente-priorisierung-von-vorhaben/ habe ich noch beschrieben, wie man konkret das nächste Vorhaben auswählen könnte.

      Zum anderen ist es ebenso Aufgabe von Führung die Menge dessen zu optimieren, was Teams umsetzen können. Wenn nun die Kapazität nicht reicht und mehr Vorhaben umgesetzt werden sollen, so kann man natürlich über das Einstellen weiterer Mitarbeiter nachdenken um mehr Vorhaben/Missionen gleichzeitig umsetzen zu können, wie du selbst schreibst. Wenn das keine Option ist, bleiben z. B. noch Optimierungen im Zuschnitt der Arbeit (welche Arbeitspakete können später folgen – Achtung: Gefahr des Aufbaus technischer Schulden), im Finden von Synergien zwischen den verschiedenen Vorhaben (was kann ich einmal implementieren und für mehrere Vorhaben nutzen – so etwas sollte ich jedoch auch ohne Druck möglichst von vornherein berücksichtigen) oder im allgemeinen Optimieren von Prozessen (auch hier sollte man vielleicht nicht unter höchstem Druck mit Experimenten beginnen).
      Eine wirkungsvollere Option ist evtl. das „Innersourcen“ von gewünschten Änderungen: Beziehen sich zum Beispiel mehrere Anforderungen auf Funktionalitäten, die andere Organisationseinheiten in meinen Services brauchen, so kann man sie befähigen diese Änderungen selbst vorzunehmen um den Aufwand für die eigenen Teams zu reduzieren. Das ist ein Ansatz, der auch gut vorbereitet sein will.

      Auch wenn Missionen unterschiedlich groß sind, so haben wir in der Product Offer Platform versucht sehr große Vorhaben in kleinere herunterzubrechen. Das gelingt aber nicht immer und ein sehr aufwändiges Vorhaben (bis zu 10 Entwickler, 7 Monate Laufzeit) musste am Stück umgesetzt werden. Wir haben in diesem Fall innerhalb der Mission sog. Workstreams definiert um kleinere Teilteams zu haben, die sich um einen definierten Bereich kümmern können. Das hat ganz gut funktioniert. Damit stellen sich dann natürlich Fragen nach Stand-up-Strukturen etc., aber das ist alles lösbar.

      Beantwortet das deine Frage halbwegs?

      Vielen Dank und viele Grüße!
      Jan

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.