Ultimative Anleitung: Wie du Liberating-Structures nutzt, um Austausch und Zusammenarbeit im Sprint-Planning wiederzubeleben

Keiner beteiligt sich am Sprint-Planning? Es mangelt an Diskussion und Austausch unter den Entwicklern? Das Sprint-Planning verkommt zu einem Pflichtmeeting, das jeder schnell hinter sich bringen will?

Wenn dir das bekannt vorkommt, können wir das ändern. Zur Wiederbelebung des Sprint-Plannings sind Liberating-Structures ideal. Sie ermöglichen, dass sich jedes Teammitglied einbringen kann. Sie fördern den Austausch zwischen den Mitgliedern. Zudem bringen sie Bewegung ins Scrum Team (im wahrsten Sinne des Wortes).

Betrachten wir eine einfache Agenda für ein Sprint-Planning:

• Warm-up
• Ein Sprint-Ziel finden
• Product-Backlog-Einträge für den Sprint auswählen
• Task-Break-Down für die Einträge des Sprint-Backlogs
• Abschluss und nächste Schritte

Im Folgenden stelle ich dir für jeden Punkt auf der Agenda eine Liberating-Structure vor, die du nutzen kannst.

Eine Anmerkung: Das ganze Sprint-Planning nur mit Liberating-Structures zu gestalten, könnte dein Team überfordern. Die Interaktion, die durch Liberating-Structures entsteht, kann zu Beginn ungewohnt sein. Ich rate dir, behutsam vorzugehen und mit einem oder zwei Punkten auf der Agenda zu beginnen. Im nächsten Sprint-Planning kannst du dann weitere Liberating-Structures ergänzen.

Lass uns mit dem Warm-up beginnen:

Was ist der Unterschied zwischen einer Gruppe und einem Team?

Ein Team vereint ein gemeinsamer Zweck; die Mitglieder haben eine Mission oder wollen ein langfristiges Ziel erreichen.

Das Ziel für den Sprint ist hierbei der nächste kleine Schritt.

Kaum etwas funktioniert besser, als diese Suche nach dem nächsten Schritt mit der Frage nach dem gemeinsamen Purpose des Teams einzuleiten. Um diesen Purpose zu finden, hilft die Liberating-Structure „9 Whys“.

Hier die Schritte im Detail:

• Paare bilden: Bitte die Mitglieder deines Scrum Teams, Paare zu bilden.
• Vorstellung: Eine Person des Paares stellt die Tätigkeit des Teams vor: „Was macht unser Scrum Team?“
• Erforschen: Die andere Person versucht mit mehrfachen Warum-Fragen die Gründe und die Wichtigkeit dieser Aufgabe zu erforschen: „Warum ist diese Tätigkeit wichtig?“ Haltet dabei, falls nötig, die Antworten schriftlich fest.
• Rollen tauschen: Nach 5 Minuten werden die Rollen in den Paaren getauscht.
• Ergebnisse teilen: Bitte nun jeweils zwei Paare, ihre Erkenntnisse und Ergebnisse miteinander zu teilen. Lade dazu ein, auf Gemeinsamkeiten zu achten.

Zwei Bemerkungen zu den Warum-Fragen:

1. Es müssen hierbei nicht 9 Fragen gestellt werden, sondern nur so viele, wie in 5 Minuten möglich sind.
2. „Warum?“ kann auch durch „Wozu?“ oder später durch „Was noch?“ ersetzt werden.

Das Gespräch zum Purpose des Teams lässt sich gut in ein Gespräch über das Ziel des Sprints überleiten.

Ich habe über Jahre die Liberating-Structure „1-2-4-All“ in Scrum Teams genutzt, um ein Sprint-Ziel zu definieren.

Das Vorgehen habe ich in diesem Beitrag ausführlich beschrieben. Heute möchte ich dir eine Alternative vorstellen: „25/10 Crowdsourcing“.

Der Vorteil von „25/10 Crowdsourcing“ gegenüber „1-2-4-All“ ist, dass die Teammitglieder ihre Ideen für Sprint-Ziele anonym ausarbeiten können. Dies kann manchmal sehr hilfreich sein, wenn du Ideen unabhängig vom Ideengeber betrachten willst.

Hier die Schritte von „25/10 Crowdsourcing“ im Detail:

1. Sammeln: Jeder in der Gruppe schreibt seine Idee für ein Sprint-Ziel auf eine Karteikarte.
2. Tauschen von Karten: Anschließend wandern die Mitglieder des Scrum Teams umher, tauschen ihre Karten aus und lesen diese kurz durch.
3. Bewerten der Ideen: Wenn die Glocke läutet, hören die Teammitglieder auf, die Karten weiterzureichen. Jeder bewertet nun für sich das Sprint-Ziel auf der Karteikarte in seiner Hand auf einer Punkteskala von 1 bis 5 (1 für wenig lohnenswert, 5 für sehr lohnenswert) und schreibt die Zahl auf die Rückseite der Karte.
4. Wiederholtes Tauschen der Karten: Wenn die Glocke das nächste Mal ertönt, werden die Karten ein zweites Mal weitergereicht, bis sie wieder läutet und der Bewertungszyklus sich wiederholt. Insgesamt werden so fünf Runden absolviert.
5. Auswertung der Ideen: Nach der fünften Runde zählen die Mitglieder im Team die fünf Punktzahlen der Karte in ihrer Hand zusammen und notieren den Wert. Anschließend wird das Sprint-Ziel mit den höchsten Punktzahlen identifiziert und mit der gesamten Gruppe geteilt.

Eine Bemerkung: Es hat sich für mich bewährt, dem Product-Owner im Team ein Vetorecht zu geben. Der Product-Owner bestimmt das finale Sprint-Ziel, da er auch die Verantwortung dafür trägt. „25/10 Crowdsourcing“ hilft jedoch dabei, zunächst unvoreingenommen viele Ideen für Sprint-Ziele zu generieren.

Nachdem das Scrum Team ein Sprint-Ziel definiert hat, kommen wir zur Erstellung des Sprint-Backlogs.

Manche Scrum Teams übertragen im Sprint-Planning viel mehr Einträge ins Sprint-Backlog, als sie jemals umsetzen können.

Aus Sicht von Scrum spricht nichts dagegen. Ziel des Sprints ist es nicht, jeden Eintrag des Sprint-Backlogs zu implementieren. Allerdings habe ich bereits mehrfach die Erfahrung gemacht, dass diese Praxis demotivierend sein kann. Sprints verwässern dadurch, und das Gefühl von Fortschritt bleibt auf der Strecke, wenn das Ergebnis am Ende des Sprints lautet: 12 von 23 Einträgen fertiggestellt.

Eine Möglichkeit, damit sich das Scrum Team nur auf absolut notwendige Einträge des Product-Backlogs einigt, stellt die Liberating-Structure „Min Spec“ dar.

Hier die Schritte von „Min Spec“ im Detail:

• Gemeinsames Ziel benennen: Wiederhole das Ziel dieses Sprints, um den nötigen Fokus zu schaffen.
• Maximale Liste generieren: Erstelle eine Liste aller möglichen Einträge, an denen das Team im Sprint arbeiten könnte, um dem Sprint-Ziel näher zu kommen. Diese „maximale Liste“ erhältst du, indem du das Team fragst: „Welche Einträge des Product-Backlogs sollten wir umsetzen, damit wir unser Sprint-Ziel erreichen können?“
• Auf „Min Spec“ reduzieren: Nicht alle Einträge der maximalen Liste sind unverzichtbar, um das Sprint-Ziel zu erreichen. Diese unverzichtbaren gilt es, zu finden, indem das Team die maximale Liste Eintrag für Eintrag auf dessen absolute Notwendigkeit prüft. Frage das Team: „Wenn wir alle Einträge bis auf diesen umsetzen, können wir dann unser Sprint-Ziel erreichen?“

Eine Bemerkung: Der letzte Schritt ist häufig mit viel Diskussion zwischen den Entwicklern verbunden. Damit die Diskussion nicht ausufert, vereinbare vorab mit dem Team, wie die Entscheidung endgültig getroffen werden soll. Soll es eine Mehrheitsentscheidung der Entwickler sein? Soll es einstimmig beschlossen werden? Entfernen wir den Eintrag aus dem Sprint-Backlog, wenn niemand einen Einwand vorbringt?

Nachdem sich das Scrum Team auf die Einträge verständigt hat, die das Sprint-Ziel realisieren könnten, gilt es, diese besser zu verstehen:

Der primäre Einsatzzweck von „Shift & Share“ ist es, langweilige Präsentationen aufzulösen, bei denen nur einer spricht und alle anderen zuhören müssen.

Der Task-Break-Down eines Eintrags des Product-Backlogs ist leider manchmal mit einer solchen Präsentation vergleichbar. Ein Entwickler macht Notizen in Jira und die restlichen Entwickler sehen ihm über die Schulter.

Wäre es nicht produktiver, wenn die Entwickler sich in kleine Gruppen aufteilen und parallel die einzelnen Einträge detaillieren?

Die Antwort auf diese rhetorische Frage lautet: ja. Die Frage ist eher, wie das gelingen kann. Die Antwort darauf ist die Liberating-Structure „Shift & Share“.

Hier die Schritte von „Shift & Share“ im Detail:

1. Beschreibung des Vorgehens: Kleingruppen werden von Station zu Station wandern. An jeder Station finden sie einen Eintrag des Sprint-Backlogs. In der Kleingruppe haben sie Zeit, diesen Eintrag zu besprechen und in Tasks aufzuteilen.
2. Benennung der Präsentatoren: Pro Station wird am Ende der Bearbeitungszeit ein Präsentator gewählt.
3. Vorstellung der Stationen: Jede Kleingruppe, bis auf den Präsentator, wechselt im Uhrzeigersinn zur nächsten Station. Dort stellt der Präsentator die bisherige Arbeit vor, und die Mitglieder der Kleingruppe diskutieren, detaillieren und teilen den Product-Backlog-Eintrag weiter auf.
4. Wechsel der Stationen: Nach der Präsentation wechselt die Gruppe die Station. Dies wird so lange wiederholt, bis jede Gruppe alle Stationen besucht hat.

Eine Bemerkung: Zu Beginn ist „Shift & Share“ etwas ungewohnt. Häufig wenden Entwickler ein, dass sie gemeinsam den Eintrag runterbrechen müssen, um das gleiche Verständnis zu erreichen. Bitte sie, es einmal auszuprobieren. Am Ende von „Shift & Share“ hatte jeder im Team die Möglichkeit, an jedem Eintrag zu arbeiten. Nur mit dem Unterschied, dass er durch die kleinen Gruppen mehr einbezogen war.

Wenn sich durch den Task-Break-Down keine neuen Erkenntnisse ergeben, ist das Sprint-Ziel nicht anzupassen. Nach einem finalen Roman-Voting steht fest, ob jeder hinter dem Ziel des Teams steht. Wenn dies der Fall ist, ist das Sprint-Planning eigentlich zu Ende. Oder doch nicht? 

Aus meiner Sicht sollte ein Sprint-Planning hier nicht enden, sondern mit einem konkreten ersten Schritt. Jeder Entwickler sollte wissen, woran er nun arbeiten will.

Hierbei hilft uns die Liberating-Structure „15-%-Lösung“. Hier die Schritte im Detail:

1. Vorstellung des Ziels: Wiederhole das Ziel für den Sprint.
2. Persönliche Reflexion: Nun überlegt jedes Mitglied im Team, woran es als erstes arbeiten sollte, um dem Ziel des Teams näher zu kommen. Das sind die „15 %“. „100 %“ bedeutet, dass das Sprint-Ziel erreicht ist. Die „15 %“ könnten beispielsweise ein erster Task aus dem Sprint-Backlog sein.
3. Vorstellung der „15 %“: Jedes Mitglied des Teams stellt seine erste Arbeit vor. Die anderen Mitglieder beraten das Teammitglied, indem sie Nachfragen stellen und Ratschläge zur Umsetzung geben oder die Mitarbeit anbieten.

Eine Bemerkung: Wenn du dich bereits länger mit Liberating-Structures beschäftigst, wird dir nicht entgangen sein, dass ich die „15-%-Lösung“ abgewandelt habe. Die Aufgabe muss nicht unabhängig und ohne die Hilfe durch andere im Team umgesetzt werden. Wäre das für jeden Task möglich, wozu bräuchten wir dann ein Team? Diese Variante der „15-%-Lösung“ hilft dem Scrum Team, direkt nach dem Sprint-Planning mit einem gemeinsamen Plan in die Implementierung zu starten.

Wenn du mehr darüber lernen willst, wie du Liberating-Structures oder andere Techniken zur Moderation in Scrum Teams nutzen kannst, empfehle ich dir den Besuch des „Professional Scrum mit Facilitation“-Trainings. Unter der Anleitung von Marc Kaufmann und mir hast du einen Tag lang die Möglichkeit, Techniken und Methoden rund um die Moderation der Scrum Events zu lernen.

Ach, und vergiss nicht, in die Kommentare zu schreiben, ob du bereits Liberating-Structures in Scrum Events nutzt. Wenn ja, interessiert mich brennend, welche ...