Niedawno na szkoleniu dostałem takie pytanie: „Zostałem nowym Product Ownerem i odziedziczyłem olbrzymi Backlog. Od czego powinienem zacząć?”
Odpowiedziałem: „Nie znam Twojego kontekstu, ale ja bym zaczął od wyrzucania całego Backlogu i zapytania 'jaka jest jedna, najważniejsza rzecz, na której powinniśmy się skupić?’ A następnie poprosił zespół, żeby się za nią zabrał. Przy czym tą rzeczą nie powinien być ficzer, a impakt, który chcemy odnieść.”
Umieszczenie tej krótkiej wymiany zdań na LinkedIn doprowadziło do bardzo fajnej dyskusji. Część ludzi pisała, że to fantastyczny pomysł i stary Backlog powinno się wywalić, a najlepiej do tego spalić. Inni zwrócili uwagę, że takie podejście oznacza zaczynanie współpracy od konfrontacji, brak szacunku dla ludzi, który tworzyli ten Backlog i pozbywanie się wiedzy, która została wypracowana przez organizację.
Oczywiście nie ma jednego, słusznego podejścia i podejmując decyzję musisz uwzględnić wiele czynników, takich jak kulturę organizacji, czy Twoje umocowanie jako Product Ownera. Dlatego też zacząłem moją wypowiedź od zdania „nie znam Twojego kontekstu”. Ponieważ jednak duże Backlogi są zmorą wielu firm, a LinkedIn nie jest dobrym medium do umieszczania rozbudowanych przemyśleń, postanowiłem na blogu zebrać negatywne konsekwencje dużego Backlogu i możliwe podejścia do zarządzania nim.
Trzy negatywne konsekwencje dużych Backlogów
Zacznijmy w takim razie od głównych powodów, dla których sugeruję unikanie dużych Backlogów.
1. Backlog to Strata
Taiichi Ohno, twórca Systemu Produkcyjnego Toyoty, nazywał wszystko, co nie przynosi wartości z perspektywy klienta „stratą”. Jeden z głównych rodzajów strat to „zapasy”, czyli wszystkie elementy, nad którymi rozpoczęliśmy, ale nie ukończyliśmy pracy. Z punktu widzenia księgowości, te półprodukty są traktowane jako „aktywa”. Jednak w rzeczywistości, pomimo, że zainwestowaliśmy w nie czas i pieniądze, to nie mamy z nich żadnego zysku. Podobnie w tworzeniu oprogramowania, wszystkie funkcjonalności, nad którymi zaczęliśmy pracować nie mają wartości do momentu dostarczenia ich użytkownikowi. Czyli wszystko co wylądowało w Backlogu jest stratą do momentu, aż nie zostanie zaimplementowane i wdrożone na produkcji. Co więcej, na zmieniającym się rynku nasze pomysły bardzo szybko się dewaluują i fantastyczne wczorajsze rozwiązania czekające w Backlogu mogą już dzisiaj nie przynieść zysku. Dodatkowo, wiedza jest ulotna, więc za każdym razem przeglądając Backlog musimy sobie przypominać „co autor miał na myśli”, czyli co i jak chcemy danym pomysłem osiągnąć. Na koniec wreszcie, porządkowanie Backlogu składającego się z kilkuset elementów to żmudna praca i najczęściej oznacza, że Product Owner nie ma czasu na inne zajęcia, takie jak kontakt z użytkownikami, interesariuszami i zespołem.
Jednak inwestycja poniesiona w stworzenie Backlogu zwykle generuje silny związek emocjonalny twórcy z dziełem. Dlatego tak ciężko jest wyrzucić, to co już stworzyliśmy, nawet jeżeli wiemy, że do momentu dostarczenia działającego rozwiązania użytkownikowi nie daje żadnego zysku. Znamy zresztą tą sytuację ze strychów, piwnic i szuflad na „przydasie”, gdzie lądują różne wihajstry, których szkoda jeszcze wyrzucić. Tylko, że znalezienie czegokolwiek istotnego w takim miejscu jest niezwykle trudne i czasochłonne. I oczywiście możemy przy okazji świąt przejrzeć całość i wyrzucić to, co jest zbędne, ale odpowiedz sobie szczerze, ile rzeczy dalej tam zostanie. Czy w takiej sytuacji wyrzucenie wszystkiego na zewnątrz szuflady i włożenie z powrotem tych rzeczy, co do których jesteśmy przekonani, że są naprawdę niezbędne, nie przyniesie lepszych rezultatów?
Jeden z Certyfikowanych Trenerów Scruma, Henrik Kniberg opowiadał kiedyś historię firmy tworzącej gry, której kolejne produkty pojawiały się na rynku za późno. Po przeanalizowaniu czasu od pomysłu do dostarczenia, okazało się, że implementacja nie trwa jakoś specjalnie długo, ale większość gier czeka pół roku w Backlogu na rozpoczęcie nad nimi prac. Całkowite wyeliminowanie Backlogu i przejście na model – albo pracujemy nad tą grą teraz, albo wcale, skróciło czas dostarczenia kolejnych gier o pół roku i rozwiązało problem.
2. Duży Backlog utrudnia ustalenie priorytetów
Jeżeli porządkowanie dużego Backlogu może być uciążliwe, to co powiedzieć o podejmowaniu decyzji co jest najważniejsze. Duży Backlog oznacza dużo opcji i dużo zaangażowanych interesariuszy. A każda decyzja na temat priorytetów jest emocjonalna i polityczna. Dlatego im większy Backlog tym więcej dyskusji, spotkań, i analiz w celu przekonania reszty organizacji do naszych racji. Szansa na podjęcie szybkiej decyzji znacząco się zmniejsza wraz z wielkością Backlogu. Tym samym skrócenie Backlogu zwiększa szansę, że organizacja skupi się nad tym, co w danym momencie jest najważniejsze.
3. Duży Backlog utrudnia re-priorytetyzację
Jeżeli proces podjęcia decyzji na temat priorytetów jest tak bolesny, to jak chętni będą wszyscy interesariusze, żeby wrócić do tej rozmowy, gdy pojawią się informacje sugerujące, że trzeba zmienić priorytety. „Nie każ nam tego przechodzić jeszcze raz” to dość popularna reakcja, jeżeli w firmie ustalenie co jest w dany momencie ważne wymaga gigantycznej ilości energii i czasu. Dlatego interesariusze będą unikać zmiany raz podjętej decyzji. W takich organizacjach zamiast reguły „inspect and adapt” stosuje się podejście „inspect and accept”, czyli wiemy, że to co robimy nie ma sensu, ale tak ustaliliśmy pół roku temu i nie będziemy tego zmieniać, tylko dlatego, że mamy nowe dane. Mniejszy Backlog zwykle oznacza łatwiejszy sposób podejmowania decyzji, a więc większą szansę, że uda się ją zmienić, jeżeli pojawi się taka potrzeba.
Trzy techniki na pracę z dużym Backlogiem
Jeżeli jednak wyrzucenie całego Backlogu może oznaczać koniec Twojej kariery jako Product Ownera, to mam dla Ciebie trzy sugestie.
1. Sprawdzaj termin ważności
Duży Backlog jest jak pełna lodówka. Być może masz w niej cenne rzeczy, które szkoda wyrzucić, jednak z dużym prawdopodobieństwem, za słoikami z przetworami zeszłoroczna kiełbasa powoli zmienia kolor. Dlatego warto wprowadzić termin ważności dla elementów w Backlogu i usuwać te, których spędziły w nim zbyt dużo czasu. To oczywiście dalej będzie powodowało krzyki w organizacji, że te pomysły są ważne i nie można ich wyrzucić. Na pewno są, ale jeżeli nie zabraliście się za ich realizację przez rok, to pewnie inne inicjatywy są ważniejsze. Oczywiście, tak jak w przypadku zawartości lodówki, różne rodzaje zgłoszeń mogą mieć inny termin ważności i na przykład zmiany wynikające z przepisów prawnych raczej nie usuwaj zbyt szybko.
2. Grupuj wiele elementów
Jeżeli utknąłeś w projekcie typu „stały zakres” (piszę w cudzysłowie, bo zakres nigdy nie jest stały), to wyrzucenie części elementów może okazać się dość niefortunne. W tym przypadku postaraj się zrobić pogrupować tematy, których nie będziecie implementować w najbliższej przyszłości – na przykład raporty. Dopiero, gdy będzie się zbliżać czas na ich realizację, powoli wyjmuj z takiego worka kolejne elementy. Zakres będzie taki sam, ale łatwiej Ci będzie poruszać się po Backlogu. Uchroni Was to również przed nadmiernym analizowaniem daleko do przodu i pozwoli skupić się na iteracyjnym dostarczaniu wartości.
Podobne rozwiązanie możesz zastosować, kiedy w Twoim Backlogu kłębią się błędy i zgłoszenia od klientów. Połącz je w tematy i atakuj grupowo. W tym jednak przypadku musisz zwrócić uwagę na spłatę długu technicznego, aby za chwilę nie wrócić do początkowej sytuacji. Najprościej to zrobić poprawiając Definicję Ukończenia (Definition-of-Done), rozszerzając ją o automatyczne testy i refaktoring kodu.
3. Opisuj cele, nie funkcjonalności
Ostatnią techniką pomagającą Product Ownerowi opanowanie dużego Backlogu jest opisywanie celów, które się chce osiągnąć, zamiast funkcjonalności, którą planuje się zaimplementować. Po pierwsze, ułatwia to grupowanie elementów (patrz powyżej) dotyczących tego samego celu, po drugie, zachęca do przeanalizowania alternatywnych rozwiązań, być może nawet niedostępnych w trakcie definiowania danego celu, i po trzecie wreszcie, pozwala prowadzić rozmowę na temat tego, czy cel ma jeszcze sens, a nie czy to dobry moment na implementacje.
Takie cele są zwykle duże i wymagają więcej pracy. Dlatego jeżeli będziesz miał ich kilkadziesiąt, to łatwiej Ci będzie przeprowadzić dyskusję w temacie „czy aby na pewno wszystkie są ważne i wszystkie chcemy osiągnąć”.
Co zrobiłby zarząd?
Na koniec warto zacytować słynną wymianę zdań pomiędzy współzałożycielami Intela, Andym Grove i Gordonem Moore. Ich firma zdobyła rozgłos produkując układy pamięci, jednak odczuwała coraz większą presję ze strony tańszych producentów z Azji. Wszyscy długo analizowali co w takiej sytuacji zrobić, aż pewnego dnia Andy zwrócił się do Gordona z pytaniem „Jeśli zostalibyśmy wyrzuceni z firmy, to jak myślisz, co zrobiłby nowy prezes?”. Moore bez wahania odpowiedział „Wyprowadziłby tą firmę z rynku pamięci”. Grove popatrzył na niego i stwierdził „Dlaczego nie mielibyśmy wyjść przez te drzwi, a następnie wrócić i zrobić to sami?”. Podobno klienci skwitowali tą decyzję zdawkowym „ale długo Wam to zajęło”.
