Scrum Retrospektive während der Ferienzeit

Die Frage kurz: Wie sollen wir mit einer Scrum-Retrospektive umgehen, wenn die Kapazität des Teams sehr gering war?

Hintergrund

Wir haben ein Team von 6 Personen: 1 PO, 4 Entwickler (davon 1 Teilzeit am Montag und Freitag) und 1 Entwickler/SM (ich). Wir haben einen einwöchigen Sprint, der am Montag beginnt und am Freitag um 9 Uhr endet, wobei die Retrospektive ebenfalls am Freitag stattfindet.

Aufgrund unterschiedlicher Sommerferien würde unsere Sprint-Retrospektive morgen mit einem Entwickler stattfinden, der von Dienstag bis Freitag gearbeitet hat, dem Teilzeitentwickler (der an diesem Montag nicht gearbeitet hat) und mir, nachdem ich die ganze Woche gearbeitet habe.

Ich bin dafür, die Retrospektive nicht ausfallen zu lassen, weil ich das Anschauen und Anpassen wichtig finde. Allerdings befürchte ich, dass wir daraus keinen großen Mehrwert ziehen werden, da nur die Hälfte des Teams vor Ort sein wird und nur zwei von ihnen tatsächlich im Sprint gearbeitet haben.

Wäre es sinnvoll, für diesen Sprint noch eine Retrospektive abzuhalten? Wenn ja, welche Art von Aktivitäten wären für diese Art von Retrospektive mit geringer Kapazität sinnvoll? Wenn nicht, sollten wir es ganz überspringen oder versuchen, es auf einen anderen Zeitpunkt zu verschieben?

Alle sind vernünftige Optionen. Ich könnte auch erwägen, die Feiertagswoche als speziellen Sprint mit geringer Kapazität oder sogar nur als „freie Woche“ zu behandeln, um Teammitgliedern die Möglichkeit zu geben, individuelle Technologieschulden aufzuholen. Welchen Reifegrad hat dieses Team?
Wir sind noch ein junges Team; das Ergebnis einer Verschmelzung eines stabilen und leistungsstarken Teams und eines kämpfenden Teams mit Epics von hoher Priorität. Leider ist mit den Prioritäten, wie sie sind, eine „Off Week“ derzeit nicht möglich.

Antworten (4)

Fragen Sie die an der Retro teilnehmenden Personen, ob dies erforderlich ist. (Oder noch besser, fragen Sie, ob sie sich etwas für die Retro überlegt haben).

Vielen Dank. Ich habe das Team gefragt und wir haben beschlossen, es durchgehen zu lassen. Wir haben eine einfache Aktivität durchgeführt, wie @BenLinders vorgeschlagen hat.
Cool! Wie ist es gelaufen?

Angesichts der Tatsache, dass die Weihnachtszeit besondere Herausforderungen für das Team mit sich bringen wird (z. B. ein unvollständiges Team, mit dem Sie es gerade zu tun haben), könnte es gut sein, dies zum Thema der nächsten Retrospektiven zu machen.

Versuchen Sie in Bezug auf die zu verwendende Übung, sie einfach zu halten. Ein Start, Stopp, Weiter (oder meine Variante Start, Aufpeppen, Stopp ) könnte geeignet sein. Oder eine Aufstellung, bei der man abwesende Personen mit etwas Bild einbringen könnte.

Führen Sie am Ende des retrospektiven Meetings eine Plausibilitätsprüfung der Aktionen durch und fragen Sie den Teilnehmer, wie er über das Meeting denkt. Verwenden Sie ihr Feedback, um das Format und das Thema anzupassen.

Ihre Gedanken dazu?

Danke für deinen Vorschlag. Wir haben uns für eine kurze Aktivität entschieden ( retromat.org/en/?id=73 ), die einige interessante Einblicke gebracht hat.
Großartig, ich freue mich zu sehen, dass mein Vorschlag, eine einfache Übung zu verwenden, für Sie funktioniert hat.

Natürlich ist es am besten, bei jeder Retro das gesamte Scrum-Team dabei zu haben. Ich würde dazu ermutigen, die Retro immer mit so vielen Leuten wie möglich abzuhalten. Ich scherze, dass ich „Scrum-Team-Bingo“ spiele, wo ich einen Punkt für jede einzigartige Kombination von Scrum-Team-Mitgliedern bekomme, die ich in einem Retro hatte. Aber im Ernst, jede Kombination von Scrum-Teammitgliedern erzeugt eine einzigartige Dynamik und bringt fast immer neue Erkenntnisse zustande. Etwas, das man natürlich vermeiden sollte, ist „hinter dem Rücken von jemandem zu reden“. Wenn dies jedoch passieren sollte, wäre dies eine gute Gelegenheit, die Angst vor Konflikten oder die Vermeidung von Verantwortlichkeit zu diskutieren (zwei der fünf Dysfunktionen eines Teams ).

Das Überspringen des Retro wäre ein Anti-Pattern. Wenn die Kapazität aufgrund von „OOO“ begrenzt ist, ist es ein guter Zeitpunkt, die funktionsübergreifenden Grenzen des Teams einzuschätzen. Welche Qualifikationslücken haben wir? Was könnten wir in Zukunft dagegen tun? Gute Sachen zum Aufdecken!