Review, ze względu m. in. na prostotę powinno być dobrze rozumianym i przeprowadzonym wydarzeniem. Często tak jest, ale nasza praktyka pokazuje jednak, że jak każde inne scrumowe wydarzenie, Review może być problematyczne. Dlaczego tak jest? Dlaczego Sprint Review jest takie trudne?
Jak powinno wyglądać Review?
W przewodniku po Scrum sprzed ostatniej zmiany, Scrum Guide 2017, Sprint Review było całkiem dobrze opisane. Zawierało proponowaną agendę, co przyczyniało się do tego, że przeprowadzenie wydarzenia wydawało się być łatwe. Wiedzieliśmy jakie i w jakiej kolejności tematy powinny być poruszone. W nowym Scrum Guide zapisy usunięto, co przyczynia się do tego, że Zespoły Scrumowe mają więcej elastyczności. Mogą przeprowadzić wydarzenie w najlepszy sposób, na jaki pozwala im środowisko w jakim działają i stan ich wiedzy.
Jak pokazuje jednak życie, elastyczność często przeszkadza. Istnieje całkiem spora grupa osób, które nie czują się komfortowo w sytuacji „pustki organizacyjnej”. Osoby te oczekują dokładnego rozpisania agendy spotkania, a jej brak odbierają jako ułomność podejścia lub lukę w metodyce. Czasem nawet widzą w tym chaos. Sytuacja ta może dotyczyć nie tylko agendy czy planu na przeprowadzenie poszczególnych wydarzeń, ale również innych aspektów wykorzystywanego podejścia. Wszystkim się nie dogodzi.
Inną, naturalną konsekwencją zmiany podejścia do zapisów w Scrum Guide jest problem z przeprowadzeniem wydarzenia, szczególnie wśród młodych zespołów. Jednym z tego symptomów jest trudność ze znalezieniem prelegentów chcących pochwalić się swoimi sukcesami – przecież za Sprint Review odpowiedzialny jest Product Owner!
Trudności
Trudności, na których chciałbym dziś skupić się dotyczą głównie aspektów fundamentalnych. Zaliczam do nich brak Interesariuszy, chęci pokazania efektów naszej pracy czy unikanie samego udziału w wydarzeniu. Te i inne trudności, żeby nie napisać „problemy”, są zawsze konsekwencją jakiś działań. Wystąpienie któregokolwiek z nich, a już szczególnie wszystkich jednocześnie, powoduje, że Sprint Review z prostego wydarzenia staję się zawiłym procesem. To z kolei prowadzi do tego, że entuzjazm do uczestnictwa w nim diametralnie maleje. Zacznijmy jednak od początku.
Pierwszą trudność to brak Interesariuszy. Wiecie, że brak zaproszenia właściwych osób jest najczęstszą sytuacją, dla której ludzie w ogóle nie chcą Review? Nie chodzi mi o brak kilku kluczowych graczy, co też może być problematyczne, ale o brak jakichkolwiek przedstawicieli tzw. biznesu. Albo o niezaproszenie właściwych!
Dla kogo wytwarzamy Produkt? Czy naprawdę nie ma nikogo, kto poświęciłby jedną, dwie, trzy godziny ze swojego życia, aby zobaczyć co wytworzyliśmy i w którą stronę zmierzamy? Nie robimy przecież Przeglądu Sprintu wyłącznie dla siebie, a chcemy skupić się na zebraniu pierwszych wrażeń od potencjalnych, przyszłych użytkowników rozwiązania. Rozwiązania, z którym ktoś przyszedł do Product Ownera i powiedział, że jest ważne i powinno być dostarczone właśnie teraz. Brak Interesariuszy powoduje, że możemy stracić wiarę w celowość organizacji tego wydarzenia. Jesteśmy Zespołem! Co zrobił Karol czy Marta wiemy, bo razem pracowaliśmy nad dostarczeniem funkcjonalności od Refinementu aż do teraz!
Oczywiście może być też tak, że mamy zespół indywidualistów zajmujących się różnymi Produktami i nie wiemy, co Karol czy Marta wytworzyli. Jak pokazuje jednak praktyka, wyniki prac poszczególnych członków zespołu interesują jednak wtedy jedynie Dewelopera, który pracę wykonał i Product Ownera.
Brak chęci
Mamy już za sobą kwestę związaną z Interesariuszami, skupmy się więc na kwestii związanej z Deweloperami. W tej materii występują dwa aspekty działania: brak chęci pokazania efektów swojej pracy oraz brak chęci udziału w wydarzeniu jako takim. Obie kwestie są bardzo podobne, źródłem pochodzenia obu może być ta sama przyczyna.
Zacznijmy od pierwszej. Napracowaliśmy się cały Sprint, wytworzyliśmy kawał dobrego Produktu ale nie ma chętnego, który stanąłby przed Interesariuszami i powiedział „Oto bardzo dobry efekt naszej wytężonej pracy!”. Zawsze zastanawia mnie przyczyna takiego stanu rzeczy. Przecież od zawsze było tak, że do pracy nie było chętnych, ale po „medale i wyróżnienia” ustawiała się kolejka. A tutaj jest inaczej. Dlaczego?
Próbowałem kiedyś zbadać to zjawisko. Wnioski jakie zauważyłem dotyczyły kilku kluczowych obszarów Review:
- podczas Review obecny był Senior Management,
- Produkt nie był skończony („a ma być pokazany”),
- Produkt jest niskiej jakości,
- zrobiliśmy coś, czego nie umiemy umiejscowić w całości rozwiązania.
Te i inne problemy powodują, że Karol, Marta, Tadeusz czy Robert mogą najzwyczajniej nie mieć ochoty na prezentacje. Mogą być to przyczyny osobowościowe (nie każdy jest ekspresyjny), mogą być to też być problemy (np. jakościowe) związane z Przyrostem. Kiedy już padnie magiczne słowo „musimy”, znajduje się ktoś, kto nie ma ochoty na prezentację, ale został wytypowany. Może się uda, częściej jednak bez właściwego nastawienia i chęci chwalenia się pracą, prezentacja taka będzie zaledwie „wystarczająca”.
Po co nam Review?
Trzecim aspektem jest brak uczestnictwa w wydarzeniu jako takim. Wspomniałem na początku poprzedniego rozdziału, że przyczyny te mogą mieć to samo pochodzenie. Faktycznie, jeśli spojrzymy na cztery wskazane przeze mnie powyżej punkty, dojdziemy do wniosku, ze każdy z nich powodować może brak chęci uczestnictwa w Sprint Review. Innymi powodami mogą być np. brak czasu („Przecież musimy kodować”) czy konieczność szybkiego dokończenia zakresu kończącego się właśnie Sprintu.
Jeśli chodzi o czas, sprawa jest jasna. Jeśli do Sprint Review nie skończyliśmy realizować zaplanowanego zakresu Sprintu, to na Przeglądzie Sprintu tego nie pokazujemy. Dodatkowo, prawdopodobnie źle się zaplanowaliśmy lub w tracie Sprintu wystąpiły okoliczności, które spowodowały taki a nie inny stan rzeczy. Jeden i drugi powód musimy wziąć pod uwagę na zbliżającej się Retrospektywie. Nie chcemy przecież, aby sytuacja powtórzyła się w kolejnej iteracji!
Dlaczego Sprint Review jest takie trudne?
Wydaje mi się, że lektura dzisiejszego wpisu pozwoliła odpowiedzieć na to ważne pytanie. Jak zwykle problem leży w nas samych, czasem w niewiedzy, czasem w obawie przed czymś, a czasem w lenistwie. Jak zwykle, jeśli chcemy coś zmienić powinniśmy zacząć od siebie, bo warto.
Dobrze przeprowadzone, skuteczne Sprint Review daje nam możliwości, o których ja, jako młody konsultant IT 16 lat temu mogłem tylko pomarzyć. Sprint Review daje nam bieżącą możliwość zderzenia Product Backlogu i dostarczonego przyrostu z potrzebą mojego Klienta. Kiedyś tej możliwości nie było, co prowadziło do późniejszych problemów i spięć między uczestnikami procesu. Dziś też tak może być, ale tylko w przypadku, gdy nie wykorzystamy nadążającej się okazji.
