Sprint Review to nie demo! 

Wydarzenia Scrum to nie „ceremonie”, a Sprint Review to nie „Demo”. Obie te pomyłki są tak częste, że gdybym zawsze prostował je w wypowiedziach ludzi, z którymi rozmawiam, to już chyba nikt nie chciałby ze mną gadać. Ale ponieważ czytasz ten tekst z własnej woli, to mogę się powtórzyć: Przegląd Sprintu to nie jest demo!

Przegląd Sprintu to nie demo

Prawie dwa lata temu Łukasz wziął na warsztat Sprint Review i opisał go w szczegółach. Niestety, od tego czasu liczba nieporozumień dotyczących tego wydarzenia wcale nie zmalała. Nadszedł więc czas na kontynuację krucjaty przeciwko traktowaniu Przeglądu Sprintu jak „demo”.

Nie wiem skąd się wzięło te nieporozumienie, bo na pewno nie ze Scrum Guide’a. Tam znajdziemy szczegółowy opis Review, wraz z listą ośmiu elementów wchodzących w jego skład. W ramach tego tekstu zacytuję i omówię siedem z nich. Ostatnie zalecenie dotyczy zapraszania kluczowych interesariuszy. Poza podkreśleniem faktu, że to Product Owner jest od wystosowania zaproszeń, nie ma tu nic więcej do skomentowania.

„The Product Owner explains what Product Backlog items have been „Done” and what has not been „Done”;
The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved”

Jeżeli mielibyśmy przygotowywać agendę na takie spotkanie, to na pewno powyższy cytat stanowiłby jej idealny początek. Najpierw niech PO wyjaśni co zostało zrobione, a co nie (buduje to poczucie odpowiedzialności za prace zespołu), a potem niech Development Team omówi co poszło dobrze, jakie były problemy i jak zostały rozwiązane.

I dopiero teraz zbliżamy się do „demo”.

Demo jest elementem, a nie sensem Review

Demonstracja Przyrostu to jeden z ośmiu wspomnianych aspektów Przeglądu Sprintu. Zanim do niego przejdziemy, odpowiedzmy sobie na pytanie „Kto prezentuje rezultaty prac?” Odpowiedź może być tylko jedna – robi to Development Team, bo to on budował Przyrost. Nie zabierajmy im okazji do pochwalenia się efektami prac i podyskutowania z interesariuszami.

„The Development Team demonstrates the work that it has „Done” and answers questions about the Increment”

Pytania na temat działającego kawałka naszego produktu powinny trafiać do Zespołu Deweloperskiego. Zbyt często dzieje się tak, że to Product Owner albo – o zgrozo – Scrum Master kradnie cały show i „prowadzi” Review. Błąd. Te wydarzenie jest dla wszystkich! A to całe „demo” jest nam potrzebne po to, żeby zebrać informacje na temat tego, nad czym będziemy pracować w dalszej kolejności.

„The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;”

Na demo czasami pojawiają się okrzyki i uwagi typu „Ale nie o to nam chodziło!” czy „Tak to nie może być!” To zawsze są dla nas cenne informacje, a o tych komentarzach powinniśmy wspólnie podyskutować. Jeżeli jest taka potrzeba, mogą one wylądować na samym szczycie Backlogu Produktu i być realizowane już w następnym Sprincie.

I chociaż zwykle uwagi interesariuszy odkładane są do backlogu „na później”, to zawsze są one istotne i pozwalają na rozwinięcie właściwej współpracy. Jeżeli zaś z naszej demonstracji na Sprint Review nie wynikają żadne zmiany w backlogu, ani nie padają żadne pytania od intersariuszy, to może powinniśmy ją sobie darować? Są przecież ważniejsze rzeczy do roboty…

Jak nie demo, to co?

Propozycja z ostatniego akapitu oczywiście jest przesadą. Zamiast rezygnować z demo, spróbujmy wprowadzić do niego te elementy, o które nam chodzi – pytania, dyskusje, plany na przyszłość.

Ciekawą techniką, którą kiedyś zaobserwowałem, jest zrobienie jakiejś funkcjonalności celowo źle. To znaczy robimy jakiś drobiazg w taki sposób, żeby w trakcie demo na Sprint Review nasi interesariusze zaprotestowali. Następnie ich propozycję uwzględniamy najpierw w backlogu, a potem w następnym Sprincie i voilà – właśnie przekonaliśmy kilka osób, że warto przychodzić na Przegląd Sprintu.

Jeżeli natomiast chcemy zminimalizować aspekt demonstracyjny, to zmaksymalizujmy w takim razie drugą nogę Przeglądu Sprintu, czyli aktualizowanie Backlogu Produktu. Idę o zakład, że to też się nie dzieje za często, a już na pewno nie na każdym Review.

„A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. (…)
The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);”

Jeżeli, jako zespół, chcecie przygotować sobie „checklistę” na wydarzenie pod tytułem Przegląd Sprintu, to Scrum Guide będzie Waszym najlepszym przyjacielem. Wtedy na pewno nie zapomnicie o przeglądu… backlogu.

Niech Product Owner pokaże Product Backlog, niech wywiążą się jakieś dyskusje na jego temat. Porozmawiajmy o prognozach, o tym co jest teraz najważniejsze i co się stanie, jak czegoś nie zrobimy.

Pamiętajmy o tych dwóch aspektach – z jednej strony Przyrost, ale z drugiej – Product Backlog.

Co jeszcze na Review?

Pozostały nam jeszcze dwie rzeczy, które mogą/powinny się zadziać na Przeglądzie Sprintu, ale z mojego doświadczenia zwykle się nie dzieją. A szkoda.

„Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.”

Jeżeli mamy jakąś roadmapę, plany długoterminowe, budżety, możliwości, etc. – warto je pokazać na Przeglądzie Sprintu. Nawet jeśli nie będą one się zmieniały zbyt często, nawet jeśli nasz produkt będzie budowany miesiące albo lata, to tym bardziej warto pokazać gdzie jesteśmy i dokąd zmierzamy. Ponownie, jest to jeden z elementów budowania zrozumienia naszego produktu.

Bo tak naprawdę w Przeglądzie Sprintu chodzi o trzy rzeczy. Jedną z nich jest to nieszczęsne demo, czyli obejrzenie efektów naszej pracy. Drugą jest zaktualizowanie Backlogu Produktu w oparciu o nowe informacje pochodzące od PO, interesariuszy, ale też i od zespołu (na podstawie efektów ich pracy).

Ale trzecią i kto wie czy nie najważniejszą rzeczą jest budowanie wspólnego zrozumienia tego, po co robimy nasz produkt i jak on powinien wyglądać. I pisząc „wspólnego” mam tu na myśli zarówno zespoły, jak i interesariuszy.

Dlatego spróbujcie odczarować swoje wydarzenia i pamiętajcie, że Sprint Review to nie demo.