Die Sprint Retrospektive

Montag, 14. Dezember 2009 von  
unter Fachartikel Scrum

Laut Wikipedia bezeichnet Retrospektive im Allgemeinen einen Rückblick. Dementsprechend ist eine Sprint Retrospektive ein Rückblick auf den gerade abgelaufenen Sprint.

Die Sprint Retrospektive findet nach dem Sprint Review, in dem die Sprint Ergebnisse präsentiert wurde statt und schließt damit den Sprint ab.Ziel der Retrospektive ist die Verbesserung des Scrum Prozesses. Und da wir in Scrum neben dem reinen Prozess auch Wert auf den sozialen Umgang zwischen allen Beteiligten legen, gehört auch dies mit in die Retrospektive.

„Der Inhalt“

Also, was wird in einer Sprint Retrospektive besprochen?

Beispiele:

– Arbeitet das Projekt erfolgreich?

– Werden die Sprintziele erreicht?

– Betrachtung der einzelnen Prozessschritte, wie z.B. das Daily Scrum oder der Sprint Review.

– Werden die Prozessschritte eingehalten?

– Sind die Ergebnisse der Prozesschritte das, was erwartet wurde?

– Welche Ergebnisse werden denn erwartet?

– Wenn Prozessschritte nicht durchgeführt werden, warum ist das so?

– Was müsste sich ändern, damit sie eingehalten werden? Oder besteht überhaupt die Notwendigkeit, sie einzuhalten.

Ganz klassisch kann hier z.B. auch darüber reflektiert werden, ob die Zeitfenster für die Prozessschritte noch angemessen ist. Wenn das Sprint Planning Meeting zum Ende hin immer hektisch wird, weil die Zeit ausgeht bevor das Sprint Backlog vollständig ist, dann könnte hier z.B. festgehalten werden, dass das Meeting eine Stunde länger angesetzt werden muss. Oder auch genau umgekehrt.

Oder z.B. die tagtäglichen Arbeitspraktiken: Werden die Codierstandards eingehalten und wenn nicht, warum? Fehlen Standards/Vorgaben und wenn ja, welche? Unterstützt die verwendete Technologie noch die Anforderungen im Projekt?

Und dann halt auch das Soziale: Wo gibt es zwischenmenschliche Reibungen und warum? Wo scheint Kommunikation zu fehlen oder nicht ausreichend zu sein und warum? Gibt es evtl. Probleme bei den Vorstellungen über die Arbeitszeiten? Und so weiter.

Und Verbesserungen werden in der Regel ja nicht dadurch erzielt, dass man mal darüber gesprochen hat sondern nur durch konkrete Maßnahmen. D.h. als Ergebnis einer jeden Retrospektive müssen konkrete Maßnahmen vereinbart worden sein, die die Verbesserung des Scrum Prozesses zum Ziel haben.

„Die Teilnehmer“

Aus diesem Inhalt ergibt sich schon so ein bisschen die Teilnehmergruppe der Sprint Retrospektive. Teilnehmer sind auf jeden Fall das komplette Team, der Scrum Master und der Product Owner. Weitere Teilnehmer wie z.B. Stakeholder können hinzukommen, dabei gelten aber zwei wichtige Regeln:

  1. nur wenn die weiteren Teilnehmer aktiv zur Prozessverbesserung beitragen können. D.h. sind diese Personen notwendig um Probleme identifizieren oder lösen zu können? Einfach nur Zuschauer sind eher nicht gewünscht. Dafür können die Daily Scrums oder Sprint Reviews benutzt werden.
  2. Alle Teammitglieder, der Scrum Master und Product Owner müssen einverstanden sein. Dabei muss eine Ablehnung auch nicht ausführlich begründet werden. In Retrospektiven kann es, gerade wenn es um soziale Probleme geht, schnell ans Eingemachte gehen und das möchte nicht jeder vor Außenstehenden machen.

Zusammenfassend kann man sagen: So viele wie nötig, so wenig wie möglich.

„Die Dauer“

Wie lange soll die Retrospektive denn dauern?

Wir erinnern uns, dass wir in Scrum ja fast alles in festen Zeitboxen machen. Als Faustformel würde ich sagen, bei einer Sprintlänge von zwei Wochen anfangs jeweils einen halben Tag. Einigen mag das ziemlich lange vorkommen, aber gerade am Anfang eines Projektes wird es ziemlich viel Justierungsbedarf geben und die Retrospektive ist das Werkzeug dafür, um das Projekt im Doing (nicht im Bezug auf die Anforderungen) auf Kurs bringen zu können. Wenn der Justierungsbedarf nachlässt, d.h. in der Retrospektive kommen nichtmehr genug „echte“ Themen auf, um wirklich den halben Tag auf Dauer zu benötigen, dann kann die Zeitbox entsprechend verkürzt werden. Das ist übrigens etwas, was in der Retrospektive als Ergebnis entstehen kann.

Und jetzt wird es noch ein paar geben, die einen halben Tag zu wenig finden. Die mögen aber bedenken, dass die Retrospektive ja in jedem Sprint stattfindet, hier also alle zwei Wochen. Und in der Regel entstehen auch nicht in jedem Sprint so viele neue Probleme oder Umstände, dass jeweils ein halber Tag zur Reflektion benötigt wird. Anfangs vielleicht ja, weil vieles neu ist aber das sollte sich zügig ändern. Und deshalb ist es auch nicht notwendig, dass am Ende jeder Retrospektive alles geklärt sein muss. Offene Themen werden dann halt in die nächste Retrospektive mitgenommen und dort weiter bearbeitet.

„Wo“

Es empfiehlt sich übrigens, wie bei den meisten Meetings, sich für die Retrospektive einen möglichst störungsfreien Raum zu suchen, in dem alle Teilnehmer ausreichend Platz und Sitzgelegenheiten haben und auch Platz für Teamarbeiten an einer Metaplanwand oder Whiteboard sind. Auf Beamer und Rechner würde ich übrigens großzügig verzichten, da dieses selten die Teamarbeit fördert.

„Die Moderation“

Ja und dann ist noch die Moderation der Retrospektiven zu klären. Ein externer Moderator, der der Situation völlig unbelastet gegenübersteht und eventuell, weil er das hauptberuflich macht auch das größtmögliche Maximum an Moderationserfahrung mitbringt, wäre natürlich das schönste. Aber machen wir uns nichts vor, die Wahrscheinlichkeit dass ein Unternehmen alle zwei Wochen einen externen Moderator finanzieren wird tendiert eher gegen Null.

In der Regel wird es also eher der Job des Scrum Masters sein, die Retrospektive zu moderieren und normalerweise sollte das auch mehr aus ausreichend sein. Sinn macht das Extrainvestment in einen externen Moderator gegebenenfalls für die ersten ein zwei Retrospektiven, wenn der Scrum Master noch wenig Erfahrung in der Moderation hat, sodass er sich hier was abschauen kann. Oder wenn die sozialen Probleme im Projekt anwachsen und der Scrum Master entweder selber involviert ist und damit eine unvoreingenommene Moderation nicht möglich ist oder er sich das Moderieren in dieser Situation noch nicht zutraut. Letzterer Grund ist übrigens kein Grund zur Schande. Ganz im Gegenteil, wenn der Scrum Master dies ehrlich eingesteht und Hilfe anfordert anstatt es doch selber zu probieren und die Situation möglicherweise damit noch verschlimmert. Wir erinnern uns: In Scrum werden Probleme immer offengelegt und aktiv angegangen.

„Der Ablauf“

Wie läuft nun so ein Sprint Retrospektive konkret ab:

Noch vor der ersten Retrospektive oder direkt als erstes der ersten Retrospektive müssen die Grundregeln/Grundprinzipien vereinbart werden. An folgenden Regeln führt für erfolgreiche Retrospektiven eigentlich kein Weg vorbei:

  1. Gegenseitiger Respekt
  2. Ehrliche Kommunikation
  3. Trennung von Person und Sache

Diese Regeln müssen von allen akzeptiert werden und jeder Teilnehmer hat jederzeit das Recht, sich auf diese Regeln zu berufen.

Weitere Regeln können dann individuell vom Team vereinbart werden.

Wenn das geklärt ist, dann kann es losgehen.

Es gibt nicht DIE Vorgehensweise oder Art, eine Retrospektive durchzuführen. Maßgeblich sind eigentlich nur die gerade genannten Grundregeln und das am Anfang benannte Ziel, konkrete Maßnahmen zur Verbesserung des Scrum Prozesses zu erarbeiten. Wer sich hier ein bisschen tiefer einarbeiten möchte, dem empfehle ich das Buch „Agile Retrospectives: Making Good Teams Great“ von Esther Derby und Diana Larsen. Einen Link dazu stelle ich in die Show Notes.

Fürs erste möchte ich hier jetzt eine Vorgehensweise vorstellen, mit der wir in meinem aktuellen Projekt erfolgreich arbeiten.

Die Retrospektive gliedert dabei auf in vier Phase: Einführung, Datensammlung, Themenbearbeitung und Abschluss.

In der Einführung erklärt der Moderator nochmal kurz die Zielsetzung, den Ablauf und die Regeln. Hier holt der Moderator vom Teilnehmerkreis auch das Commitment für Ziel, Ablauf und Regeln ein und ggfs. können hier noch Abweichungen gemeinsam festgelegt werden.

Anschließend erklärt jeder Teilnehmer kurz, wie er sich fühlt und was er von dem Meeting erwartet. Alternativ kann auch jeder Teilnehmer seine Stimmung ausdrücken, indem er auf einem Stimmungsbarometer an einer Wand einen Punkt klebt oder Strich macht und somit die Gesamtstimmung im Team visualisiert wird. Das ganze dient gleichzeitig zur Auflockerung und zur Einstimmung auf das Thema.

Bei der Datensammlung wird gesammelt, was den so im letzten Sprint passiert ist und welche Probleme das Projekt derzeit hat. Das können neu aufgetretene Probleme sein oder aber auch ältere, die das Projekt schon länger ungelöst mit sich rumschleppt.

Eine Methode, um das zu erreichen ist Mad Sad Glad. Als erstes schreiben alle Teilnehmer Karten mit positiven und negativen Ereignissen. Das kann man von der Anzahl völlig offen lassen oder z.B. auch auf jeweils 3 positive und negative Karten beschränken (jede Karte aber nur ein Ereignis). Einfach mal ausprobieren, was bei Ihnen besser funktioniert. Jeder Autor markiert seine Karte auch als positiv oder negativ, indem er eine Smiley oder ein Nichtsmiley darauf malt. Alternativ können auch Karten mit unterschiedlichen Farben verwendet werden.

Wenn alle ihre Karten geschrieben haben, dann werden diese an einer Metaplanwand gesammelt. Dazu stellt jeder Teilnehmer nacheinander seine Karten kurz vor und hängt sie dabei an die Wand. Die Betonung liegt dabei auf kurz, keine Romane. Fragen oder Kommentare durch andere Teilnehmer sind nicht erlaubt. Eine Sortierung findet auch noch nicht statt. Natürlich steht es dem Autor frei, seine Karte in die Nähe einer anderen zu hängen, die er als thematisch verwand empfindet, aber das bedeutet erst mal noch nichts.

Dann werden die Karten gemeinsam gruppiert. Dabei wird darüber gesprochen, was genau gemeint ist oder wie es gemeint ist und so weiter. Nach einer Zeit sind die Karten gruppiert und jede Gruppe bekommt eine gemeinsame Überschrift, das Thema der jeweiligen Gruppe.

Ist das geschehen, dann werden die Themen (die Gruppen sind nun zu Themen geworden) gemeinsam priorisiert. Dazu darf jeder Teilnehmer insgesamt drei Klebpunkte an die Themen verteilen, die ihm am wichtigsten sind. Die muss er übrigens nicht alle auf einzelne Themen verteilen, wenn ihm ein Thema ganz besonders wichtig ist, dann kann er auch seine ganzen Punkte an dieses vergeben.

Das Thema mit den meisten Punkten ist das wichtigste, das mit den zweitmeisten das nächstwichtigste und so weiter.

Wir gehen in die Phase Themenbearbeitung über. Dazu betrachten wir kurz nochmal, dass jeder Teilnehmer sowohl positive wie auch negative Karten schreiben durfte. Daraus ergibt sich, dass Themen eine mehr oder weniger starke Tendenz haben werden, als positiver oder negativer Faktor wahrgenommen zu werden.

Es gibt immer mal wieder die Meinung, dass Positives in einer Retrospektive nicht weiter besprochen werden muss, da es ja eh schon gut ist. Das sehe ich anders. Andere vertreten den Standpunkt, dass man aus Gründen der Motivation natürlich auch über Positives reden muss. Auch da bin ich nicht dabei, denn wir wollen in unserer Retrospektive greifbare Ergebnisse erzielen und nicht einfach mal nur drüber reden. Ja, aber was denn jetzt, drüber reden oder nicht? Die Antwort lautet, drüber reden, wenn daraus ein echter Nutzen gezogen werden kann. Nur drüber zu reden, weil es so schön war und man sich damit selber auf die Schulter klopfen kann, ist in einer Retrospektive Zeitverschwendung. Wenn man aber im Gespräch darüber Lehren für andere Bereiche des Projekts ziehen kann oder Möglichkeiten erarbeiten, etwas was gut ist noch besser zu machen, dann wird hier ein echter Mehrwert erzielt. Erfahrungsgemäß werden diese Themen aber erst eine höhere Priorität bekommen, wenn zumindest die drückendsten negativen Themen gelöst sind.

Aber zurück zur Themenbearbeitung. Die Themen werden in der Reihenfolge ihrer Priorität bearbeitet und zwar sowohl die negativen wie auch die positiven. Bei jedem Thema wird von der Gruppe (diesmal sind die Teilnehmer der Retrospektive gemeint, nicht die gruppierten Karten) zuerst die Ursache erarbeitet, also warum ist etwas ein Problem, warum funktioniert etwas nicht oder warum funktioniert etwas so gut. Hierbei kann z.B. die Methode der fünf Warums verwendet werden, bei der fünfmal nach dem Warum gefragt wird. Natürlich nicht fünfmal nach dem gleichen Warum (obwohl stete Wiederholung soll ja auch Lerneffekte erzielen) sondern jede Antwort auf ein Warum wird erneut hinterfragt um damit auf die tieferen Ursachen eines Umstandes zu kommen.

Wenn die Ursache geklärt ist, dann geht es daran konkrete Maßnahmen zu beschließen, die für die Zukunft Verbesserungen bewirken sollen, also einen negativen Effekt zu beseitigen oder zu mindern bzw. einen positiven zu verstärken. Maßnahmen werden vom Moderator schriftlich festgehalten, ein Verantwortlicher aus dem Teilnehmerkreis und ein Zieldatum bestimmt.

Wenn alle Themen bearbeitet sind oder, was wahrscheinlicher ist, die Zeit für diese Phase rum ist, dann kommen wir zum Abschluss der Retrospektive.

Beim Abschluss führen wir quasi eine kleine Retrospektive der Retrospektive durch. Dabei werden gemeinsam kurz folgende Fragen besprochen.

  1. War der zeitliche Rahmen in Ordnung? Retrospektive zu kurz oder zu lang?
  2. Wurden konkrete Ergebnisse erzielt? Wenn nicht sollte dies das Thema der nächsten Retrospektive sein.
  3. War die Art der Durchführung hilfreich?

Die Ergebnisse hieraus gehen direkt in die nächste Retrospektive ein.

„Was noch“

Damit wäre die Retrospektive durch. Aber noch ein paar kleine Hinweise.

Natürlich kann man die beschlossenen Maßnahmen einfach in ein Textdokument schreiben, dass dann niemand mehr beachtet und in Vergessenheit gerät. Mehr Effekt erzielt man jedoch, wenn die Maßnahmen zusammen mit den Verantwortlichen und Terminen groß auf Flipchartpapier geschrieben und offen im Teamraum aufgehängt werden. Das erhöht die Change, dass irgendwas davon auch erledigt wird erheblich. Außerdem sollte zum Beginn jeder Retrospektive der Status der noch unerledigten Maßnahmen abgefragt werden. Wird eine Maßnahme trotz abgelaufenen Termin zum wiederholten Male nicht erledigt, dann kann dies durchaus ein direkt ein Thema für die Retrospektive sein.

Und dann gibt es da noch eine paar Situationen, die in Retrospektiven auftreten können und in denen der Moderator gefordert ist, die Retrospektive zu retten.

Persönliche Angriffe: Wir haben weiter vorne gesagt, eine der Grundregeln für Retrospektiven ist die Trennung von Person und Sache. Normalerweise bedeutet dies, dass über Sachthemen und nicht über persönliches Verhalten diskutiert wird. Da wir in Scrum, wie aber auch schon gesagt, auch die zwischenmenschlichen Aspekte nicht außer Acht lassen, kann es manchmal auch notwendig und zielführend sein, Zwischenmenschliches zu thematisieren. Allerdings muss der Moderator hier viel Fingerspitzengefühl zeigen, bei der Entscheidung, was zulässig ist und was nicht. Haben nur vereinzelte Personen Probleme untereinander, dann sollte der Punkt aus der Retrospektive herausgezogen werden. Die betroffenen Personen sollen evtl. unter Mithilfe eines Moderators das Problem in einer eigenen Runde besprechen und klären. Betreffen die Probleme aber das ganze Team und hemmen die Produktivität des Teams, dann ist das ein Thema für die Retrospektive. Aber auch hier gilt das Grundprinzip des gegenseitigen Respekts. Keine Beleidigungen, Vorwürfe müssen auch belegt werden können, keine unzulässigen Verallgemeinerungen. Bei Verstößen hiergegen muss der Moderator sofort eingreifen und notfalls die Retrospektive auch mal unterbrechen, damit sich die Gemüter auch mal wieder beruhigen können.

Schweigen: Es gibt ja nichts furchtbareres, wenn man eine Retrospektive startet und dann, wenn nach Themen gefragt wird, alle nur schweigen. Es muss nicht so extrem sein, aber wenn Punkte nicht angesprochen werden, obwohl klar ist, dass sie da sind, dann gibt es da scheinbar ein Problem. Meist ist dies ein Vetrauensproblem, entweder in den Sinn der Retrospektive selber, also „Wozu soll das gut sein, dass ändert doch eh nichts“ oder in Anwesende. Sollte der Moderator in diese Situation kommen, dann hilft hier nur doch, auf die Metaebene zu wechseln und die Situation offen anzusprechen. Also klar adressieren, dass er das Gefühl hat, dass nicht alles angesprochen wird und er ein Vertrauensproblem vermutet. Sind Vorgesetzte von Teilnehmern anwesend, so kann dies durchaus der Grund sein. In diesem Fall kann es hilfreich sein, die nächste Retrospektive ohne diese Vorgesetzten durchzuführen und zu sehn, ob es dann besser wird. Als letztes Mittel bleiben dem Moderator nur noch Einzelgespräche, um die Ursachen für das Schweigen zu finden und zu beheben, denn gelöst werden muss dieses Problem. Ohne eine funktionierende Retrospektive kann sich ein Scrumprozess nicht weiterentwickeln und damit das Projekt nicht optimal unterstützen. Bei aller Sorge um eine funktionierende Retrospektive darf der Moderator aber nicht vergessen: In seltenen Fällen gibt es tatsächlich keine oder nur wenige Probleme, die besprochen und gelöst werden müssen. Also bitte nicht dort ein Problem unnötig erzeugen, wo eigentlich keins ist.

Schwafeln: Wenn viel gesprochen wird, ohne dass dabei was Konkretes rauskommt, dann nennt man das schwafeln. So begrüßenswert es ist, wenn die Teilnehmer in der Retrospektive viel reden, wenn einzelne Teilnehmer sich zwar viel mitteilen, dabei aber eigentlich nur heiße Luft erzeugen, dann muss der Moderator auch hier eingreifen und gezielt nach den eigentlichen Inhalten fragen. Zeit ist ein knappes Gut und es sollte gut genutzt werden. Es geht allerdings nicht darum, jede Art von informeller Kommunikation zu unterbinden. Eine Retrospektive sollte durchaus auch Spaß machen. Aber wenn einzelne Teilnehmer anfangen sich zu produzieren und damit massive Zeit für sinnvollen Inhalt vergeuden, dann kann das den Nutzen einer Retrospektive stark beeinträchtigen.

Wenn alle zwei oder vier Wochen konsequent eine Retrospektive durchgeführt wird, dann schleicht sich schnell Routine ein und diese kann auf Dauer die Effektivität einer Retrospektive beeinflussen. Abhilfe schafft hier, den Ablauf und Inhalt der Retrospektiven immer mal wieder zu variieren.

Anstatt die Karten mit den Ereignissen bei der Vorstellung zufällig auf der Metaplanwand zu verteilen, können diese z.B. anhand eines Zeitstrahls zeitlich geordnet werden. Oder man nimmt anstatt eines einfachen Zeitstrahls den Sprint Burndown und vergleicht mal, ob bestimmte Ereignisse evtl. mit Entwicklungen im Sprintfortschritt in Korrelation stehen könnten. Obwohl das teilweise mit Vorsicht zu genießen ist. Oder man ändert ausnahmsweise mal den Fokus einer Retrospektive. Normalerweise werden in einer Retrospektive ja rückblickend die Ereignisse des abgelaufen Sprints bzw. auch der Zeit davor betrachtet. Wenn die aktuellen Probleme im Projekt aber nicht zu drückend sind, dann lenkt man den Fokus mal in die Zukunft. Die Teilnehmer spielen mal zur Abwechslung eine Runde „was wäre wenn“. Alle zusammen formulieren mal, wie ihrer Ansicht nach das Projekt aussähe, wenn die Rahmenbedingungen völlig frei definierbar wären. Dann definiert man, wie die Rahmenbedingungen denn konkret sein müssten und anschließend wird überlegt, was in der tatsächlichen Welt unternommen werden müsste, um auf die idealisierten Rahmenbedingungen zu kommen. Quasi eine legitime Zeit zum Träumen mit dem Anspruch aber hieraus konkreten Projektnutzen zu ziehen.

„Und noch was“

So, jetzt haben wir noch zwei Punkte, über die wir sprechen müssen. Was ist mit unbehandelten Themen und nochmal ein genauerer Blick auf den zeitlichen Rahmen innerhalb der Retrospektive.

Wir hatten es schon angesprochen, nicht alle Themen die bei der Datensammlung aufgekommen sind, werden auch immer in der Themenbearbeitung ihren Platz finden. In vielen Retrospektiven werden hier mehr oder weniger Themen unbehandelt übrig bleiben. Was passiert nun mit diesen? Nun, das kann man unterschiedlich handhaben. Eine Möglichkeit ist tatsächlich, alle unbehandelten Themen wegzuwerfen und bei der nächsten Retrospektive komplett neu anzufangen. Wenn die Themen wichtig waren, dann werden sie auch hier wieder hochkommen. Allerdings besteht hier die Gefahr, dass wenn ein Thema bereits dreimal unbehandelt weggeworfen wurde, es bei der vierten Retrospektive nicht mehr angesprochen wird. „Wird ja sowieso nie behandelt werden“ ist die Denkweise, die sich da schnell einnistet verbunden mit einem gewissen Frust einiger Teilnehmer.

Besser ist es da, die unbehandelten Themen als Startset mit in die nächste Retrospektive zu nehmen. Diese Themen werden zusammen mit allen ihren Karten bereits auf der Metaplanwand angebracht, allerdings wird die Priorität aus der letzten Retrospektive nicht mit übernommen. Diese ist tatsächlich wieder offen. Dann werden in der Datensammlung wieder Ereignisse gesammelt und nun entweder bereits bestehenden Themen zugeordnet oder eben neue Themen gebildet. Und dann wird wieder priorisiert und die Themen wie gehabt bearbeitet. Wichtig ist dabei, dass die Prioritäten wieder offen sind und unter Berücksichtigung der aktuellen Situationen neu vergeben werden.

Kommen wir jetzt nun wirklich zum letzten Punkt, der zeitlichen Einteilung innerhalb der Retrospektive. Grundsätzlich ist natürlich jedes Team völlig frei in der Entscheidung darin, wie viel Zeit es auf was verwenden möchte. Aber man darf natürlich nicht vergessen, dass eine Retrospektive nicht einfach nur ein nettes get-togeher ist, sondern konkrete Ergebnisse erzielen soll. Dementsprechend ist es wenig vorteilhaft, 90% der Zeit mit dem Sammeln von Themen zu verbringen und dann nur noch eine halbe Stunde Zeit zum bearbeiten zu haben.

Ich mache mal einen Vorschlag für den von mir vorgestellten Ablauf bei der Annahme eines zweiwöchigen Sprints und einer halbtägigen Sprint Retrospektive, also vier Stunden.

Einführung: 15 Minuten. Kann beim ersten Mal etwas länger sein, weil hier evtl. die Spielregeln für die Retrospektive geklärt werden müssen und die Teilnehmer noch etwas länger brauchen, um das erste Mal ihre Erwartungen zu formulieren. Aber ab dem zweiten Mal müsste es in 15 Minuten gehen.

Datensammlung: 30 – 60 Minuten. Es hängt ein bisschen davon ab, wie viele neue Themen zu erwarten bzw. wie viele alte Themen schon vorhanden sind. Am Anfang, wenn vieles noch nicht eingespielt ist oder später in turbulenten Zeiten, wenn alle merken, dass es nicht optimal läuft, würde ich eher die 60 Minuten nehmen, denn es ist wichtig, dass die Themen benannt werden. Wenn sich dahingegen in den letzten Retrospektiven gezeigt hat, dass nicht mehr so viele neue Themen aufkommen, sollte der Zeitrahmen für die Datensammlung reduziert werden.

Themenbearbeitung: 120 – 150 Minuten. Die Länge dieses Blocks ist umgekehrt proportional zur Länge der Datensammlung. Je mehr, umso besser, denn nur bearbeitete Themen sind gute Themen.

Abschluss: 15 Minuten. Auch hier gilt, kann beim ersten Mal länger sein, da viel über das Erlebte der ersten Retrospektive verarbeitet werden muss. Also mal lieber 30 Minuten ansetzen. Ab dem zweiten Mal aber nur 15 Minuten. Wenn es deutlich mehr über die eigentliche Retrospektive zu besprechen gibt, dann lohnt es sich evtl. mal eine eigene Retrospektive nur zu diesem Thema zu machen.

Hey, das sind ja nur 3 ½ Stunden. Wir haben doch vier Stunden zur Verfügung! Ja schon, aber ohne gelegentliche Pausen hält das niemand durch. So zwischen Datensammlung und Themenbearbeitung würde ich eine Pause einlegen und dann nochmal eine während der Themenbearbeitung. Aber auch das muss schlussendlich jedes Team selber regeln.

Wichtig bei diesen Einteilungen ist, dass sie allen Teilnehmern klar sind. Der Moderator stellt den Ablauf mit den vorgegebenen Zeiten einschließlich der Pausen in der Einführung vor. Und diese Zeiten sollten als Obergrenzen auch wirklich eingehalten werden. Wenn 60 Minuten Datensammlung angesetzt sind, dann ist nach 60 Minuten auch Schluss. In zwei Wochen ist die nächste Retrospektive, da kann dann weitergemacht werden, aber für aktuelle Retrospektive ist Schluss! Es sind aber wie gesagt Obergrenzen. Wenn nach 45 Minuten bei besten Willen kein echtes neues Thema mehr gefunden werden kann, dann sitzen wir natürlich nicht die restlichen 15 Minuten schweigend da oder machen Unsinn. Wir gehen dann halt eben schon vorzeitig in die nächste Phase über, in diesem Fall hätten wir dann 15 Minuten mehr Zeit für die Bearbeitung der Themen. Ist doch super!

„Geschaft“

Das war es, Sie wissen jetzt alles, was Sie für eine erfolgreiche erste Retrospektive brauchen und haben auch die notwendigen Werkzeuge zur Hand, um Ihre Retrospektiven selber weiter zu entwickeln.

Dies ist das Skript der Episode „Die Sprint Retrospektive“ des Podcasts Scrumidable vom 13.12.2009.

Kommentare

Ein Kommentar zu “Die Sprint Retrospektive”

  1. Von Johannes Geske am Montag, 14. Dezember 2009 22:15

    Hi Carsten,

    toller Post! Ich habe gute Erfahrungen damit gemacht, Retrospectiven anhand des Burndown Charts des vergangenen Sprints einzuleiten. Auf diese Weise kann das Team gut erkennen, ob und wie sich bestimmte Ereignisse auf die Produktivität ausgewirkt haben. Gerade besondere Ereignisse haben meist eine entsprechende Wirkung auf den Burn Down.

    Siehe hier: http://www.scrumwanted.com/2009/11/improve-your-sprint-retrospectives/

    Viele Grüße

    Jo

Einen Kommentar hinzufügen...

Sie müssen registriert und angemeldet sein um einen Kommentar zu schreiben.