1 Jahr agil (Teil 2): Inspect & Adapt

Seit gut einem Jahr beschäftige ich mich intensiv mit agiler Software-Entwicklung – vor allem Scrum, worin ich seit Januar auch zertifiziert bin. Ab November steht mir eine neue Herausforderung bevor. Grund für eine persönliche Retrospektive:

Welche Erfahrungen nehme ich aus den letzten Monaten mit?

Teil 2: Inspect & Adept

Agile Software-Entwicklung bedeutet nicht nur permanente Verbesserung des Produktes sondern auch die kontinuierliche Verbesserung der Zusammenarbeit und des Entwicklungsprozesses. In Sprint- und Prozess-Retrospektiven sollten geeignete Maßnahmen dazu erarbeitet werden. Im Scrum-Kontext ist das die Aufgabe des Scrum Masters.

Unterschiedliche Methoden ausprobieren

Die Art und Weise wie Retrospektiven moderiert werden, sorgt dafür, dass ganz unterschiedliche Aspekte der eigenen Arbeit und der Zusammenarbeit überdacht werden. Es bietet sich daher an, verschiedene Methoden auszuprobieren.
Ich habe außer mit dem Scrum-Klassiker (“Was lief gut? Was können wir besser? Was liegt nicht in unserer Hand?”) gute Erfahrungen mit Glad-Sad-Mad und dem Happiness-Index gemacht. Die Pain-Snake führte in meinen Teams zu größeren Diskussionen, da hier befürchtet wurde, dass die Zusammenarbeit zwischen verschiedenen Teams oder gar einzelne Mitarbeiter angeprangert werden könnte.

Eigene Methoden entwickeln

Eine neue Retrospektiven-Methode habe ich mit einem Team zusammen neu entwickelt: Wir wollten weg von der Gefühlsebene und sehr sachlich und konkret die tägliche Arbeit Revue passieren lassen. Daher legten wir alle Metaplan-Karten zu im vergangenen Sprint bearbeiteten User Storys auf eine vertikale Linie auf einen Tisch, so dass alle User Storys zu sehen waren.
Dann wurden die einzelnen Karten von jedem Team-Mitglied so lange sortiert, bis keiner mehr etwas ändern mochte: Nach links gezogen wurden User Storys, bei deren Bearbeitung großes Verbesserungspotential bestand. Nach rechts gezogen wurden User Storys, deren Bearbeitung überdurchschnittlich gut gelaufen waren. In der Mitte blieben normale, durchschnittliche User Storys liegen.
Anschließend schrieb jeder auf Kärtchen, was er an jeder User Story gut und was er verbesserungswürdig fand. Diese Kärtchen wurden den User Storys zugeordnet und jede User Story sowie jede Karte wurde besprochen im Hinblick auf Maßnahmen, die sich aus den gesammelten Infos ableiten ließen.

Weitere Anregungen für Retrospektiven gibt es zum Beispiel hier.

Unerwünschte Veränderungen

Changes am Prozess sind wünschenswert, die Verbesserung des Produkts ist das Ziel.
Aber es gibt eine Art von Veränderung, die für Know-How-Verlust und Ineffektivität sorgt: instabile Teams. Je häufiger und je umfangreicher sich die Zusammensetzung des Teams verändert, desto schwieriger wird es, die Qualität und Geschwindigkeit der Entwicklung hoch zu halten oder gar zu steigern.

Produktverantwortlichkeit

Auch die Übergabe von Produkten in Maintenance-Teams birgt Nachteile: Der Abstimmungsaufwand, was das notwendige Wissen und die Zuständigkeit im Einzelfall angeht, ist enorm. Produktverantwortliche, interdisziplinäre Teams, die für Entwicklung, Wartung und Betrieb zuständig sind, könnten hier vorteilhaft sein: Die Entwickler bekommen automatisch ein Feedback, welche Bugs und Probleme auftreten und können zukünftig darauf achten. Der Product Owner kann Bugs und Features priorisieren.

Um den Product Owner wird es sich in Teil 3 dieser kleinen Serie drehen.