Fluid Scrum – ein Experiment

von Bettina Kuchenbuch

| zuletzt aktualisiert am 23.03.2023

|
• New Work

Die Ausgangslage

Für einen langjährigen Kunden sind wir mit zwei Entwicklungsteams unterwegs.  Beide Teams zusammen bestehen aus insgesamt 9 Developer:innen in einem guten Verhältnis aus langjähriger Zugehörigkeit und einigen Neuzugängen. Sie teilen sich Scrum Master und Product Owner.

Team A kümmert sich um die Produktweiterentwicklung und arbeitet nach Scrum; es hat gerade das Minimum Viable Product  (MVP) des maßgeblichen Produktziels "Redesign mit technischem Relaunch" live gebracht. Für die Zukunft bedeutet dies: Die nächsten Schritte in der Produktentwicklung werden deutlich kleiner ausfallen und das geschaffene Inkrement muss weiterentwickelt und gepflegt werden.

Team B ist zuständig für Tagesgeschäft, Wartung und zumindest theoretisch für die Entwicklung kleinerer Features, was aber aufgrund der hohen Auslastung meistens zu kurz kommt. Dieses Team (B) organisiert seine Arbeit mit Hilfe eines Kanban-Boards. Es macht regelmäßige Retrospektiven und nimmt gemeinsam mit Team A an den Review-Meetings mit dem Kunden teil. Allerdings ist der Anteil an sichtbarer Arbeit von Team B gering, sie halten eher Team A den Rücken frei.

Herausforderung und Fragestellung

Das MVP ist also nun live und das nächste Produktziel fällt weniger umfangreich aus. Daneben gibt es den Wunsch, Team B zu entlasten und das durch die Arbeit am letzten Produktziel gewonnene Wissen zu teilen.

Die komplexe Frage, die sich mir als Scrum Masterin nun stellte, war: 

Im engen Austausch mit der Product Ownerin und der kollegialen Fallberatung sind wir nach und nach zu der folgenden Erkenntnis gelangt:

Hypothese

Die Teams haben einen hohen agilen Reifegrad und können den beschriebenen Herausforderungen durch sprintbasierte flexible Teamaufteilungen begegnen. Dadurch wird dauerhaft Wissen geteilt und Unzufriedenheit aufgrund von einseitiger Arbeit vorgebeugt.

Planung

Damit diese – zugegeben etwas steile – Hypothese sich erfüllen konnte, mussten zwei Dinge gleichzeitig passieren: Das zukünftige Team (also die Vereinigung aus den Teams A und Team B) musste für die Neuerungen begeistert und das Experiment gut vorbereitet werden, um eine Chance auf Erfolg zu haben. 

Dass es zunächst wirklich nur ein Experiment sein sollte, stand für uns von Anfang an fest. In unserer Auffassung von Agilität braucht es unbedingt den Mut, etwas Neues zu wagen, aber gleichzeitig bedarf es auch Mutes,  etwas für gescheitert zu erklären.

Für die Planung haben uns Willem-Jan Agelings Ausführungen sehr weitergeholfen. Es tat gut zu lesen, dass andere bereits ein solches Modell, wie wir es uns vorstellten, gedacht hatten und dass das Kind sogar einen Namen hatte: Fluid Scrum. 

Im wöchentlich stattfindenden Teamaustausch-Meeting haben wir dann unsere Idee präsentiert und sind auf sehr interessierte, neugierige, aber auch kritische Meinungen gestoßen. Vieles wurde direkt diskutiert, andere Unsicherheiten und Fragestellungen nochmal mitgenommen. Alles in allem ein guter Pitch, was für eine Erleichterung!

Nach wiederholten Diskussionen im Team und mit Einzelpersonen, verschiedensten Visualisierungen in Miro und einer schwierigen Terminsuche in Outlook wurde irgendwann klar, dass gute Vorbereitung und Planung das eine ist. Andererseits sollte man nicht allzu lange mit dem Startschuss warten, um die anfängliche Motivation und Energie nicht liegen zu lassen. Daher fiel die Entscheidung, im April mit unserem ersten fluiden Scrum Sprint zu starten.

Um eine gute Basis für eine zukünftige Zusammenarbeit zu legen, haben wir  Meetings  für die gemeinsame Erarbeitung einer Definition of Done und des nächsten Produktziels durchgeführt, die auf das gemeinsame Verständnis und Commitment eingezahlt haben.

Durchführung

Da unser gesamtes, ab nun vereintes Team während der Pandemie die meiste Zeit auf "full remote" umgestellt hatte, sind alle im folgenden beschriebenen Scrum Events virtuelle  Termine. Da sich der Sprintablauf nicht wesentlich von dem in einem nicht fluiden Scrum unterscheidet, gehe ich im Folgenden nur auf die Unterschiede ein und fange beim Sprint an:

Sprint: 

Die Sprintlänge wurde von bisher zwei Wochen auf vier Wochen verlängert. Diese Anpassung hatte nichts direkt mit der Umstellung auf Fluid Scrum zu tun, will aber hier auch erwähnt sein.

Planning: 

Das Planning beginnt gemeinsam mit allen, also den Developer:innen, mir als Scrum Masterin und unserem PO. Der PO stellt seine mitgebrachten Sprintziele vor und das Team betrachtet gemeinsam, welche Tickets auf die jeweiligen Ziele einzahlen. Die Developer:innen überlegen sich im Anschluss, an welchem Sprintziel sie mitarbeiten wollen. Dabei ist es nicht nur wichtig zu betrachten, wo sie ihr vorhandenes Wissen am besten einbringen können, sondern auch, wo sie neues Wissen aufbauen können. 

Weitere Fragestellungen sind, ob die Crossfunktionalität für die Bearbeitung des Sprintziels gegeben ist und ob die Teams für die Qualitätssicherung mittels Code Reviews gut aufgestellt sind. Wenn die fluiden Subteams geformt sind, geht es zum detaillierten Planning der einzelnen Sprints in Breakout Sessions weiter in die Subteams, wo sich ab jetzt nichts mehr von den herkömmlichen Sprint Plannings unterscheidet. Nach dem Planning-Termin starten die Teams in die Arbeit ihrer für die Dauer eines Sprints festgelegten fluiden Teams. 

Dailies: 

Es gibt pro fluidem Team ein Daily, wobei aus jedem Team ein:e Vertreter:in an den anderen Terminen teilnimmt, um evtl. Abhängigkeiten und Schnittstellen zwischen den Subteams zu identifizieren und abzusprechen. Die Dailies sind zeitlich direkt hintereinander terminiert. In der Regel nehmen bei uns Product Owner und Scrum Masterin daran teil. Die Dailies sind bei uns auch der Ort, an dem der PO die Möglichkeit hat, kurzfristig anfallende Arbeit mitzubringen, die bei der Sprintplanung nicht berücksichtigt werden konnte. Gemeinsam wird überlegt, welches fluide Team diese Aufgaben und die entsprechenden Tickets in der Fastlane auf dem Sprint Board übernimmt.

Review: 

Am Review hat sich formell insofern nichts geändert, als dass wir es bereits vorher mit beiden Teams gemeinsam durchgeführt haben. Inhaltlich hat es sich aber durch die Fokussierung auf die Sprintziele verbessert, da sich der geschaffene Wert dadurch viel deutlicher einordnen lässt.

Retrospektive: 

Gestartet sind wir mit einer Retrospektive pro fluidem Team, um dann nach zwei Iterationen festzustellen, dass die enge Zusammenarbeit zu einer hohen thematischen Redundanz führt. Daher machen wir die Retrospektive aktuell mit dem gesamten Team, was sich bisher gut und richtig anfühlt und bei einer aktuellen Teamgröße von 11 Personen (inklusive Scrum Master und PO) noch darstellbar ist.

Refinement: 

Das Refinement ist zwar kein Scrum Event im herkömmlichen Sinn, aber da wir es in Form eines Regeltermins vornehmen, gehe ich an dieser Stelle darauf ein. Weil im Vorfeld nicht feststeht, wer bzw. welches fluide Team am Ende eine Aufgabe im Sprint umsetzt, finden unsere Refinements in der Regel mit dem Gesamtteam statt. Im Refinement werden die Tickets vorgestellt und konkretisiert, die Akzeptanzkriterien festgelegt und vorab bekannte technische Hinweise niedergeschrieben. Im Anschluss wird die Komplexität einer Aufgabe in Story Points mittels Planning Poker eingeschätzt. Bei Bedarf gibt es weitere Refinement-Prozesse im laufenden Sprint, an denen dann nicht mehr alle Devs, sondern eine repräsentative Gruppe teilnimmt.

Beobachtungen

Nach fünf Sprints kristallisiert sich eine Velocity in Story Points heraus, die sich aufgrund der flexiblen Teameinteilung nur auf das Gesamtteam beziehen kann. Auch wenn sich diese in den nächsten Sprints garantiert noch konsolidieren wird, ist bereits jetzt eine bessere Planbarkeit gegeben. 

Von den fünf Sprints haben drei mit je zwei fluiden Teams, einer mit drei und einer mit dem Gesamtteam stattgefunden. In dem Sprint mit den drei Teams hat ein Miniteam von nur zwei Entwicklern ein Thema maßgeblich vorantreiben können, das in einem herkömmlichen Sprint wahrscheinlich keine Priorität bekommen hätte– ein klarer Vorteil des Fluid Scrum. Diese Möglichkeit einer sehr gekapselten Themenbearbeitung als ein Sprintziel werden wir mit Sicherheit öfter nutzen.

Überhaupt hat sich herausgestellt, dass gut formulierte Sprintziele in vielfacher Hinsicht einen Schlüsselfaktor darstellen: Sie helfen bei der Planung und erleichtern den Prozess der Teamaufteilung in die fluiden Teams zu Beginn eines Plannings. Auch bei der Fokussierung im Laufe eines Sprints und bei der Einordnung im Review setzen die Ziele die Leitplanken. Aus meiner Perspektive völlig zurecht hat die letzte Version des Scrum Guides den Fokus auf das Sprintziel durch die Verknüpfung mit dem Artefakt Sprint Backlog geschärft.

Die vielleicht größte Unsicherheit gibt es momentan noch im Umgang mit den Refinement-Aktivitäten. Wenn zum Zeitpunkt des Refinements noch nicht feststeht, in welchem Sprint und unter welcher Beteiligung die Arbeit später umgesetzt wird: Wie können wir sicherstellen, dass genau die richtigen Menschen beteiligt werden? 

Schlussfolgerung

Am Ende des fünften Fluid Scrum Sprints sind wir optimistisch, dass unser Experiment erfolgreich war und wir mit Fluid Scrum eine bedarfsorientierte Praxis etablieren werden. Die Unsicherheiten, die auftreten, sind gut handelbar. Sie helfen uns sogar, aufmerksam zu bleiben und den Prozess im Sinne von Inspect & Adapt stetig zu verbessern. 

So ziehen wir folgendes Fazit:

• Fluid Scrum war für unsere anfangs beschriebenen Herausforderungen ein gutes Werkzeug, um Weiterentwicklung und Pflege unter einen Hut zu bekommen. 

• Auch beim Thema Wissenstransfer haben wir durch die pro Sprint neu zusammengesetzten Teams Fortschritte verzeichnen können. 

• Es macht Spaß zu erleben, dass die Teams sehr eng und auf einem höheren Level als vorher selbst organisiert zusammenarbeiten

• Fluid Scrum funktioniert für uns!