Retrospektiven zählen zum Werkzeug der agilen Softwareentwicklung. In der Retrospektive geht es darum, aus der Vergangenheit zu lernen. Das Entwickler-Team sieht gemeinsam auf einen bestimmten Zeitraum zurück. Bewertet was gut und was nicht gut gelaufen ist, ermittelt Verbesserungsbedarf und Lösungsansätze. Retrospektiven zählen auch zum Werkzeug des IT-Servicemanagements nach ITIL. Der reaktive Teil des Problem-Managements analysiert bereits aufgetretene Störungen und hat eine dauerhafte Problemlösung zum Ziel. Dieser Kurzartikel beschreibt, warum und wie wir in der Guid.New GmbH das Problem Management als Bestandteil in unsere Retrospektive eingeführt haben.
Problem Management als Teil der Retrospektive
Die Rule of Ten im Qualitätsmanagement besagt, dass die Kosten exponentiell steigen, desto später ein Fehler gefunden wird.
Umso wichtiger ist es, Fehler so früh als möglich zu identifizieren (Shift-left testing). Durch das hohe Einsparungspotenzial ist das hohe Interesse an der Fehlerursache begründet. Warum es ein Fehler so weit nach rechts schaffen konnte und welche Qualitygates in welcher Form den Fehler oder noch besser die Klasse des Fehlers abfangen hätten können, ist für einen kontinuierlichen Verbesserungsprozess hochrelevant.
Vorgehen im Problemmanagement
Wir haben besonderes Interesse, Fehlerursachen nachzugehen, die
- in Produktivumgebungen,
- im Test durch den Kunden (z.B. im Zuge von User Acceptance Tests) und
- die vor der Produktivschaltung im Zuge von Systemtests
aufgetreten sind.
In einem 2-wöchigen Meeting unterziehen wir diesen Fehlern, die bereits behoben und eine gewisse Zeit verifiziert geschlossen sind, einem Review. Der zeitliche Abstand ist nötig, um mit einer hohen Sicherheit davon ausgehen zu können, dass der Fehler tatsächlich behoben ist. Außerdem bringen uns die genannten Fehler, vor allem Produktivsystemfehler gehörig ins Schwitzen. Wenn etwas Zeit vergangen ist, kann der Vorfall mit emotionalerem Abstand objektiver analysiert werden.
Fehler werden auf ihre Ursache hin hinterfragt. Methoden wie die 5-Why-Methode bieten sich hierzu an. Wir analysieren, auf welcher Ebene der Entwicklung der Fehler entstanden ist, wie man ihn hätte vermeiden können und wie man ihn auf den Ebenen bis hin wo wir ihn tatsächlich gefunden haben, schon früher hätten entdecken können. Dadurch ergibt sich ein ganzes Maßnahmenbündel, wodurch sich die Wahrscheinlichkeit, in Zukunft auf Probleme dieser Art besser vorbereitet zu sein, erhöht. Die Maßnahmen kommen ins Backlog, um im Zuge der weiteren Entwicklung umgesetzt zu werden.
