Das vierte Hands-on Agile Meetup über Liberating Structures für Scrum befasste sich mit dem Sprint Planning, genauer gesagt mit den Gründen, warum Sprint Plannings scheitern — trotz aller Anstrengungen, die im Vorfeld unternommen wurden, von Product Backlog Refinements bis zum Sprint Review.
🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter "Food for Agile Thought" anmelden und sich über 33.000 Abonnenten anschließen.
🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!
Liberating Structures, entwickelt von Keith McCandless und Henri Lipmanowicz, umfassen eine Reihe von einfach zu erlernenden, dennoch sehr produktiven Übungen zur Verbesserung der Zusammenarbeit in — nach Scrum-Standards auch (sehr) großen — Teams. Liberating Structures überwinden dabei traditionelle Kommunikationsansätze wie Präsentationen, vorstrukturierte Diskussionen oder ein weiteres unorganisiertes Brainstorming, bei dem die lautesten Teilnehmer die Oberhand gewinnen.
Liberating Structures eignen sich gut, um das Engagement der Teilnehmer von Scrum-Events zu verbessern und so die Art von Ergebnissen zu stimulieren, die für die Schaffung von lernenden Organisationen notwendig sind. Liberating Structures bieten auch ausgezeichnete Werkzeuge, um das Product Backlog Refinement oder die Definition von Done einer IT-Organisation zu verbessern.
Schließlich sind Liberating Structures ein großartiges Instrument, wenn größere Gruppen zu Retrospektiven, zur Selbstselektion von Teams oder zur Ermittlung der nächsten Schritte zur Umsetzung einer Produktstrategie zusammenkommen.
Der Zweck des Sprint Plannings ist es, die Arbeit für den kommenden Sprint in Zusammenarbeit mit dem gesamten Scrum Team zu planen.
Es gibt zwei Hauptthemen, die das Scrum-Team dabei adressieren sollte. Laut dem Scrum Guide beantwortet das Sprint Planning zwei Fragen:
What can be delivered in the Increment resulting from the upcoming Sprint?
How will the work needed to deliver the Increment be achieved?
Quelle: Scrum Guide.
Meiner Erfahrung nach wird ein erfahrenes Scrum-Team selten in Schwierigkeiten geraten, herauszufinden, wie man den Kunden einen Mehrwert bietet; eine sorgfältige Vorbereitung führt zu einem erfolgreicehn Sprint Planning, z.B. durch regelmäßige Product Backlog Refinements oder den Sprint Review.
Bei hinreichender Transparenz und Zusammenarbeit wird das Sprint Planning in den meisten Fällen bestätigen, was das Scrum-Team in den Wochen vor dem Sprint Planning bereits als Hypothese verwendet hat. So weit, so gut, hier gibt es nicht viel zu tun.
Dann gibt es jedoch die Fälle, in denen das Sprint Planning schief geht. Wenn das Scrum Team nicht in der Lage ist, ein Geschäftsziel in ein Sprint-Ziel zu verwandeln, welches durch die Implementierung einer Reihe von Product Backlog-Einträgen erreicht werden kann.
Die Frage ist, warum geschieht dies so spät im Prozess?
Es gibt zahlreiche Sprint Planning Anti-Muster, aber dasjenige, das einem schnell in den Sinn kommt, lässt sich am besten als "Garbage in, Garbage out" beschreiben. Daher bestand die erste Aufgabe für die vier Teams des Meetups darin, die wahrscheinlichsten Fehlerursachen während des Sprint Plannings unter Verwendung der 1-2-4-All Liberating Structures Mikrostruktur zu identifizieren.
Während der 1-2-4-All-Übung kamen alle vier Teams zu einer sehr ähnlichen Einschätzung der Fehlerursache: “It’s the Product Backlog, stupid!”
Team 1:
Team 2:
Team 3:
Team 4:
Die Ergebnisse der vier Teams waren ähnlich: Erfolgreiche Sprint Plannings hängen von einem gut vorbereiteten, umsetzungsfähigen Product Backlog ab. Ein erfolgreiche Scrum-Team hat diese schwere Arbeit bereits während des Product Backlog Refinements geleistet.
Was uns zur nächsten Aufgabe führt: herauszufinden, was erforderlich ist, um ein gut vorbereiteten, umsetzungsfähigen Product Backlog zu erstellen.
Die zweite Aufgabe des Abends — die Identifizierung der Voraussetzungen für umsetzbare Product Backlogs — führte uns zu einer neuen Mikrostruktur der Liberating Structures: Die Min Specs. Der Zweck der Min Specs ist es, Prozesse und Praktiken auf das absolute Minimum zu reduzieren, welches dennoch das Ziel erreichen würde:
“What is made possible? By specifying only the minimum number of simple rules, the Min Specs that must ABSOLUTELY be respected, you can unleash a group to innovate freely. Respecting the Min Specs will ensure that innovations will be both purposeful and responsible. Like the Ten Commandments, Min Specs are enabling constraints: they detail only must dos and must not dos. You will eliminate the clutter of nonessential rules, the Max Specs that get in the way of innovation. Often two to five Min Specs are sufficient to boost performance by adding more freedom AND more responsibility to the group’s understanding of what it must do to make progress. Out of their experience in the field, participants shape and adapt Min Specs together, working as one. Following the rules makes it possible for the group to go wild!”
Quelle: Liberating Structures: Min Specs — Specify Only the Absolute “Must dos” and “Must not dos” for Achieving a Purpose (35-50 min.)
Dies sind die Vorschläge, die die Teams erarbeitet haben:
Team 1:
Positiv:
Negativ:
Team 2:
Positiv:
Negativ:
Team 3:
Positiv:
Negativ:
Normalerweise hätten wir die einzelnen Teamergebnisse zu einem Gruppenergebnis zusammengefasst. Da es hierfür keine geeignete Flächen im Veranstaltungsort gab und die Zeit langsam knapp wurde, haben wir diesen Teil jedoch übersprungen.
Übrigens, wenn Sie das Ergebnis des vierten Teams vermissen, dies geht mir ebenfalls so. 🤦♂️
Liberating Structures-Strings wirken Wunder, wenn Sie kritische Themen ansprechen müssen, welche die Einbeziehung aller erfordern und jedem eine Stimme in einer sicheren Umgebung geben sollen. Die vier Teams kamen zu Recht zu dem Schluss, dass eine erfolgreiche Sprint-Planung hauptsächlich von einem gut gepflegtem Product Backlog abhängt. Sie untersuchten daher folglich die Mindestanforderungen für ein derartiges Product Backlog, welche für die meisten Scrum-Teams gelten könnten.
Welche Erfahrungen haben Sie mit Liberating Structures gemacht, um Scrum-Events zu verbessern? Bitte teilen Sie uns dies in den Kommentaren mit.
Der nächste Artikel über Liberating Structures für Scrum befasst sich mit der Verfeinerung des Product Backlogs. Bleiben Sie dran!
📅 Professional Scrum Master Training PSM I + Liberating Structures — Berlin, 18-20 Februar 2020.
Liberating Structures für Scrum (1): Die Sprint Retrospektive.
Liberating Structures für Scrum (3): Das Product Backlog.
Erleben Sie mit uns eine spannende Liberating Structures Schulung für Scrum am 6. Juli 2019 in Berlin. Wir werden mehrere Mikrostrukturen erforschen, zu Zeichenketten verflechten und diese auf Scrum-Events wie das Daily Scrum, den Sprint Review oder die Sprint Retrospektive anwenden. Die Workshop-Sprache ist Englisch.
Sie können sich Ihren Platz für Scrum-Schulungen, Workshops und Meetups direkt sichern, indem Sie dem entsprechenden Link in der Tabelle unten folgen:
Alle kommenden Professional-Scrum-Klassen finden Sie hier.
Sie können Ihren Platz für die Schulung direkt buchen, indem Sie den entsprechenden Links zum Ticketshop folgen. Sollte der Beschaffungsprozess Ihrer Organisation einen anderen Einkaufsprozess erfordern, wenden Sie sich bitte direkt an die Berlin Product People GmbH.
Scrum Master Tasks: Join the 2024 Survey Now! TL; DR: Scrum Master Tasks: Let's Bust…
In Kürze: Scrum Master Interviewfragen zur Wertschöpfung mit Scrum Wenn Sie in Ihrem Unternehmen eine…
In Kürze: Das Product Operating Model & Scrum Lassen Sie uns Marty Cagans Einblicke in…