Antywzorce w Scrumie – czego unikać? Część 3: Przegląd Sprintu

Anty-wzorce w Scrumie

Anty-wzorce w Scrumie: Przegląd Sprintu

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 (jakochcę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 (abyjakochcę…), 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.

Źródło zdjęcia: https://flic.kr/p/61KvuL

Komentarze do wpisu: “Antywzorce w Scrumie – czego unikać? Część 3: Przegląd Sprintu

  1. Jacku, bardzo się cieszę, że cykl powrócił po tak długiej przerwie.

    Anty-wzorcem, z którym ja się najczęściej spotkałem jest sesja demo… Niestety czasem też zapytanie interesariuszy o feedback niewiele daje, bo odpowiedzą w dwóch słowach i naprawdę ciężko jest dalej taką rozmowę podsycić.

    A w kwestii #4 to potwierdzam, że przygotowanie internal review przed tym właściwym wiele daje. Następuje dokonanie podziału, kto co pokazuje, ustalenie kontekstu biznesowego / historii, w odniesieniu do której się pokaże przyrost, zamiast suchego: tu zrobiliśmy to, ten ficzer robi tamto itp. (co dla kolegów dev’ów jest zazwyczaj bardzo nieoczywiste), przećwiczenie słownictwa, jeśli review jest np. po angielsku. Polecam!

    • Bartek, dziękuję za Twój komentarz. Ja również się cieszę, że cykl powrócił i co więcej, nie będzie tak długiej przerwy przed publikacją kolejnych odcinków 🙂

      Co do interesariuszy, wygląda to jak temat warty przepracowania. Przychodzi mi do głowy kilka hipotez, natomiast ciekawi mnie, jakie są Twoje? (jako osoby, która ma kontekst wydarzenia)

      Dobrze usłyszeć, że internal review sprawdza się u Ciebie. Sam wielokrotnie obserwowałem, jak dużą różnicę jakościową daje przećwiczenie tego zdarzenia wcześniej.

      • Jacku, trochę późno, ale wracam z odpowiedzią 🙂
        Przemyśleń mam kilka. Najprostsza przyczyna, to fakt, że czasem te projekty już są u schyłku i nowe funkcjonalności są dodawane ad-hoc, bez wielkiego myślenia o dalszej wizji systemu i znajdują się już one w Product Backlogu wcześniej, przed Review.

        Dziś mi jednak kolega zwrócił uwagę na inny aspekt. U nas po Review klient ma kilka dni na własne testy i zatwierdzenie itemów w Sprint BL (jako ukończonych). Dopiero jak samodzielnie poklika, to wtedy pojawiają się jakieś przemyślenia i klient rozmawia już tylko z proxy PO, nie z całym zespołem przy okazji Review. Z jednej strony szkoda, widzę to jako stratę, bo nie ma tej wartościowej dyskusji z całym zespołem. Nie przychodzi mi jednak na myśl co można z tym zrobić. Klient też to określi jako korzyść (finansową), bo zajmuje czas jednemu człowiekowi, zamiast płacić za udział w spotkaniu całego zespołu (a boje często są o każdą złotówkę)…

  2. Bardzo fajny wpis, z wszystkimi wyżej wymienionymi problemami niestety miałem okazję się zetknąć 🙂 Dodałbym jeszcze:

    Ad. 1 – częstym błędem jest zapraszanie niewłaściwych interesariuszy, a nie tylko ich brak. Zdarzało mi się, że pomimo tego, że uczestniczyli oni w spotkaniu to nic do niego nie wnosili, mieli mały wpływ na produkt czy po prostu mało ich interesował.
    Tak naprawdę wartościowy feedback dostarczany był zazwyczaj od innych interesariuszy, którzy najczęściej nie mieli czasu przyjść na spotkanie, a to właśnie oni byli kluczowi. Ważne jest zatem aby poprawnie ich zidentyfikować i „optymalizować” listę zapraszanych (i obecnych) na review osób.

    Ad. 2 – w wielu organizacjach powszechne jest nazywanie Sprint Review jako „Demo”, stąd też pewnie konsekwencja przygotowywania jedynie dema, a nie podsumowania Sprintu jako wsadu pod kolejny Planning 🙂 Środkiem zaradczym jest tu oczywiście wyplenianie tego nawyku i stosowanie właściwej nomenklatury.

    Wydzieliłbym chyba też dodatkowy anty wzorzec, o którym wspominasz w #2 i agendzie spotkania.

    #6 – brak przedstawienia dalszej wizji i aktualnego Backlogu. Czyli typowe zadanie dla PO. Pamiętajmy, że podsumowanie sprintu ma też na celu pokazanie dalszej wizji rozwoju produktu na podstawie minionego sprintu. Co nam się udało, do czego dalej dążymy, jak zmieniły się nam priorytety w Backlogu.

    • Jarek, dziękuję za obszerny i merytoryczny komentarz.

      Ad.1 – Pełna zgoda, dobór interesariuszy to kluczowa sprawa. W uproszczeniu, gdy obserwuję owocną i zaangażowaną dyskusję podczas Sprint Review, to mam poczucie, że zaproszone są właściwe osoby. Co nie zmienia faktu, że nadal może być ktoś, kogo można dołączyć do spotkania. Z drugiej strony, na spotkaniu mogą być właściwe osoby, tyle że czasem brakuje im odwagi/przyzwyczajenia aby zadać pytanie dotyczące produktu – tutaj może pomóc na przykład Scrum Master, odpowiednio moderując dyskusję.

      Ad.2 – Ciekawa obserwacja; między innymi dlatego uważam, że budowanie wspólnego zrozumienia pojęć w organizacji jest ważne.

      Ad. 6. – Racja, to ważny punkt w agendzie.

  3. Hej. Ja chciałem odnieść się do kwestii „Przegląd Sprintu: anty-wzorzec #2 (Demo zamiast Przeglądu):”. Tutaj nie do końca się zgodzę.

    Ja osobiście zauważyłem, że jeśli na demo są ludzie zaangażowani w realizację projektu (analitycy, PO, użytkownicy, szeroko pojęty biznes, „inwestor”) to dobra prezentacja produktu (przyrostu sprintu) bardzo ale to bardzo od razu ożywia rozmowę o tym „co jest” verus „co chcą by było”. I z takiej burzy mózgów, dyskusji bardzo wiele wynika. Co pomaga wtedy to osoba dodatkowa spisująca wszystkie wnioski. By po Sprincie nanieść poprawki. Owszem spotkanie musi mieć agendę i dobrego SM co to prowadzi ale nie wolno wybijać klienta z „flow i dyskusji feedbacku” bo to najbarrdziej kreatywna część dema. Jeśli miałbym powiedzieć „dobrze a teraz zaktualizujmy backlog” to by zabrzmiło jak by developer powiedział mi „dobrze rozumiem Pana uwagi do mieszkania – chodźmy teraz i nanieśmy poprawki na projekt domu”. Wyśmiałbym go i powiedział „sam se pan je nanieś ja oczekuje dobry produkt”. Owszem trzeba nanieść zmiany na backlog jak najszybciej ale nie mieszajmy dwóch różnych rzeczy w jednym spotkaniu. Taka moja uwaga. Demo to show i tylko jak ma pewne ramy osiąga dobry feedback klienta. Gdy zmącimy je czymś nie potrzebnym to psuje jego kreatywny odbiór produktu. Powiem więcej zmącenie dema przeglądem historyjek w jirzy może tak smao wybić klienta jak chaos czy niedziałający rzutnik.

    Jest taka zasada w mediach – one day one message Czyli na jeden dzień może być tylko jeden hitowa informacja. Tak sama tutaj one meeting – one goal.

  4. Jacek Wieczorek

    Dzięki Łukasz za Twój komentarz.

    Moim zdaniem nic nie stoi na przeszkodzie, aby fizycznie zaktualizować Product Backlog, kiedy klient/stakeholderzy opuszczą już spotkanie. Istotniejsze jest zebranie od nich wcześniej feedbacku, sam proces wprowadzania zmian do PB może się zadziać już bez ich udziału.

    Natomiast pracowałem już z klientami, dla których normalne było zajrzeć wspólnie do PB podczas Przeglądu Sprintu na zasadzie „co tam macie na kolejny Sprint w planach”. Tak więc, jak to zwykle bywa, powiedziałbym, że „to zależy”.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x