Znasz to uczucie? Kończy się Planowanie Sprintu. Zespół „zakomitował się” do celu. W Jirze (lub Azure DevOps) wszystko świeci się na niebiesko w kolumnie „To Do”. Wygląda to jak plan. Ale czy nim jest?
W rzeczywistości to tylko lista życzeń. Jira świetnie odpowiada na pytanie „CO” mamy do zrobienia. Ale milczy w kwestii tego, „JAK”, „KIEDY” i „Z KIM” to zrobimy.
Przez lata pracy jako Scrum Master, Agile Coach i Enterprise Transformation Coach w dużych organizacjach (od telekomów po bankowość) widziałem ten sam schemat: silosy kompetencyjne, efekt „ja swoje zrobiłem, teraz ty się martw” i panika w ostatnich dwóch dniach sprintu.
Dlatego stworzyłem rePlan. Narzędzie banalne w swojej konstrukcji, ale rewolucyjne w skutkach. To nie jest kolejny plugin. To zmiana mentalna.
Czym w ogóle jest rePlan?
Wyobraź sobie prostą siatkę.
- Wiersze: To Twoi ludzie. Janek, Kasia, Bartek, Zosia.
- Kolumny: To dni Sprintu. Poniedziałek, Wtorek… aż do Review.
To nie jest Gantt, którego tworzy manager i narzuca zespołowi. To plansza do gry zespołowej, którą zespół wypełnia sam. Podczas planowania nanosimy na nią:
- Dostępność: Urlopy, szkolenia, wyjścia do lekarza (realna pojemność).
- Zadania w czasie: Kreski oznaczające, kiedy planujemy pracować nad danym Story.
- Zależności: Jeśli Kasia potrzebuje kodu od Janka, jej zadanie nie może zacząć się wcześniej, niż skończy się zadanie Janka.
Brzmi prosto? Siła tkwi w tym, co dzieje się później.
Efekt 1: Śmierć „Bohatera” i narodziny „Roju” (Swarming)
W tradycyjnym podejściu developer bierze zadanie i znika na 3 dni. Na rePlan widać to jako długą, samotną linię. Zespół od razu to widzi: „Hej, Marek, zajmujesz się tym gigantem przez pół sprintu sam. Co jak zachorujesz? Co jak utkniesz?”.
rePlan naturalnie wymusza Swarming (pracę roju). Zamiast jednej długiej linii, zespół zaczyna rysować dwie lub trzy krótsze, równoległe linie przy tym samym temacie.
Zysk: Wiedza nie jest uwięziona w głowie jednej osoby (Bus Factor), a zadania są zamykane szybciej.
Efekt 2: Daily Scrum przestaje być spowiedzią
Większość spotkań Daily Scrum to status meetingi: „Wczoraj zrobiłem X, dziś zrobię Y”. Nuda. I strata czasu.
Z rePlanem Daily zmienia się w taktyczną odprawę. Patrzymy na tablicę:
- „Mieliśmy skończyć ten moduł wczoraj (widać koniec linii na wtorku), a jest środa i wciąż to robimy. Linia przesuwa się w prawo. Co to oznacza dla reszty sprintu?”
- „Widzę, że jutro Zosia ma szkolenie, a Bartek czeka na jej Code Review. Mamy korek. Kto inny może to sprawdzić?”
Dyskusja przenosi się z przeszłości („co zrobiłem”) na przyszłość i zarządzanie ryzykiem („czy zdążymy”).
Efekt 3: Koniec z „Testing Squeeze”
Klasyczny problem: Developerzy kodują przez 8 dni sprintu, a Testerzy mają 2 dni na sprawdzenie wszystkiego. W Jirze tego nie widać, dopóki zadania nie wpadną do kolumny „Ready for Test”.
Na rePlan widać to w sekundę podczas planowania. Jeśli linie u Developerów są pełne do czwartku, a linie u Testerów puste na początku sprintu, a przeładowane na końcu – tablica krzyczy, że plan jest nierealny.
Wymusza to wcześniejsze angażowanie testerów lub rozbijanie historyjek tak, by testować je od 2-3 dnia sprintu.
Dodatkowo zespół łatwo przechodzi do trybu pracy, kiedy to podczas rozpoczynania prac nad danym tematem testerzy zaczynają definiować jak będzie on testowany. W efekcie na koniec pozostaje tylko wykonanie zdefiniowanego już testu.
Case Study: Transformacja w finansach
Jako Enterprise Agile Coach pracowałem z dużym Tribe’em (ok. 16 zespołów), który zmagał się z brakiem przewidywalności i niskim zaangażowaniem.
Sytuacja PRZED:
Zespoły dowoziły „punkty”, ale nie dowoziły wartości. Integracja rozwiązań następowała rzadko i boleśnie. Panował podział: „My devowie, Wy biznes”.
Wdrożenie rePlan:
Wprowadziłem rePlan nie jako narzędzie kontroli, ale jako narzędzie uzgadniania rzeczywistości.
- Na początku był opór. „To mikrozarządzanie!”. „Szkoda czasu na rysowanie kresek”.
- Przełom nastąpił, gdy jeden z zespołów dzięki tablicy zauważył w połowie sprintu, że przez nieobecność kluczowego architekta nie dowiozą Celu. Zamiast udawać, że jest OK, zmienili zakres w trakcie sprintu, informując Product Ownera.
- Sprint zakończył się sukcesem, bo dowieźli to, co najważniejsze, bez nadgodzin. Inne zespoły to zauważyły.
Efekty PO 3 miesiącach:
- Time to Market (TTM) skrócony o 35%: Dzięki wizualizacji zależności zespoły przestały się blokować. Czas oczekiwania (Waste) został drastycznie zredukowany.
- Wzrost zaangażowania o 40%: Ludzie poczuli, że mają wpływ na plan. To nie był plan managera, to był ich plan, ułożony na ich zasadach.
- Kultura planowania z kontekstem celów: Zespoły przestały planować „zamykanie tasków”, a zaczęły planować „osiągnięcie celu” w konkretnym czasie.
Skalowanie: rePlan na poziomie wielu zespołów
Siła rePlan rośnie wykładniczo, gdy położymy kilka tablic obok siebie (np. na wirtualnej tablicy Miro dla całego Tribe’u).
Jeśli Zespół A buduje API dla Zespołu B, to na zwykłym planowaniu słyszymy: „Dostarczymy to w tym sprincie”.
Na zintegrowanym rePlan widać:
- Zespół A planuje skończyć API w piątek.
- Zespół B planuje użyć tego API w środę.
Wizualizacja pokazuje kolizję zanim napisana zostanie pierwsza linijka kodu. Dzięki temu zespoły mogą negocjować kolejność prac przed startem sprintu, co jest kluczowe dla budowania zintegrowanego przyrostu w dużych organizacjach.
Podsumowanie: Od Silosów do Współpracy
rePlan leczy najcięższą chorobę zespołów Agile – samotność w tłumie.
Rozbija silosy, bo pokazuje, że pusta kratka w moim wierszu to okazja, by pomóc koledze, który w swoim wierszu „tonie”.
Zmienia narrację z „Ja zrobiłem swoje zadanie” na „My zrealizowaliśmy nasz plan”. I o to w tym wszystkim chodzi.