Artykuł jest kolejnym z serii artykułów dotyczących anty-wzorców w Scrumie. Poprzednie części dotyczyły Codziennego Scruma oraz Planowania Sprintu. Dzisiaj przeanalizuję kolejne ważne zdarzenie scrumowe, a mianowicie Przegląd Sprintu (ang. Sprint Review).
Poniżej znajdziecie subiektywne TOP 5 anty-wzorców dotyczących przeprowadzania Przeglądu Sprintu.
Przegląd Sprintu: anty-wzorzec #1 (Interesariusze nie uczestniczą)
Po czym poznać? W Przeglądzie Sprintu nie uczestniczą interesariusze. Brakuje osób zainteresowanych rozwojem produktu (np. klient końcowy, management, reprezentanci innych zespołów). W spotkaniu bierze udział wyłącznie Zespół Deweloperski, Scrum Master oraz Product Owner.
Jakie są konsekwencje? Zespół nie otrzymuje informacji zwrotnej na temat rozwijanego produktu. Traci przez to możliwość skorzystania z okazji do usprawnienia produktu, zapoznania się z inną perspektywą lub usłyszenia ciekawego komentarza. Z kolei z perspektywy interesariuszy, największą stratą jest brak możliwości śledzenia postępu w procesie rozwijania produktu. Może to powodować, że będą oni odrywać zespół od pracy w Sprincie, wymagając obecności na spotkaniach statusowych i podsumowujących rozwój produktu.
Co można zrobić inaczej? W tym przypadku rozwiązania są proste.
- zaprosić interesariuszy na Przegląd Sprintu: wg. moich obserwacji, dodatkowe osoby najczęściej nie pojawiają się na spotkaniu, bo… najzwyczajniej o nim nie wiedzą. Istnieje wiele sposobów, aby do nich trafić, takich jak zaproszenie osobiste (najbardziej skuteczne), e-mail, czy też wysłanie zaproszenia do kalendarza. Sposoby te można ze sobą łączyć, aby zwiększyć skuteczność zaproszenia,
- pokazać interesariuszom korzyści z obecności: nawet jeśli interesariusze wiedzą, kiedy i gdzie odbywa się Przegląd Sprintu, mogą nie wiedzieć, czego spodziewać się po takim spotkaniu. Warto spotkać się na chwilę i wytłumaczyć, jak przebiega typowe spotkanie oraz czego zespół zwyczajowo oczekuje od interesariuszy,
- upewnić się, że termin Przeglądu Sprintu nie koliduje z innymi spotkaniami: może się zdarzyć, że interesariusze nie docierają na spotkanie ze względu na inne, wcześniej zaplanowane zobowiązania (np. Przegląd Sprintu innego zespołu lub cykliczne spotkanie z klientem). Jeśli problem dotyczy kluczowych interesariuszy, warto rozważyć zmianę terminu przeprowadzenia Przeglądu Sprintu.
Przegląd Sprintu: anty-wzorzec #2 (Demo zamiast Przeglądu)
Po czym poznać? Odbywa się tylko część prezentacyjna spotkania. W najgorszym przypadku zespół opowiada wyłącznie o tym, co zrealizował (“zrobiłem zadanie X”, “a ja zadanie Y”) lub prezentuje zrealizowane funkcje produktu. Następnie zespół kończy spotkanie, w efekcie czego nie wywiązuje się dyskusja na temat dalszego rozwoju produktu.
Jakie są konsekwencje? Zespół traci szansę na otrzymanie informacji zwrotnej na temat rozwijanego produktu. Kluczowe filary Scruma, tzn. inspekcja oraz adaptacja, nie mają szans zaistnienia, w konsekwencji zespół porzuca możliwość zdobycia wiedzy na temat produktu od interesariuszy. Nie odbywa się dyskusja na temat dalszego rozwoju produktu, możliwych scenariuszy wzrostu, najbliższych planów oraz bieżących priorytetów.
Co można zrobić inaczej?
- zapytać interesariuszy o feedback: wystarczy zadać proste, otwarte pytanie, które sprawi, że interesariusze podzielą się z nami informacją zwrotną, przykładowo: “Co myślicie o tym, co właśnie zobaczyliście?”. Konieczna może okazać się moderacja takiej dyskusji i zapewnienie (na przykład przez Scrum Mastera), że wszyscy interesariusze podzielili się swoimi przemyśleniami.
- przygotować agendę spotkania: agenda taka pomaga w zapewnieniu, że wszystkie ważne elementy Przeglądu Sprintu odbędą się. Przykładowa agenda może wyglądać w następujący sposób:
- powitanie uczestników spotkania,
- wysokopoziomowe wprowadzenie dotyczące rozwijanego produktu,
- odwołanie się do celu aktualnego Sprintu,
- prezentacja przyrostu dostarczonego w trakcie Sprintu,
- kilka słów na temat tempa oraz progresu prac,
- uzyskanie feedbacku od interesariuszy,
- aktualizacja Product Backlogu na podstawie przeprowadzonej dyskusji,
- zamknięcie spotkania.
Przegląd Sprintu: anty-wzorzec #3 (Brak wartości dla użytkownika)
Po czym poznać? Prezentowany wynik Sprintu nie przynosi wartości dla odbiorców aplikacji. Pokazywane są techniczne aspekty produktu (tabele w bazach danych, frameworki, klasy, itp.). Pojawiają się niejasne, techniczne określenia, zrozumiałe wyłącznie dla zespołu prezentującego efekt ostatniego Sprintu.
Jakie są konsekwencje? Zespół nie jest skupiony na dostarczaniu rozwiązań dla użytkownika końcowego. Uwaga z rozwiązywania problemów użytkowników przeniesiona jest na techniczne aspekty. Zazwyczaj trudno ocenić postęp prac, ze względu na fakt, że nie widać produktu od strony użytkowej.
Co można zrobić inaczej?
- zapewnić, że elementy w Product Backlogu dostarczają wartość biznesową: można to zrealizować poprzez dobrze przeprowadzone sesje pielęgnowania Product Backlogu: podczas takich spotkań, warto zastanowić się, czy omawiane wymagania faktycznie dostarczają wartość biznesową. Poniżej dwa przykładowe podejścia, które mogą być przydatne w takiej sytuacji:
- INVEST (ang. Independent, Negotiable, Valuable, Estimable, Small oraz Testable) – podejście zaproponowane przez Bill’a Wake’a, opisujące czym powinien się charakteryzować dobrze przygotowany element Product Backlogu. Powinien być niezależny od innych zadań, o negocjowalnym zakresie, przynoszący wartość dla użytkownika, zdatny do oszacowania oraz nieduży.
- w przypadku korzystania z formatu User Stories (jako… chcę… tak, aby…) pomocne jest zwrócenie uwagi na to, czy zadanie faktycznie realizuję potrzebę użytkownika. Prosty i zrazem skutecznym trikiem, jest odwrócenie kolejności szablonu User Story (aby… jako… chcę…), co powoduje zwiększenie skupienia na precyzyjnym określeniu dostarczanej wartości.
- skorzystać z obecności interesariuszy: jeżeli interesariusze są obecni podczas Przeglądu Sprintu, to mogą być tymi osobami, które wyrażą swoje niezrozumienie dotyczące prezentowanych efektów prac. Może to być bardzo wartościowy feedback, który w trwały, pozytywny sposób może wpłynąć na dalszy rozwój produktu. Jeżeli taka dyskusja nie narodzi się samoistnie, Scrum Master może być osobą, która dzieląc się informacją zwrotną lub zadając pytania interesariuszom, może zaburzyć ten niekorzystny status quo i doprowadzić do usprawnień.
- umowa wewnątrz zespołu: zespół może umówić się, że podczas Przeglądu Sprintu nie prezentuje poszczególnych elementów systemu, tylko skupia się na pokazywaniu produktu. Konsekwencją takiej umowy może być długofalowe zadanie dla Zespołu Scrumowego, polegające na stopniowej zmianie sposobu formułowania elementów w Product Backlogu tak, aby układały się one w kolejne, wartościowe kawałki produktu.
Przegląd Sprintu: anty-wzorzec #4 (Brak planu spotkania)
Po czym poznać? Spotkanie prowadzone jest w sposób chaotyczny. Brak wyraźnego planu dotyczącego następujących po sobie wydarzeń. Zespół ma trudność w płynnej prezentacji elementów produktu. Dużo czasu ucieka na mało istotne wydarzenia (np. podłączanie komputerów do rzutnika/dużego wyświetlacza, przygotowywanie danych testowych, przełączanie się pomiędzy środowiskami deweloperskimi czy niezdecydowanie, kto z zespołu ma prezentować efekty Sprintu)
Jakie są konsekwencje? Wszyscy obecni na spotkaniu tracą czas. Spotkanie jest dla zespołu stresującym wydarzeniem i może stać się argumentem, aby zrezygnować z Przeglądów Sprintu. Interesariusze wychodzą ze spotkania z negatywnymi odczuciami.
Co można zrobić inaczej?
- przeprowadzić testowy Przegląd Sprintu: chociaż dla niektórych może to zabrzmieć jak robienie dwa razy tego samego, okazuje się, że bardzo często zespoły korzystają z takiej opcji. Pozwala to dobrze zaplanować agendę spotkania, zastanowić się, kto i w jakiej kolejności prezentuje dostarczone funkcje oraz wyłapać błędy. Zazwyczaj zespoły realizują testowy przegląd dzień przed faktycznym spotkaniem.
- przygotować agendę spotkania: bardzo często niewiele trzeba, aby spotkanie zostało przeprowadzone w efektywny sposób. Stała agenda spotkania, podzielona na bloki, pozwala z jednej strony podejść do spotkania bardziej rutynowo, z drugiej daje pewien przewidywalny schemat spotkania dla interesariuszy. Dobrą praktyką, z którą spotkałem się w jednym z zespołów, było przygotowywanie podstawowego szkieletu prezentacji wraz z agendą przez Product Ownera, który następnie udostępniał ją Zespołowi Deweloperskiemu oraz Scrum Masterowi, aby Ci dołożyli elementy wartościowe z ich perspektywy.
- odwiedzić Przegląd Sprintu w innym zespole: jeżeli oczywiście istnieje taka możliwość (tzn. istnieje więcej niż 1 zespół w organizacji), warto z niej skorzystać. Pozwoli to podpatrzeć, jak do spotkania podchodzą inne zespoły, zainspirować się lub zapytać o poradę. Jeżeli organizacja pracuje nad jednym produktem, będzie to dodatkowo okazja, aby zsynchronizować wiedzę pomiędzy zespołami.
Przegląd Sprintu: anty-wzorzec #5 (Sesja testów)
Po czym poznać? Spotkanie wygląda jak sesja testów. Członkowie zespołu prezentują dużą liczbę scenariuszy testowych, bardzo dokładnie “przeklikując” się przez aplikację. Interesariusze proszą o dokonanie szczegółowych testów (np. “wpiszcie proszę wartość z przecinkiem do pola reprezentującego kod pocztowy”). Ciężar dyskusji jest położony na sprawdzaniu, czy zadania zostały zrealizowane w poprawny sposób, brak natomiast dyskusji o szerszym kontekście wytwarzanego produktu.
Jakie są konsekwencje? Duża część spotkania przepada na wykonywanie testów, które powinny zostać wykonane jako część Sprintu i zapewnienie, że kryteria akceptacji dla elementów Product Backlogu są spełnione. Potencjał spotkania nie jest wykorzystywany. Brak czasu na uzyskanie feedbacku od interesariuszy dotyczącego szerszego odbioru produktu, niż tylko na poziomie pojedynczych zadań. Spotkanie jest długie i może okazać się nudne z perspektywy zaproszonych interesariuszy.
Co można zrobić inaczej?
- przetestować wyprodukowane elementy w trakcie Sprintu: testy to nieodłączny element każdego Sprintu i jako takie powinny być wykonane przed Sprint Review. Najczęstszym elementem Definition of Done jest ustalenie, że zadanie spełnia kryteria akceptacji i zostało przetestowane. Wykonywanie tego rodzaju testów podczas Przeglądu Sprintu to najzwyczajniej strata czasu interesariuszy,
- przenieść ciężar spotkania z testowania funkcji na całościowy produkt: bardzo drobiazgowe testowanie pojedynczych elementów Product Backlogu może odwracać uwagę od produktu jako całości. Wartościowa może okazać się moderacja spotkania w stronę dyskusji o tym, jak właśnie wytworzony przyrost produktu wpływa na dalsze plany zespołu. Zazwyczaj przenosi to ciężar rozmowy z dyskusji o pojedynczych funkcjach na poziom dużych funkcjonalności (np. w formie epic’ów) lub konkretnych wersji produktu (np. aplikacja e-commerce obsługująca dodatkowy kanał płatności),
- przygotować testy automatyczne: jeśli istnieją powody, dla których interesariusze mają potrzebę bardzo dokładnego sprawdzenia, czy wszystkie kryteria akceptacji oraz scenariusze testowe są spełnione, Zespół Scrumowy może udostępnić raport z testów lub uruchomić je jako dodatek do Przeglądu Sprintu. Praktyka pokazuje, że automatyzacja pozwala na wielokrotnie szybsze przejście po scenariuszach testowych, co pozwala zaoszczędzić masę czasu potrzebnego na ręczne “wyklikanie” testów.
Podsumowanie
Jak zwykle, zapraszam do dyskusji – jakie anty-wzorce są największym wrogiem Przeglądu Sprintu z Waszej perspektywy? Koniecznie dajcie znać w komentarzach.
Chcesz przeczytać więcej?
Powyższy artykuł to mały wycinek mojej książki “Labirynty Scruma”, której premierę planuję w okolicy połowy 2017 roku. Opisuję w niej sprawdzone, praktyczne sposoby na najczęstsze pułapki w Scrumie. Zapisz się na mój newsletter – dla subskrybentów planuję przedpremierowy fragment książki oraz dodatkowe materiały.
Aby pogłębić temat posłuchaj 98. odcinka podcastu Porządny Agile – Zarządzający na Przeglądzie Sprintu.