No problem is a problem! Erfolgsfaktoren für Retrospektiven
14. November 2011
Das Streben nach kontinuierlicher Verbesserung von Produkten und Prozessen wird in Scrum zu verschiedenen Zeitpunkten berücksichtigt. Die drei Säulen Transparenz, Überprüfung und Anpassung sind ähnlich dem Deming-Cycle (Plan, Do, Check, Act) sowohl für tägliche als auch monatliche Änderungen im Rahmenwerk verankert. Die täglichen Aktivitäten werden im Daily Standup Meeting geplant, geprüft und angepasst. Für monatliche Änderungen sind diese Prozessschritte auf das Sprint Planning, den Sprint Review und die Sprint Retrospektive verteilt. Beim Review wird das Sprint Ergebnis (Inkrement) überprüft. Hier kann es bei einem hohen Reifegrad des Produktes durchaus vorkommen, dass nur geringe Verbesserungsmöglichkeiten ermittelt werden.
Erkennt das Scrum Team aber bei der Retrospektive – also der Prüfung von Beziehungen, Prozessen und Werkzeugen – kein Verbesserungspotenzial, so ist Vorsicht geboten.
Erfolgsfaktor Unternehmenskultur
Eine wesentliche Voraussetzung für erfolgreiche Retrospektiven basiert auf der Unternehmenskultur, also der Menge von ungeschriebenen Regeln, die von allen Mitgliedern der Organisation verstanden und implizit eingehalten werden. Wenn das Auftreten von Fehlern mit Repressalien einhergeht und statt nach Vermeidungsstrategien für zukünftige Fehler eher nach Schuldigen gesucht wird, kann man in der Retrospektive keine Atmosphäre von Offenheit und Mut erwarten. Fehler werden dann nur sehr widerwillig preisgegeben. Ziel sollte es daher sein, eine Sichtweise zu etablieren, die Fehler als Möglichkeit zur Weiterentwicklung sieht, getreu Thomas Alva Edison: „Von jeder der 200 Glühbirnen, die nicht funktionierten, habe ich etwas gelernt, das ich für den nächsten Versuch verwenden konnte.“
Erfolgsfaktor Vorgehensweise
Für die Durchführung der Retrospektive existieren in der Literatur verschiedenste Abläufe. Wesentlich scheint mir die Kaizen-Grundregel, dass alle Mitarbeiter am Verbesserungsprozess beteiligt werden. Somit sollte in der Retrospektive jeder Teilnehmer die Möglichkeit erhalten, ungestört seine Aspekte vorzubringen (Storytelling). Hier greift also die Scrum-Säule der Transparenz. Erst wenn alle Themen gesammelt worden sind, werden die Geschichten ausgewertet, diskutiert und Lösungen gesucht. Die Lösungen erfordern meist die Umsetzung von Maßnahmen (Corrective And Preventive Actions), die fortan unbedingt verfolgt werden müssen. Wenn immer wieder dieselben Probleme Thema der Retrospektive sind, führt dies zur Demotivation des Scrum Teams und zu ernst zu nehmenden Zweifeln an der Sinnhaftigkeit der Veranstaltung.
Empfehlenswert ist es, die positiven Ereignisse des zurückliegenden Sprints angemessen zu berücksichtigen und wertzuschätzen. Diese wirken sich positiv auf die Team-Motivation aus und sollen zukünftig wenn möglich wiederholt werden. Einen typischen Ablauf einer Retrospektive finden Sie hier.
Kritische Reflexion des eigenen Arbeitsumfeldes
Wenn die Ergebnisse der Retrospektive ungenügend ausfallen, obwohl die Haltung des Teams so ausgerichtet ist, dass das Aufdecken von (eigenen) Fehlern als wünschenswerte Verbesserungsmöglichkeit gesehen wird und auch der Ablauf die oben aufgeführten Aspekte berücksichtigt, wird das eigene Arbeitsumfeld möglicherweise nicht kritisch genug hinterfragt. Hier hilft es, Ansatzpunkte wie die aus Kaizen bekannten
– Muda (Verschwendung)
– Muri (Überlastung der Mitarbeiter und Maschinen)
– Mura (Unregelmäßigkeit der Prozesse)
auf die eigenen Tätigkeiten zu beziehen und durch Perspektivenwechsel zu neuen Erkenntnissen zu gelangen. Auch die etwas konkreteren Kanban-Grundsätze können hilfreich sein. Betrachtenswert sind beispielsweise
– Beschränkung der WIP (Work in Progress)
– Automatisierung von wiederkehrenden Aktivitäten (z.B. Integration und Test)
– Verringerung von Koordinationstätigkeiten
– Auslastung und Schutz von Engpässen
– Erweiterung von Engpässen
– Verringerung der Variabilität
Ein funktionierender Prozess kontinuierlicher Verbesserung ist durch die Scrum Retrospektiven gegeben, erfordert aber einige Voraussetzungen. Wenn Haltung des Teams, Ablauf und Aspekte der Verbesserungsmöglichkeiten im Einklang sind, werden Retrospektiven regelmäßig Verbesserungspotenziale aufdecken. Wenn diese ausbleiben, ist die Schlussfolgerung, Prozesse, Werkzeuge und Beziehungen seien perfekt, nahe liegend, aber falsch. Oder wie es im Lean Management von Toyota heißt: No problem is a problem.
Weiterführende Artikel im Blog:
Was ist Muda?
Der Deming-Cycle und Scrum
Quelle Foto: © Wolfgang Heise – Fotolia.com
| Keine Kommentare