Angry cat

Dwadzieścia sposobów na zdemolowanie Backlogu Produktu, część 4

W pierwszej części artykułu opisałem najczęstsze problemy z Pielęgnacją Backlogu Produktu, z jakimi się zetknąłem. Część druga oraz część trzecia artykułu zawierają omówienie nieco mniej typowych błędów, jakie popełniają Zespoły. W ostatniej części skupimy się na kolejnych pułapkach związanych z Pielęgnacją.

Problem #14: dekompozycja, by „precyzyjnie” oszacować

Wspominałem wcześniej o błędzie polegającym na przedwczesnej dekompozycji wymagań, które niepotrzebne są dzielone na wiele mniejszych na długo przed tym, nim nastąpi ich choćby częściowa realizacja. Zdarza się też jednak, że w ramach Pielęgnacji dekomponuje się wymagania nie po to, by uczynić je możliwymi do realizacji, ale by „precyzyjnie” je wyestymować.

Jeśli wymagania są duże, błąd związany z ich oszacowaniem musi być wysoki, bo za dużo jest niewiadomych. Ludzie nie radzą sobie z tak dużą złożonością problemu i po prostu wprowadzają różne uproszczenia, czyniąc podświadomie rozliczne założenia. Dlatego zawsze proponuję, by dopasować oszacowania (ich rodzaj i sposób ustalenia) do wielkości wymagań i celu, dla którego estymujemy. Ma to sens czysto ekonomiczny: skoro oszacowanie i tak obłożone jest błędem, nie chcemy, by jego ustalenie było kosztowne i długo trwało.

Co się dzieje, gdy od Zespołu oczekuje się precyzyjnych oszacowań (o ile takie w ogóle kiedykolwiek są możliwe)? Lub gdy Product Owner musi tworzyć prognozy, z których potem jest bardzo bezwzględnie rozliczany i nie może pozwolić sobie na błąd? Zacznie się dekomponowanie wymagań po to, by uzyskać w ten sposób elementy małe, które da się precyzyjniej wyszacować.

Oczywiście jest to przepis na katastrofę. Dochodzi do dramatycznego spuchnięcia Backlogu Produktu (rośnie liczba elementów) i tym samym spadku jego przejrzystości. Mnóstwo pracy poświęcane jest na dekompozycję i szacowanie czegoś, co ma spore szanse nigdy nie być zrealizowane. Nieuchronnie podejmuje się z wyprzedzeniem wiele decyzji – bo przecież dekompozycja często wymaga ustalenia strategii realizacji wymagań – choć nie wiadomo, czy w przyszłości nie okażą się one błędne.

Problem #15: niewłaściwe użycie metody #noestimates

Ten scenariusz czasami wiąże się z niewłaściwym użyciem techniki szacowania #noestimates – niektórzy jej propagatorzy twierdzą, że konieczne jest dzielenie szacowanych elementów na „kawałki równej wielkości”, dzięki czemu „szacowanie nie będzie potrzebne”. Oczywiście to bzdura: ustalanie, czy „kawałki są równej wielkości”, jest przecież szacowaniem (więc wciąż szacujemy), a w technice chodzi o coś zupełnie innego:

  • Szacowane elementy kategoryzowane są na trzy grupy: dostatecznie małe (możliwe do zrealizowania bez podziału), zbyt duże (wymagające podziału) oraz niezrozumiałe (więc niemożliwe do przypisania do którejkolwiek z kategorii, wymagające dyskusji i dowiedzenia się więcej).
  • Co do zasady realizowane są potem tylko takie elementy, które uznane zostały za dostatecznie małe, więc siłą rzeczy ich wielkość jest do siebie zbliżona.
  • To powoduje, że aby ocenić tempo pracy albo dokonywać prognoz, nie potrzebujemy między tymi elementami wprowadzać rozróżnienia np. poprzez szacowanie na różne wartości dni, godzin czy Story Pointów i z tego wyliczać velocity, ale możemy traktować je ilościowo i wyliczać przepustowość (ang. throughput) – statystycznie będzie to równorzędna informacja.
  • Te elementy, które były za duże, dekomponujemy – wtedy, kiedy ma to sens (nie od razu!).
  • Te elementy, które były niejasne, doprecyzowujemy, aż będzie możliwe ich przypisanie do jednej z kategorii (ale też nie musimy robić tego od razu, jeśli wciąż tkwią gdzieś na dnie Backlogu Produktu).

Technika #noestimates użyta z sensem może uczynić proces szacowania całkiem lekkim, aczkolwiek nie wszędzie będzie efektywna. Czasami Product Owner musi dokonywać bardzo ostrej selekcji, co warto robić, a co usunięte zostanie z Backlogu Produktu i wtedy bardziej różnorodna skala estymat może okazać się niezbędna.

Problem #16: nadmierne skupienie na narzędziach

A jak już piszemy o metodach szacowania, to warto nawiązać do kolejnego błędu popełnianego w ramach Pielęgnacji Backlogu Produktu, czyli nieefektywnego użycia narzędzi. Najczęściej objawia się to na trzy sposoby, nierzadko wszystkie trzy naraz.

Pierwszym jest zastąpienie rozmowy komunikacją poprzez narzędzia. Ktoś pisze wymaganie (najczęściej Product Owner, czasami ktoś na jego zlecenie), po czym odbywa się wymiana komentarzy i uwag – ale nie ma dyskusji bezpośredniej. Ponieważ taki mechanizm wymiany informacji jest podatny na błędy interpretacji, na wszelki wypadek wszyscy starają się pisać dużo i „precyzyjnie”, żeby „wszystko było jasne”.

Efektem nie jest jednak zwykle wzrost przejrzystości informacji, ale jej dramatyczny spadek. Kilkadziesiąt komentarzy i długi na parę stron opis daje poczucie, że niczego nie pominięto. Potem, w czasie realizacji wymagania okazuje się, że w komentarzach kilka razy zadano to samo pytanie, na które nikt nie odpowiedział (i odpowiedź wciąż nie jest znana), a wiele ze wpisów wyklucza się wzajemnie. Czemu nikt tego wcześniej nie wychwycił? Cóż, bo… było tego za dużo, więc nikt nie czytał całości.

Innym objawem tego samego problemu jest dokumentowanie wszystkiego, w tym dyskusji, a nie tylko poczynionych ustaleń. W efekcie ktoś, kto chce zrozumieć, co właściwie ustalono, musi się przebijać przez nieaktualne zapisy. Pół biedy, jak się w tym nie pogubi. Gorzej, jeśli zostanie w ten sposób wprowadzony w błąd, który wyłapany zostanie nie na etapie Pielęgnacji czy w ostateczności Planowania Sprintu, ale już podczas pracy developerkiej (albo wręcz po zakończeniu prac).

Drugim objawem nadmiernego przywiązania do narzędzia jest użycie go do sformalizowania procesu. Narzędzia kuszą możliwością definiowania list kontrolnych, szablonów na różne rzeczy, wiele z nich opiera się o mniej lub bardziej rozbudowane zarządzanie tokiem pracy (ang. workflow).

Łatwo dojść do punktu, gdzie Zespół, zamiast skupiać się merytorycznie na dyskusji i zrozumieniu wymagań, zaspokaja wymogi narzędzia. Inaczej mówiąc, nie myśli o tym, co zapisać, ale jak powinno to być zapisane. To podobne nieporozumienie jak z „historyjkami użytkownika”, o którym pisałem wcześniej – skupienie wyłącznie na formacie i formalnych aspektach procesu.

Bywa, że narzędzia wymuszają na Zespole działanie w określony sposób, którego nie da się zmienić, jeśli nie dokona się zmian w samym narzędziu (a Zespół nie zawsze ma do tego prawo w organizacji). Przy czym czasami Zespół sam zastawia na siebie taką pułapkę: w dobrej wierze rozwija jakiś sposób pracy, czyniąc go coraz bardziej rozbudowanym i formalnym, po czym nie potrafi z tego zrezygnować, nawet gdy jasne staje się, że zmiany są konieczne. Dlaczego nie potrafi? Bo za dużo „zainwestował” w wypracowanie takiego sposobu pracy, by teraz z niego łatwo rezygnować.

Jest i trzeci sposób, w jaki narzędzia potrafią szkodzić. Przyjmijmy, że Zespół nie komunikuje się poprzez narzędzia, tylko organizuje spotkania i dyskusja odbywa się bezpośrednio. Przyjmijmy też, że narzędzie nie ma jakichś ograniczeń ani nie wymusza działania w określony sposób. Co wtedy wciąż może pójść nie tak? Może się zdarzyć, że narzędzie stłamsi dynamikę spotkania, jeśli Zespół będzie próbował używać go do dokumentowania wszystkiego na bieżąco w czasie Pielęgnacji.

Jak to wygląda w praktyce? Gdy zakończy się dyskusja, trzeba zapisać ustalenia – ktoś więc rzuca się do klawiatury i tworzy notatkę. Pozostali czekają, aż skończy, często patrząc na pojawiający się na ekranie tekst. Piszący czuje presję, więc się spieszy. Pośpiech powoduje błędy, ktoś tam zaczyna przypominać, że trzeba poprawić literówkę, stres powoduje kolejne błędy… Z efektywnej dyskusji Zespół nieuchronnie przechodzi do oczekiwania, aż jej efekty wtłoczone zostaną w narzędzie.

Jak zrobić to lepiej? Niech ktoś na kartce czy w jakiejkolwiek innej formie robi notatki, może nawet mogą to robić dwie osoby. Na koniec ustalić wystarczy, kto przeniesie te notatki do narzędzia (już po spotkaniu). Okazjonalnie, wyłącznie kluczowe rzeczy, zrobione zostaną w narzędziu na bieżąco. Dzięki temu spotkanie zachowa dynamikę przez cały czas jego trwania, a ustalenia nie umkną.

Jeśli jest obawa, że „sekretarz” coś pominie, wystarczy się umówić na sprawdzenie zapisków przez kogoś innego i ich ewentualne uzupełnienie. Przyjmując, że sesje Pielęgnacji nie są długie (czyli że Zespół nie robi jednej długiej sesji na Sprint), ryzyko „zgubienia” istotnego ustalenia jest zerowe.

Problem #17: Pielęgnacja w czasie Planowania Sprintu

Pisałem wcześniej o Zespołach, które w czasie Pielęgnacji Backlogu Produktu zaczynają w praktyce planować kolejne Sprinty. Zdarza się też coś dokładnie odwrotnego: Zespół nie robi Pielęgnacji w czasie Sprintu w ogóle, a o wymaganiach dyskutuje tylko w czasie Planowania.

Definicja Scruma nie zawiera wymogu Pielęgnacji, więc formalnie to dopuszczalne. Co więcej, w rzadkich sytuacjach może mieć sens – jeśli Scrum użyty jest w środowisku bardzo uporządkowanym i przewidywalnym, albo jeśli Sprinty są ekstremalnie krótkie (np. dwu- lub trzydniowe). W większości przypadków to jednak nie będzie sensowne, co najmniej z trzech powodów.

Pierwszy: Planowanie Sprintu będzie długie, a Zespół może w jego trakcie odkryć, że brak istotnych informacji odnośnie do jakiegoś wymagania. Wciąż może podjąć się jego realizacji, ale będzie ona obłożona sporym ryzykiem niepowodzenia – które być może dałoby się zredukować (albo wyeliminować), gdyby dzień lub dwa przed Planowaniem Sprintu odbyła się Pielęgnacja.

Drugi: tak realizowana Pielęgnacja skupiać się będzie w zasadzie tylko na wymaganiach na szczycie Backlogu Produktu, ale nigdy nie sięgnie niżej – do elementów, które na pewno w bieżącym Sprincie realizowane nie będą. Bardzo ciężko wtedy z wyprzedzeniem zidentyfikować zależności (bo w zasadzie tylko Product Owner będzie analizował całość Backlogu), nagminne też stanie się realizowanie dużych wymagań bez ich dekompozycji – bo nie będzie czasu na jej dokonywanie w trakcie Planowania. Efektem braku dekompozycji może być robienie niepotrzebnych zmian w produkcie – bo nie będzie możliwe oddzielenie tego, co faktycznie niezbędne od tego, co w sumie nie przynosi wartości.

Trzeci powód: Developerzy będą mieć wiedzę jedynie o tym, co znajduje się w górnej części Backlogu, przez co ich zrozumienie odnośnie do tego, czym jest produkt, po co jest budowany, w którą stronę zmierza jego rozwój, będzie ograniczone. Product Owner będzie skazany na zewnętrznych ekspertów, jeśli chodzi o analizę zależności czy ocenę wielkości wymagań. Developerzy zaczną redukować się wtedy do wykonawców cudzych koncepcji i decyzji, a to nie sprzyja zaangażowaniu (podobnie jak szkodliwe dla motywacji jest niezrozumienie samego produktu).

Problem #18: Product Owner jedynym gospodarzem pielęgnacji

Co ciekawe, nawet jeśli Pielęgnacje się odbywają, problem zbliżony do jej braku może wciąż wystąpić. Dzieje się tak wtedy, gdy Pielęgnacja odpowiada wyłącznie na potrzeby Product Ownera i jest on jej jedynym gospodarzem. Uzyska od Developerów oszacowania, być może dostanie propozycje możliwych sposobów rozwiązania jakiegoś problemu, czy też listę zależności. Jeśli jednak Developerzy nie będą czuli, że Pielęgnacja jest też dla nich (a właściwie przede wszystkim dla nich), i jeśli nie będą się czuli jej gospodarzami (przynajmniej od czasu do czasu) – wtedy i tak na Planowaniu Sprintu będą pojawiać się kłopotliwe pytania.

Inaczej mówiąc, zdarza się, że Pielęgnacja ma na celu tylko wsparcie Product Ownera w zarządzaniu Backlogiem Produktu, ale nie pomaga Developerom w przygotowaniu się do Planowania kolejnego Sprintu.

Sytuacja taka może być związana z nienajlepszymi relacjami w Zespole (np. Developerzy traktują Product Ownera jako klienta, który „zamawia” coś, co oni realizują). Może też wynikać po prostu z niezrozumienia celu Pielęgnacji. Jest nią zarówno udoskonalenie Backlogu Produktu (ustalenie jego zawartości, kolejności, zapewnienie przejrzystości), jak i przygotowanie całego Zespołu do planowania kolejnej iteracji.

To oznacza, że Pielęgnacja może być organizowana przez Developerów również bez udziału Product Ownera, jeśli uznają, że jej potrzebują np. po to, aby porozmawiać z jakimś ekspertem. Dzięki temu przy następnym spotkaniu z Product Ownerem będą mogli zaproponować możliwe warianty rozwiązania jakiejś problematycznej kwestii w produkcie. Przy czym ważne, by nie doszło do „rozklejenia” się Pielęgnacji na dwa procesy: Pielęgnację z Product Ownerem i „pielęgnację techniczną” – bo bardzo szybko okaże się, że procesy te mają rozbieżne cele i generują niedające się użyć spójnie decyzje.

Problem #19: zewnętrzny zespół analityków i ekspertów

Bywa też tak, że Pielęgnacja nie odbywa się w Zespole, a dokładniej odbywa się bez udziału Developerów. Product Owner, zamiast posiłkować się przede wszystkim Developerami, którzy budują produkt, rozmawia wtedy z zewnętrznymi ekspertami i na Planowanie Sprintu przynosi gotowe ustalenia. Nierzadko wręcz powstaje „zespół analityczny” (albo „zespół projektantów”), który ma za zadanie wspierać Product Ownera w tym działaniu. W rzeczywistości to odtworzenie kaskadowego modelu działania, choć często jest zawoalowane w sposób, który pozwala utrzymywać, że to wciąż Scrum.

Nie ma niczego nagannego w tym, że Product Owner korzysta z pracy ekspertów – byleby nie redukowało to Developerów w Zespole Scrumowym do roli wykonawców poczynionych wcześniej ustaleń. I nie chodzi tu wcale o to, że Scrum nie przewiduje takiej możliwości, ani nawet o dramatyczny spadek zaangażowania tak traktowanych Developerów w wykonywaną pracę. Ten „zespół analityczny”, złożony z ekspertów, będzie podejmował z wyprzedzeniem wiele decyzji, będąc kompletnie oderwanym od empirycznych danych. Jakich?

Przede wszystkim nikt lepiej niż Developerzy nie wie, jakie są ich możliwości. Po drugie, analizy czynione z wyprzedzeniem opierać muszą się o założenia czynione na bazie danych zebranych na długo przed podjęciem wymagań do realizacji. Developerzy, którzy nie brali udziału w tych dyskusjach, mogą nie być w stanie zmodyfikować ustaleń tak, by dostosować je skutecznie do aktualnego stanu spraw w momencie realizacji wymagań.

Poza tym taki model współpracy (a raczej „współpracy”) w Zespole będzie powodował oddalanie się Developerów od Product Ownera. Coraz bardziej będzie on dla nich klientem, coraz mniej partnerem. To może spowodować, że niekoniecznie Developerzy ujawnią przed nim wszystkie problemy, na jakie natrafiają w trakcie pracy z produktem (zwłaszcza jeśli związane to będzie np. z brakiem kompetencji).

Ten spadek przejrzystości i zaufania może prowadzić do nieodwracalnych błędów decyzyjnych Product Ownera. Może też prowadzić do nieporozumień przy planowaniu pracy w Sprintach, a nawet błędnej interpretacji wymagań. Skutkiem zaczyna wtedy być wzmożona kontrola ze strony Product Ownera, coraz większy formalizm komunikacji, coraz mniej elastyczny proces, coraz bardziej zachowawcze szacowanie i planowanie ze strony Developerów…

Dlatego, jeśli już korzysta się z ekspertów, którzy nie są częścią Zespołu, powinni oni brać udział w Pielęgnacji również z Developerami, a nie tylko z samym Product Ownerem. Podobnie jak Product Owner powinien móc brać udział w dyskusjach Developerów np. z architektami i ekspertami technicznymi.

Problem #20: bezrefleksyjne kopiowanie praktyk

Opisałem szereg dysfunkcji, które mogą pojawić się w procesie Pielęgnacji Backlogu Produktu. Być może czytelnicy odkryją, że w jednym z punktów (a może wielu) opisałem sposób działania ich Zespołu. Czy to oznacza, że należy natychmiast wprowadzić zmiany? Oczywiście nie, bo moją intencją było opisanie zagrożeń i ewentualnych negatywnych konsekwencji, jakie ten czy inny sposób przeprowadzania Pielęgnacji może przynieść. Każdy Zespół sam musi dokonać oceny, co w jego specyficznym kontekście jest korzystne, a co wymaga zmiany.

I tu dochodzimy do kolejnego z błędów, który popełniają Zespoły. Istnieje wiele poradników i wskazówek, jak Pielęgnacja powinna być przeprowadzana, ale nikt rozsądny nie zaproponował (i zapewne nigdy nie zaproponuje) uniwersalnego, jedynie słusznego sposobu, w jaki nad rozwojem Backlogu Produktu należy pracować. Niestety, nie oznacza to, że takich „uniwersalnych definicji” tego procesu nikt nie stworzył. Jest ich od groma, często wykluczają się wzajemnie, nierzadko ich twórcy są postrzegani jako autorytety – propagując, świadomie lub nie, złe praktyki.

Błędem Zespołu będzie użycie takiej gotowej instrukcji, bez upewnienia się, że ona w ogóle pasuje do tego, jak ten Zespół pracuje i jaki produkt buduje. Błędem też będzie uznanie, że „raz-a-dobrze” można taki proces Pielęgnacji dopracować, i od tego momentu kurczowo się go trzymać. Z upływem czasu zmieniają się potrzeby użytkowników produktu i interesariuszy, a za tym postępuje ewolucja zarówno Backlogu Produktu, jak i procesu jego Pielęgnacji oraz samego Zespołu Scrum.

Błędem Zespołu będzie też rezygnowanie z praktyk tylko dlatego, że jakiś ekspert napisał lub powiedział, że mogą one być problematyczne. Niewykluczone, że ma rację, ale z różnych powodów wyjątkowo, w niektórych Zespołach, te „nienajlepsze” praktyki mogą być całkiem efektywne. Oczywiście sporo zależy od rodzaju problemu, o jakim mowa – bo, przykładowo, robienie kompletnych i bardzo szczegółowych analiz każdego wymagania z wyprzedzeniem wielu miesięcy nie będzie miało sensu niezależnie od sytuacji.

Podsumowując: nie jest złym pomysłem zainspirowanie się takim czy innym „szablonem” Pielęgnacji, ale Zespół powinien mieć intencję wypracowania własnego procesu i jego świadomej ewolucji. Warto też znać słabości i ryzyka związane ze stosowanymi praktykami, ale niekoniecznie od razu trzeba z nich rezygnować, jeśli na razie nie potrafimy zastąpić ich czymkolwiek bardziej efektywnym.

Na zakończenie…

Sporządzona przeze mnie lista błędów, jakie Zespoły popełniają w czasie Pielęgnacji Backlogu Produktu, jest oczywiście niekompletna. Jest też subiektywna, nie każdy zgodzi się z moimi komentarzami. To naturalne i zrozumiałe. Mam wszakże nadzieję, że to, co napisałem, okaże się inspirujące. A także, że podpowiedzi alternatywnych praktyk (będących jakimś sposobem na unikanie problemów), okażą się przydatne.

Zdjęcie: Loan

Leave a Reply

%d bloggers like this: