Zdarza się czasem, że Przegląd Sprintu nie przynosi oczekiwanej wartości. Spotkanie to może na przykład stanowić zaledwie demonstrację prac Zespołu Deweloperskiego i to zrealizowaną w taki sposób, że nawet wieloletni użytkownik aplikacji nie jest w stanie zrozumieć, czego dotyczy prezentacja i dlaczego dana praca została w ogóle wykonana. Na to spotkanie zapraszamy wiele osób z różnych części firmy i chcielibyśmy, żeby poświęcony przez wszystkich czas nie był czasem straconym.
Kiedyś standardem było, że na koniec Sprintu podejmowano decyzję o tym, czy funkcjonalności wytworzone w jego trakcie należy udostępnić klientom. Teraz – w czasach Continuous Delivery i Continuous Deployment – z reguły zapada ona dużo wcześniej, już w trakcie Sprintu. A osoby najbardziej zainteresowane rozwiązaniem mają okazję zobaczyć efekty prac jeszcze przed ich wydaniem. Więc czy naprawdę Przeglądy Sprintu, jakie znamy z Przewodnika po Scrumie – realizowane na koniec Sprintu – ma jeszcze sens? Według nas – tak! Jeżeli chcemy, żeby nasz produkt był jak najlepszy i rozwijał się we właściwym kierunku, Sprint Review jest jednym z narzędzi, które nam w tym pomoże. Pozwala na zebranie informacji zwrotnej od interesariuszy, pokazanie w jakim miejscu rozwoju produktu jesteśmy i – przede wszystkim – pozwala wspólnie projektować jego kolejne kroki.
Oznaki dobrego Przeglądu Sprintu
Oto lista kilku elementów, które powinniśmy zaobserwować już podczas pierwszej wizyty na Przeglądzie Sprintu danego Zespołu:
- łatwo da się rozpoznać spośród zgromadzonych Zespół Scrumowy, a ich zachowanie jest wzorowe,
- zespół chętnie prezentuje wykonane prace i zachęca do dyskusji o nich,
- przychodzi wiele zainteresowanych tematem osób, a w szczególności klientów/użytkowników/osób pracujących z klientami i użytkownikami,
- Zespół Scrumowy potrafi wyjaśnić wartość biznesową, jaką przynoszą poszczególne zadania (i robi to),
- Product Owner potrafi wyjaśnić wartość wykonywanych zadań typowo technicznych (np. refaktoringu),
- w trakcie spotkania pojawia się wiele pytań i dyskusji, pogłębiających naszą wspólną wiedzę o produkcie,
- nie jest rzadkością to, że na koniec spotkania aktualizowany jest Backlog Produktu i plany na najbliższy Sprint.
Włożyliśmy bardzo dużo pracy, żeby Review Sprintów w naszej firmie dawały oczekiwaną wartość. Poniżej znajdziecie kilka przykładów działań jakie podjęliśmy, żeby rzeczywiście tak było.
Cel spotkania i jego wartość
Za Przewodnikiem po Scrumie: “Rezultatem Przeglądu Sprintu jest zaktualizowany Backlog Produktu, pokazujący, które elementy prawdopodobnie zostaną zaplanowane na kolejny Sprint. Ponadto Backlog Produktu może zostać generalnie zmieniony w taki sposób, aby wykorzystać nadarzające się okazje”. A zatem, jeżeli po kilku kolejnych Review nie zachodzi potrzeba aktualizacji Backlogu, to możemy podejrzewać, że to spotkanie nie spełnia swojego zadania i stało się po prostu statusem i demonstracją wprowadzonych zmian.
Dobrze sprawdza się wyjaśnienie celu tego spotkania wszystkim członkom Zespołu Scrumowego i przekonanie ich, żeby do tego celu dążyli, ponieważ bez tego ciężko pracować nad jakimikolwiek ulepszeniami. Bardzo ważne jest też wyjaśnienie innym uczestnikom tego spotkania, a w szczególności interesariuszom, ich roli i oczekiwań względem nich. Co prawda Zespół Scrumowy swoim działaniem może spowodować, że zaangażowanie uczestników będzie większe i będzie realizowało cel tego spotkania, jednak często jest to niewystarczające.
Wyeliminowanie patologii i zapewnienie solidnych podstaw
Kiedy uda się pokazać wszystkim prawdziwy cel organizowania Przeglądów Sprintu, możemy zacząć pracować nad technicznym aspektem tych spotkań. Najpierw powinniśmy wyeliminować problemy, które dostrzegamy – w naszym przypadku były to między innymi:
- żargon używany przez Zespół Scrumowy,
- zagłębianie się w szczegóły techniczne i nietechniczne bez wyraźnej przyczyny i bez pytań z publiczności,
- wylewanie żali i zrzucanie odpowiedzialności za niepowodzenia na innych,
- nadmierne usprawiedliwianie się z powodu niewykonanej pracy,
- pokazywanie rzeczy “prawie gotowych”, chyba że naprawdę jest to uzasadnione zebraniem informacji zwrotnej – np. gdy napotkamy problemy w realizacji,
- żarty i “śmieszki” bardzo rzadko wywołują pozytywny efekt – nasze doświadczenia pokazują, że najczęściej są odbierane jako maskowanie braku pewności siebie lub nawet próba ukrycia czegoś, co nie zostało zrobione,
- nakładanie się na siebie terminów Sprint Review różnych zespołów.
Dalej możemy pracować nad właściwą formą tego spotkania:
- suchą demonstrację zamienić w angażującą rozmowę – opartą na zrealizowanych pracach,
- używać formy “my”, a nie “ja” – np. “Paweł pokaże teraz zmianę, nad którą pracowaliśmy” zamiast “Paweł pracował nad zmianą w obszarze X i teraz ją pokaże”,
- skupić się na pokazywaniu wartości każdego zadania (biznesowego i technicznego) – np. prezentację funkcjonalności zaczynamy od omówienia wartości, a dopiero później przechodzimy do szczegółów,
- prezentować wykonane prace z punktu widzenia użytkownika (flow biznesowego),
- wyraźnie zaznaczać, które funkcjonalności są już (lub kiedy będą) dostępne dla użytkowników – szczególnie w przypadku wydawania funkcjonalności tylko dla wybranej grupy użytkowników (canary release) lub ukrywania danej funkcjonalności na środowisku produkcyjnym przed użytkownikami,
- omawiać, co poszło dobrze w trakcie Sprintu, jakie napotkano problemy oraz jak te problemy rozwiązano – traktując Review również jako dobre miejsce na dzielenie się wiedzą,
- zaczynać od Celu Sprintu i jego realizacji, a kończyć na planach na najbliższe Sprinty oraz zachęcać do dyskusji o tym.
Umiejętności prezentacyjne
W dalszej kolejności możemy skupić się nad jakością samej prezentacji. I nie chodzi tu o prezentację Power Point/Keynote, bo wcale nie jest ona wymagana, a o umiejętność ciekawego i zrozumiałego opowiedzenia o tym, co zrobiliśmy w trakcie omawianego Sprintu.
My pracowaliśmy m.in. nad:
- obrazowym prezentowaniem postępów – w postaci wykresów kołowych, wykresów spalania i innych,
- przygotowywaniem dobrego planu prezentacji – np. po Daily w dniu Review,
- przygotowaniem i przetestowaniem środowisk (np. deweloperskiego, testowego, produkcyjnego), na których prezentujemy zmiany oraz przygotowaniem danych do prezentacji – co przekłada się na to, że będzie bardziej płynna,
- przećwiczeniem wszystkiego przed Review – w takiej kolejności, jak będzie prezentowane, aby uniknąć ewentualnych niespodzianek,
- skutecznym zmierzaniem do brzegu, nieprzeciąganiem spotkania ponad niezbędny czas.
Warto znaleźć własny styl prezentacji w każdym zespole. To pomaga walczyć z nudą, zarówno po stronie interesariuszy, jak i zespołu. Tak samo jak można eksperymentować z osobą opowiadającą o Celu Sprintu czy dać Product Ownerowi możliwość zaprezentowania zrealizowanych funkcjonalności. Jednocześnie Scrum Master zespołu organizującego Sprint Review – mimo głęboko zakorzenionej chęci pomocy – powinien pozostać milczącym uczestnikiem tego spotkania. Im mniej będzie mówił i angażował się w jego przebieg, tym więcej będzie w stanie usłyszeć i zaobserwować, a następnie przekazać te spostrzeżenia zespołowi.
Zaprosić właściwych uczestników
W Przeglądzie Sprintu może wziąć udział każdy. Jednak, żeby uzyskać wartościową informację zwrotną, sami powinniśmy zadbać o uczestnictwo właściwych osób. W klasycznym ujęciu odpowiada za to Product Owner, ale nic nie stoi na przeszkodzie, żeby zaangażować w to Zespół Deweloperski.
Na pewno najbardziej powinno nam zależeć na obecności:
- klientów i użytkowników naszych rozwiązań – niezależnie od tego, czy to użytkownicy zewnętrzni czy wewnętrzni, zawsze stanowią najbardziej wartościową grupę – to dla nich wykonujemy te prace.
- pracowników naszej firmy, którzy mają bezpośredni kontakt z klientem (Customer Success Team, Account Managerowie, sprzedawcy) – najlepiej w firmie rozumieją sposoby działania i problemy klientów i użytkowników.
- analityków – nie zawsze mają informacje z pierwszej ręki, ale często pracują na większej próbce danych statystycznych. Nie zawsze opłaca się rozwijać funkcjonalność, z której prawie nikt nie korzysta lub jest “nieprzyszłościowa”, nawet jeżeli jest to uciążliwość dla kilku naszych klientów. Dodatkowo, Sprint Review pozwala tym osobom lepiej zrozumieć działanie aplikacji i to, jak korzystają z niej użytkownicy.
- osób decyzyjnych – osoby, który decydują o priorytetach na poziomie ogólnofirmowym łatwiej przekonać do zmiany tych priorytetów, gdy usłyszą przekonujące dane lub zgłoszenia od klientów.
Tradycją stało się też u nas to, że Product Ownerzy i Scrum Masterzy uczestniczą w Przeglądach Sprintów różnych zespołów i wymieniają się spostrzeżeniami. Dobrą praktyką jest też udział deweloperów – z zespołów współpracujących blisko ze sobą – nawzajem w swoich Przeglądach.
Zaangażować interesariuszy
Na koniec chcielibyśmy Was zachęcić do zaangażowania interesariuszy, którzy pojawiają się na Waszych Sprint Review.
Często ciężko jest stwierdzić, dlaczego uczestnicy naszego spotkania nie są zaangażowani, dlatego warto ich o to zapytać. Można skorzystać chociażby z prostej ankiety (np. w formularzach Google’a) rozsyłanej po Review. My pytaliśmy w niej m.in. o:
- sposób prezentacji aspektów biznesowych (ocena w skali 1-5),
- sposób prezentacji aspektów technicznych (ocena w skali 1-5),
- forma prezentacji (ocena w skali 1-5),
- czego brakuje/czego jest za dużo,
- jak powinniśmy zmienić spotkanie, żeby bardziej zaangażować uczestników w jego trakcie (np. do zadawania pytań i dawania zespołowi informacji zwrotnej).
Już same te pytania pokazują uczestnikom Review, że wymagamy od nich czegoś więcej niż tylko uczestnictwa. Udzielone odpowiedzi są często bezcennym źródłem informacji zwrotnej dla zespołu.
Jako ciekawostkę techniczną możemy powiedzieć, że znacznie więcej odpowiedzi dostawaliśmy gdy wysyłając ankietę zaznaczaliśmy opcję “Dołącz formularz do emaila”. Dzięki temu, do wypełnienia ankiety wystarczało kilka kliknięć z poziomu programu pocztowego.
Jeżeli już uda nam się zaangażować interesariuszy i będą oni zgłaszać propozycje zmian, kluczowe jest reagowanie na nie. Absolutną podstawą jest ich spisanie i odpowiedź na nie na kolejnym Review lub w trakcie kolejnego Sprintu. Nikt nie mówi, że musimy realizować każdą zgłoszoną uwagę, ale jeżeli przestaniemy na nie reagować, to uczestnicy spotkania przestaną je zgłaszać.
Podsumowując
Bez dobrze przeprowadzanego Sprint Review, ciężko będzie nam ściągnąć kluczowych z punktu widzenia rozwoju naszego produktu interesariuszy. A bez ich obecności i zaangażowania nie mamy co liczyć na obranie właściwego kierunku rozwoju produktu. Wszystkich opisanych wyżej pomysłów nie da się wprowadzić z dnia na dzień. Kluczowa jest tu konsekwencja oraz ciągłe usprawnianie Przeglądu Sprintu. Warto jednak poświęcić ten czas, bo uzyskana wartość jest nie do przecenienia.