Temat wymagań technicznych na Sprint Review obrósł co najmniej kilkoma mitami. Jedni mówią „nie da się tego pokazać biznesowi„, a drudzy „jeśli nie zrobiliśmy nic na froncie, to nie mamy czym się chwalić„. Czy słusznie? Jak zorganizować i poprowadzić „techniczne” Sprint Review?
Jak to pokazać?
Każdy z nas przynajmniej raz w życiu zastanawiał się, w jaki sposób pokazać techniczne rzeczy nas Sprint Review. Oczywiście mówiąc „każdy z nas” mam na myśli Scrum Mastera czy Product Ownera, którzy są zamieszani w organizację tego wydarzenia Scrum. Szczególnie PO dba o to, w jaki sposób wygląda i jakie są skutki Przeglądu Sprintu. Reprezentuje on przecież Produkt na zewnątrz i jest odpowiedzialny za Backlog.
Wracając do dzisiejszego tematu. Znam co najmniej jedną osobę, która pracowała przy Produkcie, w którym nie było ani grama widzialnej dla biznesu części. Wszystko czym się zajmował zespół, było backendem. „Jak to pokazać?” To pytanie słyszałem kilkanaście razy.
Zgodnie z teorią, wydarzenie pod tytułem Review nie powinno wymagać specjalnego przygotowania. Oznacza to, że elementy które spełniają Definition of Done w kończącym się właśnie Sprincie powinno dać się łatwo pokazać. I tutaj zaczynają się schody, bo co zrobić z tymi rzeczami które są ukryte gdzieś głęboko w naszym rozwiązaniu? Jak je zaprezentować w atrakcyjny, a przede wszystkim nie powodujący znudzenia Interesariuszy sposób? Jak pokazać, że przygotowaliśmy interfejs zasilający Hurtownię Danych, dzięki któremu już za dwa Sprinty będzie można wygenerować i obejrzeć raport?
Czego chce biznes?
Oczywiście nim przejdziemy do etapu pokazania tego, co udało nam się zrobić, musimy przejść przez etap rozmowy na temat mijającego Sprintu oraz ustalenia tego co jest dla nas wszystkich w Backlogu najważniejsze. Pamiętajmy, że Sprint Review to nie demo!
Gdy już zakończymy ustalenia, a timebox wydarzenia pozwala, możemy rozpocząć prezentację Przyrostu. Powinna być ona przeprowadzona w sposób, który umożliwi uczestnikom wydarzenia wyrażenia swojej opinii. Jesteśmy szczęściarzami, gdy za każdym razem jesteśmy w stanie coś pokazać i ukazać nowy stan naszego Produktu. W przypadku, gdy nie jest to możliwe lub gdy prezentacja wymaga „technicznego” zasilenia np. danymi, musimy znaleźć atrakcyjniejszą formę prezentacji naszej pracy. Wielu z nas spotkało się z sytuacją w której próba pokazania „robaczków”, czyli kodu, XML-ów bądź logów zakończyła się spektakularnym niepowodzeniem.
Czy za każdym razem trzeba coś pokazywać? A może warto spróbować zrobić coś innego? Tu jak zwykle odpowiedź brzmi „to zależy„. Najczęściej od tego, z jakim typem Interesariuszy mamy do czynienia. Jeśli są to osoby techniczne, ich poziom absorpcji tematu może być o wiele większy, niż czystego biznesu. Ci drudzy będą mocno narzekali opuszczając techniczne Sprint Review. I będą to narzekania nie na naszą pracę, ale na jakość przekazu.
Dla kogo jest Sprint Review?
Sprint Review jest przecież między innymi dla Interesariuszy. Dokonują oni inspekcji aktualnego postępu prac nad Produktem i adaptacji, proponując usprawnienia. Powinniśmy więc dostosować formę przekazu do odbiorców. Nie stoimy w tej sytuacji na przegranej pozycji. Opcji wbrew pozorom jest sporo, a wszystko jak to często bywa zależy od naszej inwencji.
Pierwszą z nich jest „.. i tak właśnie będzie to wyglądało„. Opcja ta jest najprostsza. Biznes często nie wchodzi w szczegóły rozwiązania, nie jest więc istotne w jaki sposób Produkt został „zasilony” danymi. Z ich punktu widzenia ważne jest to, że pojawiły się one w miejscu oczekiwanym i są dobrej, oczekiwanej jakości. Czy musimy robić coś więcej? Czy musimy tłumaczyć jak doszło do zasilenia Produktu? Nie.
Jeśli nie mamy nic, ale to absolutnie nic do pokazania zostaje nam opcja druga. Malowanie słowem. Dodatkowo możemy podeprzeć się ładnie przygotowaną, atrakcyjną prezentacją. Opowiedzmy o przygotowanym rozwiązaniu w taki sposób, aby zainteresować uczestników. Wyciągnijmy z przygotowanego rozwiązania smaczki, przykuwające uwagę. Potwierdźmy słownie, że wymaganie, z którym przyszedł do nas „biznes” zostało przygotowane dokładnie tak, jak chcieli. Może na efekty wizualne przyjdzie jeszcze poczekać, dziś muszą nam uwierzyć na słowo, że zrobiliśmy mały krok w kierunku osiągnięcia Celu Produktu.
Techniczne Sprint Review
Mam często wrażenie, że przyczyną technicznych Sprint Review jest chęć pokazania ogromu pracy, który włożyliśmy w rozwiązanie. Nie ma w tym nic złego, w końcu każdy chciałby być doceniony za kawał dobrej roboty, którą wykonał. Tymczasem może się okazać, że w pocie czoła dwa tygodnie pracowaliśmy nad rozwiązaniem, które mieści się w małym fragmencie naszego Produktu. I z tego właśnie chcemy się „wytłumaczyć”. Jak więc zaprezentować ten backstage?
Oczywiście, w sposób jak najatrakcyjniejszy! Przyrównajmy np. liczę linii kodu, który wytworzyliśmy do czegoś abstrakcyjnego, pokazującego jednocześnie wielkość sprawy. Pokażmy, że z punktu widzenia Interesariuszy zmiana jest niewielka, a z naszego punktu widzenia była ona wielkim wyzwaniem. Chwalmy się, ale w sposób atrakcyjny i dostosowany do odbiorcy. Gwarantuję Wam, że informacja „łączna długość napisanego kodu równa jest długości równika” będzie atrakcyjniejsza niż pokazywanie samego kodu na ekranie. Ten drugi sposób wywoła efekt odrzucenia. A my chcemy być zapamiętani.
