#005 – Porządna Retrospektywa Sprintu

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

Zobacz wersję wideo

Materiały i techniki, o których m.in. wspominamy w nagraniu:

Jeśli odcinek Ci się podobał, koniecznie podziel się nim z innymi osobami, które Twoim zdaniem mogą go potrzebować. Zdecydowanie czujemy, że nie wyczerpaliśmy wątku Retrospektyw i planujemy kolejny odcinek z dodatkowymi treściami na ich temat – jeśli są jakieś problemy, jakie napotykasz w trakcie retro, masz jakąś fajną obserwację albo dobrą praktykę, którą sugerujesz innym Scrum Masterom i Agile Coachom, daj koniecznie znać w komentarzu albo mailowo, spróbujemy dodać te rzeczy do następnego odcinka.

Daj nam znać co sądzisz o samym odcinku:

Chcemy usprawniać podcast z każdym kolejnym odcinkiem, więc podpowiedz nam, jakie niedoskonałości Twoim zdaniem powinniśmy poprawić.

Mamy sporo pomysłów na to, co jeszcze moglibyśmy nagrać, ale jesteśmy bardzo otwarci na Twoją sugestię – przekaż nam hasło albo temat, o którym moglibyśmy opowiadać w kolejnych odcinkach.

Transkrypcja odcinka

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? 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? Co to jest dobra Retrospektywa 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 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 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, 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 Retro. 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 z każdej Retrospektywy powinno wynikać przynajmniej jedno usprawnienie. 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 Retro. 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.

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 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, 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 w trakcie Retrospektywy, 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 Retrospektywę 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. Mamy kolejną Retrospektywę. 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 podczas takiej Retrospektywy, 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. Nie ma Product Ownera na Retrospektywie. 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 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 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 Product Managerami.

Jacek: Dobrze. To tyle, jeśli chodzi o dzisiejszy odcinek. Podsumowując. Porozmawialiśmy na początku o tym, co to jest Retrospektywa? 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ć Retrospektywę. 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.


5 Replies to “#005 – 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 email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Jesteśmy też tutaj

Podcast od kuchni. Tak nagrywamy dla Ciebie!

Jacek Wieczorek i Kuba Szczepanik
scenariusz do nagrania podcastu
Jacek Wieczorek Kuba Szczepanik podcast

Opinie naszych słuchaczy.

„To jest to! Ekstremalnie dobra dawka potrzebnej wiedzy. Część podcastów otwiera oczy, część porządkuje wiedzę. Polecam!”

„Mimo iż nie jestem bardzo związany z agilem/scrumem, jakieś doświadczenia z nim miałem („retrożale” ;), to bardzo przyjemnie się Panów słucha. Duża i bardzo konkretna dawka wiedzy, bez przynudzania, widać „napracowanie” przy każdym odcinku, jakość ścieżki audio na poziomie, całość w odbiorze sprawia profesjonalne wrażenie. Życzę obu prowadzącym sił do kontunuowania tego (nie)małego dzieła. :)”.

„Takich podcastów nam potrzeba!”

Oceń Podcast. Kliknij poniżej.

Apple Podcast logo
logo stitcher
Wordpress Social Share Plugin powered by Ultimatelysocial