Dlaczego właśnie te zadania związane z analizą retrospektywną? nigdy się nie skończy
Zadania do realizacji pozostają niewykonane, ponieważ większość narzędzi do retrospekcji traktuje je jak karteczki samoprzylepne — kolorowe podczas spotkania, niewidoczne w chwili zamknięcia tablicy. Właściciel, termin realizacji, przeniesienie do następnej retrospekcji, przeniesienie do listy zadań oczekujących: cztery drobne elementy, a ich brak jest głównym powodem, dla którego zespoły twierdzą: „nigdy nic nie wynika z naszych retrospekcji”.
Specyfikacja czterech elementów
Zadanie z kategorii „retro”, które przetrwa tydzień, wymaga czterech elementów w podanej kolejności: wyznaczonego odpowiedzialnego (a nie „zespołu”), terminu realizacji (a nie „następnego sprintu”), miejsca, w którym pojawi się ponownie na początku kolejnego spotkania retrospektywnego, bez konieczności pamiętania o przeniesieniu go przez kogokolwiek, oraz ścieżkę do tego samego backlogu, z którego już korzystają inżynierowie — Jira, Linear, GitHub Issues, Azure DevOps. Pominięcie któregokolwiek z tych elementów sprawia, że zadanie staje się sprawdzianem pamięci. Brak ostatniego elementu sprawi, że retrospektywa stanie się drugą listą zadań do wykonania, której nikt nie otworzy. W naszej rubryce porównawczej skrótem opisującym to jest pięć elementów: zadania do wykonania jako rzeczywiste jednostki (a nie karteczki samoprzylepne), działanie powiązane z pomysłem, z którego się wywodzi, automatyczne przeniesienie do następnej sesji retrospektywnej, pulpit nawigacyjny działań obejmujący wszystkie sesje retrospektywne oraz integracja z systemem śledzenia zgłoszeń pochodząca od samego dostawcy, a nie za pośrednictwem Zapier.
Większość narzędzi spełnia pierwszy warunek, pomijając pozostałe. Właśnie w tym miejscu pęka pętla.
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 wynikają, domyślne przenoszenie do kolejnego retro, 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 o największym znaczeniu — to właśnie tam Scrum Master, prowadzący trzy zespoły, może sprawdzić na jednym ekranie, które zobowiązania ze sprintu są nadal otwarte, a które zostały dwukrotnie opóźnione. W ramach podstawowego płatnego planu trzy zespoły po ośmiu osób kosztują 50 USD miesięcznie przy rozliczeniu rocznym, więc pełna pętla monitorowania nie jest ograniczona barierą płatności charakterystyczną dla planów korporacyjnych.
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. Przenoszenie 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żynierskiej korzystającej już z GitHub lub Linear funkcja zapisywania zmian w systemie Parabol stanowi najprostszą na rynku ścieżkę od pomysłu z retrospektywy do zgłoszenia w backlogu.
Neatro
Spełnia cztery z pięciu kryteriów — brakuje jedynie powiązania między działaniem a wątkiem dyskusji, z którego się ono wywodzi. 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ń w systemie Kanban między sesjami oraz synchronizacja z Jira, Azure DevOps, GitHub, Asana i Monday. Haczykiem jest brak 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 generowanej przez sztuczną inteligencję w różnych zespołach, a wyodrębnianie tematów wskazuje, które działania pojawiają się wielokrotnie podczas różnych retrospektyw, nie zostały jednak zamknięte. Pięć gwiazdek pomniejszonych o widok Kanban. Zakres integracji jest wąski — wyłącznie Jira, Slack i Teams, bez GitHub, Linear czy Azure DevOps — więc rozwiązanie to sprawdzi się, jeśli Państwa organizacja standardowo korzysta z Jira, a nie będzie odpowiednie, jeśli tak nie jest. Skok cenowy od wersji bezpłatnej przez 50 USD/miesiąc do 500 USD/miesiąc jest nieco niezręczny w środkowej części przedziału, ale podstawowy płatny pakiet obejmuje trzy zespoły po osiem osób.
Gdzie pojawia się rozbieżność
Tablice są najwyraźniejszym 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 dalszy przebieg retrospektywy opiera 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 zadań. Działanie wynikające 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 pola widzenia. W praktyce zespoły wykonują 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 Kanbana. 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 możliwości kontynuacji działań. Retrospektywa odbywa się na pięknym kanwie; działania są umieszczane tam, gdzie zespół sam zdecyduje o ich umieszczeniu.
FigJam
Najbardziej szczere z tych trzech rozwiązań co do swojego przeznaczenia — w przypadku FigJam wszystkie cztery kryteria dotyczące działań mają ocenę „nieprawda”. Jest to platforma do burzy mózgów, która umożliwia przeprowadzanie retrospekcji, o ile wykorzysta się odpowiedni szablon; nie udaje, że śledzi cokolwiek po zakończeniu sesji. Nadaje się do jednorazowej retrospektywy poza siedzibą firmy. Nie jest jednak odpowiednie dla zespołu działającego w trybie ciągłym.
Drugi wzorzec jest bardziej subtelny: narzędzia stworzone z myślą o retrospektywach, które rejestrują działania, ale pomijają przenoszenie zadań na kolejne sesje. EasyRetro
i RetroTool należą do tej kategorii — działania istnieją, mają wyznaczonych wykonawców, ale nie pojawiają się ponownie na początku kolejnej retrospektywy, chyba że moderator ręcznie je ponownie doda. W przypadku zespołu przeprowadzającego retrospektywy raz w miesiącu rozwiązanie to niemal się sprawdza. Przy częstotliwości co dwa tygodnie luka związana z przeniesieniem zadań jest tym, co po cichu sprawia, że co trzecia retrospektywa zamienia się w skargę, że „nigdy niczego nie zamykamy”.
O co zapytać podczas testu
Decydują o tym trzy pytania. Po pierwsze: kiedy zamknę tę sesję retrospektywną, co stanie się z zadaniami do wykonania, które właśnie utworzyłem — czy pojawią się one automatycznie na początku następnej sesji, czy też muszę je przenieść ręcznie? Po drugie: czy z tego zadania do wykonania mogę jednym kliknięciem przenieść je do naszego backlogu, i czy link ten 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 były przenoszone przez cztery sprinty z rzędu? Jeśli odpowiedź na którekolwiek z tych pytań brzmi: „można wyeksportować do pliku CSV”, to pętla nie jest zamknięta — jest to arkusz kalkulacyjny, a arkusze kalkulacyjne to miejsce, w którym zadania do wykonania umierają.