Agile Verbesserungsexperimente – transparent, wirksam, motivierend

AdobeStock_80783015

„Oh, stimmt, wir hatten uns ja Verbesserungsmaßnahmen vorgenommen. Weiß jemand, wo das Fotoprotokoll ist?“ „Leider keine Zeit gehabt…“. Trotz Retrospektiven bleiben Verbesserungs-Vorsätze oft auf der Strecke.

Zunächst einmal sollten wir uns bewusst darüber sein, dass es sich bei Verbesserungsversuchen um Experimente handelt: Wir wissen nicht, ob die Verbesserungsidee tatsächlich zum gewünschten Erfolg führen wird. Wir brauchen dafür einen gewissen Forscher-Geist und die Bereitschaft zum Lernen. Experimente schlagen nicht fehl, sondern zeigen uns, dass es so nicht geht.

Bevor wir also blauäugig jede Verbesserungsmaßnahme umsetzen, sollten wir uns überlegen, was wir durch unser Experiment lernen wollen, also welche Hypothese wir bestätigen oder widerlegen wollen.

Beispiel:

Auf dieser Basis können wir weitere Prinzipien und Praktiken nutzen, die wir für die Entwicklung von Software und Produkten mit Scrum anwenden:

  • Priorisierung nach Wert (Kosten und Nutzen): Verbesserungspotenzial wird überall und täglich sichtbar: bei der täglichen Arbeit, während der Scrum-Meetings, durch Fortschritts-Indikatoren. Manchmal sind es kleine Ideen, „low hanging fruits“, die sich schnell umsetzen lassen. Manchmal sind es handfeste Probleme, für die eine Lösung noch nicht sofort erkennbar ist und die sich vielleicht auch nicht innerhalb eines Teams lösen lassen. Wir können nicht alles gleichzeitig angehen. Wir müssen priorisieren, und zwar nach Kosten und Nutzen. Dazu eignet sich ein Verbesserungs-Backlog (oder Hindernis-Backlog).
  • Verbesserungs-Stories: Wir können die Items dieses Backlogs als Stories formulieren, damit erkennbar ist, für den die Verbesserung welchen Nutzen bringt. Z.B. „Als Entwickler brauche ich das Feedback des Product Owners auch während des Sprints, damit ich weiß, ob ich auf dem richtigen Weg bin.“
  • Aufsplitten in kleine, machbare Teile: wenn wir es mit einem „Verbesserung-Epic“ zu tun haben (z.B. „Zusammenarbeit mit dem Product Owner verbessern“), sollten wir es in Stories herunterbrechen, die in einem Sprint umsetzbar sind. Die Definition von Aktzeptanzkriterien hilft dabei, das Etappenziel für einen Sprint zu klären. Für unser Beispiel oben: „Der Product Owner reserviert sich Dienstags und Donnerstag mindestens 1/2 h nach dem Daily Scrum, um mit den Entwicklern zu arbeiten. Die Entwickler kündigen ihren Bedarf vorher an und einigen sich untereinander, wie sie diese Zeit nutzen wollen.“
  • Verbesserungs-Backlog-Grooming: Die Pflege des Verbesserungs-Backlogs kann in der Retrospektive stattfinden – wenn das Aufsammeln von Verbesserungs-Items eine tägliche Aktivität ist schon während des Sprints ist, hat das Team hier die Zeit für die Priorisierung, Verfeinerung und Entscheidung zur Durchführung von Experimenten.
  • iterativ-inkrementelle Abarbeitung und Transparenz über den Fortschritt: die machbaren Verbesserungs-Stories werden im Sprint Planning eingeplant und im Sprint umgesetzt. Als Daumenwert sollte man 10% der Team-Kapazität als „Zeit zum Schärfen der Axt“ veranschlagen. Am Ende des Sprints kann das Team kontrollieren, ob die Akzeptanzkritierien erfüllt und der erwartete Nutzen eingetreten ist. Da sich der Nutzen oft nur schwer in hart messbaren Zahlen ausdrücken lässt, bietet sich eine Zufriedenheitsabfrage im Team an, die man ggf. über mehrere Sprints verfolgen kann. Z.B. „Wie zufrieden sind wir mit der Zusammenarbeit mit dem Product Owner?“ Es können weitere Stories iterativ angegangen werden, bis die Zufriedenheit ausreichend ist. Um die Nachhaltigkeit der Umsetzung sicherzustellen, ist es ratsam, die Abfrage auch danach in regelmäßigen Abständen durchzuführen. So eine Nutzen-Kontrolle muss man natürlich nicht für jede Verbesserungs-Idee durchführen, nur für die „dicken Brocken“ (großer Aufwand, großer Nutzen).
  • Verantwortung beim Team: oft wird der ScrumMaster als derjenige angesehen, der verantwortlich für die Beseitigung von Hindernissen ist. Tatsächlich sollte sich ein selbst-organisiertes Team eigenverantwortlich an seiner kontinuierlicher Verbesserung arbeiten. Der ScrumMaster ist lediglich dafür verantwortlich, den Prozess dafür aufzusetzen.

Ein wenig Systematik kann helfen, sichtbare Ergebnisse zu erzielen. Das macht Spaß und motiviert zum Weitermachen!

Werbeanzeigen
Dieser Beitrag wurde unter Uncategorized abgelegt und mit , , , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s