Agile nie kojarzy się na pierwszy rzut oka z przewidywalnością. Bardziej ze zmianą i dostosowywaniem się do dynamiki otoczenia. A jednak… całkiem sporo czasu poświęcamy temu, aby spróbować okiełznać rzeczywistość. Przykładowe Sprinty w Scrumie mają w tle przewidywalność właśnie. Chcemy realizować pewne cele i oszacowujemy nasze możliwości, aby wiedzieć ile zaplanować, a potem staramy się zrealizować założony plan. W takim sensie chcemy być przewidywalni. Jak to osiągnąć?
Na start pewne wyjaśnienie: nie każdy zespół chce lub musi być przewidywalny. Niektóre lepiej będą działały, pracując w sposób bardzo dynamiczny, ocierając się o krawędź chaosu 😂 W tym artykule nie rozstrzygam jak jest lepiej, w nim piszę o tym co zrobić, gdy chcecie zwiększyć swoją przewidywalność.
#1 Wykres spalania (Burndown Chart) i inne narzędzia
Pierwszy krok: zrozumieć stan obecny. „Zmierz to i pokaż”. Jeśli czegoś nie możemy zobaczyć i/lub zmierzyć, to poruszamy się ciągle w sferze domniemań. Może intuicja nam podpowiada słusznie, ale równie dobrze możemy się mylić.
W przypadku zespołów pracujących w Sprintach świetnie sprawdzi się Wykres Spalania (Burndown Chart), który pozwala śledzić ile zostało jeszcze pracy. Codzienne jego używanie, np. wyświetlenie w ramach Daily, pozwala na bieżąco dyskutować o problemach z realizacją planu. Widać na nim ewentualne wrzutki, czy stoimy z pracą (np. tworzą się wąskie gardła) i wiele innych szczegółów. Więcej o samym narzędziu piszę w oddzielnym poście tutaj.
Dodatkowo Wykres Spalania to świetna podstawa do zadawania pytań: np. czy przyjmując do sprintu wrzutkę wyrzuciliśmy coś o jej równowartości; czy nadal sądzimy, że uda nam się zrealizować Cel Sprintu; gdy widzimy, że piętrzą się zadania do przetestowania – czy tylko tester może testować te zmiany. I tak dalej, i tak dalej. Problemy widać na wykresie, trudniej je zignorować.
Pozostałe narzędzia, które możesz spróbować włączyć do swojego repertuaru to Cumulative Flow Diagram lub mierzenie Cycle Time (lub Lead Time). Możecie o nich przeczytać np. tutaj.
Spróbuj tego 💡 Użyjcie Wykresu Spalania przez 2-3 Sprinty, aby przekonać się czy Wam pomoże.
#2 Odpowiednie planowanie – dodanie eventów, zależności, wizualizacja i nie tylko
Niektórzy sądzą, że agile to brak planowania. Zupełnie tak nie jest, a więcej o tym pisałem w tym poście. Tworzenie planów jest bardzo przydatne. W zależności od tego jak bardzo chcemy być przewidywalni, tym dokładniej musimy planować. Nie dajmy się jednak zwariować – trzeba znaleźć złoty środek między czasem poświęconym na planowanie, a tym jak bardzo przewidywalni chcemy być.
Jedną z najprostszych i wg mnie wręcz obowiązkowych praktyk na planowaniu jest: rzut okiem na kalendarz i wymienianie się informacjami o potencjalnych urlopach, warsztatach całodniowych, ważnych deadline’ach itp. Nierzadko widziałem zespoły pomijające ten element, a potem zaskoczone, że „przecież Zosia miała przetestować moje zadanie, a jest na urlopie, teraz musimy zaczekać 1 tydzień”. Tak prosta czynność, a tak często zapominana – kalendarz.
Dodatkowo – co z zależnościami od innych? Przez to bardzo często wywalają nam się plany. Nie myślimy o tym, że „DevOpsi mają nam przygotować środowisko” i to też zajmie chwilę. Takie zależności też należy uwzględnić jako punkt agendy podczas planowania.
Chcesz pójść jeszcze dalej? Możesz spróbować nanieść Wasz Sprint na kalendarz i sprawdzić czy rzeczywiście plan jest sensowny. Wizualizacja to jest to – poczytaj tutaj!
Spróbuj tego 💡 Przygotuj agendę i checklistę na następną sesję Planowania. Zawrzyj w niej wybrane elementy, np. rzut okiem na kalendarz, pytanie o zależności.
#3 Krótkie (np. jednotygodniowe) Sprinty
Póki nie spróbujesz, to się nie przekonasz. Tak to jest z „krótkimi” Sprintami. Widziałem to kilkukrotnie – zespół pracował w 2 tygodniowych cyklach, skracał je do jednego tygodnia i „włala”, nagle wiele problemów się rozwiązało. Oczywiście, nie każdemu to odpowiada, ale dopóki nie spróbujesz, to się nie przekonasz. Mniej do zaplanowania = mniej do ogarnięcia = łatwiej o przewidywalność. Ten temat też opisałem, więc nie będę szczegółowo omawiał jakie znaczenie ma długość Sprintu – możesz o tym przeczytać tutaj.
Spróbuj tego 💡 Prześlij zespołowi ten artykuł i podyskutujcie o tym jaka długość Sprintu jest dla Was najlepsza i czy chcecie coś w niej zmienić.
#4 Skład zespołu i znajomość domeny
W Scrumie, zespół rozwija produkt (lub jego obszar), regularnie dostarcza zmiany do klientów, a feedback loop pozwala sprawdzać czy to właściwy kierunek. Takie coś jest dużo trudniejsze, gdy skład tego zespołu regularnie się zmienia, gdy na potrzeby kolejnych projektów tworzymy kolejne zespoły itd. Wówczas bardziej mówimy o zespołach projektowych, a nie produktowych. Czasem się nie da tego uniknąć, bo nasza firma to np. software house lub game studio i siłą rzeczy kolejni klienci wnoszą nowy produkt/projekt. Tym bardziej trudno mi zrozumieć sytuacje, gdy firma rozwija swój produkt, a jednocześnie zmienia regularnie składy poszczególnych zespołów, chociaż wcale nie musi tego robić. Oczywiście nawet przy zmieniających się często projektach można zadbać o to, aby skład zespołu chociaż był możliwie stabilny.
Zapewne domyślasz się czemu ma to takie znaczenie dla przewidywalności. Zespół, który rozwija produkt i pracuje w danym składzie dłużej będzie bardziej przewidywalny niż taki, który się regularnie zmienia.
Spróbuj tego 💡 Użyj techniki 5 Why, gdy następnym razem staniecie przed pytaniem czy zmienić skład zespołu. Przejrzyj historię składu swojego zespołu – spróbuj znaleźć konsekwencje każdej zmiany – jaki wpływ miała na atmosferę w zespole, tempo rozwijania oprogramowania itp. Jeśli składy zespołów muszą się zmieniać, zastanów się jak zminimalizować straty, jak dbać o team building.
#5 Dobry refinement
Mało rozmów o historyjkach, ich niska jakość, to jedne z częstszych przyczyn trudności z przewidywalnością. Gdy nasze pomysły nie są dopracowane, to łatwiej o niespodzianki w trakcie ich realizacji. Oczywiście, nie można dać się zwariować i dyskutować godzinami o prostych rzeczach, tylko po to, aby być przewidywalnym, ale jeśli zależy nam na tej przewidywalności, to dobry refinement jest jednym z potencjalnych lekarstw.
Spróbuj tego 💡 Zastanów się nad procesem doskonalenia Backlogu w Waszym zespole i sprawdź czy warto coś w nim zmienić (np. częstotliwość, długość, facylitację).
#6 Brak wąskich gardeł, cycle time
Ile jest faz, etapów w procesie dewelopmentu w waszym produkcie? Zapewne programiści wzajemnie sprawdzają sobie kod (code review, peer review), może tester też testuje zmiany przed wejściem na produkcję. A może nawet PO musi powiedzieć “OK” zanim coś zostanie pokazane klientowi? Co z tłumaczeniem na inne języki? I tak dalej. Każdy kolejny etap to angażowanie kolejnych osób, które muszą coś wykonać, aby rzecz poszła dalej (tzw. handoff). Im takiego ruchu więcej tym więcej marnotrawstwa (waste) i jednocześnie ryzyka, że ktoś może się rozchorować albo nie będzie nadążał z obsługą takiego ruchu i stanie się wąskim gardłem.
Spróbuj tego 💡 Zbadaj Cycle Time, zwracając uwagę na poszczególne etapy przepływu pracy. Posłuchaj naszego odcinka podcastu o tym czy Product Owner powinien akceptować historyjki?
#7 Podejście do bugów, wrzutek
Możemy poświęcić wiele godzin na przygotowanie bardzo szczegółowego planu, a i tak na koniec okaże się, że coś nam te plany pokrzyżuje. Zatem zamiast skupiać się na bardzo dokładnym, czasochłonnym planowaniu, można ustalić pewne zasady dotyczące reagowania na sytuacje nieprzewidziane. Jest całkiem sporo praktyk, które próbują zaadresować problem niezaplanowanych rzeczy. Oto kilka z nich:
- każda wrzutka powoduje wyrzucenie historyjki (ze Sprint Backlogu) o porównywalnej wartości
- zostawiamy “bufor” w Sprincie na wrzutki (np. planujemy tylko na 80% naszych możliwości)
- mamy przypisanego “dyżurnego” albo “strażaka”, który zgarnia wrzutki, podczas gdy inni zajmują się tym co zaplanowane
Spróbuj tego 💡 Policz tzw. scope creep w Sprintach, podziel się wynikami z zespołem, poszukajcie wzorców, ustalcie zasady dotyczącego jego obsługi oraz radzenia sobie generalnie z bugami.
Podsumowanie
Najważniejsze jest to, aby umieć szybko reagować na zmiany. Dlatego też odnalezienie tego złotego środka (między sztywnym planowanie, przewidywalności i dynamiczną reakcją) zostawiam Wam. Jeśli jednak chcielibyście trochę zwiększyć przewidywalność swojego zespołu możecie skorzystać z powyższych porad: mierzyć, wizualizować, pracować na możliwie krótkich cyklach, często zbierać feedback, dbać o jakość swojego backlogu. Powodzenia!
P.S. Jeśli macie swoje pomysły na zwiększanie przewidywalności zespołu, zostawcie je koniecznie w komentarzu.