Antywzorce w Scrumie – czego unikać? Część 5: Doskonalenie Backlogu Produktu

Antywzorce podczas doskonalenia Backlogu SprintuTo ostatnia, piąta część popularnej serii, opisującej najpopularniejsze antywzorce w Scrumie. Poprzednie części dotyczyły Codziennego Scruma, Planowania Sprintu, Przeglądu Sprintu oraz Retrospektywy. Tym razem przyjrzymy się często zaniedbywanej sesji doskonalenia Backlogu Produktu.

Poniżej znajdziecie subiektywne TOP 5 antywzorców dotyczących realizowania procesu pielęgnowania Backlogu Produktu.

Antywzorzec #1: Sesje nie odbywają się

Po czym poznać?

Sesje doskonalenia Backlogu Produktu fizycznie nie zachodzą. Backlog Produktu jest nieprzygotowany do użycia przez Zespół Deweloperski i nie odzwierciedla bieżących potrzeb produktowych. Elementy Backlogu Produktu nie są jasne dla interesariuszy oraz Zespołu Deweloperskiego. Zespół Deweloperski często zgłasza braki dotyczące wiedzy produktowej.

Jakie są konsekwencje?

Planowanie Sprintu jest utrudnione lub przedłuża się ze względu na konieczność poświęcenia czasu na zrozumienie przez zespół elementów Backlogu Produktu. W trakcie Sprintu pojawia się wiele pytań oraz wątpliwości ze strony zespołu. Deweloperzy nie mają jasnego obrazu, jaki jest plan rozwoju produktu. Stabilne tempo pracy zespołu jest zagrożone, co może powodować demotywację w zespole. Planowanie rozwoju produktu od strony technicznej jest mocno utrudnione, ponieważ Zespół Deweloperski nie wie, jakie są przewidziane dalsze kroki rozwoju produktu.

Co można zrobić inaczej?

Wytłumacz ryzyka związane z brakiem sesji Doskonalenia Backlogu Produktu

Powodów, dla których sesje doskonalenia Backlogu Produktu nie odbywają się, może być całkiem sporo – braki w wiedzy, błędne zrozumienie czym jest agile, czy po prostu kiepska organizacja pracy. A to tylko niektóre z nich.

Niezależnie od powodów, warto mieć świadomość potencjalnych problemów, które mogą pojawić się, jeśli ostatecznie nie zdecydujemy się na regularne doskonalenie Backlogu Produktu. Poniżej kilka z nich:

  • brak zaangażowania w Zespole Deweloperskim – jeżeli Zespół Deweloperski nie otrzyma szansy na lepsze zrozumienie produktu, trudno oczekiwać, że będzie zaangażowany w jego rozwój,
  • brak samodzielności Zespołu Deweloperskiego – jeżeli Właściciel Produktu jest jedyną osobą, która zna kierunek rozwoju produkt, to mogą się pojawić spore kłopoty w sytuacji, w której uda się na urlop lub na dłuższy czas zachoruje,
  • brak wizji rozwoju produktu w Zespole Deweloperskim – zespół najczęściej chce wiedzieć, nad czym będzie pracował w kolejnym Sprincie. Chce także orientować się – chociaż oczywiście na nieco mniejszym poziomie szczegółowości – nad czym będzie pracował w kolejnych Sprintach,
  • obniżona prędkości zespołu – braki w wiedzy produktowej mogą mieć wpływ na prędkość prac zespołu. Może to być skutkiem błądzenia, szukania odpowiedzi, nieefektywnej komunikacji oraz błędnego implementowania funkcjonalności zbudowanych na bazie szczątkowej wiedzy,
  • demotywacja zespołu – powtarzające się problemy w zespole, wynikające ze słabego zrozumienia potrzeb produktowych, łatwo mogą zamienić się w narastającą frustrację, a w konsekwencji w trudno odwracalną demotywację zespołu,
  • słabej jakości architektura – zaniedbanie bieżącego doskonalenia Backlogu Produktu może spowodować utratę z pola widzenia całościowego wyglądu produktu od strony architektury. Może mieć wpłynąć negatywnie na jej kształt, a w konsekwencji doprowadzić do kumulowania się długu technologicznego, utrudniającego w przyszłości sprawną rozbudowę produktu.
  • niespełnione oczekiwania interesariuszy – sesje doskonalenia Backlogu Produktu to okazja, aby Zespół Deweloperski komunikował się z interesariuszami. Brak regularnego dialogu może prowadzić do tworzenia przez zespół kiepskich lub wręcz w skrajnym przypadku niepotrzebnych funkcjonalności.

Antywzorzec #2: Właściciel Produktu nie jest przygotowany

Po czym poznać?

Właściciel Produktu nie zna odpowiedzi na pytania padające ze strony Zespołu Deweloperskiego. Omawianie elementów Backlogu Produktu jest przeprowadzane w sposób chaotyczny.

Jakie są konsekwencje?

Zespół Scrumowy traci czas na nieefektywnym spotkaniu. Sesje doskonalenia Backlogu Produktu mogą zacząć kojarzyć się ze zwykłą stratą czasu, przez co Zespół Deweloperski przestaje widzieć w nich sens. Wzrasta ryzyko związane z pracą w Sprincie, ze względu na kiepskie przygotowanie elementów Backlogu Produktu. W konsekwencji oczekiwania interesariuszy mogą nie zostać spełnione.

Co można zrobić inaczej?

Przygotuj się do sesji doskonalenia Backlogu Produktu

Jak do każdego spotkania, do doskonalenia Backlogu Produktu warto się przygotować. Poniżej kilka obszarów, które warto przemyśleć z perspektywy Właściciela Produktu przed sesją, aby zapewnić efektywny przebieg spotkania:

  • zakres działań – które elementy będziemy omawiać? Czy będziemy omawiać elementy nieco ogólniej, jednak w dłuższej perspektywie, czy może nieco dokładniej, zawężając jednak ich ilość?
  • wiedza zespołu – czy Zespół Deweloperski wie, o których elementach będziemy rozmawiać? Czy potrzebuje czasu, aby się przygotować do dyskusji?
  • skład osobowy spotkania – kto powinien pojawić się na spotkaniu? Czy jest ktoś, kogo będziemy szczególnie potrzebować, aby omówić temat, który jest dla nas nieznany? Może warto zaprosić któregoś z interesariuszy?
  • termin spotkania – czy wszystkie niezbędne osoby mogą pojawić się na najbliższej sesji? Czy istnieją alternatywne terminy, w których możemy zapewnić wymagany skład na spotkanie?
  • wizja produktu – czy Zespół Deweloperski zna i wykorzystuje w praktyce wiedzę dotyczącą wizji produktu? W jaki sposób można nawiązać do wizji podczas spotkania?

Antywzorzec #3: Zespół Deweloperski nie jest przygotowany

Po czym poznać?

Zespół Deweloperski nie jest w stanie aktywnie uczestniczyć w dyskusji na temat elementów Backlogu Produktu. Często z ust Deweloperów padają słowa takie jak “nie wiem”, “musiałbym sprawdzić” lub też “to zależy”.

Jakie są konsekwencje?

Spotkanie może okazać się stratą czasu. Pojawia się ryzyko, że wybrane funkcjonalności zostaną dostarczone później, ze względu konieczność przełożenia dyskusji na późniejszy termin.

Co można zrobić inaczej?

Zaplanuj z wyprzedzeniem elementy do omówienia

Zdarza się, że Zespół Deweloperski potrzebuje czasu, aby zapoznać się z wybranymi elementami Backlogu Produktu. Czas ten może zależeć od doświadczenia zespołu, złożoności technicznej, ilości zaciągniętego długu technologicznego, czy też od skomplikowania produktu. Warto poinformować zespół z wyprzedzeniem, o których elementach Backlogu Produktu planujemy rozmawiać podczas nadchodzącej sesji doskonalenia Backlogu Produktu. Wystarczy nawiązać do tego słownie w trakcie zwykłej rozmowy lub zaktualizować treść zaproszenia na spotkanie.

Ustal, kto co przygotuje

Pewnego rodzaju rozwinięciem powyższego pomysłu jest umówienie się wewnątrz w Zespołu Deweloperskiego, kto rozpozna które elementy Backlogu Produktu. W takim przypadku, wybrana (lub wybrane) osoba w trakcie Sprintu rozpoznaje jeden (lub więcej) konkretny element i przygotowana pojawia się na sesji doskonalenia Backlogu Produktu, aby podzielić się z resztą zespołu tym, co udało się jej ustalić. Następnie Zespół Deweloperski jako całość toczy dalszą rozmowę na temat konkretnego elementu, będąc już bogatszym o pewną podstawową wiedzę, niezbędną, aby ruszyć dalej.

Antywzorzec #4: Tylko Właściciel Produktu aktualizuje Backlog Produktu

Po czym poznać?

Właściciel Produktu spisuje wszystkie elementy Backlogu Produktu. Nikt inny fizycznie nie modyfikuje, dodaje oraz usuwa elementów Backlogu Produktu. Zespół Deweloperski nie najlepiej orientuje się, co znajduje się w Backlogu Produktu.

Jakie są konsekwencje?

Rodzi się poczucie, że Właściciel Produktu to {jedyna osoba odpowiedzialna} za Backlog Produktu. Zaangażowanie w produkt w Zespół Deweloperski może nie wykształcić się.

Co można zrobić inaczej?

Zaangażuj Zespół Deweloperski w pracę z Backlogiem Produktu

Niezależnie od tego, w jakiej formie utrzymywany jest Backlog Produktu (fizycznej czy elektronicznej), każda osoba z Zespołu Deweloperskiego może go aktualizować. Przykładowo, podczas sesji doskonalenia Backlogu Produktu dowolny członek Zespołu Deweloperskiego może być osobą, która dodaje bądź rozbudowuje opis wybranej funkcjonalności. Inny przykład: podczas Przeglądu Sprintu ktoś inny niż Właściciel Produktu może dodać element do Backlogu Produktu, który właśnie wyłonił się na skutek dyskusji z interesariuszami.

Zespoły Deweloperskie często decydują się na przechodnią obsługę Backlogu Produktu – zmieniają się co jeden element lub decydują się na zmianę per Zdarzenie Scrumowe. Przykładowo, podczas sesji doskonalenia Backlogu Produktu, każdy omawiany element jest aktualizowany przez inną osobę. W drugim z wymienionych wariantów, jedna osoba aktualizuje elementy Backlogu Produktu przez całe spotkanie, a podczas kolejnej sesji, robi to ktoś inny.

Antywzorzec #5: Skryba wąskim gardłem

Po czym poznać?

Cały zespół siedzi wpatrzony w narzędzie elektroniczne (np. JIRA, Trello itp.) Dynamika spotkania jest słaba. Wszyscy patrzą w jeden ekran, jedna osoba “na żywo” notuje treść rozmowy w odpowiednim miejscu w narzędziu elektronicznym. Reszta uczestników czeka, aż skryba przestanie pisać, aby kontynuować dyskusję.

Jakie są konsekwencje?

Potencjał grupy nie jest wykorzystywany. Skryba staje się wąskim gardłem, natomiast w zespole narasta uczucie znudzenia, które szybko zamienia się w ogólne zmęczenie i brak zaangażowania.

Co można zrobić inaczej?

Podziel zespół na grupy

Podział zespołu na co najmniej dwie grupy pozwala na równoległą pracę nad dwoma lub większą ilością wątków. Każda grupa może przygotowywać ten sam element Backlogu Produktu lub mogą to być różne elementy. Bez względu na wybór metody, po spędzeniu określonej wcześniej ilości czasu nad danym elementem, grupy synchronizują się, budując wspólne zrozumienie funkcjonalności, wzajemnie uzupełniając się wiedzą.

Pracuj na kartkach, później przepisz do narzędzia online

Zwiększenie dynamiki spotkania można uzyskać rezygnując tymczasowo z pracy z narzędziem elektronicznym. Zamiast tego można wykorzystać tablicę suchościeralną lub zwykłe kartki, co najczęściej pozwala użycie nie tylko słów, ale również prostych rysunków oraz szkiców. Tego rodzaju aktywności lepiej angażują grupę niż statyczna obserwacja procesu notowania w narzędziu elektronicznym. Pozwala również na częstą zmianę osoby, która w danym momencie notuje lub rysuje na tablicy. Na koniec spotkania lub nawet po jego skończeniu, można przenieść wyprodukowaną treść (np. notatki, szkice, zdjęcia tablicy suchościeralnej) do narzędzia elektronicznego, tak aby zapewnić dostęp do informacji dla osób znajdujących się w innych lokalizacjach.

Podsumowanie

Doskonalenie Backlogu Produktu to bardzo często pomijana przez Zespoły Scrumowe aktywność w Scrumie. Jej brak bardzo szybko daje o sobie znać, m.in. pod postacią przedłużających się sesji planowania, braku jasności co do kierunku rozwoju produktu oraz zbyt dużych elementów branych przez zespół na Sprint. Jakie inne przeszkody stoją na drodze do udanych sesji doskonalenia Backlogu Produktu? Koniecznie podzielcie się w komentarzach.

Chcesz przeczytać więcej?

Powyższy artykuł to mały wycinek mojej książki „Labirynty Scruma”, której premierę planuję po wakacjach 2017 roku. Opisuję w niej sprawdzone, praktyczne sposoby na najczęstsze pułapki w Scrumie. Zapisz się na mój newsletter – dla subskrybentów planuję przedpremierowy fragment książki oraz dodatkowe materiały.

Komentarze do wpisu: “Antywzorce w Scrumie – czego unikać? Część 5: Doskonalenie Backlogu Produktu

  1. Przy tym antywzorcu zdecydowanie widziałbym przesadny „Gold plating” backlogu… Często na wyrost, bez posiadania pełnego obrazu staramy się wygenerować elementy backlogu do przodu. Jakie są tego skutki? Zmarnowaliśmy czas na coś, co nie zostało/nie zostanie użyte. W tym wypadku bardzo podoba mi się podejście leanowe – decyduj dopiero wtedy, kiedy to konieczne.

    • Jacek Wieczorek

      Dzięki MW za komentarz. Pełna zgoda – nie przygotowujmy zbyt mało w przód (wiemy niewystarczająco), ale też nie zbyt dużo (potencjalne marnotrastwo). Jak zwykle wygrywa zdrowy rozsądek oraz nauka na własnych doświadczeniach.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x