Pod koniec 2020 w artykule na temat pielęgnacji Backlogu Produktu obiecałem, że wkrótce napiszę o typowych błędach, jakie Zespoły popełniają w ramach tego procesu. 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 cykl czterech artykułów, z których każdy opisywać będzie kilka marnych sposobów dbania o Backlog Produktu.

Sposób 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 wypielęgnowany element Backlogu jest „dobrze zdefiniowany”, co prowokuje do trzymania się poczynionych ustaleń (skoro są one takie „dobre”), zamiast empirycznego poszukiwania najlepszego sposobu realizacji w momencie jej rozpoczęcia.

Efektem nadmiernej pielęgnacji jest także przedwczesne podejmowanie wielu decyzji i równie przedwczesne projektowanie rozwiązań. Pozornie daje to możliwość szybszej realizacji, 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 rozpoczęcia realizacji warunki te się nie zmienią. Wtedy pracę związaną z wymyślaniem rozwiązania i planowaniem sposobu na jego wytworzenie trzeba będzie wykonać raz jeszcze.
  • Gorzej, jeśli Zespół trzymał się będzie pierwotnych ustaleń niezależnie od zmian sytuacji. Podjęte już decyzje często kotwiczą umysły ludzi, utrudniając im dostrzeżenie innych (być może lepszych) sposobów działania niż te, 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 projektowych i może doprowadzić do odejścia od empirycznej kontroli procesu na rzecz wykonywania poczynionych z góry planów. Pokusa, by realizować wyłącznie „dobrze przygotowane elementy Backlogu”, 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 elementy Backlogu Produktu szybko zrealizować, jest chybiony. Następuje spowolnienie bieżącego developmentu bez żadnej gwarancji, że te dobrze przeanalizowane i opisane elementy Backlogu faktycznie kiedyś będą realizowane.
  • No, właśnie: elementy, 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ę odzyskać.

Rozsądek nakazuje, by większość prac analitycznych i projektowych wykonywać w tym Sprincie, w którym dany element Backlogu Produktu jest realizowany. Pielęgnacja powinna zatrzymać się w momencie, gdy Zespół uznaje, że element jest dostatecznie zrozumiały, by możliwe było zaplanowanie sposobu jego implementacji i zarazem na tyle mały, by prace nad nim dało się w pełni ukończyć w czasie jednej iteracji. Szczegółowe ustalenia czynione będą już w ramach Planowania Sprintu albo nawet developmentu.

Sposób 2: dążenie do uzyskania gwarancji sukcesu

Część Zespołów dokonuje zdecydowanie zbyt daleko idącej i bardzo kosztownej pielęgnacji po to, by wyeliminować wszystkie niewiadome przed rozpoczęciem developmentu. 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 pytanie o to, jaki może być najgorszy scenariusz, by przygotować się na niego. Często robią to, bo obawiają się konsekwencji, jeśli „nie dowiozą” czegoś na czas, zgodnie z oszacowaniami i prognozami. Zapewne są i inne mniej oczywiste powody.

W praktyce zawsze bardziej się opłaca zrobić coś jak najwcześniej i w ten sposób szybko wyklarować wszelkie niewiadome, niż grzęznąć w spekulacjach, przewidywaniach i analizach. Nawet najbardziej wyczerpujące projekty i plany nie dają gwarancji, że realizacja elementu Backlogu Produktu zakończy się powodzeniem. A czasu poświęconego na ich sporządzenie cofnąć się nie da.

Sposób 3: Planowanie Sprintu w ramach pielęgnacji

Stosunkowo często Zespoły Scrum dokonują w ramach pielęgnacji Backlogu Produktu wstępnego planowania działań, jakie trzeba wykonać, aby zrealizować poszczególne elementy. Nie jest to z definicji pozbawione sensu, ale zdarza się, że takie wstępne planowanie kończy się ułożeniem Backlogu przyszłego Sprintu (albo nawet kilku kolejnych). Samo Planowanie Sprintu staje się potem 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, które 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ć potem istotnych zmian w Backlogu Produktu, bo to 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 w trakcie Planowania Sprintu, czy faktycznie jest to możliwe do zrealizowania.
  • Planowanie przyszłych Sprintów w ramach pielęgnacji prowokuje do implementowania dużych zmian w produkcie poprzez ich podział na „etapy realizacji” – w efekcie okazać się może, że jedynie co parę Sprintów wytworzone zostanie coś w pełni ukończonego i wartościowego dla interesariuszy, a większość iteracji będzie jedynie kontenerem na kolejne etapy prac.
  • 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ć wymogi zawarte w Definition of Done co Sprint, bo liczyć będzie się ich zaspokojenie 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 wiedzy o bieżącym stanie produktu i potrzebach interesariuszy. Stworzone w ten sposób prognozy i plany działania w Sprintach będą o wiele lepsze niż plany czynione z dużym wyprzedzeniem, w ramach pielęgnacji.

Sposób 4: przedwczesna dekompozycja

Nieco mniej typowym, ale wciąż częstym błędem Zespołów, jest wczesna dekompozycja na mniejsze kawałki dużych elementów Backlogu Produktu. Backlog gwałtownie się rozrasta, a nierzadko pojawia się problem ze zidentyfikowaniem, skąd wzięły się poszczególne małe elementy. 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 (dwuwymiarowego) 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 elementu, a następnie wydzielenie z niego tylko tego, co powinno być zrobione najpierw. Dzięki temu Backlog nie będzie się szybko rozrastał, nie będą też potrzebne wspomniane powyżej epiki lub ich odpowiedniki w innych niż Jira narzędziach. A po zakończeniu prac nad takim niewielkim elementem można użyć pozyskanej wiedzy do podjęcia decyzji o tym, co zrobić z ciągiem dalszym, który wciąż czeka w jednym kawału na realizację.

Sposób 5: definiowanie zadań developerskich

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 tworzą listę zadań, które należy wykonać w ramach developmentu. Dlaczego twierdzę, że to błąd?

Definiowanie zadań jest w istocie planowaniem realizacji i powinno nastąpić dopiero w trakcie Planowania Sprintu, o ile w ogóle Zespół uzna za użyteczne posługiwanie się zadaniami (bo to opcjonalna praktyka w Scrumie, do tego niezbyt dobra). Jeśli zadania definiowane są przed tym, zanim element formalnie podjęty zostanie do realizacji w Sprincie (a więc przed Planowaniem), to:

  • W praktyce mamy do czynienia już z jakąś jego formą realizacji, mimo że element znajduje się wciąż w Backlogu Produktu.
  • Developerzy być może zaczną postrzegać elementy Backlogu Produktu przez pryzmat zadań, a opisy potrzeb interesariuszy odsunięte zostaną na drugi plan. Gdy tak się stanie, organizacja pracy w Sprincie skupi się przede wszystkim na realizacji takich 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 łatwiej może dojść do 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 potrzeby interesariuszy niekoniecznie ktokolwiek zadba. Istnieje spore ryzyko, że pracę zespołową zastąpi nieustanne przerzucanie problemów od osoby do osoby, zależnie od tego, jakie kompetencje w danym momencie są potrzebne.
  • 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 elementów Backlogu Produktu.
  • Zdarza się, że Developerzy zaczną awansem wykonywać zadania zdefiniowane dla elementów 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”. A wtedy stan produktu na koniec Sprintu może być trudny do ustalenia.

Scrum opiera się o pracę zespołową, ponieważ dzięki niej można najefektywniej wykorzystać posiadane przez Developerów kompetencje. Co więcej, pracując nad małą liczbą elementów Backlogu Produktu naraz, 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 Przyrostów jeszcze przed zakończeniem Sprintu.

To jeszcze nie koniec

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