/ Scrum

Przepis na retrospektywę sprintu

Jak pewnie słusznie zauważyliście w dziale SCRUM na moim blogu widniał do tej pory tylko jeden post - "Wprowadzenie do Scrum'a". Nic nie dzieje się bez przyczyny. Dopadła mnie chwila zwątpienia - "po co mi ten Scrum?", "po co mam się spalać jak reszcie zespołu to wszystko jedno?". Aż do ostatniego czwartku ;) ...

A jakby tak olać tego Scrum'a?

Zaczęliśmy nowy projekt i stwierdziłem, że nie będę się wychylał z tym Scrumem. I wiecie co? Dawno nie napisałem tyle kodu! Dawno, jako zespół, nie dowieźliśmy całej funkcjonalności w czasie mniejszym niż zakładano! Dawno nie słyszałem tak pozytywnego feedbacku ze strony managmentu - "super robota! świetnie to wygląda! i to w tak krótkim czasie!". Pomyślałem - WOW - to działa. To nie Scrum jest przepisem na sukces, a zaangażowanie ludzi, dobrze spisane wymagania, ownership i komunikacja. Ale w tym wszystkim jest jedno ale... Jednej rzeczy mi brakowało...z każdym dniem coraz bardziej. Chodzi mi tu o retrospektywę. Nigdzie w tym całym naszym procesie bez Scruma nie było miejsca na zastanowienie się "co możemy zrobić lepiej?". Nigdzie nie było miejsca, żeby pochwalić kogoś na forum całego zespołu. Owszem - dawaliśmy sobie feedback face-2-face ale brakowało mi szerszego kontekstu.

Projekt dobiegł końca, wszyscy zadowoleni - od programistów, przez testerów, product ownera i klientów. Ci ostatni, jak wynika z narzędzi do analityki, używają dostarczonej funkcjonalności i są z niej bardzo zadowoleni. Super! Ale co dalej? Zostaliśmy w tym samym składzie ale postanowiliśmy dołączyć się do innego podzespołu i razem uczestniczyć w retrospektywach. Dzięki temu zachowaliśmy "swój" sposób na organizację pracy i zyskaliśmy miejsce i przestrzeń na podzielenie się swoimi spostrzeżeniami. Dlaczego dołączyliśmy do innego zespołu? Długo by tłumaczyć ;) - w wielkim skrócie kilka osób zaangażowanych jest w prace obu podzespołów. Ale to zupełnie inna kwestia...

Powrót do korzeni

W ostatni czwartek (czas retro) przychodzi do mnie kumpel, który bardzo długo prowadził to spotkanie dla swojego podzespołu i zapytał, czy mógłbym teraz ja poprowadzić reto. Po chwili namysłu zgodziłem się, chociaż przez tydzień (w naszym 2 tygodniowym cyklu wydania oprogramowania) byłem na urlopie i zbytnio nie wiedziałem co działo się w zespole przez ten czas. Ale ok - pomyślałem "czemu nie?" - poprowadziłem retro. I wiecie co? Dawno nie czułem się tak podbudowany, taki pełen energii do dalszego działania. Nie wiem...może prowadzenie spotkań tak na mnie działa...może takie grupowe działanie, napędzanie zespołu daje mi jeszcze większego kopa i motywację. Podobno jak biegamy to zwiększa się poziom endorfin - hormonu szczęścia. Widocznie w moim przypadku zwiększa się on po każdym dobrze poprowadzonym spotkaniu. Jeszcze więcej motywacji dały mi oceny przeprowadzonej retrospektywy. Przed końcem spotkania poprosiłem każdego z uczestników o wystawienie oceny od 1 do 5. Prawie wszyscy dali 5 i 4,5. Dzięki! To daje mega kopa do dalszego działania.

Postanowiłem się z Wami podzielić moim przepisem na retro. Jeśli czujecie monotonię, znudzenie, nie wiecie jak podejść do tematu - to może znajdziecie tu inspirację i Wasze następne retro podniesie Wam poziom endorfin ;)

Po pierwsze - przygotuj się

Nie ma nic gorszego od nieprzygotowania osoby prowadzącej. Kilka razy popełniłem ten błąd. Myślałem sobie - eee tam, pojedziemy standardowo - karteczki, trzy kolumny (dobrze, średnio, źle), grupowanie kartek i action pointy. Za każdym razem, kiedy próbowałem prowadzić retro bez przygotowania wychodziliśmy poza ramy czasowe spotkania, przez co albo nie wyciągnęliśmy wniosków z dyskusji, albo nie mieliśmy planu naprawczego, albo przechodziliśmy bardzo pobieżnie przez problemy niektórych osób - co powodowało potem rozdrażnienie i zdemotywowanie.

Dlatego prowadzący spotkanie powinien się do niego dobrze przygotować.

Przegląd notatek z ostatniej retrospektywy i sprint-review

Pozwoli to na płynniejsze sprawdzenie czy action pointy z poprzedniego retro zostały wykonane. Czasami nie pamiętamy dokładnie czego dotyczył dany action point. Co prawda jest to wina złego sformułowania punktu - ale dobre tworzenie AP też jest sztuką, której opanowanie przychodzi z czasem. Poprzez sprawdzenie notatek z ostatniego retro możemy przypomnieć sobie jaka panowała wtedy atmosfera w zespole i jaki plan "naprawczy" zobowiązaliśmy się wykonać przy następnym sprincie. Analiza notatek ze sprint review (o ile takie macie) pomoże przypomnieć sobie czego dotyczył ostatni sprint, jaki był jego cel, co udało się zrealizować i jakie były problemy. Jeśli zamiast sprint review robicie tylko tzw. DEMO no to macie problem i sami musicie przypomnieć sobie obraz poprzedniego sprintu, który jest tematem waszej retrospektywy.

Wybór sposobu prowadzenia

Drugim krokiem jest wybór sposobu prowadzenia retro. Z mojego doświadczenia wynika, że najczęściej stosuje się podejście z karteczkami samoprzylepnymi i podzieleniu tablicy na 3 części:

  • co poszło dobrze (miejsce na pochwały i pozytywny feedback)
  • co poszło nie najgorzej ale można to poprawić
  • co poszło źle i koniecznie trzeba to naprawić

Spotkałem się też z podziałem (mad, sad, glad) 😡😞😍,który jest niczym innym jak odwróceniem kolejności z poprzedniego sposobu. Ale oprócz wypisywania rzeczy, które poszły dobrze, źle i nie najgorzej, sposobów na prowadzenie retro jest o wiele wiele więcej. Jeżeli szukacie inspiracji to polecam stronę retromat.org.

Plan spotkania

Załóżmy, że zostajemy przy klasycznej wersji z trójpodziałem tablicy i karteczkami. Następnym krokiem jest ustalenie agendy i podzielenie czasu jaki mamy na retrospektywę.

Scrum mówi o tym, że przy sprincie trwającym jeden miesiąc, retro powinno trwać max 3h. Przy sprincie 2 tygodniowym (jaki mamy w Egyte) na retro powinno się przeznaczyć proporcjonalnie mniej czasu, czyli max 1.5h. Niestety mała ilość salek i ich duże obłożenie spowodowało, że musieliśmy skrócić ten czas do 1h. Nie mówię, że to źle...Scrum mówi o maksymalnej ilości czasu (zawsze można skończyć szybciej). Z drugiej strony przy godzinnym spotkaniu trzeba się szybciej uwijać i bardzo, ale to bardzo pilnować czasu. Dlatego warto sobie rozpisać plan retro wraz z podziałem na minuty. Poniżej przykładowa lista:

  • 10m - przegląd action pointów z poprzedniego retro
  • 5m - przypomnienie ostatniego sprintu (cel, osiągnięcia, problemy)
  • 5m - zebranie przemyśleń na temat sprintu (wpisy na kartkach)
  • 10m - czas na przyklejenie kartek i krótkie wyjaśnienie
  • 20m - przygotowanie action pointów (dyskusja)
  • 5m - parafraza zebranych action pointów
  • 5m - ocena spotkania

Z jednej strony 5 minut to bardzo mało czasu, ale uwierzcie mi, przy dobrze poprowadzonym spotkaniu wystarcza w zupełności.

Pogrubiony element z listy (czas na przyklejenie kartek...) należy podzielić równo na każdego z uczestników spotkania. Załóżmy, że nasz zespół składa się z 5 osób - wtedy każda ma 2 minuty na przyklejenie swoich przemyśleń, zapisanych na kartkach i krótkie ich uzasadnienie. Często zdarza się tak, że uczestnicy wyrabiają się szybciej. W takim wypadku nadwyżkę czasu może przejąć kolejna osoba albo można wydłużyć czas na przygotowanie action pointów. Przy większym zespole zastanowiłbym się jednak nad wydłużeniem czasu całego spotkania do preferowanych 90 minut.

Tak przygotowany plan pozwala na sprawniejsze przeprowadzenie spotkania bez wchodzenia w zbędne dyskusje i jednocześnie utrzymuje uczestników w skupieniu. Dobrze jest też taki plan pokazać zaraz na starcie spotkania. Wtedy wszyscy są świadomi co będą robić i ile będą mieć na to czasu.

Po drugie - rozluźnij atmosferę

Dobrze jest zacząć retro od krótkiej aktywności, która "otworzy" uczestników spotkania. Przy zgranych zespołach, w których ludzie czują się swobodnie, raczej nie ma z tym problemu. Z drugiej strony, jeśli Twój zespół dopiero zaczyna korzystać z dobrodziejstw Scruma jakim jest np. retro, albo jest to świeży, jeszcze niezgrany, zespół to może być to problem.

Dlatego, jako prowadzący retro, zawsze na początku staram się wybadać grunt. Proszę np. o narysowanie na karteczce buźki/emotikona, który ma symbolizować jak dana osoba czuje się po ostatnim sprincie, jak czuje się w zespole itp. Zamiast o nastrój można poprosić każdego z uczestników żeby powiedzieli jedną nieoczywistą rzecz o sobie. Uwierzcie mi to zbliża i ośmiela zamknięte osoby. Po takiej rozgrzewce od razu zauważycie większą aktywność na retro.

Czasami zdarza się, że na retro przychodzą osoby, które nie uczestniczyły aktywnie w życiu zespołu, ale chciałyby się dowiedzieć co jest grane. Głównie chodzi mi tu o management. Często w takich wypadkach zdarza się też, że członkowie zespołu mają coś do powiedzenia/zarzucenia managementowi, ale woleli by to zrobić w formie bardziej anonimowej. Cóż - na pewno jest to sygnał do działu HR, że coś jest nie tak na linii management - developerzy, że nie ma otwartości na wzajemny, konstruktywny feedback. Kiedy czujemy, że mamy taką sytuację na retro, warto zrobić anonimową ankietę. Prosimy wtedy uczestników spotkania o użycie kartek i napisanie na nich czy czują się swobodnie, a jeśli nie to dlaczego. Takie kartki zbieramy do jakiejś czapki, kapelusza ;) czegokolwiek. Ważne, żeby dać poczucie anonimowości. Czytamy je gdzieś na stronie i wracamy z wnioskami. Można wtedy grzecznie porozmawiać z managerem, że grupa nie czuje się swobodnie w jego obecności. Koniecznie należy zorganizować kolejne spotkanie, na którym sytuacja zostanie wyjaśniona. Retro, na którym uczestnicy nie czują się swobodnie jest obarczone wielkim ryzykiem, że nie zidentyfikujemy problemów, które mogą mieć wielki wpływ na pracę zespołu.

Po trzecie - pilnuj czasu

Nieładnie jest komuś przerywać, ale czasem trzeba. Jest to bardzo trudna sztuka i przy prowadzeniu retrospektywy bardzo kluczowa. Zdarza się, że przy omawianiu niektórych problemów wywiązuje się gorąca dyskusja, która z czasem potrafi skręcić na złe tory. W tym momencie naszym zadaniem, jako prowadzących spotkanie, jest szybka reakcja i powrót do tematu. Musimy też pilnować czasu, trzymać się planu, który przedstawiliśmy na początku spotkania. Im bardziej będziemy pozwalali na niekończące się dyskusje tym mniej czasu będziemy mieć na formułowanie planu "naprawczego".

Po czwarte - plan naprawczy

Podstawą Scruma są inspekcja i adaptacja (Inspect & Adapt). Inspekcję mamy już za sobą - zebraliśmy przemyślenia na temat sprintu i omówiliśmy każde z nich. Czas na przygotowanie planu "naprawczego" - co możemy zrobić, żeby nie popełniać więcej błędów, albo co możemy zrobić aby nadal utrzymać pozytywny wynik. Wszystko zależy od tego, czy mieliście więcej pozytywnych czy negatywnych tematów ;) Formułowanie dobrych action pointów, które będą sprawdzone na następnym retro to bardzo trudna sztuka. Jedni mówią, że powinny być SMART. Jeszcze inni, że każdy punkt powinien być przypisany do konkretnej osoby, żeby uniknąć odpowiedzialności zbiorowej. Moim zdaniem sposób formułowania AP powinien być określony przez zespół. Ważne żeby można było w łatwy sposób sprawdzić, czy punkt z planu został zrealizowany, czy też nie.

Po piąte - sparafrazuj punkty

Jak już mamy action pointy to dobrze by było sprawdzić czy wszyscy członkowie zespołu tak samo je rozumieją. W takim wypadku prosimy wybrane losowo osoby aby w dwóch zdaniach wytłumaczyły o co chodzi w każdym z punktów planu naprawczego. Uwierzcie mi - daje to mega efekty. Tutaj wychodzi też, kto aktywnie uczestniczył w spotkaniu, a kto dłubał w nosie :) Czasami jedna osoba potrafi zupełnie inaczej rozumieć to co kryje się pod krótkim opisem action point'a. W takim wypadku parafraza pozwala na jeszcze dokładniejsze określenie ram punktu, który powinien zostać zrealizowany do następnego retro.

Po szóste - zbierz feedback

Po każdym przeprowadzonym spotkaniu poproś o jego ocenę. Zostaw sobie 5 minut na to, aby każdy z uczestników ocenił Ciebie jako prowadzącego i sposób w jaki prowadziłeś spotkanie. Zdziwisz się jakie uzasadnienia otrzymasz :) Pozwala to na lepsze przygotowanie do następnego spotkania ;) Pamiętaj - inspekcja i adaptacja ;)

To chyba na tyle w kwestii mojego przepisu na dobre retro. Reszta zależy już tylko od prowadzącego i zaangażowania zespołu ;)