Verschiedene Szenarien
Sehen wir uns einmal diese beiden Szenarien an:
Szenario 1
Wir haben in unserem Unternehmen eine Reihe von stabilen Teams, die sich jeweils um eine Domäne kümmern (z.B. Sign-up, Suche, Checkout usw.). Alle Teams arbeiten in synchronisierten, zweiwöchigen Sprints (d.h. alle Teams beginnen und beenden ihre Sprints gleichzeitig). Zur Vorbereitung des nächsten Sprints überlegen sich die Product Owner der jeweiligen Teams, welche Ziele sie mit ihren Teams in den nächsten Sprints erreichen wollen und passen dementsprechend ihre Backlogs an. Weil es Abhängigkeiten zwischen den Teams gibt, kommunizieren die Teams natürlich miteinander, um mit diesen Abhängigkeiten möglichst elegant umzugehen. Ansonsten arbeiten die Teams innerhalb des Sprints aber weitgehend unabhängig voneinander an ihren Zielen.
Szenario 2
Wir haben dieselbe Situation wie in Szenario 1, nur dass wir diesmal ein großes, neues Feature entwickeln wollen, von dem wir wissen, dass alle unsere Teams gemeinsam daran arbeiten müssen. Zur Vorbereitung treffen sich alle Product Owner und einige EntwicklerInnen, um ein gemeinsames Verständnis davon zu entwickeln, wie genau das neue Feature aussehen soll und wie es technologisch umgesetzt werden kann. Dann teilen sie den Gesamtumfang des Features in kleinere Pakete auf, die den jeweiligen Teams zugeteilt werden (abhängig davon, in welche Domäne sie am besten passen). Danach arbeiten die Teams mehrere Sprints lang an ihren Teilaufgaben und integrieren diese zu einem Gesamtkunstwerk. Zwischendurch koordinieren sich die Teams, um aufgekommene Fragen zu klären, Abhängigkeiten aufzulösen etc.
Beide Szenarien dürften in vielen Organisationen, die mehr oder weniger agil arbeiten, Standard sein. Im ersten Fall handelt es sich um Feature-Entwicklung in eigenständigen Teams. Im zweiten Fall handelt es sich um einen Skalierungsmechanismus, bei dem mehrere Teams zusammenarbeiten, um ein gemeinsam Feature zu entwickeln. Dass die Teams Scrum verwenden, spielt erst einmal keine entscheidende Rolle. Die Gemeinsamkeit zwischen beiden Szenarien, auf die wir hier hinauswollen, ist diese: Beide Male werden die Ziele bzw. Aufgaben an die bestehenden Teamstrukturen angepasst, d.h. wir sehen die Strukturen als gegeben an und überlegen uns dann, wie wir unsere Ziele innerhalb dieser Strukturen mit möglichst wenig Friktion erreichen können. An diesem Vorgehen ist generell natürlich nichts verkehrt. Es ist aber in vielen Organisationen inzwischen soweit zur Routine geworden, dass es schwer fällt, andere Modelle überhaupt nur zu denken.
Überlegen wir also mal, wie die beiden Szenarien sich verändern könnten, wenn wir den gegensätzlichen Ansatz verfolgen würden: die Teamstrukturen an die Ziele / Aufgaben anzupassen.
Szenario 1b
Es existieren keine festen Teams, sondern alle unsere EntwicklerInnen sind Teil eines großen Entwickler-Pools. Alle zwei Wochen gibt es einen großen Workshop, bei dem sich der ganze Pool trifft, um für den kommenden Sprint temporäre Feature-Teams zu bilden. Als Vorbereitung auf den Workshop wurde eine Liste mit Zielen vorbereitet, und zu jedem Ziel gibt es eine grobe Idee, wie man dieses Ziel wohl am besten umsetzen könnte. Nachdem Fragen diskutiert wurden, finden sich in einem moderierten Prozess kleine Teams zusammen, die sich jeweils einem Ziel widmen werden. Dabei wird darauf geachtet, dass in jedem Team die benötigten Fähigkeiten vertreten sind. Am Ende des Sprints werden die Ergebnisse vorgestellt, Features live gestellt und die Teams gehen wieder im großen Pool auf.
Szenario 2b
Auch hier haben wir die meiste Zeit über stabile Teams, die an ihren eigenen Zielen arbeiten. Diese Teamstruktur wird allerdings jedes Mal vorübergehend aufgeweicht, wenn wir ein großes Feature entwickeln wollen, das substantielle Zusammenarbeit von mehreren Teams erfordert. Jetzt überlegen wir uns, welche Fähigkeiten und welches Domänenwissen wir für das neue Feature benötigen und formen auf dieser Grundlage ein neues Team, das sich ausschließlich um die Entwicklung des großen, neuen Features kümmert. Die einzelnen Produktteams bleiben bestehen, allerdings oft nur in einer Rumpfbesetzung, weil sie einzelne Mitglieder ja vorübergehend an das neue Team “verloren” haben. Sie müssen sich nun überlegen, wie sie unter den gegeben Umständen den größten Wert generieren können und setzen sich dementsprechend Ziele für die kommenden Sprints.
Passen wir Ziele an Strukturen oder Strukturen an Ziele an?
Keines der Szenarien ist per se besser als die anderen. Es kommt auf den Kontext an. Oben haben wir beschrieben, dass wir uns zu selten die Frage stellen, ob es passend wäre, die Strukturen an die Ziele anzupassen. Wir sollten uns also regelmäßig diese Frage stellen:
Vor- und Nachteile der Ansätze
Die beiden Ansätze (Ziele an Strukturen anpassen vs. Strukturen an Ziele anpassen) bilden Pole, die ein Spannungsfeld erzeugen. Für die Anpassung der Ziele an die Strukturen spricht, dass Menschen Zeit brauchen, um in neuen Strukturen handlungsfähig zu werden. Für die Anpassung der Strukturen an die Ziele spricht, dass wir weniger Overhead durch Abhängigkeitsmanagement und Koordination haben.
Wir können die beiden Pole in einem Koordinatensystem visualisieren. Abhängig davon, wie stark wir von temporären (fluiden) Teams Gebrauch machen, entstehen unterschiedliche Kosten. Arbeiten wir mit für immer fest betonierten Teamstrukturen, entstehen früher oder später extrem hohe Kosten durch die Abhängigkeiten zwischen Teams.
Arbeiten wir mit komplett fluiden Strukturen und wechseln beispielsweise mehrfach am Tag die Teamzusammensetzung, bekommen wir extrem hohe Kosten für Team-Building.
Wie exakt die beiden Kurven aussieht, hängt natürlich vom jeweiligen Kontext ab – wenn die Teams beispielsweise an jeweils eigenen Produkten arbeiten, die stark voneinander getrennt sind, werden wir geringere Kosten durch Abhängigkeiten sehen. Am Ende geht es also darum, den eigenen Sweet-Spot zu finden.
Fokus von Teammitgliedern und Split Heads
Ein weiterer wichtiger Aspekt ist der Fokus der einzelnen Teammitglieder. Im Grunde betrifft er beide Ansätze – in unterschiedlicher Ausprägung. Wenn wir z.B. aus stabilen Teams heraus ein temporäres Team für ein wichtiges Ziel bilden, kann es passieren, dass wir einen Spezialisten im temporären Team brauchen, den sein Stammteam auch unbedingt braucht (z.B. weil nur er eine ganz bestimmte Technologie beherrscht). Dann landet man schnell dabei, dass die Person Mitglied in beiden Teams ist (Split Head). Split Heads sind ein sehr effektiver Mechanismus, um Leistung zu vernichten. Ständiger Kontextwechsel ist in der Wissensarbeit toxisch: Man muss sich immer wieder neu eindenken und verliert dadurch extrem viel produktive Zeit. Das mag in Ausnahmefällen akzeptabel sein. Wenn allerdings regelmäßig in Teams mit Split Heads gearbeitet wird, ist keine Höchstleistung zu erwarten.
Dieses Problem äußert sich bei der Arbeit mit stabilen Teams subtiler. Die Menschen sind zwar exklusiv ihrem Team zugeordnet, werden dann aber doch immer wieder von anderen Teams um Hilfe gebeten oder auch nur von den eigenen Teammitgliedern.
Um einen möglichst hohen Fokus beizubehalten, ist (neben einem Bewusstsein für das Problem) eine klare Priorisierung notwendig. Bilden wir ein neues, temporäres Team, das unsere eine Spezialistin benötigt, dann kann das neue Team nur dann fokussiert am neuen Feature arbeiten, wenn die Arbeit in den anderen Teams entsprechend de-priorisiert wird. Auch wenn wir uns entscheiden, kein neues Team für das neue Feature aufzusetzen, benötigen wir eine klare Priorität: In allen involvierten Teams sollte dann Arbeit am übergreifenden Feature eine möglichst hohe Priorität gegenüber den übrigen Team-Aufgaben haben, um geteilten Fokus zu vermeiden. So einfach diese Priorisierung klingt, so schwer tun sich viele Unternehmen damit, weil sie schmerzlich bewusst macht, dass man nicht alles gleichzeitig in hoher Geschwindigkeit entwickeln kann.
Wann baut man die Ziele/Aufgaben um die Teams und wann andersherum?
Wie so oft gibt es leider nicht die eine richtige Antwort auf die Frage, ob man die Strukturen den Zielen anpassen sollte oder andersherum. Aber wenn wir uns von alten Gewohnheiten (“wir hatten schon immer stabile Teams”) und Glaubenssätzen (“fluide Teams sind besser”) lösen, können wir Lösungen finden, die für unseren Kontext das beste Kosten-Nutzen-Verhältnis ergeben. Folgende Leitfragen können dabei helfen:
- Was ist unser Standard-Vorgehen: Passen wir eher die Strukturen an die Ziele an oder andersherum? Was sind die Vorteile, die wir dadurch erhalten? Was sind die Kosten?
- Wo befinden wir uns auf einem Spektrum zwischen sehr stabilen und sehr fluiden Teams? Haben wir mit sehr hohen Kosten durch Abhängigkeiten oder wiederholtes Teambuilding zu kämpfen?
- Wie würde das entgegengesetzte Vorgehen aussehen – wenn wir z.B. sehr stabile Teams haben und die Ziele weitgehend an die Strukturen anpassen, was würde es für uns bedeuten, sehr fluide Teams zu haben und die Strukturen an die Ziele anzupassen? Das kann man ja erst einmal als Gedankenexperiment durchspielen, um mehr Klarheit über Stärken und Schwächen und mögliche blinde Flecken zu erlangen.
- Wie sieht es bei uns mit dem Fokus auf wichtige, neue Features aus? Haben wir bei uns eine Tendenz, “Split Heads” zu produzieren? Was müssten wir tun, um das zu vermeiden?
Tiefer einsteigen
Arne und Stefan geben gemeinsam die Team of Teams-Schulung, in der neben dem hier beschriebenen Thema auch die Koordination von Teams über OKR, Engpass-Optimierung und Fluide Teams diskutiert werden. Weitere Infos: https://www.it-agile.de/schulungen/team-of-teams/
Stefan hat die vielen weiteren Überlegungen rund um das Thema in einem Buch beschrieben: „Innovative agile Teamkonzepte“
Es gibt außerdem ein kürzeres Whitepaper und Steckbriefe zu fluiden Teams, die helfen können, Strukturen an Ziele anzupassen, hier zum Download.
Über die Autoren
Arne Roock
Ich bin in einer kleinen Stadt in der Nähe von Hamburg aufgewachsen, wo ich meine zwei älteren Brüder nervte und mit sieben Jahren ein Klavier zerstörte.
Nach der Schule studierte ich Linguistik, ohne eine Ahnung zu haben, wie ich damit jemals Geld verdienen sollte. Ich fasste den großartigen Plan, in der Wissenschaft zu arbeiten, und beendete meine Doktorarbeit in einem sehr mühsamen Prozess, nur um herauszufinden, dass das überhaupt nicht der Job war, den ich wollte (und die Wissenschaft wollte mich auch nicht).
Obwohl ich dachte, Software und Wirtschaft seien langweilig, landete ich schließlich in einer Unternehmensberatung, und es stellte sich heraus, dass es mir wirklich gefiel. Nach einigen Jahren des Coachings und Trainings wurde ich von einem meiner Kunden eingestellt. Einige Jahre später begann ich für Spotify zu arbeiten, zog nach Stockholm, und hier bin ich nun und leite mein eigenes Beratungsunternehmen.
Stefan Roock
„Wir müssen immer wieder das Unmögliche versuchen, um das Mögliche zu erreichen.“ H. Hesse
E-Mail: stefan.roock@it-agile.de
LinkedIn: https://www.linkedin.com/in/StefanRoock/
Mein Name ist Stefan Roock und ich will eine bessere Arbeitswelt schaffen; eine in der Kunden von den Produkten und Services begeistert sind, Mitarbeitende ihre Arbeitsbedingungen lieben, Unternehmen erfolgreich sind und sich verantwortlich in der Gesellschaft verhalten. Ich helfe Menschen und Unternehmen dabei, ihre Potenziale für dieses Ideal zu entfesseln.
Ich verbreite und entwickle seit 1999 neue Arbeits- und Organisationsansätze in Deutschland. Das habe ich zunächst als Entwickler in agilen Teams, später als Scrum Master/Agile Coach und Product Owner getan. Ich habe seitdem mein Verständnis dessen, was für begeisternde Produkte und Arbeitsbedingungen notwendig ist, kontinuierlich weiterentwickelt. Besondere Produkte entstehen nicht dadurch, dass Teams „agil“ Anforderungen umsetzen. Stattdessen müssen Teams gemeinsam im direkten Kundenkontakt Produkte und Services gestalten.
Auf diesem Weg habe ich unter anderem die it-agile GmbH mitgegründet.