Porządny Przegląd Sprintu

Czym jest Przegląd Sprintu? Jak powinien wyglądać, a jak nie? Poznaj 6 rad dotyczących organizacji porządnego Przeglądu Sprintu i dowiedz się, jakich błędów unikać oraz na co zwrócić uwagę, by Przeglądy przebiegały sprawnie i przynosiły możliwe najlepsze rezultaty.

Czym jest Przegląd Sprintu?

Jak zorganizować porządny Przegląd Sprintu, aby przynosił jak najwięcej korzyści? Poznaj 6 wskazówek, które pomogą Ci przeprowadzić efektywny Przegląd Sprintu oraz uniknąć popularnych błędów w tym obszarze.

Przegląd Sprintu najprościej rzecz ujmując, jest wydarzeniem, podczas którego dokonujemy inspekcji Przyrostu Produktu oraz dostosowujemy działania do otrzymanych wyników. Przegląd Sprintu jest bardzo dokładnie opisany w “Przewodniku po Scrumie” i zachęcamy do zaglądnięcia do niego, gdyż zawiera on konkretną listę elementów, które powinny wchodzić w zakres tego wydarzenia Scrumowego. Oczywiście, jest to lista poglądowa i należy ją traktować jako inspirację pomagającą obrać kierunek działania dopasowanego do realiów zespołu lub organizacji. 

O tym, jak realizować Porządny Sprint rozmawialiśmy w 20. odcinku podcastu, a tu tylko przypomnimy, że taką inspekcję produktu można, a nawet warto przeprowadzać także w trakcie Sprintu, dzięki czemu sam Przegląd Sprintu będzie tylko formalnością zapewniającą wszystkich, że produkt podlega inspekcji.

Nim przejdziemy do tego, jak realizować porządny Przegląd Sprintu, to bardzo mocno zachęcamy Was do otwartości na przyznanie się do błędów lub do niewiedzy, a także pozwolenia sobie na proszenie o pomoc. Nie traktujcie Przeglądu Sprintu tylko jako okazji do chwalenia się i pokazywania tylko tego, co wyszło. Dbajcie o budowanie szczerej komunikacji opartej na zaufaniu, komunikacji zarówno między członkami zespołu, jak i zespołem i Interesariuszami. Będziemy o tym pisać jeszcze w dalszej części artykułu, jednak ponieważ naszym zdaniem jest to bardzo istotna rzecz, to chcieliśmy to poruszyć na samym początku.

Przegląd Sprintu – najczęstsze błędy

1. Brak Przeglądu Sprintu 

Być może brzmi to dla Ciebie nieprawdopodobnie, ale my wciąż spotykamy się z sytuacjami, gdzie Przegląd Sprintu jest pomijany. Czasem nie ma go wcale, a czasem jest organizowany tylko co któryś Sprint. Po prostu zespół nie dokonuje regularnej inspekcji tworzonego produktu. 

2. Na Przeglądzie Sprintu brak jest Interesariuszy

Kolejny błąd to przeprowadzanie Przeglądu Sprintu tylko w ramach własnego zespołu, bez obecności żadnego z Interesariuszy. Pokazujemy sobie rezultaty pracy, które tak naprawdę każdy z zespołu powinien i tak znać je już poprzez sam fakt współpracowania ze sobą. 

W ten sposób pozbawiamy się ciekawych wniosków i przemyśleń osób, które nie siedzą tak mocno w produkcie, jak zespół i które mają mocniejsze spojrzenie biznesowe, a nie tylko technologiczne.

3. Przyrost nie jest prezentowany

Nawet jeśli Przeglądy Sprintów odbywają się regularnie i biorą w nich udział osoby spoza zespołu, jednak nie prezentujemy im przyrostu, czyli kolejnej wersji działającego kawałka produktu, będącej efektem ostatniego Sprintu. To z kolei zwykle nie inicjuje żadnych dyskusji i przybiera formę jednostronnego pokazu, tym gorzej, jeśli w postaci listy wykonanych tasków.

4. Brak rozmowy o dalszych planach

Przegląd Sprintu to nie tylko patrzenie wstecz, ale także jest w nim miejsce do rozmowy o tym, co jest obecnie w Backlogu produktu i zaplanowania kolejnych kroków. Jest to istotne z tego względu, że w wydarzeniu biorą udział również Interesariusze, którzy mogą wnieść wiele ciekawych spostrzeżeń i informacji, które być może jeszcze nie dotarły do Zespołu deweloperskiego.

Jak zorganizować porządny Przegląd Sprintu? 

Przedstawiliśmy Wam najczęstsze błędy, z którymi się spotykamy podczas naszej pracy z różnymi organizacjami i zespołami. Teraz podpowiemy Ci, jak zorganizować porządny Przegląd Sprintu, aby przynosił faktyczną wartość.

1. Zawsze pokazuj Przyrost

Przegląd jest okazją do inspekcji Przyrostu Produktu, ale żeby móc tego dokonać, to najpierw musimy go zaprezentować. Ta porada może brzmieć dla Ciebie banalnie, jednak pamiętaj, że są sytuacje, gdy pokazanie efektów naszej pracy może wymagać odwagi, jeśli nie są one satysfakcjonujące i coś nam nie wyszło. Przecież zdarza się tak, że nie udało się nam czegoś dokończyć, czasem coś nie działa, a czasem po prostu tego Przyrostu nie ma. Jednak nie należy uciekać od tego elementu przeglądu, tylko porozmawiać o przyczynach takiego stanu rzeczy: jakie były przeszkody, czy problemy.

Pamiętaj też, że poprzez pokazanie Przyrostu, nie mamy na myśli pokazania listy odhaczonych zadań w narzędziu do zarządzania projektami (np. w Jirze). 

Jeśli nie macie możliwości pokazania kawałka produktu czy kodu, to warto ustalić z Interesariuszami, co tym Przyrostem ma być dla nas wszystkich, aby móc potem je jakoś interpretować. Taka sytuacja może się pojawić, zwłaszcza gdy naszym produktem jest np. usługa lub jakiś proces czy wydarzenie. W takich przypadkach Przyrostem może być np. jakaś rozpiska, fragmenty ciekawych wypowiedzi z wywiadów pogłębionych lub pokazanie zebranych danych i wyników ich analizy. Wszystko zależy od kontekstu, natomiast prezentacja Przyrostu powinna umożliwiać nam dyskusje na ten temat. 

2. Przygotujcie się całym zespołem

Prezentacja efektów Sprintu, zwłaszcza jeśli nie wszystko poszło zgodnie z planem, może być bardzo stresujące. Zaangażowanie się całego zespołu w Przegląd Sprintu, rozkłada ten ciężar na wszystkich. Ponadto pokazujecie Interesariuszom, że prezentowany Przyrost jest efektem pracy całego zespołu i wszyscy są zaangażowani w pracę. 

Nawet jeśli preferujecie pracę samodzielną, trochę jako wolne elektrony, to i tak zachęcamy Was do potraktowanie przeglądu jako aktywności zespołowej. Zaplanujcie przebieg wydarzenia, podzielcie się rolami i ustalcie, kto będzie notował, a kto będzie pilnował czasu lub kto zaprosi Interesariuszy. Nie musi to być zawsze ta sama osoba, nie musi to być też Scrum Master, sprawdzajcie, kto się w czym najlepiej czuje.

Takie podejście, w którym wszyscy członkowie zespołu są zaangażowani w Przegląd Sprintu, pokazuje Stakeholderom Waszą współpracę oraz dojrzałość zespołu. Ponadto każdy będzie miał swoje 5 minut i nie będzie czuł się mniej ważny.

3. Dobierz właściwych Interesariuszy i zaproś ich na Przegląd Sprintu

Wspominaliśmy o tym, że istotne jest, aby na Sprint Review obecni byli również Interesariusze. Jednak równie istotne jest to, aby były to odpowiednio dobrane osoby, a nie osoby, które w sumie nie mają nic wspólnego z danym etapem prac. 

Niejednokrotnie widzimy, że zespoły tworzą listę Interesariuszy i trzymają się jej przez wszystkie Sprinty. Nie jest to najlepsze podejście i warto zapraszać Stakeholderów w zależności od tego, jaki kawałek produktu pokazujemy. Stąd też pewne osoby mogą pojawić się tylko na jednym przeglądzie, a inne będą się powtarzać. 

Ważna jest też forma zaproszenia. Samo wrzucenie wydarzenia w kalendarz danej osoby to za mało. Aby to miało sens, a pojawienie się konkretnego Interesariusza na spotkaniu miało wartość dla obu stron, musi on mieć świadomość, jaka będzie jego rola w tym wydarzeniu, dlaczego jest dla niego i dla Was ważne, aby się pojawił oraz co powinien wiedzieć przed spotkaniem, aby jak najlepiej się do niego przygotować (i potem np. móc zadawać pytania). Bez tego taka osoba może zwyczajnie odrzucić wydarzenie, bo zapewne nie jesteście jedynymi, którzy wrzucają jej zaproszenie do kalendarza i musi on jakoś wybrać, na czym się pojawi i gdzie jest faktycznie niezbędny.

3. Angażuj zebranych na wydarzeniu.

Mamy tu na myśli zaangażowanie w spotkanie zarówno członków zespołu, jak i Interesariuszy, o czym pisaliśmy już trochę powyżej,

To dlaczego jest to ważne, przedstawimy Ci na konkretnym przykładzie. W jednym z zespołów, które wspierał Jacek, w ramach prezentacji Przyrostu produktu, przygotowano prototyp gry, która miała być wykorzystywana m.in. w celach HR-owych. Tym prototypem był wydruk z drukarki, co już stanowiło jakąś namacalną pierwszą wersję produktu. Zamiast tylko ją pokazać i zwyczajnie o niej opowiedzieć, zaprosili oni Stakeholderów do zagrania w tę grę. Oczywiście Stakeholderzy byli zaskoczeni, bo wcześniej nie spotkali się z takim podejściem. Zajęło to może 15 minut, a dzięki zobaczeniu, jak ta gra toczy się w praktyce, byli mocniej zaangażowani w późniejszą dyskusję i potrafili lepiej ubrać w słowa swoje uwagi, sugestie czy pomysły na rozwój tego produktu.

Wiemy, że nie często da się tak mocno zaangażować Stakeholderów i umożliwić im wejście w interakcję z Przyrostem Produktu, jednak kiedy jest taka możliwość, to zawsze ją wykorzystujcie. Skorzystacie na tym i Wy i produkt.

Gdy Przyrost Produktu jest mniej namacalny, to Stakeholderów możecie zaangażować poprzez zadawanie pytań kierowanych do konkretnych osób, tak aby każdy miał okazję do podzielenia się swoimi obserwacjami i przemyśleniami. To może też być ankieta, którą mogą wypełnić anonimowo, a której wyniki przedyskutujecie na kolejnym spotkaniu. Ważne jest tu właśnie to, aby było poczucie, że ich zdanie ma znaczenie i będzie wykorzystane w późniejszych etapach prac.

4. Wizualizuj przebieg spotkania

Mamy tu na myśli spisywanie punktów dyskusji, pojawiających się pytań, wniosków czy decyzji. Ma to na celu uniknięcie sytuacji, że jakieś ważne rzeczy nam umkną, co jest bardzo prawdopodobne, gdyż tego typu spotkania, zwłaszcza jeśli bierze w nich udział dużo osób, często bywają chaotyczne. 

Nie jest konieczne, aby notatki robiła zawsze jedna osoba, możecie się zmieniać co Przegląd Sprintu czy nawet podczas tego samego spotkania. Również sposób notowania jest dowolny, wybierzcie swój ulubiony, np. tablica suchościeralna, karteczki post-it przyklejane na ścianę czy zwykła, duża kartka papieru. 

Co ważne, nie chodzi tu o zwykłe notowanie we własnym zeszycie, chodzi o to, aby ta notatka była widoczna dla każdego i każdy mógł do niej wrócić po spotkaniu. Nie jest to też protokół wydarzenia, tu mają się znaleźć ważne aspekty dotyczące produktu, które pojawiły się na spotkaniu, jakieś wątpliwości czy inspiracje.

5. Eksperymentuj z formułą

Nawet jeśli obecny sposób realizacji Przeglądu Sprintu jest dla Was optymalny, to mocno Cię zachęcamy do sprawdzania nowych formuł, eksperymentowania, bawienia się tym trochę. Niech recepta na Przegląd Sprintu zawarta w Scrum Guide Was nie blokuje przed szukaniem innych sposobów, potraktujcie to tylko, jako punkt wyjścia.

Przykładowo, w jednym z zespołów, z którym współpracował Kuba, Product Ownerka przyniosła z domu zestaw banknotów z gry “Monopoly” i rozdała je Interesariuszom, którzy mieli je zainwestować w kierunki, które ich zdaniem powinny być wybrane. Przerwanie rutyny w tych spotkaniach mocno zmieniło interakcję z Interesariuszami oraz wzmocniło ich zaangażowanie w całe wydarzenie. 

Czy dodałbyś/abyś coś do tych wskazówek? A może podzielisz się swoimi doświadczeniami z przeprowadzaniem Przeglądu Sprintu?

Dodatkowe materiały

• Porządny Sprint

Transkrypcja podcastu „Porządny Przegląd Sprintu”

Kuba: W dzisiejszym odcinku wrócimy do tematu porządnych wydarzeń scrumowych i zrealizujemy ostatnie z wydarzeń, którego nam zabrakło do kompletu mini-serii, czyli „Porządny Przegląd Sprintu”. W ramach odcinka zdefiniujemy sobie Przegląd Sprintu, porozmawiamy o tym, co może pójść nie tak w trakcie realizacji Przeglądu Sprintu, jak można go robić źle, a cały odcinek skończymy zestawem naszych porad, które przychodzą nam do głowy, gdy pracujemy z klientami, jakie rzeczy warto uwzględnić, na jakie rzeczy warto spojrzeć, gdy się robi Przegląd Sprintu. Ale zaczniemy od definicji, czym jest Przegląd Sprintu.

Jacek: Jakbym miał najprościej zdefiniować „Przegląd Sprintu”, to bym powiedział, że jest to okazja, żeby dokonać inspekcji Przyrostu Produktu i dokonać adaptacji w zależności od tego, co zobaczymy, czego się dowiemy, co będzie wynikiem takiej inspekcji.

Kuba: No, dorzuciłbym – teoretyzując – że to jest wydarzenie scrumowe, kończące Sprint, przedostatnie w kolejce, bo ostatnia jest Retrospektywa Sprintu. Co ciekawe, gdy przygotowywaliśmy się do odcinka, zgodziliśmy się z Jackiem, że tutaj temat Przeglądu Sprintu jest akurat w „Przewodniku po Scrumie” dosyć precyzyjnie opisany. Nie chcemy tutaj czytać „Przewodnika po Scrumie”, ani go jakoś wiernie odtwarzać punkt po punkcie, ale jeśli nie czytałeś lub nie czytałaś niedawno „Przewodnika po Scrumie”, to w temacie Przeglądu Sprintu jest bardzo konkretna lista podpowiedzi, zarówno, po co to jest robione, jak i konkretne punkty, które warto w ramach Przeglądu Sprintu uwzględnić.

Jacek: Tylko znów warto mieć z tyłu głowy to, że to nie chodzi o to, żeby tą listę literalnie wypełnić, a raczej o to, żeby była inspiracją, bo – co do zasady – nadaje dobry kierunek, przy czym w szczególności jeśli masz nieco większe doświadczenie ze Scrumem, no to wierzę, że jesteś w stanie samodzielnie tą listę sobie zaktualizować, poszerzyć, a nawet lekko zmienić, nadal zachowując sensowność tego wydarzenia.

Kuba: Albo jego ducha czy jego esencję. I coś, co też wspomniałem à propos mini-serii, to Przegląd Sprintu jest zwieńczeniem całego Sprintu, więc w ramach tego odcinka na pewno nie chcemy powtórzyć porad, jak zrobić dobry Sprint, bo dobry Sprint będzie prawdopodobnie dawał całkiem dobry, porządny Przegląd Sprintu. Ale jedną radę, Jacek, chciałeś szczególnie powtórzyć z odcinka, w którym ten Porządny Sprint wspominaliśmy.

Jacek: Tak. Porada, o której wspominaliśmy już w odcinku dwudziestym, dotyczącym tego, jak realizować Porządny Sprint, dotyczy tego, że tej inspekcji produktu nie powinniśmy się obawiać również w trakcie Sprintu. I zawsze jak rozmawiam z zespołem, tłumacząc czy rozwiewając wątpliwości na temat tego, czym jest a czym nie jest Przegląd Sprintu, to używam takiego porównania, że Przegląd Sprintu to jest taki „bezpiecznik”, który zapewnia, że co najmniej raz w Sprincie ta inspekcja produktu zostanie wykonana. Natomiast nic nie stoi na przeszkodzie, żeby kawałkami, stopniowo, w niepełnym wymiarze, ten Przyrost Produktu, który wyłania się w trakcie Sprintu pokazywać stakeholderom, poddawać pod dyskusję, czyli po prostu dokonywać takiej inspekcji i adaptacji, ale w takim mikrowymiarze.

Kuba: A taka druga uwaga na temat teorii Scruma czy jego podstaw, to jest temat Przeglądu Sprintu, jako okazji do zrealizowania wartości scrumowych. I często spotykamy się – jeszcze będziemy o tym mówić w dalszej części odcinka – z nieefektywnymi Przeglądami albo Przeglądami, którym czegoś brakuje. No i często to, czego brakuje to jest to, że trochę zabrakło otwartości, trochę zabrakło – mówiąc wprost – powiedzenia całej prawy, przyznania się do, na przykład, błędów albo poproszenia o jakieś… poproszenia o pomoc, bo się zespół z czymś nie jest w stanie wyrobić czy nie jest w stanie sobie z czymś poradzić – no i Przegląd Sprintu jest też – literalnie w „Scrum Guidzie” jest to powiedziane, a ja bym to mocno podkreślił i rozszerzył – jest też okazją do tego, żeby powiedzieć, że coś nie wyszło, a nie tylko co wyszło. Jest w stanie powiedzieć, czego nie wiemy, czego nie rozumiemy. Fajnie, jeśli toczy się w takiej atmosferze i właśnie podzielane są te wartości, które powodują, że zarówno zespół, jak i interesariusze – wszyscy, którzy uczestniczą w Przeglądzie Sprintu – faktycznie bardzo szczerze, bardzo otwarcie, w dużym zaufaniu rozmawiają o tym, jak wyglądają sprawy, gdzie jest produkt, gdzie są jakieś plany, jak wygląda rynek, jak wygląda też jakość produktu, co wszystko w skrócie prowadzi do tego, że efektywny Przegląd Sprintu jest okazją do zbudowania zaufania do tego, co wykonuje zespół i też zaufania wzajemnego pomiędzy zespołem a resztą organizacji. Jeśli na Przeglądzie Sprintu malujemy trawę na zielono i mamy poczucie, że „kupili to”, no to obawiam się, że jesteśmy w jakiejś takiej ślepej uliczce, no i nie „kupili” tego, tylko może nie w każdej organizacji mówi się takie rzeczy wprost, może nie chcieli urazić, a tak naprawdę zaczynamy budować zamiast otwartości, to budujemy jakąś ściemę, no i pierwsza rada spoza takiego pakietu, która będzie w drugiej części odcinka, zdecydowanie Przegląd Sprintu to nie jest miejsce na sprzedaż czy, wręcz powiem, ściemę.

Jacek: Pełna zgoda. Chcielibyśmy zacząć zagłębianie się w temat Przeglądu Sprintu od przejścia po takim stopniowaniu, gdzie chcielibyśmy zacząć od takiej najbardziej nieudanej czy wątłej formy Przeglądu Sprintu i tak krok po kroku pokazywać, w którą stronę może ewoluować to spotkanie, czyli zaczniemy od takiego wariantu najgorszego i stopniowo będziemy dokładać taką, nazwijmy to, progresję, żeby pokazać, w którą stronę Twój Przegląd Sprintu mógłby się rozwijać. No i pierwszy taki punkt startowy to jest punkt, w którym Przegląd Sprintu po prostu w ogóle się nie odbywa. I choć może brzmieć to nieprawdopodobnie, no to nadal w swojej praktyce wspierania firm, jako konsultant zewnętrzny, spotykam się z sytuacją, w której rozmawiamy sobie o Scrumie z zespołem, zadaję jakieś pytania, dopytuję czy rozmawiam z managerem, no i wychodzi, że jakieś tam stand-upy się dzieją, czasem nawet jakieś Retrospektywy, ale kiedy pytam o Przegląd Sprintu, no to słyszę, że „tego akurat nie robią”. Czyli po prostu ten moment, kiedy dokonujemy inspekcji produktu, on po prostu w ogóle nie zachodzi.

Kuba: No, może też być tak – i to też obserwuję w niektórych organizacjach – że Przegląd Sprintu odbywa się, ale nie po każdym Sprincie. Robimy to nieregularnie, czasem są ku temu powody czysto subiektywne, czasem obiektywne – nie mamy czasu, akurat źle wypadło. Albo niestety, ale Sprint wyszedł słabiej, więc w ostatniej chwili odwołujemy Przegląd, bo „coś tam”, no i dokonujemy inspekcji produktu pod warunkiem, że jest to zupełnie na naszych korzystnych zasadach, a w innych przypadkach po prostu nie odbywa się Przegląd.

Jacek: Idąc dalej, możemy dojść do poziomu, w którym mamy już tą regularność, Przegląd Sprintu się odbywa, natomiast nie pojawiają się żadni interesariusze, nie pojawia się nikt spoza składu Zespołu Scrumowego, no więc w konsekwencji, właściwie pokazujemy sobie rezultaty pracy, w ramach zespołu, który te rezultaty powinien znać już poprzez sam fakt współpracowania ze sobą. Tak więc, no, pozornie wydarzenie jest, ktoś mógłby na zielono zaznaczyć checklistę, że Przeglądy Sprintu odbywają się…

Kuba: …w Outlooku się wszystko zgadza.

Jacek: W Outlooku jest w porządku, natomiast w praktyce, jeżeli nie wpuszczamy nikogo spoza zespołu, no to też nie spodziewajmy się jakichś rewolucyjnych wniosków i przemyśleń po przeprowadzeniu Przeglądu Sprintu bez zaproszonych gości.

Kuba: Załóżmy, że jest lepiej i ci goście zaproszeni przychodzą, niestety w niektórych organizacjach zaproszeni goście są „częstowani” jakąś formą prezentacji, jakąś formą opowieści, jakąś formą pokazania czegoś na ekranie, co wygląda jak lista zadań nie do końca łatwa do zinterpretowania. Mówiąc wprost – niektóre Przeglądy Sprintu odbywają się regularnie i z gośćmi, ale niestety nie jest prezentowany Przyrost, nie jest prezentowany rezultat, kolejna wersja działającego produktu, będąca efektem ostatniego Sprintu.

Jacek: I trochę lepszą wersją tego, co powiedział Kuba, jest faktyczne pokazanie produktu, jednak często jest to takie pokazanie produktu – które nazywamy, że to jest takie „demo”. Czyli pokazujemy produkt, natomiast pokazanie tego Przyrostu nie inicjuje dyskusji. Czyli raczej tylko taki jednostronny pokaz, po którym ani nie oczekujemy, ani nie spodziewamy się, ani też nie animujemy dyskusji w kierunku tego, żeby dowiedzieć się: „No dobrze, pokazaliśmy produkt, no i teraz, co z tego wynika?”.

Kuba: No i jeśli wytrwałeś lub wytrwałaś do tej pory, no to ostatni – nadal jeszcze negatywny – przypadek, który czasem spotykamy, to brak rozmowy o planach, co dalej. Tak metaforycznie na każdym Sprint Review spotykamy się po to, żeby spojrzeć wstecz, ale już nie rozmawiamy o tym, co jest obecnie w Product Backlogu, jakie są plany na kolejny Sprint lub kolejne Sprinty. Jeśli przedsięwzięcie, które realizujemy ma jakieś daty brzegowe, to te daty nie są wymieniane. Za każdym razem jest feedback do przeszłości i być może nawet wyciągnięcie z tego wniosków w kolejnym Sprincie, ale interesariusze nie są aktywnie zaangażowani w to, żeby zarówno spojrzeć, rzut okiem na przyrost, ale również rzut okiem na przykład na Backlog Produktu czy inne tematy, które są związane z tym, jak powinien produkt rozwijać się w przyszłości.

Jacek: Pokazaliśmy taki dosyć szeroki wachlarz tego, jak ten Przegląd Sprintu nie powinien wyglądać albo na jakie aspekty zwrócić uwagę i chcielibyśmy teraz podzielić się z Tobą bardzo konkretnymi wskazówkami, jak taki Przegląd Sprintu zrealizować, żeby przynosił wartość. I pierwszą taką naszą poradą i tak się zgodziliśmy z Kubą, że taką bazową – jest porada, która brzmi: „Zawsze pokazuj Przyrost”. Tak jak wspomnieliśmy na samym początku, Przegląd jest okazją, żeby dokonać inspekcji Przyrostu, ale żebyśmy mogli dokonać inspekcji Przyrostu, to musimy go zaprezentować. I porada może brzmieć banalnie, porada może brzmieć w taki oczywisty sposób, natomiast pokazanie efektu pracy, który nie zawsze jest satysfakcjonujący, wymaga odwagi i nie zawsze jest to przyjemny moment dla zespołu, kiedy pokazują Przyrost, ten Przyrost jest niedoskonały, czasem ten Przyrost może być nieskończony, czasem ten Przyrost może nie działać, a czasem wręcz nie ma czego pokazać, no i zespół rozkłada ręce, ale nadal inicjuje rozmowę na temat tego, dlaczego się nie udało, jakie były problemy, co stoi na przeszkodzie, żeby taką regularną przyrostowość produktu uzyskać, tak więc zachęcamy, żeby ten produkt zawsze pokazywać i niech to będzie coś takiego, co uruchamia dalszą dyskusję na temat rozwoju produktu.

Kuba: I może, dla ścisłości, doprecyzuję, że Przyrostem nie jest pokazanie listy skończonych zadań w narzędziu elektronicznym, na przykład Jira. Jira jest Przyrostem pod warunkiem, że pracujemy w Atlassianie. W innych sytuacjach prawdopodobnie nie pracujemy nad przyrostowością Jiry i, owszem, w którymś momencie może Backlog trzeba pokazać, ale może niekoniecznie na początku. I to wcale nie jest takie proste, bo to też może bardzo zależeć od kontekstu, od zespołu, w jakim pracujemy. Jeśli jesteśmy zespołem, który pracuje nad produktem cyfrowym, ale o niezbyt imponującym interfejsie użytkownika – jeśli w ogóle – no to może się okazać, że ten Przyrost to jest na przykład kod albo to jest jakiś interfejs czy jakieś API, jakiś kawałek, który wcale nie jest aż taki prosty do zinterpretowania. No i być może wtedy albo trzeba się z tym pogodzić i sobie to jakoś z interesariuszami przepracować w ramach inspekcji Przyrostu, co to dokładnie znaczy, albo być może dobudować kawałek produktu, żeby rezultaty w ogóle były interpretowalne, a nie że pokazują na przykład pola w bazie danych.

Jacek: Zgadza się. Podałeś przykład taki z branży cyfrowej, natomiast i trudniej, i łatwiej – w zależności od kontekstu – może być w sytuacji, w której używamy Scruma w firmach, które nie produkują nic cyfrowego, czyli albo naszym produktem jest usługa, albo naszym produktem jest jakaś zmiana, albo naszym produktem jest jakiś proces, albo jakieś wydarzenie. No i tak – z jednej strony może to być wyzwaniem o tyle, że jak możemy pokazać zmianę w procesie? Z drugiej strony często, no, te rzeczy, które produkują zespoły niebędące zespołami IT, one nie mają backendu, takiego, który zwykle mamy, jeśli tworzymy produkty cyfrowe, tak więcej najczęściej te zmiany, które mamy, one są namacalne. Czasem taką zmianą jest jakiś nowy proces, czasem to jest jakaś rozpiska, czasem to są jakieś zebrane dane, czasem to jest przeprowadzenie jakiegoś konkretnego wydarzenia i zebranie informacji zwrotnej, przeanalizowanie tego i zaprezentowanie w zjadliwy sposób. Wszystko zależy od kontekstu, natomiast Przyrost powinien być też taki, żeby jego prezentacja umożliwiła nam dyskusję na temat tego: „Dobrze, na dziś jesteśmy w punkcie A, to teraz jak przejść do kolejnego punktu i pytanie, czy to jest B, czy to jest punkt C?”, czyli takie wyznaczenie drogi dalszego rozwoju naszego produktu.

Kuba: I rozmowa o tym, jak zawsze pokazać ten Przyrost na Przeglądzie Sprintu może też wygenerować konieczność wykonania jakichś dodatkowych czynności w środku Sprintu, żeby mieć coś interpretowalnego już na spotkaniu z interesariuszami i fajnie, że wspomniałeś te realia poza IT. Ja bym dorzucił do tego, co powiedziałeś, z jednej strony kwestię na przykład statystyk – jak mamy proces i go zmieniliśmy, to możemy porównać statystyki, ale w trakcie gdy pracujemy nad tym procesem trzeba uwzględnić ten krok, jak to pomierzymy. No, a z drugiej strony, niektóre rzeczy na przykład można sfilmować albo zrobić zdjęcia, zrobić jakieś wywiady, ankiety z osobami, które uczestniczą w jakimś procesie. Jest to być może jakaś dodatkowa praca do wykonania – na pewno to jest dodatkowa praca do wykonania, ale w efekcie uzyskujemy taki namacalny Przyrost, który podlega łatwej interpretacji, a przy okazji też samemu zespołowi też o wiele konkretniej jest interpretować to, co zostało zrobione. Zmieniliśmy proces i jest lepiej, gorzej, niektóre rzeczy widać gołym okiem – to akurat jest bardziej interpretacja praktyki linowej, no ale nie bez powodu również do realiów procesów czy usług czy produkcji wykorzystywana jest po prostu wideorejestracja tego, co się dzieje, bo obraz przemówi do nas o wiele lepiej niż po prostu opowieść czy jakaś sucha statystyka. Idąc dalej z naszymi poradami, czyli kończąc już wątek zawsze pokazywania Przyrostu, przeszedłbym do takiej porady przygotowania się do Przeglądu Sprintu całym zespołem. I wyraźnie chcę odróżnić to, co chwilę temu wspomniałem, czyli to, że czasem przygotowanie przyrostu wymaga pracy do wykonania przez cały zespół, ale ja tu już mówię stricte o wydarzeniu scrumowym jako o po prostu spotkaniu czy prezentacji, jakiejś formy wystąpienia, która powoduje, że jest zaprezentowany rezultat. Zarówno uczestniczy w tym i Product Owner, a ja tutaj mocno podpowiadam i w zasadzie jest to moja domyślna rada dla każdego startującego zespołu: zaangażujcie się w to całym zespołem. Niech każdy, kto uczestniczył w pracy w Sprincie ma jakąś cząstkę, niech będzie współzaangażowany w pokazanie rezultatów, w opowiedzenie, zaangażowany też w dalszą dyskusję – że to z jednej strony angażuje wszystkich i też trochę rozkłada ciężar, czyli to nie jest tak, że Sprint Review jest superstresujące dla jednej osoby, a cała reszta ma przerwę w pracy, a z drugiej strony – jest to takie pokazanie na przykład interesariuszom, że to, co jest Przyrostem jest efektem pracy całego zespołu, wszyscy do tego kontrybuowali, każdy ma kawałek swojej własnej opowieści, swojej własnej prezentacji, swojej własnej odpowiedzi na niektóre pytania, bo współkreował ten przyrost, współkreował efekt kolejnego Sprintu.

Jacek: I to, co powiedziałeś – w szczególności ten ostatni aspekt – z mojej perspektywy jest istotny, bo nawet jeśli zespół w trakcie Sprintu nie pracował jako zespół, a bardziej jako grupa wolnych elektronów, gdzie każdy wziął swoje zadania na planowaniu, zniknął i pojawił się dopiero pod koniec Sprintu, no to samo to zaplanowanie tego wydarzenia kończącego Sprint z perspektywy produktowej, może być bardzo fajną taką aktywnością zespołową – na takiej zasadzie, żeby zaplanować Sprint jako zespół, no to musimy się zastanowić, jak się podzielimy rolami, kto będzie za co odpowiadał, kto zaprezentuje jaki kawałek produktu, kto będzie  notował, kto będzie trzymał czas, kto powita interesariuszy – no i tutaj też ważny komentarz jest taki, że to nie musi być zawsze ta sama osoba. To nie musi być zawsze na przykład Scrum Master, taki „domyślny” w tej roli. Tak jak mówisz, w sensie powiedziałeś o tej „domyślności” porad, no, ja też domyślnie zachęcam do tego, żeby podzielić te role jak najbardziej, żeby każdy miał te swoje parę minut – czy nawet dwie, trzy wypowiedzi – ale raz, żeby się pokazał stakeholderom, żeby pokazać zespołowość, ale też, żeby mieć takie poczucie „Napracowałem/napracowałam się cały tydzień, dwa (w zależności, jak długo trwa Sprint), no i to jest ten mój moment, kiedy mogę się tym pochwalić”. To jest takie supermiękkie z jednej strony i ktoś może powiedzieć: „Jakie to ma znaczenie? Ważny jest ten produkt”. Tak. Ale z drugiej strony jest taki kolejny mikrokrok, który zbliża nas do transformowania grupy osób w faktyczny zespół i uważam, że jest to inwestycja warta swojej ceny.

Kuba: Dobra, to mamy Przyrost, mamy przygotowane spotkanie z perspektywy zaangażowanych wszystkich uczestników zespołu. Jaka jest następna rada?

Jacek: Następna rada brzmi: „Dobierz właściwych interesariuszy i zaproś ich na Przegląd Sprintu”. Jak mówiliśmy sobie na początku o tych takich mniej udanych pomysłach na Przegląd Sprintu, no to jeden z takich wariantów to było spotkanie, podczas którego nie ma interesariuszy. Stąd zaproszenie ludzi spoza zespołu jest bardzo ważne. No i tutaj kluczowe jest to, żeby to były właściwe osoby. To, co obserwuję w zespołach to to, że wpadają w pułapkę wygenerowania listy stakeholderów, a następnie trzymania się tej listy literalnie przez kolejne Sprinty, tygodnie i miesiące, natomiast to, co byśmy chcieli tutaj zaakcentować z Kubą to to, żeby tych stakeholderów dobierać w zależności od tego, jaki kawałek produktu pokazujemy. Tak więc te osoby mogą się zmieniać, pewne osoby mogą się powtarzać na Przeglądach, pewne osoby to mogą być osoby z jakichś nowych obszarów firmy, a czasem nawet możemy być w takiej sytuacji, że do końca nie wiemy, kogo zaprosić. I tu warto poradzić się innych stakehodlerów, poradzić się osób, które są dłużej w firmie, poradzić się osób z managementu – kogo jeszcze moglibyśmy zaprosić, wiedząc, że będziemy pokazywać jakiś tam wybrany aspekt produktu.

Kuba: Często jest jednak tak, że samo zaproszenie – zwłaszcza traktowane jako po prostu wysłanie czegoś w Outlooku – to mało. Tu gigantyczną rolę ma, moim zdaniem, przede wszystkim właściciel produktu, który powinien budować relację z tymi interesariuszami. No, nie traktować ich tak metodą siłową, że wrzuca im coś w kalendarz, tylko po prostu porozmawiać, wyjaśnić, zaangażować, zapytać. Jest ku temu szereg okazji, bo prawdopodobnie Product Owner  jest w jakimś kontakcie z interesariuszami, gdy jest na etapie budowania backlogu, w ogóle rozpoznawania, co jest w ogóle potrzebne w ramach pracy w produkcie na rzecz danego interesariusza lub na styku między produktami, no ale to jest jeszcze jedna okazja do tego, by trochę jak mantrę przypominać, po co jest Przegląd Sprintu, zaprosić na kolejny, wyjaśnić, czego się można spodziewać. I jeśli jesteśmy w firmie, która dopiero stawia pierwsze kroki w Scrumie, to może się okazać, że samo zatytułowanie spotkania w ogóle nikomu nic nie mówi. No a z drugiej strony, jeśli jesteśmy w firmie, która już jest całkiem rozkręcona zwinnie, to może się okazać, że – znowu – samo zatytułowanie „Robimy Przegląd Sprintu produktu X” absolutnie nic danemu interesariuszowi nie mówi, bo na przykład jest odpowiedzialny za marketing w tej organizacji i dostaje pięć zaproszeń na Przegląd Sprintu, no i selekcjonuje wydarzenia, na których się pojawi, musi zrozumieć, po co jest potrzebny na tym wydarzeniu, no i być może – tak jak mówiłeś już wcześniej – być może zapraszajmy takie osoby, nazwijmy je, VIPy, może nie na każde spotkanie, bo i tak nie przyjdą, ale to zadbajmy o to, żeby raz na jakiś czas się pojawili, gdy mamy szczególnie coś do pokazania lub jakiś krytyczny punkt, w ramach rozwoju naszego produktu. I to się pewnie wymyka takim absolutnym radom: „Zawsze miej każdego”, ale realizm czy pragmatyzm mówi mi: „Zadbaj o to, żeby byli ci, co powinni być”. I to z jednej strony jest reprezentacja osób na rzecz których pracujemy, ale też – z drugiej strony – jest zadbanie o to, żeby pojawiali się decydenci, osoby, które realnie mogą wpłynąć na to, co realizujemy. Mogą wpłynąć pozytywnie, mogą też wpłynąć niestety negatywnie, zwłaszcza jeśli ich pominiemy, nie zadbamy o to, żeby się pojawiali.

Jacek: I tutaj płynnie możemy przejść do kolejnej porady, która brzmi: angażuj interesariuszy podczas Przeglądu Sprintu. Co mam na myśli, mówiąc „angażuj”? Dam Ci bardzo konkretny przykład: w jednym z zespołów, który wspierałem, zespół jako część Przyrostu przygotował prototyp gry, która miała być użyta – nazwijmy to tak bardzo szeroko – w celach HR-owych. No i co zrobił zespół? Pokazał pierwszą wersję produktu, co już było ciekawe, bo to był faktycznie prototyp, ta gra była wydrukowana na drukarce, nie była perfekcyjna, nie była doskonała, nie była dopieszczona, ale to, co jest istotne, ona była namacalna. Czyli zespół faktycznie przyniósł tą grę na Przegląd. No i co zrobił dalej? W ramach Przeglądu, zamiast powiedzieć, że zrobili grę i pokazać zdjęcia (co i tak byłoby niezłe), no to oni po prostu powiedzieli: „Słuchajcie, mamy tą grę tutaj i chcielibyśmy w ramach Przeglądu z wami zagrać”. Ja na to patrzyłem z boku, no i pierwsza reakcja stakeholderów była taka: „Co tu się dzieje?”. W sensie… podejrzewam, że nigdy…

Kuba: [śmiech] „Jesteśmy w pracy!”.

Jacek: Tak, nigdy nikt ich nie zaprosił do takiej interakcji, natomiast faktycznie zagraliśmy w tą grę, to nie zajęło dużo czasu – to, myślę, było dziesięć, piętnaście minut – i już widząc, jak toczy się gra (bo gra, tak może dopowiem tylko, polegała na tym, że dosyć często ludzie rotowali się w parach i odpowiadali na bardzo konkretne pytania), no to już po tych interakcjach było widać, że ludziom się podoba. Że te emocje, które chcieliśmy i te zachowania, które chcieliśmy wzmocnić grą – że one faktycznie się pojawiły. I po zakończonej rundzie, po zakończonej grze, wszyscy wrócili na swoje miejsca i można było porozmawiać o tym, jakie doświadczenie właśnie miało miejsce, czy ta gra spełnia oczekiwania, które pokładaliśmy i tak dalej. Tak więc taki, powiedziałbym, ekstremalny przykład zaangażowania stakeholderów, to jest po prostu umożliwienie im doświadczenia, jak to jest wchodzić w interakcje z Przyrostem Produktu.

Kuba: Też mam taki mocny przykład zespołu, który przygotowywał pewne rozwiązania, nazwijmy to, marketingu wewnętrznego, no i właśnie zamiast pokazywać projekty, zamiast pokazywać czy opowiadać jakieś wesołe historie, to po prostu każdy zaproszony na spotkanie interesariusz dostał do ręki kubek, dostał do ręki butelkę, dostał do ręki plakat, dostał do ręki jeszcze parę innych gadżetów, które ten zespół wykonał – to były prototypy, to były jakieś wersje robocze, one tam praktycznie się rozlepiały, ale już można było zupełnie inną interakcję z Przyrostem wykonać, a przy okazji każdy ten interesariusz, jakby, został ewidentnie fizycznie zaproszony do udziału w tym wszystkim. To nie było smutne siedzenie na spotkaniach i przeglądanie swojego telefonu ukradkiem, tylko absolutnie wszyscy zupełnie ożywieni, zupełnie roześmiani – luźne komentarze, ale też bardzo konkretne uwagi zespół zebrał na bazie takiego Sprint Review, a dokładnie to samo można było pokazać w Power Poincie, „Taki mamy projekt kubka”, koniec.

Jacek: Mhm.

Kuba: Zupełnie inaczej do tego podeszli i też zupełnie inaczej zebrali feedback oraz też zbudowali zaufanie do siebie, jako taki zespół dynamiczny, bardzo intensywnie współpracujący z interesariuszami. Natomiast jest tak, że nie każdy zespół ma aż taki fajny produkt.

Jacek: Dokładnie to chciałem dodać, bo takie, myślę, dwa mocne przykłady daliśmy, które mogą być dużą inspiracją, natomiast nie zawsze tak jest. W sensie, czasem ten produkt jest mniej namacalny albo ta interakcja nie jest aż tak bardzo możliwa, natomiast nadal można angażować stakeholderów poprzez zadbanie o to, żeby ich opinia wybrzmiała. I to możemy zrobić zadając ogólne pytanie do wszystkich uczestników, albo zadając punktowe pytanie do konkretnych osób i zapewnienie, że wszyscy się wypowiedzą. To nie musi być też pytanie w formie słownej, to może być ankieta rozdana papierowa bądź wysłana elektronicznie, przy czym zwykle ten współczynnik odpowiedzi tych papierowych – na bazie moich doświadczeń – jest wyższy. To może być jakiś feedback door, czyli technika, w której interesariusze zostawiają feedback w jakimś konkretnym miejscu, przy tym tu znów warto zadbać o to, żeby to nie było tylko zostawienie feedbacku, tylko żeby jednak na bazie tych przemyśleń dokonać jakiejś dyskusji. Tak więc tych możliwości jest dużo, cel jest jeden: uruchomić dyskusję, spowodować, że zaczniemy się zastanawiać, co dalej z produktem, w którą stronę idziemy, czy to, co zobaczyliście, czy to spełnia wasze oczekiwania, co byłoby jeszcze lepsze – czyli techniki tutaj mają znaczenie drugorzędne, bardziej chodzi o efekt, który chcemy uzyskać. 

Kuba: I nawet jeślibyśmy nie chcieli – z jakiegokolwiek powodu – wchodzić w żadną z bardziej wysublimowanych technik i chcemy zrobić po prostu dyskusję, to naprawdę byłbym czujny na to, jakie pytania zadajemy, czy zostawiamy przestrzeń na odpowiedź na te pytania, bo niestety często widzę jedno jedyne pytanie na samiuśkim końcu spotkania, gdy już w zasadzie wszyscy wstają z krzeseł: „Czy są jeszcze jakieś pytania? Nie? Dzięki, dobrze, to do widzenia”. I może i byłyby te pytania, może ktoś siedział cały czas się nie odezwał, bo akurat nie było momentu pasującego, żeby się wypowiedzieć, no i przegapiliśmy okazję, żeby ciekawy wątek usłyszeć albo chociaż kontrowersyjny, ale cały sens jest tego, żeby tą inspekcję zrobić głęboko, przedyskutować głęboko, no i być może się nie zgodzić, ale chociaż wiedzieć, że są różne zdania. Następną poradą, którą bym podsunął z trochę innego kalibru – ale też dosyć technicznego – to rada: wizualizuj przebieg  spotkania. Często spotkania scrumowe – zwłaszcza Przegląd Sprintu, gdy jest dosyć liczny udział gości, sporo wątków – mogą być dosyć chaotyczne. I to dosyć chaotyczne z samego przebiegu, nawet bardzo zaangażowana dyskusja też potrafi być chaotyczna. Ludzie się przekrzykują, zadają pytania, ktoś tam nie dokończył wątku, a pojawia się zupełnie nowy. I bardzo wartościowe jest, jeśli zaplanujemy całym zespołem, że ten przebieg będzie w jakiś sposób zwizualizowany. Gdy mówię „wizualizowany” mam przede wszystkim na myśli spisywane punkty dyskusji, pytania, wnioski, decyzje. Ale być może jest to też dyskusja, w której po prostu można narysować jakiś kawałek procesu, narysować schemat naszego produktu, być może schemat naszego interfejsu, jeśli nie mamy go gotowego, ale jest realizowana jakaś dyskusja, czyli wszystko to, co pozwoli nam lepiej się komunikować. O wiele lepiej komunikujemy się, gdy mamy przed oczami tekst lub rysunek niż tylko gdy jedna osoba mówi do drugiej osoby i w powietrzu wisi jakaś notatka, ale nikt nigdy jej nie zapisał. Zapisujmy. No i można to zrobić na parę sposobów.

Jacek: Tak. I to nie musi być przede wszystkim jedna ta sama osoba – czyli, znów, tak naturalnie to, co obserwuję, no to wpadamy w pułapkę: „Scrum Master będzie notował” i stoi biedny lub biedna z tym pisakiem. Tak naprawdę dowolny członek zespołu może wziąć pisak i zacząć przeprowadzać czy prowadzić notatki z tego, co się dzieje. Dowolna osoba z zespołu może jakieś tam rzeczy zacząć przedstawiać w sposób wizualny, na przykład przy użyciu kartek typu post-it i zapisywać różnymi kolorami różne rzeczy, po to, żeby na koniec spotkania łatwo było powiedzieć, które elementy zapisane dotyczą tematu A,  które dotyczą tematu B. Tak naprawdę to, co zakodujemy kolorystycznie, to może być dowolna rzecz, tak więc istotne jest to, żeby – i myślę nawet, że to jest taka też rada ukryta w tej radzie – żeby faktycznie dbać o to, żeby ta rola była rotacyjna. Dlaczego? Moje doświadczenie jest takie, że w momencie, kiedy wchodzimy w taką rolę – takiego facylitatora, moderatora czy osoby, która notuje – no to o wiele bardziej empatyczni stajemy się, kiedy inna osoba prowadzi, a my jesteśmy członkiem zespołu, no i reagujemy bądź nie, na to, o co ta osoba nas prosi. Tak więc jeżeli wszyscy w zespole sobie taką rundkę zrobią i zobaczą, że to nie jest takie proste utrzymać porządek w grupie, gdzie na przykład możemy mieć piętnaście, dwadzieścia osób na przeglądzie, no to trochę więcej mamy empatii, jak jesteśmy w roli członka zespołu i widzimy, że jakaś osoba stara się, próbuje, nie może dojść do głosu – swoją postawą możemy pomóc tej osobie przeprowadzić to spotkanie, tak więc taka empatia dla osoby, która prowadzi, moderuje, uważam, że to jest coś, co warto rozwijać.

Kuba: Ja bym podkreślił coś, co może być źle zinterpretowane w tej naszej radzie. Nam nie chodzi tylko o to, żeby robić notatkę ze spotkania – bo często notatka wydaje się dosyć oczywista, że siedzi ktoś, kajecik, długopis i skrzętnie notuje wszystko to, co się wydarzy. Bardzo dużą wartością jest to, że ta notatka jest i jest ona czytelna i widoczna dla wszystkich uczestników. Interesariusze, którzy zgłaszają jakieś pomysły, pytania, uwagi, wnioski – widzą, że wszystkie te rzeczy są zawarte, czyli że nie jest nic pomijane. Zespół po wszystkim może do tego wrócić i – tak, jak mówisz o pomocy – to jeśli ja widzę, jako członek zespołu, że ktoś męczy się z notatką i na przykład pominął jakiś ważny punkt, to ja od razu na bieżąco w czasie spotkania mogę go dopisać. Jeśli widzę, że bardzo przekręcił w hasłowym znotowaniu to, co powiedział jakiś interesariusz, to też mogę to doprecyzować i interesariusz też może powiedzieć: „No, tak jak to zapisaliście, to nie oddaje tej myśli, którą ja przekazuję”. Więc tutaj możemy też się o wiele lepiej zrozumieć i tak na przyszłość z tego skorzystać, jak wszyscy tą notatkę widzimy przed oczami. Ważne, żeby to nie było coś, co blokuje nam tempo spotkania. Stąd tutaj ta „rada w radzie”, o której ty powiedziałeś, niech to będzie dedykowana osoba w zespole, być może niezaangażowana w inne czynności w ramach spotkania, żeby faktycznie skupić się w stu procentach na oddaniu przebiegu spotkania.

Jacek: Ja tylko zaakcentuję, że cieszę się, że to powiedziałeś, czym jest ta notatka, czym nie jest, bo możemy mieć różne skojarzenia – i my, i ty słuchaczu – w sensie, to absolutnie nie są „minutki”, to nie jest „protokół”. Bardziej to są ważne aspekty dotyczące naszego produktu, które wypłynęły. Pomysły wątpliwości, rzeczy, które zespół będzie potrzebował sprawdzić, inspiracje. Czasem ktoś podrzuci kontakt w organizacji, na zasadzie: „Wiecie co, w tym temacie to idźcie do osoby X”. Wszystkie te rzeczy warto uchwycić, bo w tym całym takim też napięciu pewnym w trakcie Przeglądu Sprintu, gdzie zespół oczywiście chce też, oprócz feedbacku, po prostu wypaść jako kompetentny, bardzo łatwo jest, żeby te rzeczy umknęły, zapomnimy, wydaje nam się, że ktoś zapisze, ale w sumie nie zapisuje, tak więc takie transparentne podejście do wizualizacji ważnych aspektów tego spotkania uważam, że jest bardzo wartościowe.

Kuba: I ostatnią radą, którą sobie wyselekcjonowaliśmy i chcemy się z Tobą nią tutaj podzielić, to rada, żeby eksperymentować z formułą. Staraj się, zmieniaj, poprawiaj, nawet jeśli bieżący sposób realizacji Przeglądu Sprintu już jest całkiem w porządku.

Jacek: Ostatnio pracowałem z zespołem i bardzo fajnie zespół – tak na uważam takiej bardzo dosyć dużej samoświadomości – zaczął dyskutować o tym, jak bardzo formuła ich spotkań przeglądowych się zmieniła – gdzie zaczynali od salki w ustawieniu teatralnym, potem zmienili ustawienie teatralne na półokrągłe. Następnie raz siedzieli wszyscy członkowie teamu, potem stali, potem rotacyjnie byli angażowani w tematy, następnie stwierdzili, że: „może spróbujmy w dużej salce. W dużej salce w sumie nie do końca było tak fajnie, jak się spodziewaliśmy, bo przytulniej było w mniejszej, było więcej interakcji”. Tak, powiem metaforycznie, bo ludzie trochę bardziej wpadali na siebie i nie można było za bardzo uciec. I pewnie w trakcie dalszych prac będą odkrywać kolejne pomysły – z projektorem, bez projektora, ankieta pisemna czy słowna. Tu pole do popisu jest bardzo duże i jakby… o tyle to chciałbym zaakcentować, że wspomniałeś, że w „Scrum Guidzie” tam jest jakiś przepis – no i znów, żeby nie wpaść w tą pułapkę, jak ten Przegląd Sprintu przeprowadzić, a raczej potraktować to jako punkt wyjścia, a następnie w sposób ciągły szukać lepszych sposobów pokazywania Przyrostu Produktu stakeholderom. Uważam, że to jest kluczowe.

Kuba: Rzuciłeś serią bardzo fajnych możliwych alternatyw na to, jak poprowadzić Przegląd Sprintu. Z takich najbardziej szalonych eksperymentów, którego ja byłem świadkiem to to, gdy Zespół Scrumowy chcąc rozmawiać o dalszych krokach w rozwoju swojego produktu – a byli na takim, powiedzmy, rozdrożu i było kilka alternatyw, Product Owner chciał zasięgnąć rady interesariuszy, zobaczyć, co interesariusze by rekomendowali. No, w tym przypadku akurat konkretnie Product Ownerka przyniosła z domu zestaw banknotów z „Monopoly”, rozdała interesariuszom i zamiast robić ankietę albo robić zestaw wolnych wniosków, co uważacie, że warto byłoby zrobić, interesariusze po prostu musieli te pieniądze z Monopoly rozłożyć na, nazwijmy to, kapelusze, które reprezentowały konkretne kierunki rozwojowe i jak w „Dragons’ Den” zainwestować w kierunki, które ich zdaniem powinny być wybrane, co było jakąś tam rekomendacją dla Product Ownerki, natomiast z perspektywy odbioru i z perspektywy formuły była to zmiana rutyny, bardzo zmieniająca interakcję z interesariuszami, przeżycie dla całego zespołu. No i na początku może była trochę obawa, czy nie jesteśmy za bardzo niepoważni, ale jak interesariuszom się powiedziało, że są inwestorami, no to się każdy poczuł bardzo zaangażowany, nawet jeśli była to jakaś forma gry. No i myślę, że to też jest taka gdzieś granica czy właśnie powiedzenie: „No, nie ma granic, angażujmy się, miejmy pewien luz, wyciągajmy, co się da, najwyżej odkryjemy granicę, że przesadziliśmy, że było zbyt luźnie, zbyt szalenie, póki nie spróbujemy, to się tego nie dowiemy”.

Jacek: Fajne to, co mówisz, bo to wyraźny przykład pokazujący, jak można pójść z Przeglądem, jeśli chodzi o przesuwanie tego punktu, w którym to jest takie bardzo statyczne, czasem nawet statusowe spotkanie – w taką formułę warsztatową, gdzie faktycznie angażujemy osoby – i to nie tylko na zasadzie: „Powiedz nam, co myślisz”, tylko one wchodzą w pewien proces współtworzenia produktu, decydowania o kierunku czy w ogóle wymyślania alternatyw. I im dłużej pracuję w zwinnych środowiskach, tym coraz bardziej się przekonuję, że właśnie to jest ta właściwa formuła i im bardziej ona jest interaktywna, tym po prostu z tych Przeglądów jesteśmy w stanie wyciągnąć więcej dla siebie.

Kuba: To na koniec podsumuję nasze porady, jak robić dobrze Przegląd Sprintu. Zawsze pokazuj Przyrost, przygotuj się całym zespołem, miej jako interesariuszy właściwe osoby, angażuj zebranych na wydarzeniu, wizualizuj przebieg spotkania i eksperymentuj z formułą.

Jacek: Na koniec chcielibyśmy zaprosić Cię do dołączenia społeczności, którą budujemy wokół podcastu Porządny Agile. Zapraszamy Cię do dołączenia do naszej listy mailingowej, którą znajdziesz pod adresem porzadnyagile.pl/lista.  Zostawiając nam swój adres mailowy, będziemy w stanie być z Tobą w kontakcie, będziemy wysyłać Ci dodatkowe materiały spoza tego, które publikujemy w ramach podcastu, między innymi też podzielimy się tym, jak pracujemy, czyli taki trochę „Porządny Agile od kuchni”.

Kuba: Albo: „Making of”.

Jacek: Albo „Making of”. Mamy wiele różnych pomysłów. Część z tych pomysłów już jest realizowana, mamy też kolejne, tak więc jeżeli chciałbyś lub chciałabyś dostać coś więcej od nas niż tylko ten podcast, dołącz do naszej społeczności porzadnyagile.pl/lista.

Kuba: A ci z Was, którzy już na tej liście są, zapraszamy do obukierunkowegko kontaktu – my wysyłamy Wam powiadomienia o nowych odcinkach, również wyślemy te dodatkowe materiały, o których Jacek wspominał przed chwilą, ale jeśli macie do nas jakieś pytania, komentarze albo po prostu dobre słowo, koniecznie się tym podzielcie, bo daje nam to dużego powera.

Jacek: I to by było wszystko na dzisiaj. Dzięki, Kuba.

Kuba: Dzięki, Jacek.

Jacek: I do usłyszenia…

Kuba i Jacek: …wkrótce!