Dienstag, 1. Dezember 2015

Wie macht man eine gute Retro?

Als ich den Blog gestartet habe, haben mich vor allem die Fragen beschäftigt, wie sich eine Retro innerhalb der Timebox strukturieren lässt, also wie viel Zeit man pro Phase einplanen sollte und wie man einen roten Faden zwischen den Phasen erzeugt.

Als Entwicklerin war ich in den Teams, in denen ich bisher gearbeitet habe, Retros alle zwei Wochen gewohnt, die zwei oder zweieinhalb Stunden dauerten und dachte, das wäre auch eine sinnvolle Zeit.

Nachdem ich jetzt als Prozessbegleiterin mit zwei sehr kleinen Teams gearbeitet habe, das eine schon recht routiniert, das andere noch neu zusammengestellt, habe ich festgestellt, dass die Antwort auf die Frage nach der Dauer der Retro ist: "it depends".

Diese Teams haben jeweils einstündige Retros und kommen in dieser Zeit trotzdem zu Ergebnissen, die sie weiterbringen.

Ester Derby und Diane Larsen meinen sogar in diesem Talk, dass in manchen Situationen mit manchen Teams 5 minütige Retros effektiv sein können, auch wenn alle Phasen berücksichtigt werden sollten. Das würde ich gern mal sehen.

Mit dem routinierten Team plane ich eine Jahresabschluss-Retro, dafür werden wir wahrscheinlich mehr Zeit als eine Stunde benötigen. Ich glaube, dass es schon wichtig ist, mal längere Retros zu machen, um es dem Team zu ermöglichen, seine Potentiale noch tiefer zu betrachten. Aber sie regelmäßig zu verhaften, obwohl sie sich auch in kurzer Zeit reflektieren können, ist nicht agil.

Was den roten Faden angeht, zieht sich dieser meiner Meinung nach durch Gather Data, Generate Insights und Decide What To Do.

In diesen Phasen kann man die Methoden nicht wahllos kombinieren, sondern muss sie ineinander übergehen lassen. 

Die Phasen Set the Stage und Close the Retro sind von diesem Kern eher entkoppelt.
Interessant finde ich auch die Idee, in diesen beiden Phasen die gleiche Methode zu verwenden, um den Kreis zu schließen.

Deshalb werde ich jetzt das Format meiner Blogbeiträge ändern, wenn ich von Retros berichte, und entweder die Methoden im Kern oder am Rand beschreiben.

2 Kommentare:

  1. Ich finde Deine Einsichten immer klasse und abonniere Dein Blog ja deswegen (falls Du das noch nicht weisst).

    Wir kämpfen hier immer darum, wie man richtig Retrospektiven durchführt. Was meinst Du, geht das bei kleinen Projekten auch alleine, oder geht sowas nur im Team, oder noch doller, nur im Team mit Moderation?

    Und warum benutzt Du englische Wörter wie Gather Data - als Suchhilfe im Web?

    AntwortenLöschen
    Antworten
    1. Hi Gregor, danke fürs Lesen und den Austausch. =)

      Zum Thema Retros einführen haben wir ja schon kurz gesprochen, können das aber gern auch nochmal weiter diskutieren, wenn Du mal wieder in Hamburg bist. Schreib mir einfach ne Mail.

      Hier trotzdem ein paar schriftliche Gedanken:

      Wenn man eine Retro alleine durchführt - weil man alleine an einem Projekt gearbeitet hat - hilft das Format bestimmt auch, um sich selbst zu strukturieren. Was aber wegfällt sind die verschiedenen Blickwinkel und gerade die machen eine Retro so wertvoll, weil sie das eigene Bild relativieren oder verstärken können.

      Dass ein Team sich selbst moderiert, halte ich für schwierig, weil jeder ja auch seine Sichtweise auf das Thema hat. Es gibt Teams, die das machen, zum Beispiel mit einem rotierenden Moderator, der dann in der Retro, die er moderiert, nicht inhaltlich sprechen darf oder mit einem festen Retro Format, das die Teammitglieder so verinnerlicht haben, dass zu jeder Zeit klar ist, was die Aufgabe der jeweiligen Retro Phase ist. Andere Teams haben auch ein Teammitglied als festen Scrum Master / Agile Coach in Doppelrolle.

      Diese Möglichkeiten bergen alle gewisse Risiken, deshalb halte ich sie für schlechte Kompromisse.

      Der rotierende Moderator kann in den Retros, die er moderiert, nicht inhaltlich teilnehmen, was Potential des Teams ungenutzt lässt. Außerdem ist es schwierig, Kontinuität in den Verlauf der Retros zu bringen, wenn der Moderator stets wechselt. Dazu kommt, dass die temporären Moderatoren ihre Aufgabe die Retro zu moderieren wahrscheinlich nicht so im Vordergrund sehen und sich mit dem Thema nicht genug beschäftigen können, nur wenig Routine gewinnen und so die Rolle der Moderation nicht so gut ausführen können, wie jemand der sich darauf konzentriert und das Team langfristig begleitet.

      Ein festes Retro Format bietet zwar Orientierung, kann aber dazu führen, dass das Team die Retros mit einer Routine durchführt, die keine neuen Ideen und Blickwinkel mehr generiert. Ich halte es für wichtig, die Methoden regelmäßig zu wechseln, um die Frage nach möglichen Verbesserungen auf unterschiedliche Art und Weise und mit unterschiedlichen Schwerpunkten zu stellen, damit sich die Teilnehmer immer wieder selbst überraschen können.

      Die Doppelrolle Teammitglied und Moderator bietet zwar im Gegensatz zum rotierenden Moderator den Vorteil der Kontinuität und Konzentration auf diese Rolle, verschärft aber das Problem, dass der- / diejenige nicht inhaltlich an den Retros teilnehmen darf. Es bringt den- / diejenige/n und die anderen Teammitglieder in einen Konflikt: Wer spricht gerade? Der Moderator oder das Teammitglied? Auch außerhalb der Retros ist das ein Problem: Ist das Projekt gerade in einer schwierigen Phase, benötigt es sowohl vom Teammitglied als auch vom Agile Coach 100% Einsatz. Jemand, der im gleichen Team beide Rollen ausfüllt, wird in solchen Situationen die eine Rolle vor die andere priorisieren müssen, was dem Projekt schadet.

      Wir haben uns zwar dafür entschieden, die Doppelrolle Entwickler / Prozessbegleiter einzuführen, aber nicht im selben Team, damit klar ist, welche Rolle der- / diejenige in dem jeweiligen Team einnimmt und das Problem, gleichzeitig in beiden Rollen eine schwierige Projektphase überwinden zu müssen, nicht auftritt.

      Zum Englischen: Ich hab mich entschieden, den Blog auf Deutsch zu schreiben, weil es im Englischen bereits viele wertvolle Beiträge zum Thema Retros gibt und man in seiner eigenen Sprache (umgangssprachliche) Feinheiten besser transportieren und verstehen kann als in einer Fremdsprache.
      Trotzdem benutze ich die Fachbegriffe, die die Retro-Phasen beschreiben, wie sie initial von Ester Derby und Diane Larsen vorgestellt wurden, auf Englisch. Übersetzt kommen sie mir nicht so griffig vor. Ist aber wahrscheinlich Geschmackssache.

      Löschen