Retrospektywa

Retrospektywa (należy do podstawowych spotkań scrumowych) - jest okazją do sprawdzenia i dostosowania procesu działania zespołu. Jest to 1-3 godz. spotkanie z podziałem czasu (w zależności od długości sprintu) prowadzone przez Scrum Mastera, podczas spotkania cały zespół omawia zakończony Sprint i określa, co można zmienić, co może sprawić, żeby następny sprint był bardziej skuteczny lub produktywny [Scruminc, 2012].

Agile Manifesto sugeruje, że "zespół zastanawia się, jak stać się bardziej skutecznym" [Agile Manifesto, 2001].

TL;DR

Retrospektywa jest spotkaniem zespołu projektowego po zakończonym sprincie, mającym na celu ocenę procesu pracy i znalezienie sposobów na jego ulepszenie. Spotkanie składa się z kilku etapów, w których zespół analizuje wykonaną pracę, identyfikuje problemy i podejmuje decyzje dotyczące poprawek. Retrospektywa ma na celu ciągłe doskonalenie pracy zespołu. Ważne jest skupienie się na wartości biznesowej i konkretnych działaniach, które poprawią efektywność zespołu.

Cel retrospektywy

Po zakończeniu iteracji zwykle odbywają się dwa spotkania:

• Sprint Review - przegląd sprintu (lub demo), koncentruje się na uzyskiwaniu informacji zwrotnej o produkcie i omawianiu sposobu postępowania
• Retrospective - retrospektywa, koncentruje się na zespole i procesach używanych dla dostarczania oprogramowania.

Celem retrospektyw jest pomaganie zespołom w ciągłym ulepszaniu ich pracy. Zwinna retrospektywa, w Scrumie, jest praktyką stosowaną przez zespoły do refleksji na temat sposobu pracy i ciągłego doskonalenia się w tym, co robią.

Szczegółowe cele dla retrospektyw są następujące:

• Znalezienie sposoby na ulepszenie używanych praktyk
• Odkrycie, co jest robione dobrze
• Zapoznanie się z przyczynami nieudanych celów
• Znalezienie sposoby na poprawę reakcji zespołu na klientów
• Odbudowanie uszkodzonych relacji [Derby E., Larsen D. 2006, s. 17]

Układ retrospektywy

Układ retrospektywy zależy od:

• Długości iteracji
• Złożoności (technologii, relacje z zewnętrznymi działami, organizacja zespołu)
• Rozmiaru zespołu
• Poziomu konfliktu lub kontrowersji [Derby E., Larsen D. 2006, s. 17]

Przykładowy podział czasu przy retrospektywie:

• Set the stage (Przygotuj się) 5%

Ustawienie sceny (przygotowanie) wymaga powitania i wyjaśnienia celu spotkania.

• Gather data (Zbierz dane) 30-50%

Gromadzenie danych dotyczy pracy w ostatnim sprincie. Dla podjęcia decyzji w kierunku polepszenia pracy zespołu niezbędnym jest opis zdarzeń w sprincie.

• Generate insights (Wygeneruj spostrzeżenia) 20-30%

Jest czasem na przemyślenie, znalezienie przyczynowo-skutkowego związku pomiędzy zdarzeniami.

• Decide what to do (Zdecyduj, co zrobić) 15-20%

Decydujemy co chcemy zrobić z występującymi problemami.

• Close the retrospective (Zamknij retrospektywę) 10%

Zamykanie spotkania jest wyciągnięciem wniosków i czasem na ocenę skuteczności właśnie retrospektywy.

• Shuffle time (Czas dodatkowy) 10-15%

Dodatkowy czas jest potrzebny, aby objąć wszystkie fazy. Ludzie potrzebują czasu, dla przejścia z jednej czynności do drugiej [Derby E., Larsen D. 2006, s. 19; Andriyani Y., Hoda R., Amor R. 2017, s. 15]

Z zespołem, który jest nowy w retrospektywach, można skorzystać z czterech kluczowych pytań, które zdefiniował Norman Kerth:

• 1. Co zrobiliśmy dobrze?

Podejście skoncentrowane na rozwiązaniach, opartych na sile. Musimy podkreślać udane czynności w zespole.

• 2. Czego się nauczyliśmy?

Uświadamia ludziom, że aby stać się lepszymi, będą musieli się uczyć.

• 3. Co powinniśmy zrobić inaczej?

Zachęca członków zespołu do szukania rzeczy, które chcą zmienić. Często pomaga to ułatwić dyskusję, dowiedzieć się, dlaczego trzeba zmienić proces i zbudować wspólne zrozumienie i zaangażowanie w działania, które zespół wykona.

• 4. Co nadal nas wstrzyma?

Może ujawniając rzeczy, które poprzednio były niewypowiedziane [Gonçalves L., Linders B. 2013, s. 8-9]

Wartość biznesowa a Retrospektywa

Kilka rzeczy, które można zrobić w czasie retrospektywy, aby podnieść wartość biznesową:

• Uświadomienie zespołowi, że szukamy działań, które mogą wzmocnić zespół
• Skupić się na uczeniu się i zrozumieniu zamiast obciążenia odpowiedzialnością
• Ograniczenie liczby problemów i przedmiotów, które omawiasz w czasie retrospektywy. Lepiej mieć kilka działań wysokiej jakości, niż wiele z ryzykiem, że nie zostaną wykonane. Warto zmienić tylko jedną rzecz na raz.
• Skoncentrowanie na jasno zdefiniowanych problemach i pomoc zespołom znaleźć działania usprawniające, które są dla nich ważne,aby ich działalność była lepsza.
• Użycie analizy przyczyn źródłowych, aby znaleźć przyczyny problemów. Następnie określenie działania, aby zapobiec ich ponownemu występowaniu.
• Kontynuacja i ocena postępów działań, aby pomóc zespołowi zrozumieć, dlaczego niektóre działania zadziałały, a inne nie i sprawienie, by postęp był widoczny.
• Użycie różnych ćwiczeń w retrospektywach w zależności od problemów, sposobu myślenia zespołu itp [Gonçalves L., Linders B. 2013, s. 3-4].

Retrospektywa — artykuły polecane

Metodyka Extreme Programming — Backlog produktu — RACI — Daily scrum — Feature-Driven Development — Cykl Deminga — Sprint — Facylitacja — Metody szkoleń

Bibliografia

• Agile Manifesto (2001), Principles behind the Agile Manifesto
• Andriyani Y., Hoda R., Amor R. (2017), Reflection in Agile Retrospectives, University of Auckland, New Zealand
• Derby E., Larsen D. (2006), Agile Retrospectives Making Good Teams Great, Pragmatic Bookshelf, USA
• Gonçalves L., Linders B. (2013), Getting Value out of Agile Retrospectives, Leanpub
• Scruminc (2012), 3 Steps to an Effective Retrospective

Autor: Serhiienko Maiia