Kolumne

Groß und (Fr)agil: Lassen sich Retrospektiven skalieren?

Timo Becker, Christoph Niemann

(c) Shutterstock / eelnosiva

Sprint-Reviews und Retrospektiven – diese beiden Regel-Meetings aus der Scrum-Welt lassen sich nicht ohne weiteres auf große Agile-Projekte übertragen. Wie man dennoch auch in großen Szenarien die gewünschten Effekte der regelmäßigen Reviews erzielen kann, ist heute das Thema unserer Kolumnisten Christoph Niemann und Timo Becker.

Groß und (Fr)agil?

Vielleicht kennen Sie die Situation: Man startet agil und alles läuft gut – bis das Team wächst und das Produkt von mehreren Scrum-Teams entwickelt wird. Schnell steht der agile Protagonist auf unbekanntem Terrain: Wie skalieren Product-Owner, Aufgabenverteilung und teamübergreifende Abstimmungen? In dieser Kolumne wollen wir erprobte Lösungspraktiken und Patterns aus bekannten Skalierungs-Frameworks aufzeigen. Heute geht es darum, wie Sie Wissen effizient zwischen vielen Menschen und teamübergreifend austauschen.

Gedränge am Rückspiegel

Zum Ende eines Sprints sieht Scrum zwei Regelmeetings vor: In den Sprint-Reviews geht es um die inhaltlichen Ergebnisse des Sprints, in den Retrospektiven um die Art der Zusammenarbeit im Team. Beide skalieren nicht unendlich. Da sie verschiedene Ziele verfolgen, unterscheiden sich die Lösungen, die sie an die Arbeit mit mehreren Teams anpassen:

Basar-Review

Sprint-Reviews skalieren nach unserer Erfahrung nur bedingt.

Im Sprint-Review stellen Teams ihre umgesetzten User-Storys vor, der PO nimmt sie ab, interessierte Stakeholder können sich informieren und dem Team direkt Fragen stellen. Diese Art von Review skaliert nach unserer Erfahrung nur bedingt: Ein Review von Inkrementen mehrerer Teams braucht viel Zeit. Es bindet die anwesenden Stakeholder und Teammitglieder in einem zu langen Treffen.

In einem Bazar-Review zeigt jedes Team seine umgesetzten Stories an einem eigenen Stand. So sehen Besucher und PO das Product Increment des abgelaufenen Sprints in einer Gesamtschau. Der PO geht während des Bazar-Reviews von Stand zu Stand und nimmt die Storys des jeweiligen Teams ab. Interessierte Stakeholder und Teammitglieder besuchen die Teams, deren Stories sie interessieren. Durch den Bazar-Stil können sich alle Beteiligten interessenbezogen – und damit effizient – informieren. Gleichzeitig schafft der PO eine große Anzahl an User-Storys von unterschiedlichen Teams, ohne dass andere Teilnehmer sich an seinen Zeitplan anpassen.

In Retrospektiven reflektieren die Mitglieder von Scrum-Teams Erfahrungen aus der letzten Iteration, diskutieren positive wie negative Aspekte der Zusammenarbeit und leiten konkrete Maßnahmen für den kommenden Sprint ab. So lösen sie eins der Versprechen der agilen Softwareentwicklung ein: Abläufe kontinuierlich adaptieren und verbessern. In großen agilen Projekten kommt zu teaminternen Prozessen die Zusammenarbeit zwischen den Teams als zweite Dimension hinzu. Es gibt verschiedene, sich teils ergänzende Möglichkeiten, wie sich die Mitglieder verschiedener Teams austauschen können:

  • An einer Joint Retrospective nehmen Vertreter aus jedem Team, der PO des Produktes sowie die Scrum-Master aller Teams teil. Sie sprechen über Themen, die alle Mitglieder betreffen, zum Beispiel gemeinsames Lernen, die Zusammenarbeit zwischen den Teams, die Rolle des PO oder teamübergreifende Strukturen wie die Communities of Practice. Eine solche Retrospektive ist besonders dann sinnvoll, wenn die Teams nicht isoliert arbeiten sondern große Berührungsflächen haben.
  • An einer Retrospective of Retrospectives nehmen einzelne Vertreter aus jedem Team teil. Sie diskutieren über Probleme und Maßnahmen, die die Teams in ihren eigenen Retrospektiven identifiziert bzw. festgelegt haben. Im Gegensatz zur Joint Retrospective liegt der Fokus damit nicht auf teamübergreifenden Prozessen, sondern auf dem Austausch über die Prozesse und Probleme in den Teams. Ziel ist, team-interne Maßnahmen zu ergänzen, zu verbessern, zu re-priorisieren oder durch andere Teams zu unterstützen.
  • An einer Projekt-Retrospektive nehmen alle Mitglieder aus allen Teams teil. Dabei werden Techniken wie Storytelling und Open-Space eingesetzt, um zunächst den Projektverlauf zu reflektieren. Anschließend diskutieren die Teilnehmer Themen, die als Problemzonen aufgefallen sind. Schließlich werden die Ergebnisse konsolidiert, priorisiert und in Maßnahmen für die nächsten Sprints übersetzt. Ein solches Event bietet sich insbesondere zum Abschluss eines größeren Teilziels oder eines Epics an. Da alle Teammitglieder daran teilnehmen und sich direkt einbringen können, fördert die Projekt-Retrospektive das Teambuilding und die Identifikation mit dem Produkt.

Ergebnisse der team-übergreifenden Retrospektiven werden in einem zentralen Impedimentboard verwaltet. Es macht teamübergreifende Hindernisse sichtbar – als erster Schritt, um sie für alle zu beseitigen. Ein klassisches Kanban-Board eignet sich hier besser als ein Scrum-Board: Durch die Work-in-Progress-Limitierung und den Fokus auf maximalen Durchsatz werden identifizierte Probleme schnell angegangen und beseitigt.

Welche Erfahrungen haben Sie mit Retrospektiven und Reviews in großen Agile-Projekten gemacht? Was funktionierte gut, was weniger gut? Wir freuen uns auf Ihre Kommentare!

Groß und (fr)agil?

In der Kolumne Groß und (fr)agil? stellen Christoph Niemann und Timo Becker (MaibornWolff) Lösungsansätze vor, um agile Entwicklung auf große Szenarien zu skalieren. Ganz nach dem Motto: Groß und agil – das muss kein Widerspruch sein!

Bisher erschienen:

Aufmacherbild: elephant running across a tightrope von Shutterstock / Urheberrecht: eelnosiva

 

Geschrieben von
Timo Becker
Timo Becker
Timo Becker ist Software-Ingenieur bei MaibornWolff und entwickelt aktuell Individual-Software in einem großen agilen Projekt.
Christoph Niemann
Christoph Niemann
Christoph Niemann ist IT-Consultant bei MaibornWolff. Er arbeitet am liebsten im agilen Requirements-Engineering an der Schnittstelle zwischen Fachbereich und Entwicklungsteam. Mit seiner agilen Erfahrung, besonders mit Scrum, hilft er Projekten beim Umbau vom Wasserfallmodell auf ein iteratives Vorgehen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: