Oś czasu – alternatywna metoda na Retrospektywę Sprintu

Gdy obserwuję początkujące zespoły scrumowe i Scrum Masterów prowadzących Retrospektywy, najczęściej jako stosowane techniki na tym wydarzeniu widzę różne odmiany podobnych do siebie podejść: Start/Stop/Continue, Diagram Rozgwiazdy, Plusy i Minusy czy zwykłe generowanie tematów do dyskusji. Zaletą tych podejść jest na pewno duża otwartość na tematykę, jaka może się pojawić w czasie dyskusji w zespole, widzę jednak takie momenty w życiu zespołów, gdy potrzebne są bardziej ukierunkowane sposoby moderacji przebiegu rozmowy usprawnieniowej. Jedną z takich technik jest dla mnie “Oś czasu” (w oryginalnych angielskich publikacjach określana jako “Timeline”). W tym artykule przybliżę tę technikę, podpowiem kiedy warto ją zastosować i podzielę się praktycznymi doświadczeniami z moich prób jej wykorzystania.

Na czym polega technika “Oś czasu”?

Zespół rysuje oś, która oddaje poddawany analizie okres (ostatni sprint, ostatnie wdrożenie, ostatni etap projektu, …) – najlepiej na kartce z flipcharta rozłożonej na stole. Oś ta jest uzupełniana przez wszystkich członków zespołu o wydarzenia, jakie nastąpiły w ramach danego okresu (aktywności zespołu, przerwania, miłe i trudne momenty). Na tym etapie dobrze jest być drobiazgowym i spróbować zespołowo odtworzyć precyzyjny przebieg sytuacji, jeśli chodzi o wykonane działania i ich kolejność  – często zdarza się, że nawet działania sprzed tygodnia są już bardzo różnie zapamiętywane i całym zespołem możemy ustalić obiektywnie jak było w rzeczywistości. Gdy odtworzymy już realny rozwój sytuacji, możemy przejść do generowania spostrzeżeń:

  • Jeśli ćwiczenie realizujemy w ramach Retrospektywy po jakimś kryzysie (nieudany sprint, nieudane wdrożenie, nieporozumienie w zespole), Scrum Master może nawigować grupę w stronę ustalenia pierwotnej przyczyny problemu, która na zwizualizowanej osi czasu może się ukazać wyraźniej niż gdybyśmy mieli rozmawiać bez żadnych pomocy (np. Nie udało się wdrożenie, bo ostatnie dni sprintu były bardzo nerwowe, bo byle jak podeszliśmy do planowania, bo Backlog Produktu był kiepsko przygotowany, bo w poprzednim sprincie w ostatniej chwili pojawiły się nowe priorytetowe elementy, o których w ogóle nie mieliśmy okazji rozmawiać). Zwłaszcza w sytuacjach, gdzie łańcuch przyczynowo-skutkowy jest długi i sięga dalszej przeszłości, dopiero pokazanie sobie zależności oraz przedyskutowanie post factum rozwoju sytuacji może dać nam mocne przemyślenia na temat usprawnień w przyszłych sprintach (np. Ustalenie, że jeśli zdarza się sytuacja z nowymi elementami, to robimy ponadprogramowe Doskonalenie produktu (tzw. refinement) i twardo przestrzegamy (albo wprowadzamy sobie) Definicję Gotowości).
  • Oś czasu może być techniką do ustalenia ciągu zdarzeń w przypadku pozytywnego obrotu spraw. Analogicznie jak w powyższym przykładzie, korzystne dla zespołu może być ustalenie konkretnych źródeł tego, że np. wyjątkowo dobrze się nam pracowało, dostarczyliśmy dużo wartości biznesowej albo zrealizowaliśmy wybitnie dobre jakościowo rozwiązanie. Zagłębienie się w podstawy sukcesu daje szanse na faktyczne trwałe usprawnienia – coś co na niejednej Retrospektywie realizowanej klasycznie zamknęłoby się w stwierdzeniu “Kontynuujmy dobrą współpracę”.
  • Oś czasu może też być techniką używaną bez konkretnej tezy (nie było ani kryzysu ani jakiegoś wybitnego sukcesu) – Scrum Master może zaproponować to podejście by przełamać zwykłą rutynę technik skupionych na generowaniu tematów i zogniskować uwagę na przebieg prac zespołu i dopiero na bazie tego poprosić o wskazanie punktów w czasie, o których poszczególne osoby chciałyby rozmawiać. Uwaga całego zespołu może się przesunąć z ogólnego mówienia co jest dobre a co kiepskie na konkretne momenty i konkretne sytuacje.

Po wygenerowaniu spostrzeżeń zespół przechodzi do typowego kroku Retrospektywy, czyli ustalenia akcji usprawnieniowych – decyzji o zmianach postępowania, konkretnych kroków zmieniających narzędzia, procesy czy pomysły na wpłynięcie na osoby i procesy wpływające na zespół z zewnątrz. Jak zwykle przy okazji Retrospektyw na tym etapie może być potrzebne wyselekcjonowanie najważniejszych wątków (zwłaszcza oś czasu sięgająca więcej niż jeden sprint może być kopalnią tematów, z których nie uda się przedyskutować wszystkich). Może też być potrzebne stosowanie ograniczeń czasowych w dyskusji o danym temacie usprawnieniowym (tzw. timeboxy), zwłaszcza jeśli zespół ma tendencje do dłuższych dywagacji.

Kiedy “Oś czasu” może się przydać?

Tę technikę na Retrospektywie szczególnie polecam zespołom, które przeżyły jakiś kryzys, który nie ma oczywistych źródeł. Szereg czynników w takich sytuacjach może utrudnić dobrą ocenę sytuacji, zwłaszcza jeśli byliśmy jako członek zespołu jakoś wplątani w rozwój wypadków.

Oś czasu może też być dobrą formułą dla usprawnień między zespołowych – przedstawiciele zespołów mogą porozmawiać o ostatnim wdrożeniu, ostatnim kwartale, wielozespołowo realizowanym projekcie. To podejście pomaga skupić się na faktach (bo najpierw trzeba je ustalić i niejednokrotnie najpierw się zgodzić jak w ogóle sytuacja się rozwijała) i dopiero na nich bazować przy ustalaniu usprawnień.

Jak już wspomniałem w akapicie powyżej “Oś czasu” może też być techniką proponowaną zespołom, który wpadły w rutynę podobnych do siebie Retrospektyw. W porównaniu do generowaniu pomysłów na rozmowę i późniejszą swobodną wymianę możliwych usprawnień, w “Osi czasu” mamy bardzo angażujące wszystkich uczestników generowanie faktów a potem miejsce na zauważanie związków przyczynowo-skutkowych. Zbudowana oś daje też dobry podkład (wizualizację) pod dyskusję między różnymi osobami w zespole – każdy może wskazać swój pomysł, jednocześnie wiążąc go z konkretnym wydarzeniem umiejscowionym w czasie

Dodatkowe porady praktyczne związane z “Osią czasu”

  • Ponieważ ćwiczenie dla niejednego zespołu będzie nowością i będzie często bardziej skomplikowane niż dotychczas realizowane generowanie pomysłów na kartkach, warto zadbać o wyraźną instrukcję, najlepiej z przykładami i sprawdzeniem u uczestników, czy jakiś punkt z polecenia wymaga przeformułowania, by być lepiej zrozumianym. Poza samą instrukcją postępowania nie zapomnijmy o wyjaśnieniu celu ćwiczenia i zarysowaniu jego spodziewanego przebiegu.
  • Gdy generujemy oś, zadbajmy o to, by kartka, na której rozklejamy przebieg wydarzeń była wystarczająco duża i wystarczająco dostępna. Może nas zaskoczyć to, że nieudany konkretny sprint ma swoje korzenie w historii sprzed kilku tygodni albo miesięcy, więc Scrum Master powinien być gotowy na szybkie powiększenie obszaru, na którym można generować spostrzeżenia (np. poprzez doklejenie kolejnej kartki z flipcharta i wydłużenie osi bardziej w przeszłość). Lepiej sprawdzi się kartka rozłożona na środku długiego stołu albo na podłodze niż wisząca na ścianie – bo jednocześnie można do takiej osi podchodzić z co najmniej dwóch stron.
  • Dobrze jest być gotowym na to, by kodować pewne typy wydarzeń konkretnymi kolorami post-itów albo kartek. Scrum Master szykując ćwiczenie powinien mieć w zanadrzu zapas różnych kolorów i klarownie podać zasady wszystkim uczestnikom (np. Żółte kartki to działania zespołu, fioletowe to wydarzenia spoza zespołu, zielone to podjęte decyzje, itp.). Nowe kategorie mogą się pojawić dynamicznie w trakcie dyskusji (np. potrzeba bardziej drobiazgowego kategoryzowania działań zespołu na aktywności programistyczne i aktywności testerskie), więc dobrze jest prowadzić legendę łatwo widoczną dla wszystkich uczestników ćwiczenia i mieć oko na to, czy członkowie trzymają się proponowanej konwencji
  • Ponieważ ćwiczenie uwypukli związki przyczynowo-skutkowe, warto być gotowym na to, w jakiej konwencji będzie je zespół zaznaczał. Można to zrobić poprzez wyrysowanie strzałek markerem, bardziej elastycznym rozwiązaniem może być przygotowanie sznurka, włóczki albo tasiemki, którą połączyć można wiele kartek (przylepiając je) i nadal mając możliwość manipulacji kolejnością czy układem spostrzeżeń.
  • Jeśli są fakty bezsprzeczne w rozwoju sytuacji (np. Dzień i godzina wdrożenia, początek i koniec sprintu, jakieś konkretne spotkanie istotne dla przebiegu sytuacji), Scrum Master może już przed Retrospektywą przygotować elementy osi czasu, by pomóc zespołowi zestawić najbardziej podstawowe informacje i przy okazji dać dodatkowe punkty odniesienia w generowaniu spostrzeżeń.
  • Przy dużych zespołach (albo wielozespołowych Retrospektywach) na etapie generowania faktów na osi może być potrzebne podzielenie uczestników na podgrupy. Warto zadbać o to, żeby każda grupa składała się z w miarę różnorodnych przedstawicieli specjalizacji albo poziomów doświadczenia. W takiej sytuacji podgrupy będą generować duplikujące się wydarzenia i dodatkowym krokiem będzie musiało być usunięcie dublujących się kartek. W takiej sytuacji trzeba być czujnym, czy w pozornie identycznych sformułowaniach faktów nie ma jednak niuansów, które robią różnicę. Alternatywnie (zwłaszcza przy bardzo długich analizowanych okresach) może poprosić podgrupy by skupiły się na różnych miejscach osi (np. jedna podgrupa pracuje nad początkiem sprintu a druga nad końcem) i w drugim kroku podgrupy zamieniają się miejscami i sprawdzają czy w wypracowanych do tej pory materiałach nie ma luk albo nieścisłości.
  • Dyskusję o przebiegu sprintu mogą też wzbogacić historyczne dane takie jak wykres spalania, statystyki zadań w toku oraz wygenerowanie indywidualnych ocen zadowolenia poszczególnych członków zespołu (np. wykorzystanie happiness index, czy poproszenie każdego członka zespołu by dodatkowo poza faktami wygenerował też swoje odczucia co do stresu czy morale w kolejnych momentach sprintu według jakiejś umówionej prostej skali). Rozmowy usprawnieniowe w takiej sytuacji nie będą się opierać tylko o przebieg suchych wydarzeń, ale w zespole poszczególni członkowie mogą pokazać sobie swoje emocje (“owszem, udało mi się na czas zrealizować kluczowe zadanie, ale byłem bardzo wkurzony i nie chciałbym być pod taką presją w przyszłości”).
  • Na wygenerowanym podkładzie z faktów (i ew. wspomnianych wyżej emocji) swoje obserwacje może dorzucić też Scrum Master (zwłaszcza jeśli dostrzega jakąś rzecz, którą zespół pomija). Ponieważ to zespół generował fakty i spostrzeżenia, można bardzo miękko (i bez zbędnych dyskusji o mylnym wrażeniu SMa) zwrócić uwagę zespołowi na jakieś dodatkowe elementy (np. poza samymi zależnościami między zadaniami pokazać też duże skupiska zadań realizowanych jednocześnie – czyli wysoki poziom pracy w toku).

Autor zdjęcia „Timeline” Manuel Frias źródło zdjęcia: https://flic.kr/p/TnABdt na licencji CC BY-NC-ND 2.0

Dodaj komentarz

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

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x