Szablon retrospektywy sprintu dla zespołów inżynierskich

Dlaczego większość retro nie przynosi zmiany

Retrospektywy sprintu mają strukturalny problem, którego szablony nie naprawiają: zespoły generują pomysły na usprawnienia, ale ich nie przeglądają. Retro wytwarza pięć zadań. Kolejna retro otwiera się z czystą kartą. Te same problemy wypływają ponownie.

Poniższy szablon wpieka przegląd w otwarcie, żeby nie dało się go pominąć. Ta jedna zmiana robi dla skuteczności retro więcej niż jakakolwiek korekta formatu.

Agenda (do skopiowania)

Czas trwania: 60 minut dla sprintu dwutygodniowego; 45 minut dla sprintu tygodniowego
Format: prowadzony, ze wspólną tablicą asynchroniczną (Miro, FigJam, Notion — do wyboru)

Sekcja 1 — Przegląd zadań (10 min)

Odczytaj zadania z zeszłego sprintu jedno po drugim
Oznacz każde: Zrobione / W toku / Porzucone (krótki powód porzucenia)
Przenieś dalej wszelkie niedokończone elementy; nie roztrząsaj ich teraz na nowo

Sekcja 2 — Migawka danych (5 min)

Velocity sprintu vs. cel
Praca nieplanowana, która przekroczyła jeden dzień
Incydenty lub zdarzenia dyżurowe
Zmiany zakresu w środku sprintu
Wrzuć dane na ekran, jeszcze bez dyskusji

Sekcja 3 — Co poszło dobrze (10 min)

Zespół dodaje elementy asynchronicznie przed spotkaniem lub w pierwszych 3 minutach
Omów 2–3 najważniejsze; pomiń elementy z oczywistą zgodą
Nie trać czasu na rzeczy, na których nie da się nic zrobić

Sekcja 4 — Co poprawić (15 min)

Ten sam format: wkład asynchroniczny, omawiaj elementy o najsilniejszym sygnale
Dla każdego elementu: zdarzenie jednorazowe czy powracający wzorzec? Tylko wzorce stają się zadaniami
Zadaniem facylitatora jest przekuć „to było frustrujące" w coś konkretnego i możliwego do zmiany

Sekcja 5 — Zadania (15 min)

Każdy element musi mieć: opis, jednego właściciela (nie „zespół"), termin
Celuj w maksymalnie 2–3 elementy; więcej rozwadnia odpowiedzialność
Przenieś dalej wszelkie niedokończone elementy z Sekcji 1

Zamknięcie (5 min)

Szybkie plus/minus/delta na temat samej retro
Potwierdź, że podsumowanie wyjdzie przed końcem dnia

Czego brakuje popularnym formatom retro

Start/Stop/Continue oraz Co poszło dobrze / Co poprawić / Zadania to oba prawidłowe formaty. Problem nie leży w formacie — leży w tym, że szablony rzadko kodują krok przeglądu na początku. To jedyny krok, który tworzy ciągłość odpowiedzialności od jednej retro do następnej. Bez niego retro jest maszyną do odczuć, a nie maszyną do zmian.

Szablony nie adresują też dyscypliny ograniczeń czasowych. „Co poprawić" niemal powszechnie się przeciąga, bo angażuje emocjonalnie bardziej niż „co poszło dobrze". Bez twardych ograniczeń 60-minutowa retro staje się 90 minutami dyskusji i 5 minutami pośpiesznych zadań na końcu. A zadania to jedyna część, która cokolwiek zmienia.

Trzecia luka: zadania zapisuje się jako mętne dyrektywy. „Poprawić komunikację frontend–backend" to nie jest zadanie. „Sarah zorganizuje cotygodniową 30-minutową synchronizację między liderami frontendu i backendu, począwszy od najbliższego poniedziałku" — to jest. Właściciel i data startu muszą zostać nazwane na sali — później konkrety miękną.

Kumulujący się koszt tych wzorców ujawnia się tygodnie później jako kontekst, którego nigdy nie zapisano, i decyzje roztrząsane na nowo. Podatek od spotkań omawia, jak wygląda to liczbowo w skali kwartału.

Dlaczego podsumowania retro są trudniejsze do napisania niż notatki ze standupu

Podsumowania standupu są krótkie. Podsumowania planowania sprintu są ustrukturyzowane. Podsumowania retrospektywy są trudne, bo treść jest chaotyczna — karteczki, dyskusja przeskakująca między sekcjami, mieszanka odczuć i danych. Ktokolwiek pisze podsumowanie, musi odtworzyć spójny wątek ze spotkania, które szło naraz w wielu kierunkach.

Pavleur radzi sobie z tym dobrze właśnie dzięki temu chaosowi. Przechwytuje wszystko, co powiedziano podczas spotkania, i to, co jest na ekranie — wspólną tablicę, wykres velocity z Sekcji 2, ticket incydentu, do którego ktoś się odniósł w Sekcji 4. Raport po spotkaniu jest ustrukturyzowany, z zadaniami wyciągniętymi z tego, co faktycznie postanowiono na sali (z właścicielami i datami, tak jak je nazwano). Bez odtwarzania, bez porządków po rozmowie.

Narzędzia do transkrypcji oparte tylko na dźwięku łapią słowa, ale nie kontekst wizualny. Na retro to właśnie wizualia są często najważniejszą częścią — tablica z karteczkami, wykres, który wyłonił wzorzec, ticket, który zakotwiczył dyskusję. Ten kontekst nie istnieje w podsumowaniu opartym tylko na dźwięku. Bezpośrednie porównanie narzędzi: Pavleur na tle alternatyw.

Częste tryby porażki retro

To samo zadanie pojawia się w trzech kolejnych retro. Sekcja 1 jest nienegocjowalna. Jeśli element wciąż nie zostaje zrobiony, albo porzuć go z podanym powodem, albo go eskaluj — nie przenoś go dalej w nieskończoność.

Dyskusja przechodzi w wyładowanie się bez rozwiązania. Zadaniem facylitatora w Sekcji 4 jest przełożyć „ten proces jest zepsuty" na jedną konkretną, możliwą do zmiany rzecz. Jeśli nie da się jej skonkretyzować w 30 sekund, trafia do poczekalni.

Nikt nie dodaje elementów asynchronicznie przed spotkaniem. Wyślij tablicę 24 godziny wcześniej. Zasiej ją 2–3 elementami, by przełamać problem pustej kartki. Spotkania idą lepiej, gdy każdy przychodzi z czymś zapisanym.