Low battery, no problem!

W życiu jak to w życiu…. Zdarza się ze wskaźnik poziomu naszych baterii spada niebezpiecznie nisko. Co zrobić, gdy taką sytuację zaobserwujemy w zespole? Scrum masterze ratunku!

Energy Levels Retrospective jest idealnym rozwiązaniem na delikatne wybadanie tematu. Czy są jakieś nierozwiązane problemy? Czy potrzeba zadziałać jakoś punktowo? A może po prostu przyczyna leży gdzieś indziej? Jedną osobę boli ząb, choroby w zespole i inne prywatne problemy? Każdy z nas ma swoje życie… bo przecież nie sama pracą żyje człowiek, prawda? 😅

Tak, czy inaczej trzeba działać. Zupełnie inaczej funkcjonuje zespół, gdy pojawi się chociaż świadomość sytuacji drugiej osoby. Zrozumienie, szacunek, wsparcie…. Tak!

Pamiętajcie, że kluczem do sukcesu jest zbudowanie trwałego, funkcjonującego zespołu. To nie ma być zespół, który zrobi swoje, a następnie jego zapał spali się jak spadająca gwiazda, tylko dream team! 😊

Przykładowy przebieg retro:

Poniżej przykładowa tablica, jaką można zastosować:

Etap I: Pre-etap

Jaki jest aktualny poziom baterii poszczególnych osób?
Zbadajmy to i poprośmy uczestników o uzupełnienie pierwszej części na górze po prawej stronie tablicy. Ja zawsze proponuję dowolność i nie ograniczam do jednej metody: można przedstawić swoje myśli za pomocą zdjęcia/gifa, karteczki z opisem, czy zaznaczyć za pomocą ikonki na rysunku „your energy” swoje emocje i odczucia.
Na to zadanie przeznaczam około 3-5 min, nie więcej – tutaj badamy tzw. „aktualny stan gry” i niczego kreatywnie nie wymyślamy. Jak się da za duzo czasu, to nic dobrego z tego nie wychodzi 🫣

Etap II: Zbieramy dane
Zastanówmy się, co dodaje nam energii oraz co powoduje, że nasza bateria szybko się rozładowuje?

Teraz czas na lewą stronę tablicy.

Na to zadanie przeznaczam z reguły około 15-18min, ale obserwuję, czy uczestnicy spotkania nie potrzebują jednak więcej czasu. Jeśli tak, to dodaję do licznika kilka extra minut (korzystam ostatnio z tablicy Mural i funkcjonalności Timer). Ważne jest, by każda osoba mogła w pełni przemyśleć zagadnienie, ponieważ jest to baza do kolejnej rundy.

Time’s up! Czas minął!

Na koniec tego etapu warto poprosić, by każda osoba w kilku słowach opisała, co dodała do tablicy. Tak jak w poprzednim etapie, można wykorzystać wszystkie możliwe sposoby od zdjęć po karteczki. Uwielbiam, gdy pojawiają się rożnego rodzaju gify – zawsze mnie zaskakuje jak czasem trafnie potrafią określić nasze emocje, np. padnięta chmurka 😁 Jest to zawsze dodatkowy element humorystyczny! To jest ważne, by przejść przez wszystkie elementy, tak by w etapie III wszyscy wystartowali z tym samym kontekstem.

Etap III: Czas na zmiany!

Przejdźmy teraz do prawego dolnego obszaru przykładowej tablicy. Na podstawie tego, co się przed momentem dowiedzieliśmy, robimy burzę mózgów i wrzucamy na karteczkach pomysły na usprawnienia.

Czas trwania rundy, to około 10min.

W następnym kroku możemy zgrupować pomysły i przejść do głosowania. Wybieramy 1-2 pomysły, którymi się zajmiemy w najbliższej iteracji.

Ostatnim krokiem jest doprecyzowanie pomysłu, należy go omówić – tak by wszystkie zebrane osoby wiedziały z czym dany Action Item się wiąże.

Jakie można napotkać trudności w tym retro?

Tego rodzaju retro jest dosyć długie i wymaga dosyć dużego skupienia. Jeżeli planujesz lodołamacz, to lepiej wybrać coś krótkiego i szybkiego 😊

Wartosc dodana takiego retro?

Uczymy się nie tylko tego, co kogoś dręczy, ale w jaki sposób poszczególne osoby ładują swoje baterie. Dzięki temu można spróbować to jakoś zakcelerować, bo czemu nie 😊

Retro generuje mnóstwo wartości dodanych dla Scrum mastera… wiesz jaki jest stan baterii poszczególnych osób, wiesz w jaki sposób się ładują, wiesz co je wyczerpało, także pomoże ci to nakierunkować Twoja dalszą prace i będzie dla Ciebie drogowskazem. Takie warsztaty scalają zespół. Nic nie łączy bardziej, niż wspólne problemy.

Warto pamiętać, by na takim spotkaniu pojawiły się także pozostałe osoby a nie tylko dev team, by był to cały zespół scrumowy wraz z tzw. Ekspertami (opisanymi w Scrum Guide). Tak wiem i mam świadomość, że w Polsce mamy do czynienia z różnymi scrumbut’ami, ale to też nie jest nic złego. Gdy PO, PM, Kierownik, Analityk usłyszą o tym wszystkim, to również będą mieć możliwość dokalibrowania swojego działania i odwrotnie, dev team również może i powinien spojrzeć na druga stronę z większa wyrozumiałością.

Bo przecież, solidną podstawą jest zrozumienie siebie na wzajem 😊