Planowanie na kilka miesięcy

Co zrobić w sytuacji, kiedy Management poprosi nas o przygotowanie „planu na projekt”? Planowanie na kilka miesięcy do przodu ma swoje wady i zalety – wiecie jakie?

 

Potrzeba

O planowaniu w długim terminie w kontekście Scrum i Scrum Guide możemy powiedzieć dokładnie tyle, że jest go bardzo mało. Długoterminowym planem realizacji Produktu jest nasz Product Backlog, który kiedyś może uda nam się dostarczyć.

Jak zwykle powtarzamy, aby zrobić coś porządnie i z zaangażowaniem musimy znać potrzebę. W przypadku spojrzenia na długi termin, potrzebą tą będzie dostarczenie planu na projekt. Może dzięki temu uda się zatwierdzić budżet, może dostaniemy zielone światło na zatrudnienie (w slangu branżowym – “zasobowanie”) niezbędnych członków naszego zespołu – Deweloperów, Product Ownera, Scrum Mastera i kogokolwiek jeszcze potrzebujemy.

Znając potrzebę, łatwiej będzie nam się zmotywować do tego, aby przygotowany plan był lepszy od najlepszego, jaki wytworzylibyśmy w ciemno. Czy jednak jesteśmy w stanie przygotować go tak aby rzeczywistość nie zweryfikowała go negatywnie?

Wielokrotnie pisaliśmy o zmienności, o tym, że działając w krótkich okresach mamy możliwość łatwiejszego dostosowania się do aktualnych potrzeb interesariusza i firmy. Czy planowanie długoterminowe nie będzie więc zaprzeczeniem tej idei? Czy planowanie w długim okresie da nam jakiś dodatkowy atut?

Gdy rozpoczynaliśmy pisać tego bloga wiodącą metodyką był Scrum. Jakiś czas temu gładko przeszliśmy na metodyki skalowalne. Jedna z nich szczególnie wspiera długoterminowe planowanie Sprintów. Co więcej, idę o zakład, że co najmniej 50% z Was ma w swoich Jirach, Asanach, TFS-ach i innych plan na najbliższe 2-3 Sprinty. Mylę się?

 

Zalety

Niewątpliwą zaletą tworzenia Sprint Backlogów na więcej niż obecny Sprint jest możliwość przewidywania. Urlopy, L4, szkolenia, wyjazdy integracyjne, wszystkie te rzecz (może poza L4) da się przewidzieć – mają swoje miejsce w kalendarzu. Jeśli wiemy, że się wydarzą, jesteśmy w stanie ułożyć Backlogi kolejnych Sprintów tak, aby pokrywały  dostępne kompetencje w naszym Scrum Team.

Przykład z życia – proszę bardzo. Mamy w zespole dokładnie jednego Frontend Dewelopera. Wiemy, że w kolejnym Sprincie nie będzie mógł świadczyć dla nas usług, bo idzie na zasłużony urlop. Planując Sprint +1 wezmę to pod uwagę, a co za tym idzie prace związane z frontem zostaną odłożone na później. Proste!

Kolejnym argumentem “za” jest pozorne zwiększenie przewidywalności. Planowanie wielu Sprintów zwykle poprzedzone jest stosownym wydarzeniem, podczas którego Zespól commituje się do wykonania zakresu i/lub osiągnięciu Celu Sprintu. A jeśli mowa już o commitowaniu, to mamy od razu kolejny argument “za”. Wiemy (z pewną dozą dokładności) co będziemy robić w perspektywie najbliższych 2-6 Sprintów. Na pewno dokładniej, niż analizując poszczególne wymagania znajdujące się w Backlogu Produktu, czego i tak nie robi 95% z nas.

 

Nie ma róży bez kolców

Wymieniłem trzy podstawowe zalety, czas więc na wady takiego podejścia. Numer jeden to brak pragmatyzmu i potencjalna strata czasu. Planując więcej niż jeden Sprint narażamy się na to, że życie bardzo szybko nasze plany zweryfikuje. Po co tracić więc czas? Neutralizując tę wadę trzeba spowodować, aby plan był przygotowany przy zaangażowaniu wszystkich członków Zespołu. Zwielokrotniamy wówczas szansę na jego powodzenie.

Kolejnym aspektem, o którym nie mogę nie napisać jest ciśnienie na dowiezienie. Niestety, ale planowanie na kilka Sprintów (a co za tym idzie miesięcy) do przodu często odbierane jest jako „dobra, powiedzieli, że dowiozą”. Często zobowiązanie to jest rozumiane dużo bardziej dosadnie niż planowanie najbliższego Sprintu. Nie możemy do tego dopuścić! To, że planujemy się na 2 miesiące nie oznacza, że jest to commitment. Jest to “tylko” nasza obietnica dołożenia wszelkich starań w zakresie dostarczenia. Mamy na uwadze, że ktoś w oparciu o nasze planowanie mógł zaplanować np. wydanie czy integracje z innymi systemami. W dalszym ciągu jest to jednak plan i to obarczony ryzykiem zmieniającego się świata.

Trzecim aspektem jest brak przygotowania. Nie można ułożyć długoterminowego planu na wysokopoziomowej wiedzy w zakresie wymagań. To się nie uda. Nasza wiedza musi być dokładniejsza, może nie jak w przypadku planowania najbliższego Sprintu, ale jednak musimy wiedzieć więcej.  Planowanie na tzw. „grubych klockach” może spowodować, że nasze szacunki będą bardzo niedokładne, nasze capacity za małe, a dostarczone rozwiązanie nie będzie miało wartości biznesowej.

 

Planowanie na kilka miesięcy

Wymieniłem po trzy wady i zalety. Analizując możecie dojść do wniosku, że jednych lub drugich może być dużo więcej. Całkiem słusznie, razem tworzymy społeczność #białko, razem więc możemy wymienić się doświadczeniami. Co Wy widzicie jako wady i zalety takiego planowania?

Z mojego doświadczenia mogę napisać, że planowanie na kilka miesięcy do przodu na pewno wymaga narzutu na przygotowanie. Jego efektem jest na pewno lepsze rozumienie zakresu, często również przesunięcie otrzymanej wartości biznesowej ze Sprintu na np. Wydanie (patrz: Release Planning). Powoduje to często lepsze rozumienie zwinnej metodyki przez Deweloperów.

Nie umiem jednoznacznie odpowiedzieć, czy lepiej planować się na jeden czy na przykład na sześć Sprintów. Może Wy mi podpowiecie?

Łukasz Bręk

15 lat doświadczenia w IT, 8 lat doświadczenia w metodykach zwinnych, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy/systemowy, Agile Coach, trener Scrum. Swój warsztat szlifował na projektach waterfallowych, dziś skupiony wokół zwinnego dostarczania Produktu.

Click Here to Leave a Comment Below

Tomek - 15 września 2021

Planowanie powinno odbywać się co Sprint, na Sprint planningu. Ale nic nie stoi na przeszkodzie, by prognozować (np: metodą Monte Carlo jak nie mamy estymat) na bazie naszego velocity ile wykonamy zakresu w ciągu najbliższych 2/3/4/5 i więcej Sprintów. Tylko trzeba pamiętać, że jest to prognoza i może nam pomóc w ustaleniu priorytetów (np: ze względu na deadline pewnych funkcjonalności) albo w odchudzaniu releasu w celu dostarczenia większej ilości must have wymagań czy elementów product backlog kosztem fajerwerków dających efekt “wow” (chociaż też bym uważał z zupełnym obcięciem tych fajerwerków bo uzyskamy niską satysfakcję wg. modelu Kano)

Reply
    Łukasz Bręk - 20 września 2021

    Cześć Tomek,

    Dzięki za komentarz. Masz 100% racji, planowanie Sprintu powinno odbywać się na Sprint Planningu, po to jest to wydarzenie. Jednak często pojawia się pokusa, bądź nawet żądanie, aby tych Sprintów zaplanować więcej.

    To, o czym napisałeś powyżej tylko częściowo pokrywa zakres zagadnienia. Prognoza jest dobra przy zwinnym podejściu, jednak gdy mamy do czynienia z “projektem”, takim z krwi i kości sprawa się komplikuje. Zwinność zwinnością, ale zakres ma być wykonany w określonym terminie. Tutaj pojawia się największe wyzwanie.

    Znów, zgadzam się z podejściem w zakresie tzw. wodotrysków. Mają one zresztą fajną definicję (za PWN): efektowny, lecz zbędny dodatek do czegoś, zwykle do jakiegoś urządzenia.

    Czy jeśli jest zbędny, w myśl zasad pragmatyzmu jest konieczny do zaimplementowania? Z drugiej strony może być to tzw. Quick Win, efekt WOW może spowodować, że będziemy lepiej postrzegani przez Klienta.

    Ł.

    Reply
Leave a Reply: