Pora na przedostatnią część wędrówki po mitach, nieporozumieniach i półprawdach na temat Scruma. Tym razem zajmę się Przeglądem i Retrospekcją Sprintu.

Przypominam, że dostępne są cztery poprzednie części, które najwygodniej czytać po kolei, ale nie jest to konieczne (część pierwsza, część druga, część trzecia oraz część czarta).

Mit 43: Przegląd Sprintu to oficjalna nazwa demo

Jednym z najstarszych i do tego bardzo szkodliwym nieporozumieniem związanym ze Scrumem jest przekonanie, że celem Przeglądu Sprintu jest zaprezentowanie interesariuszom najnowszej wersji produktu. Trudno więc dziwić się, że do zdarzenia przylgnęła nazwa demo i nie tak łatwo ją od niego odlepić.

W rzeczywistości Przegląd Sprintu to zdarzenie, w którego trakcie następuje inspekcja:

  • bieżącego stanu produktu,
  • postępów w osiąganiu Celu Produktu,
  • adekwatności tego Celu w odniesieniu do aktualnych potrzeb interesariuszy,
  • planów dalszego rozwoju produktu opisanych w Backlogu Produktu,
  • wszystkiego, co ma istotny wpływ na przebieg prac nad produktem.

Inspekcja może ujawnić, że produkt rozbiega się z potrzebami interesariuszy (bo się zmieniły, bo pojawiły się nowe, bo Zespół źle je zrozumiał). Jej skutkiem może być uznanie Celu Produktu za osiągnięty albo nieaktualny (wtedy trzeba ustanowić kolejny). Sam Backlog Produktu też może się zmienić.

Celem Przeglądu jest potwierdzenie kierunku, w jakim zmierza rozwój produktu i jego adaptacja, jeśli okaże się to konieczne. Ograniczenie zdarzenia wyłącznie do demonstracji skutkuje przerwaniem pętli inspekcji i adaptacji, bo odbywa się wyłącznie sprawdzenie.

Mit 44: Przeglądu Sprintu wymaga demonstracji każdej zmiany

Pochodną mitu poprzedniego jest przekonanie o konieczności zaprezentowania interesariuszom wszystkiego, co zdołali wytworzyć Developerzy. Interesariusze są więc bombardowani nadmiarem informacji, a nierzadko Przegląd zamienia się w wykonywanie na żywo raz jeszcze wielu testów. Jeśli jakaś funkcjonalność nie ma aspektów wizualnych, Zespoły potrafią pokazywać np. logi z działania systemów informatycznych albo i sam kod…

Sensu nie ma to żadnego i rozsądniej byłoby zapytać interesariuszy, co chcą zobaczyć. Albo jeszcze lepiej udostępnić im nową wersję produktu i być gotowym do udzielenia wyjaśnień, jeśli pojawią się pytania. O niewizualnych aspektach działania produktu można natomiast opowiedzieć. No, chyba że Zespół boi się, że interesariusze nie uwierzą w to, co usłyszą, ale to już zupełnie inny problem.

Mit 45: w trakcie Przeglądu każdy Developer ma pokazać efekty swej pracy

Developerzy, jeden po drugim, wyjaśniają, nad czym pracowali w Sprincie i demonstrują zmiany w produkcie, których dokonali. Brzmi znajomo? Mam nadzieję, że nie, ale obawiam się, że każdy choć raz zetknął się z Zespołem, który tak postępuje.

Gdzieś u podstaw tego nieporozumienia leży przekonanie o tym, że Przegląd Sprintu to demo, ale jest w nim też silna domieszka dwóch mitów, o których już pisałem w części drugiej cyklu: że Planowanie Sprintu to moment zawierania kontraktu na dostarczenie konkretnych funkcjonalności na koniec Sprintu (mit 16), a za każdą zmianę odpowiada indywidualnie jakiś Developer (mit 17).

Nakłada się czasami na to oczekiwanie ze strony kierownictwa (a bywa, że również interesariuszy), by Developerzy „wyliczyli się” z wykonanej pracy.

Oczywiście to sprzeczne z ideą skupienia na Celu Sprintu i wartości dla interesariuszy – ważniejsze się staje „dowiezienie” wszystkiego zgodnie z planem i wykazanie się produktywnością. Nie pasuje też do sensu istnienia wszechstronnego Zespołu Scrum, który łączy kompetencje, by wspólnie rozwiązywać złożone problemy, zamiast borykać się z nimi jednoosobowo, w razie potrzeby przerzucając robotę od Developera do Developera.

Mit 46: Developerzy są gospodarzami Przeglądu Sprintu

Skoro Przegląd to demo, a przeprowadzić mają go Develoeprzy, są gospodarzami spotkania. Product Owner w tej wizji Przeglądu jest w zasadzie jednym z interesariuszy, a zdarza się, że i jego trzeba zapraszać (zupełnie tak, jakby nie był częścią Zespołu).

Jak to powinno wyglądać? Cały Zespół gości interesariuszy, a jeśliby już doszukiwać się roli gospodarza spotkania, powinien nim być raczej Product Owner. Co więcej, tenże Product Owner musi wiedzieć, jeszcze nim rozpocznie się Przegląd, co zostało ukończone, ale z tym akurat nie powinno być problemu, bo przecież uczestniczy w Sprincie, nawet jeśli nie jest jednocześnie Developerem.

Mit 47: Product Owner jest moderatorem Przeglądu Sprintu

Jeśli nie Developerzy, to na pewno Product Owner będzie prowadził spotkanie, bo to w końcu jego produkt i Developerzy realizowali zmiany, o których zdecydował. Wydaje się to logiczne. Niemniej za tym sposobem myślenia kryją się dwa nieporozumienia.

Jedno związane jest z przekonaniem, że jakiś moderator zawsze jest potrzebny – a przecież grupa zaangażowanych ludzi potrafi prowadzić dyskusję również bez moderatora.

Drugie nieporozumienie: moderatorem może być każdy w Zespole Scrum. Nic nie stoi na przeszkodzie, by był nim czasami Scrum Master, czasem któryś z Developerów, a w pozostałych przypadkach (pewnie najczęściej) Product Owner. Spotkanie może zresztą prowadzić więcej niż jedna osoba, zależnie od tego, czego akurat dotyczy dyskusja.

Przy okazji: warto, by Zespół Scrum ustalił przed Przeglądem, jak chce go poprowadzić, żeby zdarzenie było maksymalnie wartościowe dla wszystkich uczestników.

Mit 48: Przegląd Sprintu to scrumowa forma odbioru produktu

Ciągoty do rozliczenia się z wykonanej pracy przybierają różne formy, z których jedna wiąże się z przekonaniem o istnieniu jakichś odbiorów produktu w Scrumie. W klasycznych projektach klient często zleca wykonanie prac, po czym w ustalonych momentach pojawia się, by zaakceptować (lub odrzucić) to, co zostało zrobione – to właśnie wspomniane odbiory. Przegląd Sprintu ma rzekomo być ich odpowiednikiem.

A przecież Scrum to nie metoda projektowa, tylko proces długotrwałego rozwoju produktu w serii krótkich iteracji w sposób przyrostowy. Nie ma w nim odbiorów, bo nie mają one sensu:

  • o tym, czy produkt jest techniczne ukończony, rozstrzyga spełnienie warunków zawartych w Definicji Ukończenia,
  • rzeczywistą wartość produktu potwierdzi użycie najnowszej jego wersji.

Celem Zespołu w trakcie Przeglądu nie jest przecież udowodnienie interesariuszom, że zostało zrobione to, co wykonane być powinno. Chodzi o ustalenie, czy produkt, jaki powstał, jest tym, jakiego teraz potrzebują, a jeśli ma zostać zmieniony, to w jaki sposób.

Do tego Sprinty służą potwierdzeniu (walidowaniu) hipotez odnośnie do tego, co jest możliwe do zrobienia i co przyniesie korzyści interesariuszom, a nie do realizowania z góry ułożonego szczegółowego planu i rozliczania się z jego wykonania.

Mit 49: Przegląd Sprintu potwierdza wartość produktu

Można spotkać się ze stwierdzeniem, że feedback od interesariuszy to potwierdzenie wartości, jaką udało się wykreować w ciągu Sprintu. Cóż, nie jest to prawdziwe stwierdzenie, ponieważ dopóki najnowszy Przyrost nie zostanie faktycznie użyty i nie zbierze się informacji na temat jego działania w praktyce, dopóty wartość pozostaje jedynie potencjalna.

To nieporozumienie wydaje się mało istotne, ale może mieć dalekosiężne skutki. W organizacjach, które postrzegają Przeglądy jako wystarczające narzędzie do walidacji produktu, nie podejmuje się wysiłków, by użycie nowych wersji produktu następowało szybko i często. Wszyscy poklepują się po ramionach, patrząc na listę ukończonych rzeczy i ciesząc się na korzyści, które już uzyskano, po czym w końcu użytkownicy dostają produkt do rąk i… następuje bolesna niespodzianka.

Mit 50: w trakcie Przeglądu Sprintu ustala się, co zostało ukończone

Jeszcze paskudniejszym nieporozumieniem niż wspomniane wcześniej odbiory jest przekonanie, że o tym, czy development zakończył się i powstał Przyrost, rozstrzygają uczestnicy Przeglądu Sprintu. Mit ten idzie pod rękę z innym, o którym pisałem w części czwartej cyklu – że w Sprincie powstać ma tylko jeden Przyrost.

Jest to oczywiście bzdura, bo Zespół Scrum, jeszcze zanim rozpocznie się Przegląd, musi wiedzieć, co udało się ukończyć i z czym wybiera się na spotkanie z interesariuszami. Punktem odniesienia do oceny jest tutaj Definicja Ukończenia. Pomysł, by wespół z interesariuszami dywagować, co jest ukończone, pojawia się często tam, gdzie tej Definicji brak albo jest ona stosowana wybiórczo.

Bywa też, że Zespół uznaje za Przyrost tylko taką wersję produktu, o której interesariusze mówią, że chcą jej użyć. I jest to jak najbardziej możliwe w Scrumie, bo nic nie stoi na przeszkodzie, by Definicja Ukończenia wymagała nie tyle powstania produktu nadającego się do użycia, ile jego faktycznego przekazania użytkownikom. Tyle że w takim przypadku to przekazanie do użycia (niektórzy powiedzą: wydanie) musi nastąpić jeszcze przed Przeglądem Sprintu, a nie po nim albo w trakcie.

Inaczej mówiąc, taki wymóg w Definicji Ukończenia nie zwalnia Zespołu z konieczności jej spełnienia w ramach developmentu, który kończy się przed Przeglądem.

Mit 51: development nie musi zakończyć się przed Przeglądem

Czy aby na pewno development nie może trwać do ostatniej chwili Sprintu? Zdarzyło mi się uczestniczyć (na szczęście jako obserwator) w Przeglądach, gdzie omawiane były rzeczy wciąż nieukończone („ale mamy jeszcze dwie godziny, żeby je skończyć”). Byłem też świadkiem jednego Przeglądu, w którym „zapomniano” interesariuszom powiedzieć, że to, co widzą, wciąż jest robione…

Przypominam więc: Przegląd służy empirycznemu sprawdzeniu stanu spraw i podjęciu na tej podstawie decyzji (adaptacji planów dalszego działania). Wszystko, czego do Przeglądu nie udało się ukończyć, wciąż pozostaje do zrobienia i żadne „prawie skończone” oraz „za dwie godziny” nie mają sensu, bo stanowią odejście od empiryzmu. A bez empiryzmu Scruma nie ma.

Mit 52: decyzja o użyciu produktu zapada w trakcie Przeglądu

Warto też wyklarować kolejne nieporozumienie, jakoby nowa wersja produktu, czyli Przyrost, mogła być użyta wyłącznie na koniec Sprintu, jeśli zapadnie taka decyzja w trakcie Przeglądu.

Skoro Przyrostem jest nowa wersja produktu nadająca się do użycia, w pełni ukończona w myśl zapisów Definicji Ukończenia, to znaczy, że każdy Przyrost może zostać przekazany użytkownikom. Nie ma żadnego powodu, by zwlekać z tym do końca Sprintu.

Mit 53: Product Owner może wydać nieukończony produkt

Nikt nie będzie się spierał, że Przyrost nadający się do użycia można wydać (czyli przekazać użytkownikom). Wiele osób idzie dalej i twierdzi, że Product Owner ma prawo, z racji bycia właścicielem produktu, wydania każdej nowej jego wersji, nawet jeśli nie została wytworzona w myśl wymogów zawartych w Definicji Ukończenia.

Czy to poprawna interpretacja zasad Scruma? Absolutnie nie. O tym, czy produkt można wydać, decyduje cały Zespół, bo Developerzy określają, czy powstał Przyrost, a Product Owner ocenia, czy taki Przyrost jest sens przekazywać użytkownikom. Prawo głosu ma też Scrum Master, który musi zapobiec próbom przeprowadzenia wydania skutkującego spadkiem przejrzystości lub uniemożliwiało empiryczny rozwój produktu.

Można więc powiedzieć, że jeśli nie ma Przyrostu, nie istnieje w ogóle podmiot decyzji o wydaniu, a decyzję tę podejmuje wspólnie cały Zespół.

Mit 54: Przegląd Sprintu jest zdarzeniem retrospektywnym

Skoro Przegląd Sprintu skupia się nad tym, co udało się wytworzyć w trakcie iteracji, jaki Cel udało się osiągnąć i jakie inne istotne informacje Sprint ujawnił – jest to zdarzenie retrospektywne, zajmujące się tym, co już się stało. Czy to prawda?

Nie, to kolejny mit. Przegląd obejmuje przecież dyskusję na temat planów dalszego rozwoju produktu, a sprawdzenie tego, co było i co powstało do tej pory, służy jej zasileniu empirycznymi danymi. Dlatego zdarzenie to skierowane jest w przyszłość i można powiedzieć, że jest to przegląd perspektywy nadchodzących Spritnów bardziej niż retrospektywne spojrzenie na ten, który właśnie się kończy.

Mit 55: Retrospekcja Sprintu służy usuwaniu problemów

A skoro o Retrospekcji Sprintu mowa, to dla wielu Zespołów Scrum jest oczywiste, że ma ona na celu zidentyfikowanie, co poszło nie tak i naprawienie popełnionych błędów. W efekcie Retrospekcje stają się sesjami szukania dziury w całym, gdy Zespół już na tyle dobrze sobie radzi, że oczywistych problemów znaleźć nie może. Albo przestaje Retrospekcje prowadzić, bo uznaje, że nie są mu potrzebne.

Tymczasem w Scrumie Retrospekcja Sprintu to zdarzenie, którego celem jest poszukiwanie możliwych usprawnień i podnoszenie skuteczności działania Zespołu nie dlatego, że coś działa źle i wymaga naprawy, ale dlatego, że może działać jeszcze lepiej. Usprawnianie to nie tylko rozwiązywanie problemów, jak pisałem wiele lat temu.

Prawidłowa będzie więc Retrospekcja, która skupi się na szukaniu nowych możliwości i nauczeniu czegoś, co pomoże Zespołowi się rozwinąć. Zachęcam, by z takiej możliwości korzystać.

Mit 56: w trakcie Retrospekcji Sprintu nie dyskutuje się o produkcie

Sprint obejmują dwie pętle inspekcji i adaptacji: jedna dotyczy produktu i jego rozwoju, druga Zespołu i procesu, jakim się posługuje. Obie zaczynają się Planowaniem Sprintu, pierwsza kończy się Przeglądem, a druga Retrospekcją.

A skoro istnieją dedykowane zdarzenia poświęcone każdej z nich, w trakcie Przeglądu nie dyskutujemy o Zespole i procesie, a w trakcie Retrospekcji o produkcie i jego rozwoju.

I właściwie można się zgodzić z tymi wnioskami, ale nie oznacza to, że w trakcie Retrospekcji dyskusja o produkcie jest niepożądana. Są bowiem dwa aspekty, które wymagają uwagi Zespołu: to, jaki produkt budować oraz to, w jaki sposób go budować. Na tym pierwszym aspekcie skupia się Przegląd Sprintu. Natomiast na tym drugim Retrospekcja.

Dlatego jest jak najbardziej właściwe i pożądane, żeby Zespół w trakcie Retrospekcji szukał sposobu usprawnienia produktu od strony technicznej, np. uzupełniając Definicję Ukończenia tak, by powstawał Przyrost wyższej jakości. Może nawet zdarzyć się, że wnioski w Retrospekcji przełożą się na zmiany funkcjonalne produktu, jeśli potrzebne będzie wbudowanie w niego mechanizmów, które np. ułatwią monitorowanie działania różnych funkcjonalności.

Mit 57: tylko Zespół Scrum może brać udział w Retrospekcji

W wielu organizacjach nie do pomyślenia jest, by ktokolwiek spoza Zespołu Scrum wziął udział w Retrospekcji Sprintu. W końcu służy ona Zespołowi, a szczera i otwarta dyskusja wymaga poczucia bezpieczeństwa. Nie mówiąc już o tym, że Scrum Guide jasno określa, kto bierze udział w tym zdarzeniu.

I jest to niemal prawda, bo faktycznie, bez zgody ze strony Zespołu nikt na Retrospekcję pchać się nie powinien. Niemniej sam Zespół ma jak najbardziej prawo zaprosić do udziału kogokolwiek, kogo obecność uzna za niezbędną. Przykładem może być zaproszenie jakiegoś kierownika, by przedyskutować z nim potrzeby Zespołu.

Mit 58: Retrospekcję Sprintu ma prowadzić Scrum Master

Skoro Retrospekcja Sprintu służy poszukiwaniu usprawnień, a za podnoszenie skuteczności odpowiada Scrum Master, to powinien być jej moderatorem, czyż nie? Przekonanie o tym jest dość powszechne, a umiejętność przygotowania i poprowadzenia dobrej Retrospekcji ma stanowić swoisty egzamin dojrzałości dla Scrum Masterów.

Tyle że to nieporozumienie. Tak, Scrum Master bierze na siebie odpowiedzialność za skuteczność Zespołu, ale jednym z przejawów tej skuteczności jest zdolność dokonywania usprawnień bez moderacji Scrum Mastera. Inaczej mówiąc, nie ma żadnego obowiązku, by to Scrum Master moderował zdarzenie, ani nawet nie ma obowiązku moderowania go przez kogokolwiek (pisałem o tym jakiś czas temu).

Mit 59: Przegląd i Retrospekcja muszą odbyć się w tym samym dniu

W dużej liczbie Zespołów (o ile nie w większości) Sprinty zaczynają się i kończą w ten sposób, że Przegląd i Retrospekcja realizowane są w ostatnim dniu iteracji, a Planowanie Sprintu kolejnego odbywa się w dzień później. Z tej powszechności narodziło się przekonanie niektórych użytkowników Scruma, że jest to wymagany podział.

Tymczasem ważna jest sekwencja: Sprint zaczyna się Planowaniem, a kończy Przeglądem, po którym następuje Retrospekcja. Wszystkie te zdarzenia mogą się odbyć jednego dnia albo i w trzech różnych dniach, byleby odbywały się po kolei.

Mit 60: usprawnienia z Retrospekcji trzeba dodać do Backlogu Sprintu

Skoro usprawnienia zidentyfikowane w trakcie Retrospekcji Sprintu mają być realizowane w Sprincie kolejnym, nasuwa się logiczny wniosek, że powinny być dodane do Backlogu tego Sprintu, najpóźniej w trakcie najbliższego Planowania. I faktycznie, to prawda, ale nie w każdym przypadku.

Nieporozumienie bierze się z tego, że z rozpędu Zespoły dodają do Backlogu Sprintu wszystkie usprawnienia, niezależnie od ich charakteru i tego, kto ma nad nimi pracować. A przecież Backlog Sprintu jest artefaktem, którym niepodzielnie zarządzają Developerzy i służy organizacji ich pracy.

Jeśli więc zidentyfikowano usprawnienie, nad którym Developerzy nie będą pracować, bo np. dotyczy tego, czym zajmuje się Product Owner, to jaki sens jest dodawać je do Backlogu Sprintu?

To nieporozumienie wynika poniekąd z jednej z poprzednich edycji Scrum Guide, w której taki wymóg był zapisany w sposób nie do końca czytelny (więcej o tym piszę tutaj). Na szczęście w 2020 kontrowersyjne zalecenie już się nie pojawia, choć czkawką odbija się w wielu Zespołach nadal.

Ciąg dalszy

A w kolejnej, już ostatniej części listy rzeczy, których w Scrumie nie ma, a z różnych powodów niektórzy uznają je za obowiązkowe, piszę o pielęgnacji Backlogu Produktu, Zespole Scrum, przejrzystości oraz Definicji Ukończenia.