Retrospektywa jest odpowiedzią na 12. zasadę Manifestu Agile:
W regularnych odstępach czasu zespół analizuje możliwości
poprawy swojej wydajności, a następnie dostraja i dostosowuje
swoje działania do wyciągniętych wniosków.
Potężne narzędzie, które wykonane dobrze może przynieść nam wiele dobrego, ale jednocześnie, gdy wykonane zbyt mechanicznie i bez przemyślenia, może przynieść nam więcej szkody niż pożytku.
Wstęp
Dzisiaj chciałbym się z Wami podzielić Retrospektywą, którą miałem niedawno okazję poprowadzić we Włoszech, a jej celem było spojrzenie wstecz na ostatnie pół roku i wyciągnięcie wniosków ze współpracy na linii Zamawiający – Dostawca. I opracowanie planu usprawnień oczywiście 😉
Na samym spotkaniu pojawiło około 20 osób: kilku Product Ownerów, Scrum Master, programiści i inni członkowie zespołów. Branża typowo nie-agile’owa, projekt z zespołami rozproszonymi (dwa kraje europejskie), skomplikowaną historią (Waterfall -> Agile) i wieloma sytuacjami typu: My -> Oni.
Opanuj podstawy Product Discovery w 5 dni
Zapisz się na Product Discovery Academy FREE - 5-dniowy, darmowy kursu podstaw product discovery od Product Academy. Codziennie czeka na Ciebie rozbudowana lekcja wideo i materiały dodatkowe.
Retrospektywa to spotkanie szczególne. Wszystkie pozostałe spotkania w Scrumie dotyczą tego, żeby dostarczyć produkt (wartość). Natomiast omawiane spotkanie pozwala na to, żeby przez chwilę się zatrzymać i zastanowić się JAK to robimy i na ile dojrzały jest nasz proces wytwarzania (np. oprogramowania).
No to zaczynamy 🙂
Agenda spotkania
Plan naszej retrospektywy prezentował się następująco:
- Początek spotkania – Cel: wprowadzenie odpowiedniej atmosfery i nakreślenie kierunku spotkania
- “Timeline” – Cel: uwspólnienie wspomnień, przypomnienie sobie kluczowych zdarzeń i informacji
- “Weather report” – Cel: zebranie od wszystkich uczestników odczuć odnośnie bieżącej sytuacji w projekcie, pretekst do poruszenia konkretnych tematów związanych z dojrzałością procesu dostarczania wartości, rozgrzewka do kolejnego ćwiczenia
- “Speed car” – Cel: wygenerowanie listy spowalniaczy projektowych
- “Cause-effect diagram” – kontynuacja poprzedniego ćwiczenia, Cel: Burza mózgów mająca na celu znalezienie wszystkich możliwych przyczyn niepożądanych efektów (spowalniaczy)
- “Problem-solving tree” – Cel: burza mózgów mająca na celu wygenerowanie możliwych akcji naprawczych
- “Decide what to do” – Cel: wybieramy akcje naprawcze
- Końcówka spotkania – Cel: Podsumowanie spotkania
Rozgrzewka – „Timeline”
Cel ćwiczenia: Uwspólnienie wspomnień o okresie, który chcemy ocenić. Ćwiczenie pozwala na spojrzenie na omawiany okres z różnych perspektyw i tworzy solidną podstawę do kolejnych ćwiczeń.
Realizacja ćwiczenia:
- Tworzymy grupy maksymalnie 4-5 osobowe i rozdajemy karteczki post-it (Im mniejsze grupy tym lepiej – dlaczego to takie ważne, wyjaśnimy za chwilę)
- Przez 5-10 minut grupy generują wspomnienia (zdarzenia, sukcesy, porażki – wszystko co z jakiegoś powodu było ważne dla grupy)
- Przedstawiciele każdej z grup przenoszą „swoje” timeline’y na jeden wspólny
Dlaczego warto dzielić obecnych na spotkaniu na mniejsze grupy?
Jest to jeden ze sposobów na uniknięcie sytuacji, gdy osoby bardziej ekspresywne dominują spotkanie nie pozwalając na zebranie feedbacku od osób bardziej introwertycznych.
„Weather report”
Cel ćwiczenia: zebranie od wszystkich uczestników odczuć odnośnie bieżącej sytuacji w projekcie, (i pokazanie grupie, że ktoś może mieć inne zdanie ode mnie na dany temat – z różnych przyczyn) ale też pretekst do poruszenia konkretnych tematów związanych z dojrzałością procesu dostarczania wartości oraz idealna rozgrzewka do kolejnego ćwiczenia
Realizacja ćwiczenia:
- Do tego ćwiczenia posłuży nam przygotowana przeze mnie ankieta (Pobierz szablon)
- Na wstępie poruszam każdy z tematów – pierwsze 7 tematów to nic innego jak siedem marnotrawstw Kanbana.
- Kolejne sześć kategorii to tematy, na których zależało mi, żeby się im przyjrzeć w kontekście dyskusji nad dojrzałością procesu oraz możliwymi usprawnieniami: ścieżki eskalacji, zaangażowanie zespołu, bycie przygotowanym (do spotkań, do wdrożeń, do testów), na ile sprawne jest nasze środowisko testowe, jak często potrafimy wdrażać i jak dojrzały jest nasz proces dostarczania oprogramowania.
- O każdym temacie mówię 2-3 zdania i co one oznaczają w kontekście projektu. Każdy z uczestników wypełnia ankietę samodzielnie, a następnie nanosi swoje wyniki na wspólną tablicę
- Na koniec chwila na omówienie, niektórzy dzielą się swoimi wrażeniami z wypełniania takiej ankiety
Dodatkowe uwagi:
W tym ćwiczeniu nie o wyniki chodzi, choć duże rozbieżności przy niektórych tematach mogłyby sugerować, że różne strony patrzą na te same rzeczy pod innym kątem.
Może brakuje odpowiedniej wymiany informacji? Dodatkowo brakuje opisu co oznacza 1, a co oznacza 5. Dla mnie 4.5 może dla Ciebie oznaczać 3.5, itd.
Skoro nie wyniki tu były najważniejsze, to co? Istotą tego ćwiczenia jest przejście i zastanowienie się każdego z uczestników na każdy z zaproponowanych tematów. Ankieta niejako „zmusiła” każdą osobę do przemyślenia i oceny na ile dany temat to problem w naszym projekcie a na ile wszystko jest tutaj w porządku.
„Speed boat” (Speed car)
Cel ćwiczenia: wygenerowanie listy projektowych spowalniaczy (i przyśpieszaczy)
Realizacja ćwiczenia:
- Małe grupy (maksymalnie 4-5 osobowe) robią burzę mózgów i na karteczkach post-it generują odpowiedzi na pytania:
- [Karteczki czerwone/różowe] „Co takiego działo się w projekcie, że czuję, że nie pracowałem tak efektywnie jakbym mógł” lub „zespół nie pracował tak efektywnie jak by mógł”
- [Karteczki zielone/żółte] „Co takiego działo się w projekcie, że pracowałem / zespół pracował efektywnie, co nam pomagało”
Na koniec ćwiczenia reprezentanci każdej z grup przyklejają swoje karteczki na jedną dużą tablicę czytając na głos co zostało napisane
Na tym etapie nie zastanawiamy się jeszcze nad rozwiązaniami. Tutaj po prostu pozwalamy się wszystkim w pewien sposób „wyżalić”, ale jednocześnie jest miejsce na podkreślenie tych wszystkich elementów, które już działają.
To ćwiczenie ma swoją kontynuację. Tematów pojawiło się kilkanaście i aby zawęzić tematy do analizy i dyskusji zastosowaliśmy tutaj metodę priorytetyzacji zwaną potocznie „metodą trzech kropek”:
- Każda osoba ma do dyspozycji trzy kropki / głosy
- Można „wydać” swoje trzy kropki na trzy różne tematy lub zastosować inną kombinację: np. 2-1 lub nawet trzy kropki na jeden temat
- To ćwiczenie daje nam poczucie „sprawiedliwego wyboru”, przez to że każdy głos jest tak samo ważny i ciężko podważyć, dlaczego akurat rozmawiamy na te tematy, a nie na inne
Efekt:
Mamy posortowaną listę tematów do przeanalizowania i przedyskutowania, jednocześnie mamy bardzo fajny punkt odniesienia to przyszłych retrospektyw.
„Cause-effect diagram”
Cel ćwiczenia: Znalezienie źródła problemów, których przyczyny są trudne do zlokalizowania i prowadzą do niekończących się dyskusji
Realizacja ćwiczenia:
- W małych grupach (4-5 osób) robimy burzę mózgów w następujący sposób:
Napisz problem, który chcesz zbadać na karteczce i umieść go na środku tablicy. - Dowiedz się, jakie są podstawowe przyczyny, wielokrotnie zadając pytanie „Dlaczego (tak się dzieje?”)
- Udokumentuj swoje odkrycia, pisząc więcej drobiazgów i pokazując związki przyczynowe ze strzałkami.
Na ten moment nie omawiamy jeszcze żadnych możliwych rozwiązań, analizujemy tylko możliwe przyczyny.
Efekt: Rezultat jednej z grup
“Problem-solving tree”
Cel ćwiczenia: burza mózgów mająca na celu wygenerowanie możliwych akcji naprawczych
Przebieg ćwiczenia:
- W małych grupach (4-5 osób) robimy burzę mózgów w następujący sposób:
- problem do rozwiązania zapisujemy na górze tablicy
- podczas tego ćwiczenia grupy omawiały dokładnie te same tematy, co w poprzednim ćwiczeniu
- uczestnicy spisali pomysły na temat tego, co mogą zrobić, aby rozwiązać problem
na koniec głosowanie kropkami (wewnątrz grup), aby zdecydować, jakie działania naprawcze należy podjąć jako pierwsze
Efekt ćwiczenia: (na przykładzie jednej z grup)
“Decide what to do”
Wynikiem poprzedniego ćwiczenia są wybrane trzy akcje naprawcze, dla każdego tematu po jednym. Warto się tutaj chwilę zatrzymać, aby każda grupa mogła przedstawić nad czym pracowali i jaka akcja naprawcza została wybrana.
I teraz najważniejsza część spotkania: wybranie osób odpowiedzialnych za konkretne akcje naprawcze. To wcale nie znaczy, że ta osoba jest musi sama się uporać z danym tematem. Jej odpowiedzialność powinna się przynajmniej odnosić do popychania tematu do przodu, aby na następnej retrospekcji można było ocenić efekty tych działań.
Podsumowanie
Spotkanie retrospektywne wymaga kontynuacji w rozsądnym czasie. W przeciwnym razie zespół mógłby poczuć, że udzielanie informacji zwrotnych jest bezcelowe (ponieważ nic się nie zmienia). Nie ma też sensu robić kolejnej retrospektywy, o ile nie ma postępu w działaniach naprawczych (w przeciwnym razie będzie odczucie, że mówimy o tych samych kwestiach, ale nic się nie zmienia), natomiast nawet gdy taka sytuacja występuje – warto porozmawiać z zespołem i przedstawić skąd wynika ten stan rzeczy.
W internecie możecie znaleźć wiele pomysłów na udaną retrospektywę (choćby znany Retromat). Powyższy artykuł to sprawdzona w boju kombinacja poszczególnych ćwiczeń, która finalnie dała ciekawy efekt. Mam nadzieję, że zainspiruje Was to do poszukiwania i eksperymentowania z formułą retrospektywy.
Więcej o retrospektywach opowiem też podczas najbliższych szkoleń dla PO. Zapraszam 🙂 Szczegóły pod poniższym linkiem:
➔ Darmowy kurs product discovery ✨ - opanuj podstawy product discovery w 5 dni
