Pod koniec 2020 w artykule na temat Pielęgnacji Backlogu Produktu obiecałem, że wkrótce napiszę na temat typowych błędów, jakie Zespoły popełniają w ramach tego procesu. Jak widać, to „wkrótce” zamieniło się w wiele miesięcy, ale w końcu – z ogromnym opóźnieniem – wywiązuję się z obietnicy. W ramach rekompensaty będzie to artykuł długi, dla wygody podzielony na cztery części.

Problem #1: nadmierna Pielęgnacja

Najbardziej typowym błędem jest Pielęgnacja, która doprowadza do zbyt szczegółowego i nadmiernie precyzyjnego opisu elementów Backlogu Produktu. Prawie nigdy za tą precyzją nie idzie wzrost przejrzystości, a nawet jest wręcz odwrotnie: w zalewie szczegółów, detalicznych opisów, załączników czy komentarzy ginie informacja o kluczowej potrzebie użytkownika.

Rośnie też fałszywe poczucie, że wymaganie jest „dobrze zdefiniowane”, co prowokuje do trzymania się poczynionych ustaleń (skoro są one takie „dobre”), zamiast empirycznego poszukiwania najlepszego sposobu realizacji w momencie jej rozpoczęcia.

Efektem takiej nadmiernej Pielęgnacji jest także przedwczesne podejmowanie wielu decyzji i równie przedwczesne projektowanie rozwiązań. Pozornie daje to możliwość szybszego zrealizowania wymagań, bo wystarczy potem tylko wdrożyć ustalenia w życie. W praktyce jest to z wielu powodów nieefektywne:

  • Decyzje podejmowane są z uwzględnieniem sytuacji i stanu produktu w momencie Pielęgnacji – nie ma jednak gwarancji, że do momentu realizacji, warunki te się nie zmienią. Wtedy pracę trzeba będzie wykonać raz jeszcze.
  • Gorzej, jeśli Zespół trzymał się będzie pierwotnych ustaleń niezależnie od zmian sytuacji. Podjęte decyzje często „kotwiczą” umysły ludzi, utrudniając im dostrzeżenie innych (być może lepszych) sposobów działania niż to, jakie pierwotnie zaplanowali – o ile w ogóle zechcą się za nimi rozejrzeć.
  • Taka daleko idąca Pielęgnacja jest odtworzeniem typowej fazy analizy znanej z metod klasycznych i może doprowadzić do odejścia od empirycznej kontroli procesu na rzecz wykonywania poczynionych z góry planów. Pokusa, by realizować „dobrze przygotowane wymagania”, zamiast na bieżąco ustalać detale już podczas developmentu, bywa bardzo silna.
  • Im bardziej rozbudowany jest proces Pielęgnacji, tym więcej czasu i wysiłku skonsumuje. Argument, że dzięki temu potem można szybko wymagania zrealizować, jest chybiony; na poczet tej „szybkiej realizacji potem” spowalniamy development odbywający się teraz, bez gwarancji, że te dobrze przeanalizowane wymagania faktycznie kiedyś zrealizujemy.
  • No, właśnie: wymagania, nad którymi Zespół się napracował, mogą zostać usunięte z Backlogu Produktu, zanim nastąpi ich realizacja. Wysiłku i czasu włożonego w ustalanie detali nie da się jednak odzyskać.

Rozsądek nakazuje, by większość prac analitycznych i projektowych wykonywać w tym Sprincie, w którym wymaganie faktycznie będzie realizowane. Pielęgnacja powinna zatrzymać się w momencie, gdy Zespół uznaje, że będzie w stanie zrealizować wymaganie w Sprincie, bo jest ono dostatecznie małe i zrozumiałe. Szczegółowe ustalenia czynione będą już w ramach realizacji.

Problem #2: dążenie do zagwarantowania sukcesu

Część Zespołów dokonuje zdecydowanie zbyt daleko idącej i bardzo kosztownej Pielęgnacji po to, by wyeliminować wszystkie niewiadome przed podjęciem wymagań do realizacji. Jest to oczywiście równie sensowne co organizacja polowania na jednorożce. Gdy zmagamy się z niestabilną złożonością, pewne może być tylko to, co już nastąpiło, a wszystko inne jest zaledwie prognozą, obciążoną większym lub mniejszym błędem. Dlaczego więc Zespoły działają tak nierozsądnie?

Być może nie zgadzają się z tym, że złożoności nie da się wyeliminować z rozwiązywanych problemów i próbują ją zredukować kosztem czasu i wysiłków włożonych w analizy. A może poszukują odpowiedzi na to, jaki może być „najgorszy scenariusz” tak, by przygotować się na niego. Często robią to, bo obawiają się konsekwencji, jeśli „nie dowiozą wymagania na czas, zgodnie z oszacowaniami i prognozami”. Zapewne są i inne, mniej oczywiste powody.

W praktyce zawsze bardziej się opłaca zacząć coś robić jak najwcześniej i w ten sposób szybko ustalić, jak jest naprawdę, zamiast grzęznąć w spekulacjach, przewidywaniach i analizach. Nawet najbardziej wyczerpujące projekty i plany nie dają gwarancji, że realizacja wymagania zakończy się powodzeniem. A czasu poświęconego na ich sporządzenie cofnąć się nie da.

Problem #3: Planowanie w ramach Pielęgnacji

Stosunkowo często Zespoły Scrum dokonują w ramach Pielęgnacji Backlogu wstępnego planowania działań, jakie trzeba wykonać, aby zrealizować wymagania. Nie jest to z definicji pozbawione sensu, ale zdarza się, że to wstępne planowanie kończy się ułożeniem Backlogu przyszłego Sprintu (albo nawet kilku kolejnych). Samo Planowanie Sprintu staje się potem właściwie formalnością – odbywa się tylko po to, by potwierdzić poczynione wcześniej plany i być może ustalić Cel Sprintu (a i to nie zawsze, bo po co komu Cel, skoro „wiadomo, co mamy dowieźć”).

Takie postępowanie niewiele ma wspólnego ze Scrumem, w którym każde zdarzenie ma konkretny cel i zdefiniowane zostało tak, by maksymalizować możliwość empirycznej kontroli procesu. Jeśli Zespół „przesunie” czynności, jakie powinny mieć miejsce w czasie Planowania Sprintu tak, że odbędą się one w całości w poprzedzających Sprintach (w ramach Pielęgnacji Backlogu), to w końcu Sprinty zaczną służyć po prostu realizacji wcześniej poczynionych planów. A to nieefektywne, z kilku powodów:

  • Zaplanowanie Sprintów z wyprzedzeniem zwiększy presję na Product Ownera, by nie dokonywać istotnych zmian w Backlogu Produktu – to nierzadko zdemolowałyby poczynione wcześniej plany. Maksymalizacja wartości produktu (a mówiąc ściślej jej optymalizacja) może stać się utrudniona, wzrośnie też ryzyko, że Zespół zacznie robić rzeczy zbędne siłą rozpędu.
  • Może pojawić się też presja, by „wziąć do Sprintu wszystko, co planowaliśmy”, bez realnej oceny na początku iteracji (w ramach Planowania), czy faktycznie jest to możliwe do zrealizowania.
  • Planowanie Sprintów w ramach Pielęgnacji prowokuje do implementowania dużych zmian w produkcie poprzez ich podział na „fazy realizacji” – w efekcie okazać się może, że realnie tylko co któryś Sprint pojawi się coś naprawdę wartościowego dla interesariuszy, a większość iteracji to po prostu kontener na kolejne etapy prac (uzyskanie postępu w realizacji statycznego planu).
  • Planowanie z góry Sprintów wygeneruje pokusę, by unikać powtarzania niektórych kosztownych czynności w każdej iteracji. Developerzy, świadomi tego, że to, co robią w bieżącym Sprincie, podlegać będzie dalszym modyfikacjom, mogą odłożyć na później testowanie lub pisanie dokumentacji. Jeśli tak zrobią, narastać zacznie dług techniczny, nastąpi też erozja praktyk developerskich.
  • Nierzadko takie układanie Sprintów z góry idzie w parze z planami wydań produktu, np. co kwartał albo pół roku. Ważność Sprintu zaczyna maleć i zaczyna on być traktowany jako etap miniprojektu, którym jest przygotowanie produktu do nadchodzącego wydania. W skrajnym przypadku Zespół przestaje realnie spełniać Definition of Done co Sprint, bo liczyć będzie się jej ewentualne spełnienie dopiero przed samym wydaniem. A wtedy empiryczna kontrola procesu, w którym rozwijany jest produktu, przestaje być możliwa.

Planowanie Sprintów powinno odbywać się dopiero w momencie ich rozpoczęcia (na początku iteracji), bo empiryczne działanie wymaga uwzględnienia aktualnego Backlogu Produktu i wiedzy o bieżącym stanie produktu. Stworzone na bazie tej empirycznej wiedzy prognozy Sprintu będą o wiele lepsze niż plany czynione z dużym wyprzedzeniem, w ramach Pielęgnacji, jeszcze nim zakończył się poprzedni Sprint.

Problem #4: przedwczesna dekompozycja

Nieco mniej typowym, ale wciąż częstym błędem Zespołów, jest wczesna dekompozycja dużych wymagań na szereg małych elementów Backlogu Produktu. W efekcie zamiast jednego, mamy takich elementów kilka, bywa, że kilkanaście. Backlog Produktu gwałtownie się rozrasta, a nierzadko pojawia się problem ze zidentyfikowaniem, skąd wzięły się poszczególne małe wymagania. Oczywiście tu w sukurs przychodzą nam narzędzia takie jak Jira z jej nieszczęsnymi „epikami”, które pozwalają pogrupować taką drobnicę. Ceną za to jest wprowadzenie dwupoziomowego (a czasami i trzypoziomowego, jeśli „epiki” pogrupujemy dodatkowo w ramach różnych „tematów”) opisu zawartości Backlogu, który w Scrumie miał przecież być prostą „płaską” listą.

Dużo lepszą strategią jest omówienie możliwego sposobu dekompozycji dużego wymagania, a następnie dokonanie jej w wymiarze minimalnym: wydzielenie do nowego, niewielkiego elementu tylko tego, co naprawdę powinno być zrobione najpierw. Dzięki temu wymagań w Backlogu nie będzie przybywać tak szybko, nie będą też potrzebne wspomniane powyżej „epiki”. To małe wymaganie, wydzielone z dużego elementu, zostanie zrealizowane – i wtedy można zastanowić się, w jaki sposób przedefiniować i dekomponować to, co pozostało do zrobienia (o ile jeszcze w ogóle będzie potrzebne).

Problem #5: niepotrzebna dekompozycja na zadania

Jeśli już mowa o dekompozycji, warto wspomnieć o kolejnym błędzie, jaki popełniają Zespoły. Wcale nie tak rzadko w ramach Pielęgnacji poświęcają one czas na zdefiniowanie zadań, które należy wykonać w ramach realizacji wymagań. Niekoniecznie przy tym dokonują fizycznego podziału wymagania na szereg elementów opisujących poszczególne zadania – choć i to się zdarza.

Taka identyfikacja zadań jest w istocie planowaniem realizacji i powinna nastąpić dopiero na Planowaniu Sprintu, o ile w ogóle Zespół uzna za użyteczne posługiwanie się zadaniami (bo to opcjonalna i wcale nie najlepsza praktyka w Scrumie). Jeśli zadania zdefiniowane są przed tym, zanim wymaganie formalnie podjęte zostanie do realizacji w Sprincie (a więc przed Planowaniem), to:

  • W praktyce mamy do czynienia już z jakąś jego formą realizacji, mimo że formalnie samo wymaganie znajduje się wciąż w Backlogu Produktu.
  • Developerzy zaczną spoglądać na elementy Backlogu Produktu przez pryzmat zadań, same wymagania odsunięte zostaną na drugi plan. Organizacja pracy w Sprincie skupi się przede wszystkim na realizacji zaplanowanych zadań, niekoniecznie zaś na uzyskaniu wartości. Tym samym nad perspektywą produktową, związaną z potrzebami interesariuszy, zacznie dominować perspektywa projektowa (realizacja planu opisanego zadaniami).
  • Im silniejsze będzie skupienie na zadaniach, tym większe ryzyko specjalizacji Developerów, którzy podejmować będą te prace, na których znają się najlepiej. W efekcie każdy będzie „robił swoje”, a o wymagania jako całość niekoniecznie ktokolwiek zadba. Istnieje spore ryzyko, że zamiast pracy zespołowej nad wymaganiami, nastąpi nieustanne przekazywanie sobie wymagań do „dalszej realizacji”.
  • Podobnie jak to ma miejsce w przypadku planowania Sprintów z wyprzedzeniem, przedwczesne definiowanie zadań „kotwiczy” Developerów na jeden, z góry określony sposób realizacji wymagań.
  • Zdarza się, że Developerzy zaczną „awansem” wykonywać zadania zdefiniowane dla wymagań wciąż znajdujących się w Backlogu Produktu. Dzieje się tak najczęściej wtedy, gdy w Zespole doszło do powstania silosów – Developer, nie mając w bieżącym Sprincie żadnych zadań „wymagających jego specjalizacji”, zacznie „realizować kolejny Sprint”. W efekcie tego stan produktu na koniec Sprintu może być trudny do ustalenia.

Scrum opiera się o pracę zespołową, ponieważ dzięki temu można najefektywniej wykorzystać posiadane przez Developerów kompetencje. Co więcej, pracując nad małą ilością elementów Backlogu Produktu na raz, redukuje się czas ich realizacji (tu nisko kłania się prawo Little’a) – jest mniej przełączania między kontekstami, mniej problemów z koordynacją prac wielu Developerów, możliwe staje się dostarczenie szeregu kolejnych inkrementów jeszcze przed zakończeniem Sprintu.

To jeszcze nie koniec…

Zachęcam do lektury drugiej części artykułu, w której opisuję kolejnych kilka błędów związanych z procesem Pielęgnacji Backlogu Produktu.

Zdjęcie: Loan