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.

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?