Dlaczego Państwa działania retro nigdy się nie uda
Elementy akcji umierają, ponieważ większość narzędzi retro traktuje je jak karteczki samoprzylepne - kolorowe na spotkaniu, niewidoczne w momencie zamknięcia tablicy. Właściciel, termin realizacji, przeniesienie do następnego retro, przesunięcie do backlogu: cztery małe funkcje, a ich brak jest przyczyną, dla której zespoły mówią "nigdy nic nie robimy z naszymi retro".
Cztery cechy specyfikacji
Zadanie z retrospektywy, które przetrwa tydzień, wymaga czterech elementów w następującej kolejności: imiennego właściciela (nie „zespołu”), terminu realizacji (nie „następnego sprintu”), miejsca, w którym pojawi się ponownie na początku kolejnej retrospektywy bez konieczności pamiętania o przeniesieniu go, oraz ścieżki do tego samego backlogu, z którego już korzystają inżynierowie — Jira, Linear, GitHub Issues, Azure DevOps. Brak któregokolwiek z tych elementów sprawia, że zadanie staje się sprawdzianem pamięci. Brak ostatniego sprawia, że retrospektywa staje się drugą listą rzeczy do zrobienia, której nikt nie otwiera. W naszej rubryce porównawczej skrótem tego jest pięć elementów: zadania do wykonania jako rzeczywiste jednostki (a nie karteczki samoprzylepne), działanie powiązane z pomysłem, który je zrodził, automatyczne przeniesienie do następnego retrospektywnego spotkania, pulpit nawigacyjny działań obejmujący wszystkie retrospektywy oraz integracja z narzędziem do śledzenia zgłoszeń, która jest natywnym rozwiązaniem, a nie mostkiem Zapier.
Większość narzędzi spełnia pierwszy warunek, a pomija resztę. W tym miejscu pętla się zrywa.
Narzędzia, które zamykają pętlę
TeamRetro
Spełnia wszystkie pięć kryteriów: działania oznaczone przez właściciela powiązane z pomysłem, z którego się wywodzą, domyślne przenoszenie do następnego retrospektywnego spotkania, pulpit nawigacyjny śledzenia działań z widokiem Kanban oraz własne integracje z Jira, Azure DevOps, GitHub i Linear. Pulpit nawigacyjny działań jest elementem, który ma największe znaczenie — to właśnie tam Scrum Master prowadzący trzy zespoły może sprawdzić na jednym ekranie, które zobowiązania sprintu są nadal otwarte, a które zostały dwukrotnie przesunięte. W podstawowym płatnym pakiecie trzy ośmioosobowe zespoły kosztują 50 USD miesięcznie przy rozliczeniu rocznym, więc pełna pętla działań następczych nie jest dostępna wyłącznie w ramach cen dla przedsiębiorstw.
Parabol
Te same pięć flag, nieco inne podejście: działania są przesyłane do Jira, GitHub, GitLab, Azure DevOps i Linear jako rzeczywiste zgłoszenia z backlogu w momencie ich utworzenia podczas retrospektywy, a nie eksportowane później. Przeniesienie zadań jest wbudowane w przebieg spotkania. Kompromisem jest liczba spotkań — bezpłatny plan jest ograniczony do 10 spotkań miesięcznie, więc trener prowadzący retrospektywy w więcej niż dwóch zespołach potrzebuje planu płatnego. Dla organizacji inżynieryjnej już korzystającej z GitHub lub Linear funkcja zapisywania zmian w Parabol stanowi najprostszą ścieżkę od pomysłu z retrospektywy do zgłoszenia w backlogu dostępną na rynku.
Neatro
Spełnia cztery z pięciu kryteriów — brakuje jedynie powiązania między działaniem a wątkiem dyskusji, który je wygenerował. Dla zespołu, który nie spiera się zbytnio o kontekst, jest to wystarczające. Wszystko inne jest na swoim miejscu: domyślne przenoszenie zadań, odpowiedni tracker działań typu Kanban między sesjami oraz przesyłanie do Jira, Azure DevOps, GitHub, Asana i Monday. Haczyk polega na braku natywnej integracji ze Slackiem lub Teams — przypomnienia pojawiają się wewnątrz narzędzia, a nie tam, gdzie zespół już funkcjonuje.
ScatterSpoke
Inne podejście: działania są priorytetyzowane na podstawie oceny wpływu przez AI w różnych zespołach, a wyodrębnianie tematów wskazuje, które działania pojawiają się wielokrotnie w różnych retrospektywach, nie będąc zamknięte. Pięć zalet minus widok Kanban. Zakres integracji jest wąski — tylko Jira, Slack i Teams, bez GitHub, Linear czy Azure DevOps — więc rozwiązanie to będzie odpowiednie, jeśli Państwa organizacja standardowo korzysta z Jira, a nieodpowiednie, jeśli tak nie jest. Skok cenowy od wersji darmowej do 50 USD/miesiąc i 500 USD/miesiąc jest niezręczny w środkowej części, ale podstawowy płatny poziom obejmuje trzy zespoły po osiem osób.
Gdzie pęka pętla
Tablice są najdobitniejszym przykładem problemu strukturalnego. Nie ma w tym żadnej pogardy — świetnie sprawdzają się w tym, do czego zostały stworzone. Niezgodność polega na tym, że efekty retrospektywy opierają się na zobowiązaniach, a model danych tablicy opiera się na kształtach.
Miro
W tym kontekście zadania do wykonania istnieją wyłącznie za pośrednictwem konwertera kart Jira / Azure DevOps / Asana — a wersja z dwukierunkową synchronizacją jest dostępna w pakiecie Business, a nie Starter. Brak przenoszenia danych, brak pulpitu działań, brak tablicy Kanban działań. Zadanie z retrospektywy to karteczka samoprzylepna, którą ktoś musi pamiętać, aby kliknąć prawym przyciskiem myszy i „przekonwertować na kartę Jira”, zanim tablica zniknie z widoku. W praktyce zespoły robią zrzut ekranu, wklejają zadania do Slacka, a podczas kolejnej retrospektywy otwierają nową tablicę. Porównanie z Parabol wyraźnie pokazuje tę lukę.
Mural
Ma taki sam kształt jak Miro. Synchronizacja kart Sticky-to-Jira / Azure DevOps jest dostępna w planie Business+, brak przenoszenia zadań, brak pulpitu nawigacyjnego, brak Kanbanu. Trzy ośmioosobowe zespoły to koszt 240 USD miesięcznie rozliczany rocznie w ramach podstawowego płatnego planu, co stanowi dwukrotność kosztu TeamRetro przy mniejszej liczbie funkcji. Retrospektywa odbywa się na pięknym płótnie; działania znajdują się tam, gdzie zespół sam zdecyduje o ich umieszczeniu.
FigJam
Najbardziej szczere z tych trzech narzędzi co do tego, czym jest — rubryka FigJam wskazuje „nieprawda” w przypadku wszystkich czterech flag dotyczących działań. Jest to platforma do burzy mózgów, która umożliwia przeprowadzanie retrospekcji, jeśli dostarczy się szablon; nie udaje, że śledzi cokolwiek po zakończeniu. Nadaje się do jednorazowej retrospekcji poza siedzibą firmy. Nieodpowiednia forma dla zespołu działającego w sposób ciągły.
Drugi wzorzec jest bardziej subtelny: narzędzia natywne dla retrospekcji, które rejestrują działania, ale pomijają przeniesienie zadań. EasyRetro
i RetroTool należą do tej kategorii — działania istnieją, mają właścicieli, nie pojawiają się ponownie na początku kolejnego retrospektywnego spotkania, chyba że moderator ręcznie je ponownie doda. W przypadku zespołu przeprowadzającego retrospektywy raz w miesiącu to prawie działa. Przy częstotliwości co dwa tygodnie luka w przenoszeniu zadań jest tym, co po cichu zamienia co trzecie spotkanie retrospektywne w skargę, że „nigdy niczego nie zamykamy”.
O co zapytać podczas testu
Trzy pytania rozstrzygają sprawę. Po pierwsze: kiedy zamykam tę retrospekcję, co dzieje się z zadaniami, które właśnie utworzyłem — czy pojawiają się one automatycznie na początku następnej retrospekcji, czy też muszę je przenosić ręcznie? Po drugie: czy z tego zadania mogę jednym kliknięciem przenieść je do naszego backlogu, i czy link pozostaje aktywny, gdy inżynier zamknie zgłoszenie? Po trzecie: czy w ciągu sześciu sprintów Scrum Master może sprawdzić, które zadania zostały otwarte, które zamknięte, a które przeniesione na cztery kolejne sprinty? Jeśli odpowiedź na którekolwiek z tych pytań brzmi „można wyeksportować do pliku CSV”, to pętla nie jest zamknięta — to arkusz kalkulacyjny, a arkusze kalkulacyjne to miejsce, gdzie zadania do wykonania umierają.