Bessere Retrospektiven mit effektiven Verbesserungen

bonsaiLaut den Kommentaren bei den Ergebnissen meiner Umfrage „Wo klemmt es in euren Retrospektiven“, gibt es zwei Favoriten, die ich zuerst in einem Blog Artikel behandeln soll. Das ist zum einen die Nummer vier (Gefühltes Desinteresse im Team sich schon wieder mit einer Verbesserung zu beschäftigen) und die Nummer fünf (Nur sachlich/fachliche Themen werden besprochen). In diesem Blog Artikel das Problem mit dem gefühlten Desinteresse sich schon wieder mit einer Verbesserung zu beschäftigen näher beleuchten.

Wie immer ist ein solches Problem stark von jeweiligen Kontext abhängig, weshalb ich hier sicher keine generelle Lösung beschreiben werde. Wenn ich ein solches Verhalten beobachtet habe, hatte es meist einen der folgenden Gründe:

  1. Die bisherigen Verbesserungen, welche in Retrospektiven beschlossen wurden, wurden am Ende nie umgesetzt.
  2. Die beschlossenen Verbesserungen hatten keinen Effekt, nichts änderte sich.
  3. Das Team bekam nicht genügend Zeit, um an den beschlossenen Verbesserungen zu arbeiten.

Verbesserungen werden nie umgesetzt

Das Verbesserungen nicht umgesetzt werden liegt in den meisten Fällen daran, dass diese Dinge im normalen Tagesgeschäft untergehen. Da bringt es nichts, dass Verantwortliche und Deadlines definiert werden, wenn die beschlossenen Verbesserungen für niemanden mehr sichtbar sind. So spricht auch in der nächsten Retrospektive niemand mehr über die Verbesserungen, die das letzte Mal beschlossen wurden. Das Ergebnis ist Frust im Team.

Zu einer guten Retrospektive gehört eine entsprechende Nachbereitung. Die Ergebnisse müssen aufbereitet werden und sichtbar für alle im Teamraum aufgehängt werden. Ergebnisse, die in Wikis oder Emails verteilt werden, sind schon am nächsten Tag vergessen. Wenn das Team mit einem Board arbeitet, an dem alle für das Team geltende Aufgaben hängen (bei Scrum das Sprint Backlog), gehören die beschlossenen Verbesserungen aus der Retrospektive ebenfalls dort hin. Nur so kann ich sicherstellen, dass das Team sie nicht aus den Augen verliert. Steht die nächste Retrospektive an, so gehören auch immer die Aufgaben aus der letzten Retrospektive mit dazu. Es macht keinen Sinn neue Verbesserungen zu definieren, wenn die alten noch nicht abgearbeitet wurden.

Verbesserungen haben keinen Effekt

Viele Teams feiern vor allem in den ersten Monaten nachdem ein kontinuierlicher Verbesserungsprozess eingeführt wurde einen Erfolg nach dem anderen. Gerade am Anfang ist es einfach Verbesserungspotentiale zu sehen und umzusetzen. Nachdem aber diese „low hanging fruits“ geerntet wurden kommt der Prozess ins Stocken. Man kommt scheinbar nicht mehr vom Fleck.

Als erstes muss man verstehen, dass jede Verbesserung, jede Maßnahme die ich in einer Retrospektive beschließe nichts anderes ist als ein Experiment. In unserem Berufsalltag haben wir es in den meisten Fällen mit komplexen adaptiven Systemen zu tun, deren Verhalten sich nur sehr begrenzt vorhersagen lässt. Ich kann also vorher gar nicht wissen, ob ich den Effekt bekomme, den ich mir vorgestellt habe. Deshalb ist es auch wichtig, dass ich jedes meiner Experimente mit einer Hypothese ausstatte. So kann ich in der nächsten Retrospektive überprüfen, ob meine Maßnahme (mein Experiment) aus der letzten Retrospektive den gewünschten Effekt hatte. Wenn dies nicht der Fall ist, kann ich die Retrospektive dafür nutzen, ein neues Experiment zu definieren, so lange bis ich mit dem Effekt zufrieden bin und mein Ziel erreicht habe (Das angepasste Phasenmodell für Retrospektiven habe ich bereits auf meinem englischen Blog beschrieben). Ein Nebeneffekt von diesem Vorgehen ist, dass meine Retrospektiven ein klares Ziel haben und dadurch (wieder) zu einem wertvollen Meeting wird. Zusätzlich macht es Sinn, dass sich die Teammitglieder mit Systemischen Denken (System Thinking) und Komplexitätsdenken (Complexity Thinking) auseinander setzen, um besser verstehen zu können, wie sie das System beeinflussen können welches sie umgibt. Dazu mehr in einem anderen Blog Artikel.

Das Team bekam nicht genügend Zeit

Oft wird auch bemängelt, dass man im Projektalltag nicht genug Zeit bekommt, um an seinen Experimenten (Verbesserungen) zu arbeiten. Die Prioritäten liegen auf anderen Aufgaben und niemand kommt dazu wirklich etwas zu verändern.

Hierzu hat mein Freund Yves Hanoulle im März diesen Jahres einen Blog Artikel geschrieben, in der er eine besondere Form der Retrospektive vorstellt: Die Arbeitsretrospektive (Work Retrospective). Der Ablauf ist etwas anders, als man es gewohnt ist, startet aber auch mit der Phase „Den Boden bereiten“. In der Phase „Daten sammeln“ geht man dann aber nicht wie sonst dazu über die letzten Wochen zu analysieren, sondern jeder Teilnehmer erhält fünf Minuten, um zwei potentielle Verbesserungen auf jeweils einen Post-It zu schreiben, die man innerhalb einer Stunde erledigen kann. Danach stellt jeder Teilnehmer seine Ideen vor und jeder sucht sich einen Partner mit dem er eine der Aufgaben innerhalb der nächsten Stunde bearbeitet. Nach dieser Stunde trifft man sich wieder und jedes Paar stellt ihre Ergebnisse vor.

Ich selbst bin ein großer Fan dieser Form von Retrospektive. Es ist sicher keine Retrospektive, die man nicht häufig durchführen kann, aber eine Retrospektive bei der man viel lernen kann. Wenn es gut läuft lernen die Teammitglieder, was man alles in kurzer Zeit bewegen kann. Und wenn es noch besser läuft, haben sie in der kurzen Zeit etwas zustande gebracht, dass von größerer Bedeutung für das Team war. Bei solchen Arbeitsretrospektiven sind es oft kleine Dinge, die man schon länger vor sich hergeschoben hat und wofür man sich jetzt endlich einmal die Zeit nimmt. Und es ist doch immer ein gutes Gefühl, wenn man wieder etwas von seiner Aufgabenliste streichen kann. Probiert es mal aus, ich bin gespannt auf ihr Feedback.

Was für Erfahrungen habt ihr gemacht? Welche Ideen könnt ihr beisteuern? Habt ihr Fragen? Ich bin schon jetzt gespannt auf eure Kommentare.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


neun − 5 =

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>