Retro nie usprawnia Twojego zespołu? 🤔 Sprawdź nasz webinar, jak robić porządną Retrospektywę 🔥

Porządna Retrospektywa Sprintu

Jeśli mielibyśmy robić tylko jedno wydarzenie scrumowe w zespole, robilibyśmy Retrospektywę. W tym materiale definiujemy, czym jest porządna retrospektywa Sprintu i jak może wyglądać jej właściwa struktura oraz przestrzegamy przed kilkoma niedociągnięciami, jakie często spotykamy.

Jednym z wydarzeń Scruma jest Retrospektywa Sprintu. Ma ona ogromne znaczenie dla pracy Zespołu Scrumowego, a to, jak poważnie do niej zespół podchodzi wpływa na proces usprawniania ich pracy.

Czym jest Retrospektywa Sprintu?

Retrospektywa Sprintu jako praktyka ma swoje korzenie w ostatniej z „Zasad stojących za Manifestem Zwinnego Wytwarzania Oprogramowania”, mówiącej o tym, że zespoły w trybie ciągłym usprawniają swój proces pracy.

Retrospektywa Sprintu – definicja

Retrospektywa Sprintu jest regularną okazją dla Zespołu Scrumowego do porozmawiania na temat tego, jak może usprawnić on swój proces pracy we wszystkich możliwych aspektach. Istotne jest też to, by usprawnianie pracy realizować jako zespół profesjonalistów, którzy wspólnie odpowiadają za dostarczanie wartości biznesowej w jak najbardziej efektywny sposób. Dobry Zespół Scrumowy ciągle poszukuje coraz lepszych sposobów swojej pracy, ciągle się uczy i próbuje usprawniać swoje procesy.

Definiując Retrospektywę Sprintu z perspektywy Scruma warto podkreślić, że jest to wydarzenie, które następuje po każdym Przeglądzie Sprintu i kończy cały Sprint. Cały Zespół Scrumowy (Developerzy, Scrum MasterProduct Owner) rozmawiają o tym, jakie są możliwe usprawnienia, wnioskując na bazie wykonanego Przyrostu i zakończonego Sprintu. Poprzez retro Zespół dokonuje inspekcji i adaptacji procesu swojej pracy.

Kiedy i jak często odbywa się Retrospektywa Sprintu?

Bardzo istotne jest to, by podkreślić moment przeprowadzania retro. Retrospektywa Sprintu powinna kończyć każdy Sprint. Jednym z popularnych antywzorców jest pomijanie tego wydarzenia i płynne przejście od przeglądu poprzedniego Sprintu do planowania kolejnego Sprintu. Dzieje się tak, zwłaszcza gdy Zespół skupia się na przeglądaniu zadań w Backlogu Sprintu i spontanicznie zaczyna rozmawiać (ze sobą lub z interesariuszami) o kolejnych możliwych zmianach w produkcie. Oczywiście taka płynność w dyskusji po Sprincie nie przekreśla wdrożenia nowych usprawnień, jednak rekomendujemy domknięcie jednego Sprintu przed rozpoczęciem planowania kolejnego i rozdzielenie tych aktywności wyraźnie zaznaczonym spotkaniem usprawnieniowym. Dzięki temu Zespół nie pominie refleksji nad tym, które aspekty pracy chce usprawnić lub jakie eksperymenty rozpocząć. Retrospektywa Sprintu powinna się odbyć przed Planowaniem kolejnego Sprintu, ponieważ wyniki ustaleń (decyzje lub działania usprawnieniowe) mogą mieć duży wpływ na plan kolejnego Sprintu.

Przedostatnia wersja Scrum Guide (przed aktualizacją Scruma z 2020) bardzo wprost rekomendowała, by z każdej Retrospektywy wynikało przynajmniej jedno usprawnienie. W wielu przypadkach może to oznaczać pracę do wykonania, którą należy umieścić w planie kolejnego Sprintu.

Czy można działać Scrumem bez Retrospektywy Sprintu?

Jeśli sami mielibyśmy wybrać tylko jedno wydarzenie w Scrumie, które możemy przeprowadzić, to byłaby to właśnie Retrospektywa Sprintu. Uważamy, że bez przeprowadzenia procesu usprawniania pracy Zespołu Scrumowego straci jeden z fundamentów zwinności. W takiej sytuacji istnieje zagrożenie, że zespół będzie działać miesiącami, a nawet latami bez żadnych ulepszeń, powtarzając te same błędy i tracąc okazję do zmian.

Widzieliśmy sporo zespołów, które próbowały wybierać niektóre elementy Scruma. Zdecydowanie możemy powiedzieć, że jeśli zespół tworzy regularnie Przyrost i organizuje sobie Retrospektywę po zrealizowaniu tego przyrostu, istnieje duża szansa, że cała reszta Scruma wyłoni się mu automatycznie.

Jak przeprowadzić porządną Retrospektywę Sprintu?

Co ma wpływ na skuteczne przeprowadzenie Retrospektywy? Co zrobić, aby Zespół chciał uczestniczyć w tych spotkaniach i aktywnie brał w nich udział, wierząc w ich sens i zasadność?

Struktura Retrospektywy Sprintu

Przede wszystkim zadbaj o strukturę Retrospektywy, czyli sposób, w jaki spotkanie jest realizowane

Jeśli prowadzisz retro, pilnuj, aby czas poświęcony na Retrospektywę nie przerodził się w planowanie kolejnego Sprintu lub dyskusję o pomysłach na zmiany w Przyroście. Spotkanie to nie powinno mieć formy luźnej pogadanki, bez konkretnego pomysłu na jej przebieg. Warto ustalić kto rozpoczyna spotkanie (zwykle jest to Scrum Master), jaka jest zastosowana technika dochodzenia do przemyśleń i ustaleń oraz zapewnić możliwość aktywnego udziału każdego uczestnika.

Dobrym przykładem struktury jest ta zaproponowana przez Esther Derby w książce „Agile Retrospectives”.

5 kroków Retrospektywy Sprintu wg książki „Agile Retrospectives”:

  • otwarcie Retrospektywy,
  • zebranie danych, czyli co się działo w trakcie Sprintu i jakie tematy istotne dla zespołu,
  • wygenerowanie spostrzeżeń,
  • wygenerowanie konkretnych akcji,
  • zamknięcie spotkania

    Poniżej opisujemy szczegółowo każdy z kroków tej struktury.

1. Otwarcie Retrospektywy

Podczas pierwszego kroku, czyli otwarcia Retrospektywy, wyjaśnij jaki jest cel tego wydarzenia Scrumowego. Wszyscy uczestnicy spotkania powinni mieć świadomość: po co się spotykamy, co chcemy osiągnąć i do czego dążymy? Zwłaszcza w początkującym Zespole Scrumowym jest to okazją do przypomnienia, na czym polega Scrum i jego poszczególne elementy. Otwarcie Retrospektywy jest też dobrym miejscem na wprowadzenie nowego pracownika do zespołu lub wyjaśnienie planowanego przebiegu spotkania.

Rozgrzewki na początku Retrospektywy

Otwarcie możesz wykorzystać do wprowadzenia ćwiczenia  typu „icebreaker” czyli rozgrzewki przed rozmową na trudniejsze tematy. Rozgrzewki przydają się zwłaszcza tym osobom, które zwykle są mniej zaangażowane w dyskusje. Wykonując krótkie ćwiczenie (najczęściej w postaci dość spontanicznej i lekkiej wypowiedzi) Ci bardziej nieśmiali albo wycofani mają już pierwszy krok za sobą w odezwaniu się do pozostałych. W późniejszych etapach spotkania łatwiej będzie im wejść w dyskusję. Jest wiele technik (mniej lub bardziej szalonych), ale sami preferujemy raczej bardziej stonowane podejście. Ważne jest jednak to, by otwarcie potraktować jako szybką rozgrzewkę i rozbudzenie zespołu, więc nie zwróć uwagę, by nie skonsumowało zbyt dużo czasu.

Jednym z prostszych ćwiczeń, jakie możesz zaproponować, jest zadanie całemu zespołowi pytania o to, jak oceniają pracę w ostatnim Sprincie. Poproś o ocenę Sprintu w skali 1-5 przez każdego członka zespołu albo opisanie go jednym słowem. Takie proste pytanie skłania do zastanowienia się nad tym jak się każdemu członkowi Zespołu pracowało, a Tobie jako osobie prowadzącej pozwala szybko rozeznać się jakie są nastroje czy nastawienia różnych osób.

Możesz jako alternatywę na rozgrzewkę wykorzystać technikę Check-in z Core Protocols. To może być bardzo pomocne jeśli wiesz, że czekają Twój Zespół rozmowy na poważne tematy, przykładowo, ponieważ coś w Sprincie poszło bardzo źle.

2. Zbieranie danych

Po otwarciu pora na drugi krok, czyli zebranie danych. W tym etapie zaangażuj wszystkich członków Zespołu Scrumowego w proces definiowania i zbierania wszystkiego, co wydarzyło się w trakcie Sprintu i jest warte omówienia, by na tej bazie uzyskać usprawnienie.

W tym etapie każdy członek zespołu ma okazję wyrazić swój punkt widzenia. Efektem tego jest zebrana (zwykle duża) pula tematów, które z perspektywy zespołu są istotne. Rolą facylitatora jest pozwolenie wszystkim wypowiedzieć się w pełni, a także motywowanie do podzielenia się swoimi spostrzeżeniami i wnioskami, nawet jeśli wyrażają niepopularną myśl. Stąd też istotne jest sformułowanie pytania, na które zespół odpowiada, tak aby było zrozumiałe i zachęcające do wypowiedzi.

Przy zbieraniu danych, tak jak przy otwarciu, można skorzystać z wielu technik. Na początek proponujemy coś prostego, np. technikę Start-Stop-Continue albo Starfish (rozgwiazda).

Ponieważ etap zbierania danych generuje zwykle wiele tematów, ważne, aby osoba moderująca spotkanie doprowadziła do ich grupowania i syntezy, tak aby wchodząc w kolejny etap mieć już wybrane kilka konkretnych z nich. Nie chodzi o to, aby przegadać wszystkie zgłoszone wątki, a wybrać te 3-5 najważniejszych dla Zespołu i na nich się skupić w pierwszej kolejności.

3. Wygenerowanie spostrzeżeń

Gdy masz już zebrane i poukładane dane, przychodzi pora na ich zgłębienie i wygenerowanie spostrzeżeń.

Ponownie pamiętaj o możliwości wypowiedzenia się swobodnie każdego z członków zespołu. Rekomendujemy mocno poeksplorować, jakie Zespół widzi opcje i pomysły na to, jakie są możliwe rozwiązania na dany problem. Spróbuj zachęcić uczestników, by nie „wskakiwali” za szybko w pierwsze rozwiązanie, jakie komukolwiek przyszło do głowy.

Obserwując Retrospektywę, bardzo często można doświadczyć efektu kuli śnieżnej, gdzie każdy z członków dzieli się swoim pomysłem i efekcie wzajemnej inspiracji pojawiają się zupełnie nowe, jeszcze lepsze rozwiązania. Nie wyłoniłyby się one bez dania szansy na podzielenia się wszystkimi opcjami z innymi członkami lub przez szybkie wybranie pierwszego z rozwiązań.

Pamiętaj też, że Twój Zespół nie musi wybierać tylko jednego rozwiązania jako usprawnienie. Jeśli ma to sens w danym kontekście, zaproś członków zespołu do eksperymentu i poproś o przetestowanie kilku rozwiązań jednocześnie albo w niewielkich odstępach czasowych. Gdyby uczestnicy rozmowy usprawnieniowej zbyt mocno zablokowali się na konieczność znalezienia rozwiązania perfekcyjnego, przypomnij Zespołowi, że będą kolejne Sprinty, w których również będzie można zmienić podejście, jeśli wybrany obecnie pomysł jednak się nie sprawdzi.

Przestrzegamy jednak przed narzucaniem przez moderatora swoich przekonań i wprowadzania na siłę swojego z góry ustalonego rozwiązania. Scrum Master powinien moderować grupę, facylitować dyskusję, dorzucić swoje pomysły (jeśli w kontekście dyskusji jest to adekwatne), ale warto powstrzymać się przed narzucaniem swojego zdania.

Retrospektywa Sprintu - Przykład struktury autorstwa Esther Derby z książki „Agile Retrospectives” I krok – otwarcie Retrospektywy, II krok – zebranie danych, czyli co się działo w trakcie Sprintu i jakie tematy istotne dla zespołu, III krok – wygenerowanie spostrzeżeń, IV krok – wygenerowanie konkretnych akcji, V krok – zamknięcie spotkania.

4. Wygenerowanie akcji

Ten krok struktury Retrospektywy to moment, aby przejść do określenia konkretnych akcji do wykonania. Pora na ustalenie co, kto i kiedy zrobi, by zmienić sposób działania Zespołu Scrumowego. Jeśli przyporządkowywanie się do działań wychodzi w Zespole spontanicznie, sprawdź czy wszyscy dokładnie rozumieją to, co należy zrobić i dlaczego.

Zadbaj o to, by powstał konkretny plan realizacji zadań, a nie tylko lista pomysłów i usprawnień bez żadnych wzajemnych zobowiązań i konkretów. Upewnij się też, że Zespół podjął się takiej liczby akcji, które faktycznie jest w stanie zrealizować w jednym Sprincie (i dalej być w stanie zrealizować Cel Sprintu).

5. Zamknięcie spotkania

Ostatnim krokiem struktury, po tym, gdy są ustalone akcje do wykonania, jest upewnienie się, że cały zespół je akceptuje. Domknięcie spotkania to moment na głośne powtórzenie ustaleń przez Scrum Mastera lub ochotników z zespołu. Mocno rekomendujemy, by zebrać plan działania w formę wizualną, którą łatwo szybko przejrzeć lub do niej wrócić po paru dniach.

Jako osoba facylitująca Retrospektywę pozwól wszystkim na komunikat “nie, jednak nie zgadzam się z tym punktem”. Lepiej, jeśli członek Zespołu przekaże swoje veto w trakcie retro a nie w trakcie Sprintu.

Ile powinna trwać Retrospektywa Sprintu?

Poruszając temat Retrospektywy i jej struktury, warto wspomnieć, że dobrą praktyką jest poukładanie jej czasowo. Określ sobie i uczestnikom czas przewidywany na każdy jej etap i limit czasowy na całość wydarzenia. Jeśli nie masz lepszego pomysłu – zacznij od godziny albo półtora na całe spotkanie.

Pamiętaj, aby być elastycznym – nawet jeśli zadeklarujesz sobie, że otwarcie ma trwać 5 minut, a okaże się, że potrzebne jest jednak więcej czasu, to pozwól sobie na to. To nie jest tak, że każdy krok ma swój z góry nakazany czas. Właściwe wyczucie elementów przychodzi z doświadczeniem i naturalne jest to, że na początku nie zawsze trafisz z dobrym limitem czasowym na ćwiczenie albo całe spotkanie.

Ustalanie struktury Retrospektywy może być trudnym zadaniem zwłaszcza dla początkujących moderatorów i początkujących zespołów. Ważne jest, żeby tylko struktura nie przysłoniła sensu całego wydarzenia, czyli dostarczania lepszej wartości i wdrażania usprawnień.

Może się też zdarzyć tak, że dołączysz na spotkanie z przygotowaną wcześniej strukturą wydarzenia, ale okaże się, że sytuacja wymaga zmiany tego planu. Odważ się w takiej sytuacji na otwartość i nie bój się powiedzieć: „ok, ta technika nie działa w naszym kontekście, spróbujmy czegoś innego”. Podziel się z Zespołem swoimi spontanicznymi pomysłami i nie bój się eksperymentować „na żywo”, jeśli okoliczności Cię do tego zmuszają.

Jeśli chcesz poznać więcej technik, które możesz wykorzystać w swoim zespole to polecamy Ci wspomnianą wcześniej książkę “Agile Retrospectives” oraz stronę Retromat – Plans for Retrospectives. Pamiętaj jednak, że mają one służyć przede wszystkim usprawnieniom, a nie być tylko grą i zabawą samą w sobie. A jeśli nadal czujesz niedosyt wiedzy o tym, czym jest Retrospektywa Sprintu, sprawdź nasz webinar Porządna Retrospektywa Sprintu.

Obejrzyj nasze webinary!

Rozbuduj wiedzę, którą przekazujemy w podcastach.
Zobacz nasze materiały premium:

Dodatkowe materiały w temacie „Porządna Retrospektywa Sprintu”

Transkrypcja nagrania "Porządna Retrospektywa Sprintu"

Jacek: Dzisiejszy odcinek poświęcimy na rozmowę o tym, jak przeprowadzić porządne Retro, czyli porządną Retrospektywę. Zaczniemy od zdefiniowania, czym jest Retrospektywa Sprintu? Później przejdziemy do tego, jak zrobić porządną Retrospektywę. Na koniec odcinka podsumujemy całą rozmowę i najważniejsze punkty, które poruszymy. Czym jest Retrospektywa Sprintu? Co to jest dobra Retrospektywa Sprintu, Kuba?

Kuba: Zanim nazwę, zdefiniuję Retrospektywę Sprintu, to coś, co od czego bym wyszedł to, to nawet jeśli nie chcemy perspektywą Scruma, to Retrospektywa Sprintu ma swoje korzenie w ostatniej z wymienionych zasad, stojących za Manifestem Zwinnego Wytwarzania Oprogramowania, czyli wytyczną, czy wskazówkę o tym, że zespoły w trybie ciągłym usprawniają swój proces pracy. To jest dla mnie najważniejsza definicja Retrospektywy, nawet wychodząc trochę właśnie poza takie definicje scrumowe, czy Przewodnika po Scrumie. Retrospektywa Sprintu to jest moment, czy to jest ta regularna okazja, żeby zespół porozmawiał na temat tego, jak usprawnia swój proces pracy we wszystkich możliwych aspektach, bo to łatwo definiować też poprzez przykłady. Usprawnia swój proces pracy jako zespół. Usprawnia swój sposób pracy jako profesjonaliści, czyli swój warsztat pracy. Usprawnia się też jako część organizacji, czyli zespół w kontekście innych zespołów w firmie, w kontekście procesów ogólnofirmowych. No i też jest wymiar, zespół jako jakaś taka cząstka, czy może jedyna forma dostarczania wartości biznesowej. Czyli ta perspektywa, jak nam idzie dostarczanie wartości, dla Klienta, dla Użytkownika, dla odbiorcy. Jak możemy to robić jeszcze lepiej?

Jacek: Wspominasz o Manifeście Agile. Na samym początku, jak jest definiowany, to jest tam też taka formuła mówiąca o tym, że poszukujemy lepszych sposobów wytwarzania oprogramowania. Więc czasami myślę sobie o Manifeście Agile, że to jest tylko taki punkt w czasie, w którym grupa mądrych osób zebrała wiedzę ze swoich głów i nazwała to Manifestem Agile. Natomiast takim absolutnym DNA Manifestu, jest to, że to, co tak naprawdę nas interesuje, to jest poszukiwanie lepszych sposobów pracy. I to szeroko rozumianych. Współpracy między ludźmi, technologii, współpracy z biznesem i tak dalej. Tak więc, jakby samo podejście zwinne, tak się głębiej zastanowić, opiera się na tym, że jedyne czego możemy być pewni to to, że będziemy się zmieniać, że będziemy się usprawniać, że będziemy szukać lepszych sposobów na robienie tego, co robimy dzisiaj.

Kuba: Że będziemy próbować. Bo to nie zawsze jest tak, że prostą drogą do usprawnienia. Czasem będzie też próba, która niekoniecznie wyjdzie. I to też jest OK, bo się ciągle uczymy. Natomiast taka definicja Retrospektywy Sprintu, czysto scrumowa, no to jest to wydarzenie scrumowe, kończące Sprint, kończące iterację, następujące po każdym przeglądzie Sprintu, na którym cały Zespół Scrumowy uczestniczy, rozmawia o tym, jakie są możliwe usprawnienia, wnioskując na bazie do tej pory wykonanego przyrostu, na bazie przepracowanego Sprintu. Dokonuje inspekcji i adaptacji procesu pracy siebie jako Zespołu Scrumowego. I to jest specjalnie taka generyczna formuła, czy generyczna definicja, bo tych rzeczy, które mogą podlegać usprawnieniom, zawsze jest więcej, niż dany zespół jest w stanie przepracować w danym momencie. Zawsze coś jest do poprawy, tu jest jednak ta myśl. Zawsze jest coś do usprawnienia. Zawsze jest coś, co może być jeszcze lepiej.

Jacek: Cieszę się, że wspomniałeś tak wyraźnie o tym, kiedy pojawia się Retrospektywa Sprintu, w sensie, gdzie jest jej miejsce w Sprincie. Dlatego, że często spotykam się z sytuacją, w której Sprint się kończy. Następuje, bądź nie następuje jakaś tam forma przeglądu Sprintu. Częściej nie następuje. Ona się płynnie zamienia w planowanie Sprintu, no bo w sumie jak już mówimy o tym, czego nie dostarczyliśmy, no to od razu przerzućmy w Jirze do kolejnego Sprintu. Dopiero gdzieś później, już po zaplanowaniu Sprintu jest przerwa i zespół podejmuje decyzje – to jeszcze Retrospektywa Sprintu. Jak już mamy Sprint zaplanowany, to zróbmy Retrospektywę. Wydaje mi się, że nie przekreśla nam tych usprawnień, które podczas takiej Retrospektywy się pojawiają, natomiast uważam, że bardzo sensowne jest domknąć kończący się Sprint. Podsumować, zastanowić się, które aspekty pracy chcielibyśmy usprawnić. Jakie eksperymenty chcielibyśmy rozpocząć. Tak, żeby ten nowy Sprint zaplanować już z tą wiedzą, która wypłynęła podczas Retrospektywy. Może się zdarzyć, że te pomysły na usprawnienia, które mamy, one będą dotyczyć już początku Sprintu, czyli planowania Sprintu. Być może inaczej podejdziemy do zastanowienia się, jaką mamy pojemność zespołu? Może trochę inaczej podejdziemy do tematu celu Sprintu? Może trochę inaczej podejdziemy do tego, co będziemy prognozować jako zakres. Tak więc miejsce Retrospektywy w całej tej strukturze uważam, że jest nieprzypadkowe i faktycznie bardzo się trzymam tego, żeby to spotkanie zamykało Sprint, żeby w nowy Sprint wejść z nowymi ustaleniami.

Kuba: Do tych argumentów dodałbym jeszcze to, że zresztą uwypuklone w najnowszej aktualizacji Przewodnika po Scrumie jest też to, że każda Retrospektywa Sprintu powinna kończyć się ustaleniem przynajmniej jednego usprawnienia. Co może w wielu przypadkach, po prostu oznaczać pracę do wykonania. Czyli zespół sobie najpierw zaplanował Sprint. Załóżmy niestety na przykład do pełna, absolutnie nie zostawiając sobie żadnego miejsca. Po czym na przykład wymyślił – nie wiem – w kilka godzin wewnątrz całego Sprintu poświęcimy na jakąś zmianę narzędzi, albo poświęcimy na wymianę wiedzy. I nagle się okazuje, że w najbliższym Sprincie to nie ma już miejsca, bo jest zaplanowany pod korek. Albo wracamy do planowania, wywalamy coś z Backlogu Sprintu, bo podjęliśmy decyzję, że w ramach usprawnienia wrzucamy coś zupełnie innego, coś, czego się nie spodziewaliśmy.

Jacek: Jeśli chodzi o Retrospektywę, myślę, że gdybyśmy się zabawili w takie pytanie – gdybyś miał robić jedno wydarzenie w Scrumie, to jakie byś robił? W ciemno strzelam, że byśmy oboje wskazali, że jest to Retrospektywa Sprintu. Przynajmniej ja powiem za siebie.

Kuba. Tak, zdecydowanie też się z tym zgadzam.

Jacek: Podchodzę do tego w ten sposób. Jeżeli nie mamy nic, ale mamy proces usprawniania się, w  jakikolwiek sposób zrealizowany. To najprawdopodobniej, jesteśmy sobie w stanie, tak to formułuję, że matematycznie wyprowadzić kolejne rzeczy. Natomiast, jeżeli nie mamy dobrej Retrospektywy i mamy jakiś tam sposób pracy, to najprawdopodobniej ten sposób pracy będzie się ciągnął często miesiącami, często nawet widzę latami. I spotykam, pracując z Klientami takie zespoły, które od bardzo długiego czasu nie dokonały żadnej dużej, istotnej zmiany. W sensie te zmiany, które robią, są bardzo małe. Moim zdaniem, patrząc z boku, nie mają znaczącego wpływu, jak jako całość działa zespół. Tak więc zdecydowanie, jeżeli miałbyś/miałabyś realizować tylko jedno wydarzeń w Scrumie, zdecydowanie moim zdaniem powinna to być Retrospektywa Sprintu.

Kuba: W pełni się z tym zgadzam. Jeśli mówisz o tym wywodzeniu, no to ja to widzę jako coś takiego, że jeśli chcemy się poważnie zastanowić, jak pracujemy, a o tym jest Retrospektywa Sprintu i chcemy poważnie coś usprawnić, to spora szansa, że wokół cykliczności takiego usprawniania, same nam się pojawią pozostałe sytuacje. Bo na przykład dosyć popularny temat, czy realizujemy te zadania, do których się nazwę to w cudzysłowie, się zobowiązaliśmy, czy zaplanowaliśmy je. No to może się okazać, że ciągła rozmowa o tym, jak lepiej ocenić ile jesteśmy w stanie zrobić, czy dostarczyć wartości, czy zrealizować jakichś zadań, czy ficzerów, czy jakkolwiek to mierzymy, no to jest spora szansa, że jeśli rozmawiamy o tym, żeby to ciągle usprawniać, to nam automatycznie wyjdzie cykl planowania i podsumowania pracy w postaci przeglądów. Jest spora szansa, że jeśli wyjdzie nam w toku ciągłego usprawniania jakaś niedoskonałość komunikacyjna w zespole, to nawet gdybyśmy z jakiegoś powodu nie robili codziennego Scruma, to jest szansa, że może byśmy codziennie sprawdzali po trochu, jak jesteśmy z poprzednimi realizacjami planu i jakbyśmy mogli zaktualizować ten plan i w ogóle, gdzie jesteśmy z tematami, co nas blokuje? Moim zdaniem tutaj od końca patrząc, powiedziałbym tak – przyrost i Retrospektywa po zrealizowaniu jakiegoś przyrostu, jest sporą szansą na to, że tu automatycznie nam cała reszta Scruma sama się nagle pojawi. No i w tym momencie, w takim razie bardzo smutną refleksją jest to, że niestety wiele zespołów akurat z tego wydarzenia scrumowego, dosyć łatwo rezygnują, albo traktują to jako jakiś taki drobny momencik do szybkiego odhaczenia w toku. Jak to powiedziałeś, ja spotykam taki duży moment w Scrumie, w Sprincie – takie Review-Retro-planowanie. Tak naprawdę przyciągające się trochę Review Sprintu, płynnie przechodzące w szybkie planowanie, bo jesteśmy na mega gazie, są jakieś feedbacki. Trzeba było się wytłumaczyć, bo coś nie wyszło. Retro? Szkoda czasu, idźmy do przodu.

Jacek: Powiedzieliśmy trochę o tym, czym jest Retrospektywa. Podkreśliliśmy też, dlaczego jest to ważne spotkanie, w szczególności jeśli pracujemy iteracyjnie. Chcielibyśmy teraz opowiedzieć o tym, co naszym zdaniem ma wpływ na to, żeby taka Retrospektywa była spotkaniem skutecznym, żeby taka Retrospektywa była spotkanie, w którym zespół faktycznie chce uczestniczyć i wierzy w to, że te rzeczy, które na Retrospektywie ustalają, faktycznie mają sens. Pierwsza rzecz, na którą chcielibyśmy zwrócić uwagę, to jest struktura Retrospektywy. Czyli sposób, w jaki to spotkanie jest realizowane. To z czym się bardzo często spotykam, to jest, jak już się pojawi ta Retrospektywa, jak nie ma tego przykładu, o którym przed chwilą mówiłeś, gdzie jakby (antyprzykładu) wszystko się zlewa w jedno godzinne spotkanie. No to jeżeli faktycznie mamy wydzielony czas na Retrospektywę, to bardzo często spotykam coś takiego, że to jest taka bardzo luźna pogadanka. Luźna rozmowa. Powiedziałbym, często bez jakiegoś konkretnego pomysłu. Ktoś tę rozmowę zaczyna. Zdarza się, że to jest Scrum Master. Czasem tę rozmowę rozpoczyna osoba w jakiejś czapce lidera. Czasem jest to jakiś Project Manager, który gdzieś tam w okolicach zespołu funkcjonuje. Natomiast ta rozmowa najczęściej nie prowadzi do zbyt głębokich wniosków, z tego względu, że tak naprawdę, moim zdaniem zespół nie ma w ogóle szansy, żeby się sensownie wypowiedzieć. Jeśli chodzi o strukturę, to bardzo popularną strukturą jest struktura zaproponowana przez Esther Derby w książce „Agile Retrospectives”, która składa się z pięciu prostych kroków. Pierwszy krok, to jest otwarcie Retrospektywy. Drugi krok, to jest zebranie danych, czyli zastanowienie się co się działo w trakcie Sprintu, jakie tematy są dla nas istotne? Trzeci punkt, to jest wygenerowanie spostrzeżeń. Punkt czwarty – wygenerowanie konkretnych akcji. Punkt piąty, to jest zamknięcie. Myślę, że krótko dwa zdania powiemy o tym, jak z takiej struktury możesz skorzystać.

Kuba: Na pewno jest też tak, jeśli chodzi na przykład o otwarcie, to rzeczą, którą często widzę, że zapomina się w zespołach, do których przychodzę (zwłaszcza na samym początku), to jest po prostu wyjaśnienie, jaki jest cel tego wydarzenia scrumowego? Po co się spotykamy? Co chcemy osiągnąć? Do czego dążymy w tym spotkaniu? Po co w ogóle to robimy? To jest na wielu warstwach. Chociażby, zwłaszcza w początkującym zespole to jest coś takiego, że to jest kontekstowa okazja do przypomnienia, na czym Scrum w ogóle polega. Jak go tutaj możemy zrealizować jeszcze raz, właśnie przez inspekcję, adaptację, empiryzm i te rzeczy. Po drugie, w wielu zespołach zdarza się, że ta wiedza jest różnorodna i na przykład mamy nowego członka zespołu, albo kogoś, kto sygnalizuje, że mimo wszystko czegoś tam nie rozumie. Jakieś takie spokojne, krótkie wyjaśnienie, po co to jest, może być bardzo wartościowe. A nawet w zespołach dosyć znanych i w miarę rozeznanych, nikomu nie zaszkodzi w ramach otwarcia spotkania, krótkie przypomnienie, co jest celem. Po co się tu spotykamy? Do czego dążymy? Dla mnie jakby taką składową otwarcia tego spotkania jest na samym początku przypomnienie wymiaru czasowego. Przypomnienie, po co się spotykamy. Przypomnienie o tym, że chcemy tutaj ustalić jakieś kroki usprawnieniowe do najbliższego Sprintu. Są rzeczy, które w ramach otwarcia są realizowane, też inne.

Jacek: Tak, zgadzam się z tym, co mówisz. W szczególności rezonuje ze mną ten aspekt wykorzystywania każdego początku wydarzenia w Scrumie. W szczególności z zespołem, który dopiero uczy się Scruma, żeby przypomnieć tak naprawdę, gdzie jesteśmy w całym Sprincie. Co poddajemy inspekcji? Co poddajemy adaptacji? Dlaczego? To, co będziemy robić przez najbliższy czas, jest ważne, jakby w kontekście całej układanki. Natomiast jeśli chodzi o otwarcie, bardzo często wykorzystuję ten punkt w strukturze, wprowadzając technikę, wprowadzając ćwiczenie, bądź zadając jakieś konkretne pytanie, które ma na celu zastanowienie się, skupienie, spojrzenie trochę w przeszłość, w zeszły Sprint, czasem może trochę dalej niż zeszły Sprint. Tak, żebyśmy za chwilę, kiedy będziemy się zastanawiać, co konkretnie się wydarzyło, jak pracowaliśmy, jaki jest nasz stosunek do tych zdarzeń, żebyśmy mieli świeżo w pamięci, jak nasz Sprint wyglądał. Często zaraz po przeglądzie Sprintu zespoły wskakują w Retrospektywę. Nawet nie ma chwili czasu, żeby dosłownie poświęcić minutę, czy poświęcić dwie minuty nad tym, jak wyglądał ten Sprint. Jak mi się pracowało? Przykładowa jakaś prosta technika to może być poproszenie każdej osoby, żeby oceniła sobie w głowie ten Sprint od 1-5 albo żeby zastanowiła się, jakby miała ten mijający Sprint opisać jakimś jednym wyrazem czy słowem, to co by to było? Te brzmiące banalnie dwa przykłady powodują, żeby jednak tę cyfrę podać, albo ten jeden wyraz opisujący Sprint wyprodukować, no to musimy się zastanowić, OK – jak mi się pracowało? Jak wchodziłem w interakcję z innymi? Jak ten Sprint był udany, bądź nieudany?

Kuba: Wymiar takiego ćwiczenia, jest drugi ważny, że też po prostu zrobiliśmy coś, do czego chcemy zaangażować wszystkich Uczestników. Jeszcze do tego będziemy pewnie w przykładach w dalszej części odcinka wracać. Tutaj z jednym z popularnych kłopotów jest to, że są osoby mniej zaangażowane. No i teraz w pewnym sensie to otwarcie, można potraktować jako taką umowną rozgrzewkę. Jeśli zrobimy szybką, bardzo krótką rundkę jakiegoś ćwiczenia, w którym każdy się musi zastanowić, uspokoić, przypomnieć sobie, że jest już na tym konkretnym wydarzeniu, dokonuje też przy okazji refleksji na temat zrealizowanego Sprintu. Robi jakąś krótką wypowiedź, czy jakieś krótkie ćwiczenie, czy jakąś krótką aktywność, no to można powiedzieć tak umownie, że jest już rozgrzany. Jak już przyjdzie czas dyskutować o różnych rzeczach, proponować różne rzeczy, no to już się obudziliśmy. Już jesteśmy tutaj. Już wiemy, że jest czas działać. Stąd akurat nie przywiązywałbym dużej wagi z perspektywy Scrum Mastera prowadzącego Retrospektywę, do tego, żeby akurat z tej rozgrzewki wynikały jakieś kosmosy, jakieś super ustalenia, czy od razu jakieś wielkie, głębokie przemyślenia. Jakby ucieszmy się z tego prostego faktu, że robimy szybką rundkę. Może jednak dobrze wymieniłeś dwie praktyki. Ja bym dorzucił jeszcze z dwie inne. Na pewno warto pomyśleć, czy by nie wykorzystać praktyki Check-in z Core Protocols, czyli jakby opowiedzenie o swoich emocjach. To może być piekielnie istotne, zwłaszcza jeśli czekają nas jakieś trudne tematy, albo coś w Sprincie poszło na tyle ciężko, że wiadomo, że będą za chwile dosyć emocjonalne tematy do usprawniania się. Ale to też może być na przykład takie przełamanie potencjalne trudnych tematów. No to na przykład zacznijmy szybką rozgrzewkę od podziękowania komuś za coś, albo powiedzenia wprost, co było fajne w tym, co zrealizowaliśmy w poprzednim Sprincie. Potraktować to, jako rozgrzewkę. Nawet nie jako część jakiejś struktury, nie wiem, Start – Stop – Continue. To nie musi być takie Continue rozumiane jako konkretne akcje usprawnieniowe, tylko po prostu powiedzmy sobie głośno, co było fajne, z czego jestem zadowolony, co mnie ucieszyło? Jakieś takie rozgrzewkowe, ale pozytywne pytanie, żeby każdy coś powiedział, a przy okazji, żebyśmy sobie powiedzieli różne miłe rzeczy, bo niektóre zespoły wpadają w taki wzorzec, że Retro to jest ten moment, w którym sobie wyżygujemy różne rzeczy, gdy się smucimy, gdy ciągle narzekamy. Można też poopowiadać sobie, co jest fajne.

Jacek: Kiedy mamy już otwartą Retrospektywę, to możemy przejść do punktu drugiego tłumaczonego na język polski jako zebranie danych. To jest moment, w którym angażujemy wszystkich członków Zespołu Scrumowego w proces definiowania w proces zbierania, w proces generowania tego wszystkiego, co się wydarzyło w trakcie Sprintu. Czyli tak praktycznie na ten moment patrząc, to jest moment, w którym zespół kiedy zespół wyrzuca z siebie każdy pojedynczy członek zespołu ma okazję, żeby wyrazić siebie. Czy to słownie, czy pracując w jakiejś grupie, czy pisząc swoje jakieś tematy, które uważa za istotne, lub które chciałby poruszyć na kartce, na jakiejś tablicy. Nie mniej jakby efektem tej konkretnej aktywności jest zebrana duża zwykle pula tematów, obszarów, wydarzeń, które z perspektywy zespołu są istotne. Jest to o tyle ważne, że jeżeli ta faza nie nastąpi i na przykład jakiś członek zespołu, który trochę bardziej czuje się liderem narzuci tematy, no to może się okazać, że bardzo fajnie przegadamy tematy, które dla tej osoby z podejściem liderskim być może są istotne. Natomiast nie wypowiedziały się trzy inne osoby, które jeśli je zapytać, pozwolić im się wypowiedzieć, okazuje się, że mają świetne przemyślenia, trafne uwagi i bardzo cenny wkład w dalszą dyskusję zespołu. Tylko po prostu musimy się tym osobom pozwolić wypowiedzieć.

Kuba: Bardzo istotną na tym etapie zbierania danych jest sformułowanie pytania, na jakie zespół odpowiada. Tutaj widzę, że to raz, niesformułowanie tego pytania w ogóle, albo sformułowanie je na początku w sposób niechlujny i niejednoznaczny, może oznaczać, że na przykład połowa zespołu odpowiada na pytanie, czy generuje swoje jakieś obserwacje na temat, jak nam poszło w Sprincie. Część od razu zaczyna mówić, co byśmy chcieli zmienić, usprawnić. A jeszcze ktoś tam zaczyna generować jakieś dygresje lub ciągnie jakieś wątki mniej na temat. Zwłaszcza jeśli, to jest pewnie kwestia roli Scrum Mastera, zwłaszcza jeśli byśmy chcieli, żeby zespół zaobserwował jakiś trudny temat. Tak troszkę nazwę to podsterować Retrospektywę. To może się okazać, że ten etap zbierania danych, to już jest ten moment, żeby naprawdę zadbać o to, na jaki temat dane generujemy. Na jaki temat tymi obserwacjami się wymieniamy i co chcemy tak naprawdę mieć. Bo to może nam, w bardzo prostym przypadku, wygenerować trochę zamieszania, ale w najcięższych przypadkach, może oznaczać, że pół spotkania niektórzy członkowie zespołu w ogóle są na innym spotkaniu myślami – w jakimś innym temacie lub nie zrozumieli naszych intencji. Więc tutaj zamieniając tę radę na bardzo konkretną technikę, to wielokrotnie ze Scrum Masterami przed rozpoczęciem Retrospektywy rozmawiam, jakie pytanie chcesz zadać na początku? Może warto to pytanie wręcz zapisać. W sensie, jeśli jesteśmy w salce i mamy tam jakąś tablicę, to możemy to pytanie zapisać, żeby wszyscy je mieli przed oczami. Bo to nie jest oczywiste, nawet jeśli mamy my jakąś intencję, to nie jest oczywiste, że członkowie zespołu to zapamiętają.

Jacek: Tutaj znów mówisz o pytaniu. Mam przed oczyma wiele technik, z których sam korzystałem do zbierania danych. Tak, żeby wymienić kilka, to te najbardziej popularne, które można spotkać w prawie każdym zespole, to jest faktycznie taki Start – Stop – Continue. Przy czym moim zdaniem ta formuła narzuca to, że już jakby sugerujemy, co byśmy chcieli zacząć lub co chcielibyśmy zastopować. Podobną w sumie formułą jest na przykład Starfish, czyli po polsku rozgwiazda. Można po prostu poprosić osoby, jako inna technika, żeby wypisały na kartkach rzeczy, czy tematy, którymi chciałyby podzielić się z innymi osobami. No i dalej te tematy, w postaci tych kartek, one gdzieś lądują na jakiejś ścianie, na jakiejś tablicy. Jakby patrząc na to, mamy jakby taki zbiorowy obraz na to, co się zadziało w Sprincie. Myślę, że to jest też dobry moment, żeby powiedzieć, że zwykle ten proces zbierania danych, on potrafi wygenerować bardzo dużo tematów. Ważne jest też, żeby osoba, która moderuje to spotkanie, doprowadziła do syntezy tych danych. Bardzo często można tematy pogrupować, już na etapie zbierania danych. Kiedy będziemy chcieli wejść jakby w kolejny już etap, już wybrać konkretne tematy do spostrzeżeń, to też nie musimy, tych nie wiem, 45-ciu tematów, które zostały wygenerowane przez zespół, wszystkich po kolei robić. Możemy sobie wybrać konkretne tematy. Najważniejsze trzy, najważniejsze pięć, albo ustalić sobie jakiś konkretny czas na temat, tak żeby z tej chmury tematów, który właśnie został wygenerowany przez zespół wybrać te najważniejsze dla zespołu i na tych najważniejszych się skupić.

Kuba: Ja bym nawet poszedł dalej. Powiedziałeś, że mogą sobie wybrać te najważniejsze. Ja bym powiedział, że koniecznie trzeba sobie wybrać te najważniejsze. I nawet też długo byłem fanem takiej Retrospektywy bardzo poukładanej czasowo, że tam pierwszych dziesięć minut otwarcie. Później zbieranie danych kolejne dziesięć minut. I taki szablon co do minuty rozpisanej Retrospektywy, ja to też spotykam u osób mniej doświadczonych, że no to ile powinno mi to zająć? Dziesięć, piętnaście minut? Ile na temat powinienem/powinnam dać? Dziesięć, pięć? Ja bym powiedział – daj jakieś ograniczenie czasowe. Dziesięć, piętnaście minut na pierwszy temat. Ale absolutnie bądź OK z tym że po upływie tych dziesięciu minut potrzebujemy kolejne dziesięć minut. Jeśli rozmawiamy o tej najważniejszej jednej rzeczy, który cały zespół ustalił, że to ta wymaga w szczególny sposób poważnego traktowania, to możliwe i całe Retro może zejść tylko na ten jeden temat, jeśli tylko doprowadzimy do konkretnych akcji usprawnieniowych. Więc tutaj selekcja, prioretytezacja jest kluczowa. Żebyśmy nie przemarnowali czasu na rzeczy mniej istotne. Nawet bym obrócił to, żebyśmy przede wszystkim skupili się na rzeczach najważniejszych.

Jacek: Jak mówisz o tym, że faktycznie możemy dać więcej czasu i tak dalej, pozarządać tym. To tutaj mam taki przykład zespołu, który nigdy nie miał porządnej Retrospektywy i do tego zespołu dołączyć Scrum Master. Pierwsze Retro, w którym ten zespół miał szansę uczestniczyć porządnie, oczywiście zmoderowane przez tego Scrum Mastera, który był doświadczoną osobą, to Retro trwało trzy godziny. Było o czym rozmawiać. Oni pracowali w Sprintach krótkich. Nie pamiętam dokładnie, czy to był tydzień, czy dwa. Tu mógłby ktoś powiedzieć, że przecież time boxy, ograniczenia czasowe. Natomiast to jest taki moment, kiedy uważam, że w grę wchodzi zdrowy rozsądek i te osoby poprowadzone przez tego Scrum Mastera, sposób w jaki on stworzy im przestrzeń do tego, żeby mogli zacząć mówić, to naprawdę było coś niesamowitego. Chwilami miałem wrażenie, że te osoby pierwszy raz mają okazję powiedzieć, co im leży na sercu. Tak więc absolutnie się zgadzam z tym, że mówimy dzisiaj o tej strukturze, ale to nie jest coś takiego, że musimy przejść przez te pięć kroków. To nie jest też tak, że ten każdy krok trwa ileś i koniec i nie wiem, w środku interesującej dyskusji my przerywamy i mówimy – koniec punktu drugiego, musimy iść do punktu trzeciego. Więc absolutnie tutaj wyważenie osoby, która moderuje jest kluczowe, żeby po prostu nie zabić kluczowej dyskusji dla danego zespołu, tylko dlatego, że zegarek powiedział nam, że jest koniec czasu.

Kuba: Alarm zaczął pikać i należy pójść dalej. Niezależnie od tego, że właśnie ktoś się otwierał i w następnym zdaniu miał powiedzieć coś ważnego. To w ogóle jest temat trudny, zwłaszcza dla osób początkujących, ale nawet w tym zaawansowaniu mogą się zagubić. Żeby czasami ta struktura nam nie przysłoniła sensu. Czyli ktoś tam usilnie przeciąga zespół przez konkretną technikę, przez konkretne ramy czasowe. Jakby blokuje jakieś głębsze dyskusje, no bo musimy. I tutaj się pojawiają argumenty, bo salka, bo czas, bo spotkanie, bo Scrum Guide. Gubimy ten moment, w którym tak w ogóle chodzi o ten moment, żeby nam się lepiej współpracowało, czy lepiej pracowało. Czy żebyśmy dostarczali lepszą wartość i jakość, a nie o to, że musimy wypełnić jakąś check-listę idealnego Scrum Mastera, czy idealnej Retrospektywy Sprintu. Co może również oznaczać jakby, w którymś momencie może się okazać, że po prostu ten tutaj gorset struktury, którą chcemy zaproponować, po prostu nie siada w zespole. To widać, jak tylko chce się tylko na to patrzeć. Jeśli widzę, że to nie działa, no to miejmy – ja, Ty, wszyscy miejmy odwagę, żeby stwierdzić, no nie, no coś nie zagrało. Mogę spróbować poprawić. Mogę w ogóle zrezygnować i stwierdzić, dobrze to nie wyszła nam ta technika, to spróbujmy inaczej, albo po prostu porozmawiajmy.

Jacek: Absolutnie. Tu jakby mogę dodać komentarz taki, że wielokrotnie wchodziłem na spotkanie z zespołem mając w głowie jakąś strukturę przygotowaną. Na skutek tego co się działo, gdy już rozkręciła się Retrospektywa Sprintu, zmieniałem swój plan. Bo widziałem, że te techniki, te pomysły, które miałem na ten konkretny Sprint, po prostu one w tym kontekście, w którym się teraz znajdujemy, jakby z tymi tematami, po prostu nie ma sensu. Więc po prostu zmieniałem. Oczywiście mając jakby z tyłu głowy, że wychodzimy z usprawnieniami. Czyli mamy te zebrane dane. Co dzieje się dalej?

Kuba: Przechodzimy do momentu, jeśli te dane mamy już zebrane i sprioretetyzowane, no to mamy też jakiś największy temat. To może być, czy problem, czy może być jakiś pomysł. To może być jakaś niedoskonałość. Warto by było teraz się zagłębić i wygenerować spostrzeżenie, jak to Esther Derby proponuje. Czyli zagłębić się, nazwę to ogólnie, problem. Coś, co tutaj bym bardzo mocno rekomendował, to to, że ponownie w temacie generowania, jak w tym temacie zbierania danych, znowu uwzględnić możliwość wypowiedzenia się swobodnie i najlepiej bez sugerowania się wzajemnie członków zespołu. Czyli przede wszystkim unikajmy podejścia. Mamy problem. Pierwszy pomysł na rozwiązanie, rozmawiamy, czy to jest dobry pomysł i go robimy. Tak naprawdę zdecydowanie zachęcam tutaj do pomyślenia perspektywą, jakie mamy opcje do rozwiązania tego zagadnienia, problemu, tematu. Raczej takie pytanie zadawać, jako wstęp do wygenerowania spostrzeżeń. Tak, żeby różne osoby miały okazję wymienić swoje różne pomysły, swoje różne preferencje do tego, co one widzą jako rozwiązanie. Tak samo również, a może bym powiedział wcześniej, wygenerować różne swoje spostrzeżenia na temat tego, co tu jest problemem, a co tu jest tylko i wyłącznie symptomem i być może problem jest jeszcze głębszy. Więc tak naprawdę jakby na tym etapie proponuję zanurkować w różne przemyślenia różnych osób na temat tego, co jest możliwą, źródłową przyczyną problemu. Również poeksprolować, jakie mamy opcje, różne pomysły na to, jakie są możliwe rozwiązania na dany temat, w szczególności, żeby za szybko nie wskakiwać w pojedyncze. Lub bardzo podobny do tego problem, który też na Retrospektywach spotykam, że przeistacza się dyskusja z powiedzmy generowania rozwiązań i konkretnej, konstruktywnej rozmowy. To raczej zamienia się to w taką lekką bijatykę, czy ten jeden zgłoszony pomysł na rozwiązanie to jest dobry, czy zły? Jakie są jego wady? Jakie są jego zalety? Tak naprawdę cała rozmowa nam schodzi na jakieś takie dygresje, zamiast po prostu w taką bardzo konstruktywną i szeroką rozmowę na temat różnych pomysłów. Również tych bardziej kreatywnych, niż to pierwsze, które przyszło komuś do głowy.

Jacek: To takie dwa przemyślenia mam, jak o tym mówisz. Pierwsze, że tak naprawdę uważam, że nie ma też co zbyt bardzo upierać się przy rozwiązaniach i tak dalej. Z tego względu, że ja osobiście traktuję i tak też komunikuję i namawiam zespoły, żeby patrzyli na wydarzenie jakim jest Retrospektywa Sprintu jako okazję do wyszukania pewnych eksperymentów, które zrealizujemy w ramach Sprintu. To może trwać tydzień, dwa i tak naprawdę to jest taka nasza inwestycja. Jeżeli nawet któreś rozwiązanie nie zadziała, a często te rozwiązania nie działają, to nic się nie dzieje. Ale jest też kolejna Retrospektywa Sprintu. Bierzemy inne rozwiązanie i tak naprawdę uczymy się. Tak więc wielokrotnie widziałem dwudziestominutowe dyskusje, które rozwiązanie bierzemy na kolejny Sprint, gdzie tak naprawdę uważam, nie ma to znaczenia. Wybierzmy jedno, sprawdźmy. Wybierzmy drugie, zobaczmy i dalej będziemy podejmować kolejne decyzje.

Kuba: A może wręcz zróbmy równoległe eksperymenty? Cała rozmowa, żeby wybrać jedno, jedyne słuszne rozwiązanie od razu na jednej retrospektywie. No straszna pułapka. Mało się tak zdarza, że jak już się usprawniamy, to od razu ten jeden jedyny poprawny krok.

Jacek: A druga myśl, którą miałem jest taka, że lubię ten moment generowania rozwiązań, bo bardzo często doświadczam czegoś takiego, że każdy ma jedno lub dwa rozwiązania. Wypisujemy te rozwiązania i nagle okazuje się, że na skutek syntezy pierwszego z trzecim i piątego z szóstym wyłaniają się zupełnie nowe, fajne pomysły, które nie wyłoniły by się, gdyby każdy powiedział swój pomysł i byśmy w tym momencie ucięli dyskusję. I tak jak mówisz wybrali jeden z tych pomysłów, bo któryś musimy wybrać. Tak więc jest to absolutnie kluczowy moment, w którym zespół, jeżeli wszystkie osoby w tym zespole są zaangażowane – dopiero jak zaangażujemy cały zespół w tę rozmowę, no to mamy szansę jakby połączyć te kilka osób. Jakby połączyć tę wiedzę, którą mają i naprawdę bardzo często zaskakuje mnie na jak świetne pomysły wpadają zespoły, tylko przez to, że stworzyły sobie przestrzeń na to, żeby spokojnie te rozwiązania poeksplorować, poniezgadzać się, pozgadzać się no i często też wyprodukować coś zupełnie nowego.

Kuba: Jak mówisz o tych fajnych rozwiązaniach, to ja tutaj tak może trochę skontruję optymizm. Będzie często tak, zwłaszcza jeśli jesteśmy, mówimy z perspektywy doświadczenia, że te zespoły na początku te pomysły mogą mieć również błędne, albo niewystarczająco jakieś, nazwę to głębokie, czy wszyscy wiemy, że zupełnie co innego może by im pomogło, bo tak mówi nasze doświadczenie dziesięciu czy setki innych zespołów, u których ten problem wyskoczył. No ale to też ten moment, że fajnie zaufać w mądrość zespołu, czyli jeśli zespół kolektywnie stwierdza, że jednak będą próbować poprawiać testy manualne, mimo że pomogłyby im testy automatyczne, no to może czas na danym Retro zaakceptować takie rozwiązanie i pójść sobie dalej. Wrócić do tematu w kolejnych retrospektywach, bo jest spora szansa, że temat będzie wracać. Czyli też to, co teraz powiedziałem, to jest trochę przestroga przed próbą modelowania rozwiązań, która może się też zdarzać. Czasem to widzę, w sensie Scrum Master moderując spotkanie i generując, moderując tę sesję generowania, sam nie jest do końca usatysfakcjonowany i tak trochę mniej lub bardziej umiejętnie podpowiada, jaka powinna być właściwa wersja. Nie mam problemu z tym, że uczestniczy, zaraz i tak pewnie skomentujesz. Merytorycznie Scrum Master uczestniczyć może, na pewno fajnie, żeby nie mieszał tej warstwy – moderuje grupę czy facylituje dyskusję w całej grupie,  z tym, że wprowadza ich w jakąś tam ustaloną z góry wersję, czy ustalone z góry rozwiązanie.

Jacek: No to jest w ogóle, dotknąłeś ciekawego obszaru, bo powiedziałeś o roli Scrum Mastera. Od razu przychodzi mi do głowy rola Product Ownera gdy dzieje się Retrospektywa Sprintu, ale wracając jakby na początek do Scrum Mastera, to faktycznie sam wiem z doświadczenia, będąc Scrum Masterem w zespołach, że trudno jest jednocześnie zapewniać, że cała grupa ma odpowiednią strukturę i że jakby poruszamy się efektywnie, sensownie w kierunku konkretnych rozwiązań, jednocześnie dokładając swoich rozwiązań, które tak jak wspomniałeś, możemy bardziej lubić, możemy mniej lubić. Tak więc bardzo łatwo jest zapomnieć, że jesteśmy w roli moderatora i wskoczyć w rolę członka zespołu deweloperskiego, który ma swoje zdanie i bardzo mu zależy, żeby przekonać kolegę, że pomysł A jest kiepski, a pomysł B jest świetny. Więc tutaj jakby to co widzę też, jak Scrum Masterzy sobie radzą z tym tematem, to jest to, że trochę większą aktywność mają na początku. Czyli jakby wrzucają pewne tematy, pewne obserwacje. Często właśnie wartościowe, bo nikt inny takich obserwacji nie ma. Często to są jakieś rzeczy z okolic procesu. Czyli przykładowo Scrum Master na etapie zbierania danych dzieli się informacją na temat tego, jak wygląda na przykład przewidywalność zespołu z ostatnich Sprintów, czy jaki jest trend prędkości zespołu.

Kuba: Ale to może być też, żeby wyjść z takich mechanicznych rzeczy, to też na przykład zaobserwowano jakieś problematyczne interakcje pomiędzy członkami zespołu. Zwłaszcza jeśli nikt tego nie wspomniał. Przerywamy sobie, albo ktoś tam się niefajnie zachował i być może ze środka tego nie widać tego tak dobrze, jak widać to oczami Scrum Mastera.

Jacek: Tak więc to jest jakby jeden aspekt. Jeżeli jesteś Scrum Masterem, to nie rezygnuj z tego, żeby dołożyć od siebie swój punkt widzenia. Natomiast jeśli chodzi o Product Ownera, częściej niż w przypadku Scrum Mastera spotykam się z sytuacją, w którym tego Product Ownera w ogóle nie ma na takim spotkaniu. Jest Retrospektywa Sprintu ale nie ma Product Ownera na niej. Ta osoba powinna być na tym spotkaniu, dlatego, że jest członkiem zespołu. Jestem bardzo daleki, żeby myśleć, że Product Owner to jest biznes, a zespół, że to jest IT. Uważam, że tylko dobrze naoliwiona współpraca między tymi kompetencjami może dać fajne efekty. Drugi aspekt jest taki, co obserwowałem w co najmniej paru zespołach, że jeżeli nie ma Product Ownera, to zespołom o wiele łatwiej jest gro problemu przerzucać na Product Ownera. Mamy kiepski Backlog, mamy kiepskie User Stories, nie wiemy po co to robimy. Tylko sam fakt, że nie ma Product Ownera daje taką lekkość w tym, że możemy wiele tematów przesunąć poza obszar naszego wpływu i powiedzieć – Bylibyśmy świetni, no ale sam widzisz, ten Product Owner nie robi tego, tego i tamtego. Natomiast z jakby drugiej strony.

Kuba: Jeśli mogę. Wtedy akcją jest usprawnieniową z takiej Retrospektywy, porozmawiać z Product Ownerem.

Jacek: Porozmawiać z Product Ownerem. Tak. Przekazać mu pięć punktów, w których musi być lepszy. Na pewno efekty będą rewelacyjne. No tak i teraz to pytanie mnie trochę wybiło, aczkolwiek to była ważna dygresja. Ale już wiem co chciałem powiedzieć. Chciałem powiedzieć to, że odważny Product Owner, czy Product Owner, który wie do czego służy Retrospektywa Sprintu i potrafi z niej skorzystać, no moim zdaniem to zmienia grę. Na takiej zasadzie, w szczególności takie dyskusje na temat tego jak nam idzie realizacja celów biznesowych. Czy jesteśmy zadowoleni z efektów pracy? Często Product Ownerzy potrafią mieć bardzo fajne uwagi, które no znów poprzez specyfikę zwykle pracy zespołu, który skupia się trochę bardziej na części takiej rozwiązaniowej, technicznej, powoduje, że te rzeczy biznesowe unikają. Tak więc myślę, że jeśli mówimy tutaj o wygenerowaniu spostrzeżeń, tak wracając do struktury, no to uważam, że pełność pewną, czy takie pełne spojrzenie na problemy zespołu uzyskamy tylko wtedy, jeżeli będziemy mieli wszystkie te role. Czyli zespół developerski, Scrum Master, o którym wspominałem no i jakby tutaj ta ostatnia wypowiedź dotycząca roli Product Ownera.

Kuba: Dobra. To przedostatnią częścią struktury jest wygenerowanie akcji. Tutaj jakby one płynnie wychodzą ze spostrzeżeń, czyli jest spora szansa, że jak się dobrze zgłębimy, jak poeksplorujemy te opcje to też zespół wymyśli konkretne rozwiązanie. Natomiast jakby docisnął bym ten temat, że oprócz wymyślonych rozwiązań to też trzeba sobie porozmawiać wprost, konkretnie. Co, kto, kiedy zrobi? Jakby wiele fajnych pomysłów, nawet wróćmy do tego Twojego przykładu z tym niedoskonałym Backlogiem. Załóżmy, że mieliśmy Product Ownera na spotkaniu, czyli jednak sobie razem powiedzieliśmy, że to razem ten Product Backlog razem możemy poprawić, no to sobie powiedzmy kiedy to zrobimy? I dlaczego w środę o 13.00? Kto załatwi salkę? Jak się musimy do tego przygotować? Co dokładnie pod tym rozumiemy? Czy może chcemy przy okazji jeszcze kogoś poprosić, żeby nam w tym pomógł? Czyli cała lista akcji, pomysłów, co chcemy zrobić. Kto z nas to zrobi? Kto z zespołu to zrobi? Kiedy to zrobi? Czy wprowadzamy te działania do Backlogu Sprintu, bo są na tyle duże, że ważne, żebyśmy o tym nie zapomnieli. Bardzo konkretny plan realizacji tych usprawnień, a nie tylko dobra lista pomysłów, usprawnień bez żadnych zobowiązań się wzajemnych i konkretów.

Jacek: No to jest ten przypadek, o którym mówisz, to jest pierwszy krok do tego, żeby Retrospektywa Sprintu zamieniła się w spotkanie, na które nikt nie ma ochoty przychodzić. No bo jakby się tak zapytać, co myślą o Retrospektywie, no to usłyszymy coś w stylu – przychodzimy, wymyślamy, ale tak naprawdę nic się nie dzieje. Tak więc, raz – to jak mówisz, wygenerowanie tych akcji, przygotowanie planu, konkretne określenie kto robi i w jaki sposób. Natomiast cała sztuka, to jest doprowadzenie do tego, że te akcje wcielamy w życie. Tutaj myślę, że to jest jakby ważne miejsce, żeby też nie przysypać zespołu czterdziestoma pomysłami na usprawnienia, których tak naprawdę nie jesteśmy w stanie zrealizować, tylko znów – zawężyć. Wybrać konkretne trzy. I nawet jeśli często słyszę, że zespół mówi – No jak możemy zrobić więcej? – a widzę w historii, że tam się nic nigdy nie działo, to zawszę mówię wtedy – Zróbcie te trzy. Jak zrobicie te trzy to i tak to już będzie to trzy razy lepiej jak jest, bo dotychczas nie robiliście nic.

Kuba: Tak. Najważniejsze, żeby te rzeczy cały zespół też zaakceptował. I tutaj chyba ostatni punkt struktury jest dobrym sposobem na to, żebyśmy sobie dobrze to zapamiętali. To jakby domknięcie rozumiem tak, czy przez przykład, zrealizowałbym to tak, że to jest ten moment, żeby sobie głośno powtórzyć głośno wszystkie ustalenia, jakie mamy. Może to zrobić Scrum Master, jeszcze lepiej jakby Scrum Master poprosił zespół jako całość. Czy poprosił jakichś ochotników o to, żeby przeszli przez dotychczas zebrane ustalenia, plany usprawnieniowe i po prostu, żebyśmy sobie jeszcze raz przypomnieli, co ustaliliśmy? Fajnie, jeśli to przy okazji jeszcze generuje jakąś formę na przykład wizualizacji, którą możemy ze sobą zabrać, żebyśmy też tego jako domknięcie nie traktowali coś, co chyba obaj spotykamy, że domknięciem jest jakiś mail, albo strona na Wiki jakimś firmowym, że domknięcie to jest, że zrobiliśmy podsumowanie jakiegoś spotkania. Jeszcze raz przejdźmy przez całą listę ustaleń. Zgódźmy się co do nich, albo odkryjmy trochę późno, bo sam koniec spotkania, ale odkryjmy, że się nie dogadaliśmy. Lepsze to, niż się zorientować po całym Sprincie, że się nie dogadaliśmy i że poszło coś nie tak.

Jacek: No zdecydowanie to domknięcie, to nie są minutki ze spotkania. 

Kuba: Nie jesteśmy Project Managerami.

Jacek: Dobrze. To tyle, jeśli chodzi o dzisiejszy odcinek. Podsumowując. Porozmawialiśmy na początku o tym, co to jest Retrospektywa Sprintu? Jakie są jej korzenie? Jaka jest wartość z tego, żeby to spotkanie przeprowadzać we właściwym momencie cyklu pracy? Następnie przeszliśmy po strukturze zaproponowanej przez Esther Derby w książce „Agile Retrospectives” po bardzo konkretnych pięciu krokach. Te kroki to, punkt pierwszy, to jest otwarcie. Następnie jest zebranie danych. Następnie wygenerowanie spostrzeżeń. Następnie wygenerowanie konkretnych akcji. No i punkt piąty, domykający, to jest po prostu domknięcie.

Kuba: W ramach tego odcinka w szczególności nie chcieliśmy wyczerpać tematu możliwych technik. Jeśli są jakieś techniki, kilka akurat wspomnieliśmy, ale na pewno jest ich jeszcze o wiele wiele więcej. Jeśli szukasz konkretnej techniki polecamy zarówno „Agile Retrospectives”, z której tę strukturę wyciągnęliśmy w ramach tego odcinka. Polecamy też stronę. 

Jacek: „Plans for Retrospectives”. Kiedyś to się nazywało „Retromat”. 

Kuba: Tam można znaleźć dużo technik, podpowiedzi, jak facylitować wydarzenie jakim jest Retrospektywa Sprintu. Natomiast nie zapomnijmy o tym, że te struktury, te techniki, te wszystkie konkretne ćwiczenia ona mają przede wszystkim służyć usprawnieniom, a nie tylko być grą i zabawą samą w sobie.

Jacek: Te pojęcia, które przed chwilą się pojawiły, podlinkujemy do opisu bieżącego odcinka i to będzie już wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: Do usłyszenia wkrótce.

← Older
Newer →

10 Replies to “Porządna Retrospektywa Sprintu”

  1. Jacek Durlik

    Cześć.
    A kiedy Wy sprawdzacie realizację akcji z poprzedniego retro?
    Niby to część backlogu i w sumie inkrementu powinna być, czyli review, jednak często ten element jest pomijany i zespoły ciągle rzucają się na nowe dane, nowe akcje bez domknięcia poprzednich.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Wordpress Social Share Plugin powered by Ultimatelysocial