Porządny Refinement Backlogu Produktu

Czym jest Refinement Backlogu Produktu i jak go realizować w zespole, aby uzyskać jak najlepsze efekty? Dlaczego warto przeprowadzać proces doskonalenia Backlogu Produktu, zwany potocznie refinementem lub groomingiem? Jak często pracować nad Backlogiem Produktu, w jakim składzie oraz po jakie konkretne sposoby realizacji tego procesu sięgać? Poznaj nasze wskazówki i dobre praktyki. Całość podsumowujemy kilkoma praktycznymi poradami na bazie naszych własnych doświadczeń w pracy z zespołami.

Jakie wątki poruszamy w tym materiale?

Czym jest Refinement Backlogu?

„Przewodnik po Scrumie” Refinement Backlogu Produktu definiuje jako proces dodawania elementów Backlogu produktu, uszczegółowienia ich i wyceniania oraz szeregowania rzeczy, które w Backlogu już się znajdują. Natomiast odchodząc trochę od definicji słownikowej, możemy powiedzieć, że Refinement Backlogu Produktu to po prostu proces tworzenia, rozbudowywania i ciągłego pielęgnowania Backlogu produktu. 

Możesz spotkać się też ze starym określeniem na Refinement Backlogu Produktu – Grooming. Ta nazwa została oficjalnie wycofana przez twórców „Przewodnika po Scrumie”, więc wspominamy o niej tylko informacyjnie.

Zwróć uwagę, że Refinement Backlogu jest procesem. Oznacza to, że jest to coś ciągłego, coś co się nie kończy. Zespół w kolejnych Sprintach rozbudowuje lub rozwija Backlog Produktu. Ponadto świadomie w Scrumie nie jest dodefiniowanie, w jakiej formie ma się odbywać. Refinement Backlogu może mieć format spotkania, warsztatu, pracy indywidualnej i wielu innych czynności. Dlatego w praktyce Refinement Backlogu może wyglądać różnie w w zależności od specyfiki i przyzwyczajeń danego zespołu. 

Niestety z uwagi na wspomniany brak dodefiniowania, w wielu zespołach, z którymi mamy do czynienia, proces Refinementu sprawia kłopot. Nie pomaga też mit panujący w niektórych firmach, że „skoro pracujemy zwinnie, to po prostu siadamy i działamy”. Osoby działające z takim założeniem przyjmują, że dopiero w trakcie pracy wyjdzie co tak naprawdę jest do zrobienia. W najgorszej interpretacji tego nastawienia proces pracy z Backlogiem Produktu w ogóle nie zachodzi. Pierwszy moment, w którym zespół zaczyna się zastanawiać, co tak naprawdę jest w tym Backlogu, to etap Planowania Sprintu. W efekcie czas, który Zespół Scrumowy powinien przeznaczyć na zaplanowanie prac na Sprint, przeznacza w całości na nadrobienie Refinementu. Członkowie Zespołu dogadują się, o co tak naprawdę chodzi w pracy, która jest w Backlogu. Czasu na zaplanowanie Sprintu już najczęściej nie ma, przez co Sprinty kończą się kiepsko. 

A przecież zazwyczaj wystarczy tylko kilka godzin w skali tygodnia, aby spojrzeć w Backlog Produktu i zastanowić się, co jest do zrobienia i dlaczego jest to ważne.

Spotykamy też zespoły, które nawet na Planowaniu Sprintu nie robią Refinementu. To już proszenie się o katastrofę, ponieważ wtedy członkowie Zespołu nie rozumieją rozumieją, po co coś robią, albo nie rozumieją potrzeby klienta. W rezultacie, na Przeglądzie Sprintu może się okazać, że dumnie prezentowany wynik prac jest kompletnie czym innym niż to, co było faktycznie potrzebne.

Kolejnym ważnym aspektem regularnego prowadzenia Refinementu w zespole jest umożliwienie zespołowi współtworzenia produktu. Zespół ma wtedy okazję nie tylko wysłuchać Właściciela Produktu i usłyszeć co jest do zrealizowania. Dzięki zaangażowaniu się w proces tworzenia produktu Zespół może się zastanowić, jakie rozwiązania są możliwe. Ma szansę pomyśleć, jaki jest koszt różnych opcji rozwiązań. Ważnym krokiem może być też zdefiniowanie tego, jakie są kryteria akceptacji.

Osobiście widzimy, że zespoły, które samodzielnie odpowiadają za tworzenie i pielęgnację Backlogu produktu funkcjonują zupełnie inaczej. Są wyraźnie lepsze pod wieloma względami od zespołów, które dostają bardzo dokładnie rozpisane zadania od Product Ownera. U tych drugich zespołów brak jest współtworzenia i brania odpowiedzialności za kształtowanie produktu.

Refinement Backlogu to również okazja do tego, żeby oddzielić potrzebę od możliwego rozwiązania. Użyjmy prostego przykładu z realiów rozwoju produktu cyfrowego. Product Owner mówi do Zespołu: „Zróbcie mi wyszukiwarkę na liście klientów”. Jeśli zlecający umie wyrazić swoją potrzebę przez pryzmat szczegółowego rozwiązania, pojawia się złudzenie oszczędności czasu. Zespół może natychmiast zabrać się do przygotowania żądanej wyszukiwarki. W efekcie jednak praca zajmuje np. 10 Sprintów, bo członkowie Zespołu od razu założyli realizację konkretnej funkcji. Zamiast tego mogli poszukać jakichś sprytnych rozwiązań, które w jeden lub kilka Sprintów załatwiają temat i zaspokajają albo całą potrzebę, albo znaczną jej część. Zespół ze wspomnianego przykładu nie przeanalizował innych opcji niż wyszukiwarka, ponieważ nie analizował przyczyn, dla którego jest ona oczekiwana. Nie pojawiła się okazja przepracowania i zrozumienia potrzeby, jaką faktycznie miał zgłaszający. Być może rozwiązaniem równie dobrym (a jednocześnie tańszym) byłaby możliwość sortowania, filtrowania albo wygodnego grupowania listy klientów.

Prawdę mówiąc, nie znamy zespołu, który nie potrzebowałby Refinementu w ogóle. Nawet jeśli faktycznie dany Zespół realizuje jakąś inicjatywę dłuższy czas, to nadal jakaś forma uporządkowania, poukładania, podzielenia i wycenienia elementów Backlogu Produktu jest potrzebna. Choćby po to, aby Planowanie Sprintu było bardzo sprawne. Jeśli zespół twierdzi, że wcale nie potrzebuje jakiejś odmiany procesu Refinementu, nasuwa się pytanie, czy oni w ogóle są zwinnym zespołem? W jakim stopniu współpracują, jak zdefiniowany jest produkt, który rozwijają? Czy produkt jest rozwijany przyrostowo? Być może pod fasadą Scruma realizowany jest w takim zespole długofalowy projekt, realizowany kaskadowo.

Ile czasu należy przeznaczyć na proces Refinementu?

„Scrum Guide” kiedyś mówił, że Zespół powinien przeznaczyć ok. 10% czasu Sprintu na Refinement Backlogu Produktu. Obecnie ta wytyczna zniknęła po najnowszej aktualizacji Przewodnika po Scrumie. W praktyce to, ile czasu Zespół poświęca na Refinement Backlogu, może zależeć bardzo mocno od złożoności i innowacyjności produktu. Wpływ na potrzebny czas na Refinement Backlogu może mieć też to, jak różnorodne wymagania wzajemnie się na siebie nakładają i ile ich pojawia się jednocześnie. 

Warto wspomniane 10% traktować jako średnią w dłuższym okresie. Jeśli Zespół podejmuje na Refinement Backlogu większy epic, inicjatywę lub projekt, może potrzebować w danym Sprincie więcej czasu na te aktywności. Cały Zespół analizuje coś, co jest nowe i duże, potrzebuje się wgryźć w temat. Być może członkowie zespołu muszą zacząć od poznania użytkownika i jego potrzeby lub porozmawiać z interesariuszami. Refinement Backlogu dla takiego przypadku może „zjeść” trochę więcej czasu w tym Sprincie, żeby płynnie przejść do dostarczania kolejnych przyrostów w jak najszybszym tempie w nadchodzących Sprintach.

Można powiedzieć, że czas poświęcany na Refinement Backlogu jest zwykle większy na początku. Im bardziej zespół zna produkt, im lepiej rozumie się z Product Ownerem, im bardziej zna stakeholderów, tym czasu na Refinement Backlogu może potrzebować mniej. Dla tygodniowego Sprintu 10% ze wspomnianej wcześniej wytycznej oznacza mniej więcej 3,5 godziny pracy zespołu.

Natomiast zespół, który nigdy nie robił Refinementu, nie zna produktu, ma silne silosy wewnętrzne, może potrzebować więcej czasu na ten proces. Refinement Backlogu w takim Zespole może przyjąć postać całodniowych warsztatów, gdzie uczestnicy próbują zrozumieć, co jest do zrobienia i jak mogą potrzebny produkt wytworzyć.

Jak realizować Refinement Backlogu w zespole?

Jednym z najbardziej popularnych sposób na przeprowadzanie Refinementu jest spotkanie warsztatowe całego zespołu. Zespół zapoznaje się z tym, co jest na to spotkanie zaproponowane, najczęściej przez Product Ownera. Na spotkaniu członkowie zespołu rozmawiają o tym, jak to rozumieją i rozbijają Backlog na mniejsze elementy. Wynikiem całej dyskusji jest zebranie przygotowanych elementów Backlogu Produktu. Oprócz tego zapisem warsztatów jest różnej formy notatka czy wizualizacja, np. procesu, wizji produktu czy planu działania nad kolejnymi przyrostami. 

Tego typu warsztatowa forma ma swoje ograniczenia i wady. Im  większy zespół, tym trudniej utrzymać uwagę i energię na dłuższych spotkaniach. Stąd też realizowane są alternatywne sposoby przeprowadzania Refinementu.

Podziel duży zespół na podgrupy warsztatowe

Duże zespoły, np. dwunastoosobowe, są dzielone na grupy (np. na dwie grupy sześcioosobowe) i powstają mniejsze podzespoły.

W jednym z podejść wszystkie grupy dostaję te same tematy do przepracowania. Po ustalonym czasie, grupy te spotykają się, prezentują swoje wyniki i porównują je. Wspólne omówienie może prowadzić do powstania kolejnych wniosków i pomysłów. 

Inne podejście polega na tym, że grupy otrzymują zupełnie inne elementy Backlogu Produktu. Przykładowo: pierwsze trzy elementy wędrują do grupy pierwszej, kolejny trzy do grupy drugiej. Grupy pracują osobno nad tymi elementami, a po ustalonym czasie dzielą się między sobą efektami pracy. Jest tu też oczywiście przestrzeń na to, aby grupa, która nie pracowała nad konkretnymi elementami, mogła wnieść swoje uwagi, przemyślenia lub zastrzeżenia.

Modyfikacją tego podejścia jest forma inspirowana ze Strategii Disneya z wykorzystaniem technik kreatywnych. Jedna grupa przepracowuje przydzielone do niej elementy Backlogu i zapisuje efekty tej pracy, po czym przekazuje je do drugiej grupy. Druga grupa pracuje nad tym, co wytworzyli poprzednicy, ale ich zadaniem jest poprawienie, skrytykowanie lub znalezienie jakiegoś problemu. Takie krytyczne nastawienie może doprowadzić do znacznego usprawnienia opisu elementów Backlogu. 

Ostatecznie, dzięki podziałowi na podgrupy (według dowolnego wzorca), przepracowanie jest efektem całej grupy, ale niekoniecznie działającej jednocześnie. Technika ta usprawnia podejście pracy całego zespołu, ponieważ praca odbywa się w sposób równoległy. Dodatkowym plusem jest to, że w mniejszych grupach trochę prościej o aktywizację wszystkich uczestników. 

Tworząc takie podgrupy, zadbaj o to, by stworzyć je w sposób najbardziej różnorodny pod kątem kompetencji. To pozwoli spojrzeć na konkretny problem z jak najróżniejszych perspektyw.

Działaj w innych formach niż tylko warsztatowe

Praca w grupach nie musi sprawdzać się tylko na spotkaniach całego zespołu. Refinement Backlogu Produktu może odbywać się również pomiędzy spotkaniami, jako proces współpracy kilku osób. Ustalone grupy dostają wcześniej konkretne zadania do przepracowania i na umówione spotkanie przychodzą przygotowani, prezentując reszcie grupy efekty swojej pracy. Pozwala to uniknąć sytuacji, w której jest tak dużo niewiadomych, że uczestnicy nie są w stanie ruszyć z miejsca z przygotowaniem opisu czy podziałem. W zależności od przypadku blokerem może być to, że członkowie Zespołu muszą o coś dopytać, iść do innego zespołu, czy poprosić o informacje interesariusza.

Technika ta uwypukla wskazówkę, żeby do Refinementu podchodzić w sposób iteracyjny. Chodzi o to, że z pojedynczego warsztatu twój Zespół nie musi wyjść z rozwiązaniem gotowym od razu do wytwarzania. Refinement Backlogu (jego pojedynczego elementu) zorganizować można w sposób etapowy:

• Pierwszy krok – zapoznanie się z tematem – odbywa się w gronie całego Zespołu. Pod jego koniec wyłaniana jest grupa robocza, reprezentacja Zespołu która wejdzie w szczegóły.
• Krok drugi – praca kreatywna, wymagająca skupienia – odbywa się pomiędzy spotkaniami.
• Krok trzeci – prezentacja efektów pracy całemu Zespołowi. Wyznaczone osoby dzielą się podczas wspólnego spotkania wynikami swojego działania i pomagają zrozumieć przygotowane elementy Backlogu. 

Plusem takie podejścia iteracyjnego, jest to, że Zespół zyskuje czas pomiędzy konkretnymi etapami. Członkowie Zespołu, którzy podjęli temat, mogą w spokoju zastanowić się nad dobrym rozwiązaniem i dzięki temu uzyskać lepsze efekty.

Pozwól na pracę pojedynczych osób

Kontrowersyjną opcją działania w procesie Refinementu może być praca indywidualna. Zespół może wytypować osobę do danego aspektu, która bierze na siebie przemyślenie go w całości. Po dobrej analizie wątku, wybrana osoba przynosi do grupy rezultat swojej pracy.

Ta metoda ma dużą wadę polegającą na tym, że jednoosobowe rozpracowywanie tematu zawsze będzie miało ograniczenie zawężonego postrzegania problemu. Ta jedna osoba nie będzie widziała i wiedziała wszystkiego. Szczególnym niebezpieczeństwem w tym podejściu jest pomysł na to, że zawsze to będzie jedna i ta sama osoba. Często będzie to ekspert (najstarszy w zespole doświadczeniem). W wielu zespołach będzie to analityk, który specjalizuje się w zarządzaniu i modelowaniu wymagań. Ich doświadczenie i wiedza to duży plus, jednak może to też zamknąć możliwość kreatywnego wkładu i przejścia tego procesu odkrywania, co jest w ogóle do zrobienia. Uwzględniając powyższe przestrogi, stosuj pracę indywidualną z umiarem i w tych miejscach, gdzie faktycznie daje to wartość dodaną.

Kto powinien brać udział w Refinemencie?

Odpowiedź jest prosta: w Refinemencie powinien brać udział cały Zespół Scrumowy. Czasem może pojawić się pokusa przekazania odpowiedzialności za ten proces wybranym osobom, jednak zdecydowanie warto, żeby przynajmniej na którymś z etapów w procesie uczestniczył faktycznie cały zespół. Różne osoby ze swojej perspektywy i swojej specjalizacji są w stanie wnieść dużo na temat Backlogu Produktu, a także na temat tego, czego potrzebują, żeby efektywnie wykonać pracę w Sprincie.

Jeśli ktoś z zespołu nie ma ochoty uczestniczyć w Sprincie, szuka sposobu na wykręcenie się lub pyta, czy to spotkanie obowiązkowe, to radzilibyśmy zrozumieć, co takiego sprawia, że ta osoba nie chce uczestniczyć w spotkaniu wyjaśniającym i układającym, to co robimy. Zdarza się, że wychodzi tu temat wysokiej nieefektywności tego spotkania odczuwanej przez daną osobę. Zatem to sygnał, że coś w spotkaniach należałoby zmienić, dopytać też co poprawić, jak zwiększyć efektywność spotkania. 

Jeśli na spotkanie zapraszamy osoby spoza zespołu będące ekspertami w pewnych obszarach, to podajmy konkretne godziny, w jakich ta osoba będzie potrzebna, bo właśnie w tym czasie planujemy o rzeczach z jej domeny rozmawiać. Taki zewnętrzny ekspert chętniej przyjdzie na spotkanie, a my jako zespół będziemy prowadzić też warsztat bardziej efektywnie i otrzymamy wsparcie merytoryczne.

Na spotkanie można też zaprosić wszelkiego rodzaju stakeholderów i interesariuszy produktu/projektu, który rozwijamy. Oni mogą dostarczyć nam taki szerszy kontekst biznesowy – zrozumieć osadzenie konkretnej inicjatywy w firmie, pokazać perspektywę celów strategicznych, kierunek rozwoju firmy, wskazać zespołowi, co jest szczególnie istotne. 

Warto tu jednak pomóc tym osobom sprawnie uczestniczyć w spotkaniu, gdyż nie mają oni doświadczenia w pracy developerskiej i komunikacja może przebiegać mniej sprawnie. 

Specyficznym przykładem stakeholderów, których czasem warto zaprosić na spotkanie to inne zespoły, które mogą być też czasem interesariuszem naszej pracy. To dużo lepsza praktyka niż “głuchy telefon” i poleganie na tym, że dwóch Product ownerów ze sobą się dogada. 

Ostatnią grupą, jaką można zaprosić na warsztaty to reprezentacja użytkownika. Może to być użytkownik wewnętrzny, np. kolega z innego działu, który będzie używał rozwijany przez nas CRM, ale też może być to użytkownik zewnętrzny, czyli klient. Tego drugiego oczywiście dużo trudniej pozyskać na Refinement Backlogu. Jednak posiadając takich early adoptersów czy beta-testerów, można uzyskać naprawdę sporo wartościowych informacji o naszym produkcie. Jeśli niestety nie mamy możliwości zaproszenia użytkownika to niech go reprezentuje chociaż właściciel produktu.

Jak realizować Refinement Backlogu Produktu skutecznie?

1. Róbcie Refinement Backlogu – to pierwsza i podstawowa porada. Jak już wspomnieliśmy, są osoby, które mają poczucie, że go nie potrzebują. Jednak zdecydowanie warto go przeprowadzać. Nawet jeśli realizujecie Sprinty bez tego procesu, to  prawdopodobnie dostarczylibyście o wiele więcej wartości biznesowej, gdybyście ten proces sprawnie sobie przeprowadzili.

Skutkiem braku Refinementu może być to, że nie dostarczamy produktu albo jest on bardzo niskiej jakości, albo jest on opóźniony. Jest to efekt tego, że nie do końca rozumiemy co i po co robimy, nie do końca przemyśleliśmy naszą pracę  i obiecujemy coś, czego nie jesteśmy w stanie dostarczyć. To szereg konkretnych, nawarstwiających się problemów, u których podstaw leży brak Refinementu.

2. Dbajcie o strukturę Refinementu – Warto zadbać o to, żeby było jasne, co chcemy podczas tego spotkania osiągnąć. Cały zespół powinien też mieć przestrzeń na to, żeby się wypowiedzieć. Jeżeli pojawiają się jakieś osoby z zewnątrz, to też warto zaplanować.

Jest tu świetna przestrzeń dla Scrum Mastera, który swoimi zdolnościami facylitacji i moderacji może bardzo łatwo nadać strukturę temu spotkaniu, no i spowodować, że po prostu wejdziemy z konkretnymi problemami, a wyjdziemy z naprawdę z fajnymi efektami, czyli po prostu z przepracowanymi elementami Backlogu Produktu i z takim wspólnym zrozumieniem tego, co tak naprawdę jest do zrobienia.

3. Eksperymentujcie z formą Refinementów – Testujcie różne techniki, różne podejścia. Inspirujmy się od innych zespołów, sprawdzajcie co lepiej u Was działa, podejdźcie do tematu bardziej kreatywnie. 

Takim super małym i prostym eksperymentem dla każdego do zastosowania od jutra jest wyłączenie monitora, rzutnika i podejście do tematu offline. Sama taka drobna rzecz może spowodować, że to spotkanie zyska zupełnie inną dynamikę.

4. Przygotujcie się do spotkania – Nie będziecie wówczas tracić czasu na tym konkretnym spotkaniu na szukanie odpowiedzi, których być może w ogóle w tym danym momencie nie będziecie w stanie zdobyć. Stąd też przygotowanie siebie, jako uczestnika, zapoznanie się z tym, o czym będziemy rozmawiać, być może zaciągnięcie jakiejś wiedzy od osób z zewnątrz, pozwoli dokonać syntezy i po prostu przygotować te konkretne elementy bez problemów pod tytułem: „tego nie wiemy”, „o to musimy zapytać”, „na to jeszcze nie ma zgody”, „a tutaj czekamy na konkretną decyzję”.

5. Dajcie sobie czas – Nie narzucajcie sobie sztywnych zasad i presji czasowej, że na jednym spotkaniu załatwicie temat danego elementu Backlogu Produktu. Przecież może być to proces rozłożony w czasie, a w tym odstępie pomiędzy jedną rozmową a drugą dajcie sobie przestrzeń na przemyślenie tematów. Nie zamykajcie się też na to, że przed rozpoczęciem pracy musicie mieć absolutnie wszystko jasne i każdą wątpliwość totalnie rozwianą. Może to doprowadzić do tego, że zamęczycie się wszyscy procesem Refinementu, doprowadzając Backlog do takiej perfekcji, która nie jest tu potrzebna i zamyka też możliwość pracy w sposób eksploracyjny już w czasie developmentu.

Mamy nadzieję, że przekonaliśmy Cię do przeprowadzania Refinementu, jeśli wcześniej miałeś/aś co do niego wątpliwości. Chętnie też poznamy Twoje sprawdzone techniki na Refinemencie lub wskazówki odnośnie do tego procesu. Podziel się nimi w komentarzu.

Transkrypcja podcastu „Porządny Refinement Backlogu”

Jacek: Dzisiejszy odcinek jest kontynuacją serii o tym, jak porządnie używać i korzystać ze Scruma. W odcinku piątym rozmawialiśmy o tym, jak zrealizować Porządną Retrospektywę Sprintu, natomiast dzisiejszy odcinek poświęcimy tematowi doskonalenia Backlogu produktu. Tak, żeby było prościej nam poprowadzić ten odcinek, będziemy korzystać z angielskiej nazwy, która najczęściej jest przez nas spotykana w pracy zespołów, czyli będziemy używać określenia Refinement Backlogu. Inne określenia, które możecie spotkać, nazywające ten sam proces, to także Grooming, jednakże ta nazwa została oficjalnie przez twórców „Przewodnika po Scrumie” wycofana. Gdybyś miał, Kuba, zdefiniować, czym jest Refinement Backlogu, jak byś go nazwał?

Kuba: „Przewodnik po Scrumie” Refinement Backlogu definiuje jako proces dodawania elementów Backlogu produktu, doszczegółowania ich i wyceniania oraz szeregowania rzeczy, które już w Backlogu są. Jak ja tłumaczę, czym jest Refinement Backlogu, to często odchodzę z takiej definicji słownikowej do poziomu „po co to jest i czemu ma to służyć”, no i Refinement Backlogu to jest po prostu proces tworzenia, rozbudowywania i ciągłego pielęgnowania Backlogu produktu, który, no, sam znikąd się nie pojawia, a nawet jeśli w miarę wiemy, co chcemy robić, to i tak to trzeba przegadać, zgodzić się, zrozumieć. Jeśli stosujemy wyceny, to wycenić, jeśli coś jest większej natury, to musimy to podzielić na mniejsze elementy – i te wszystkie czynności, te wszystkie aktywności w Scrumie zebrane są pod nazwą „Refinement Backlogu produktu”. I tak słownikowo bym podkreślił jedną rzecz, że warto zwrócić uwagę, że to jest proces. No i siłą rzeczy proces oznacza, że, po pierwsze, jest to coś ciągłego, czyli to się nie kończy, to nigdy nie będzie miało jakiegoś tam efektu końcowego, no, zespół ciągle w kolejnych Sprintach pracując, ciągle pojawiają się w tym Zespole potrzeby rozbudowywania czy rozwijania Backlogu, no i też z tego, że jest to proces, powiedzmy tak słownikowo też wynika jedna rzecz, że świadomie w Scrumie nie jest to dodefiniowanie, czy to jest spotkanie, czy to jest warsztat, czy to jest jakaś czynność. W praktyce może być różnie – i to też wyraźnie w jednym ze zdań w „Przewodniku po Scrumie” jest wspomniane, że to Zespół Scrumowy odpowiada za ten proces i zespół też decyduje, w jaki sposób to robi, jakie techniki dobiera. Jest to jedna z tych części Scruma, która jest świadomie niedodefiniowana, świadomie zostawiona decyzji zespołu i wiemy – i o tym też w odcinku później będziemy trochę wspominać – że może być różnie, że są różne techniki na Refinement Backlogu, różne procesy, to może zależeć od kontekstu zespołu, to może zależeć od jego doświadczenia, od jego jakichś też preferencji co do form pracy wspólnej, zespołowej czy pracy analitycznej.

Jacek: No, tutaj ta wolność, o której wspominasz, jak to spotkanie można prowadzić, uważam, że z jednej strony daje dużą dowolność co do tego, jak będziemy pracować, jak często i w jakim składzie – i to jest bardzo fajne. Natomiast z drugiej strony, sam Refinement Backlogu nie jest wydarzeniem. Tak jak zespoły są w stanie powiedzieć, że jest codzienny Scrum, jest Planowanie Sprintu, jest Przegląd Sprintu, tak często, moim zdaniem, przez to, że ten proces doskonalenia Backlogu nie jest tak jasno zdefiniowany – i uważam ogólnie, że w „Scrum Guidzie” poświęcono mało miejsca na jego wytłumaczenie, no to bardzo często się spotykam z sytuacją, w której w ogóle nie następuje coś takiego, jak pochylanie się nad Backlogiem Produktu. I dla wielu zespołów, z którymi się spotykam, jest to zaskoczenie, że w ogóle coś takiego ma miejsce i jak oni w ogóle powinni do tego procesu podejść.

Kuba: No, ja mam taką anegdotę, że osoba, z którą pracowałem i której Scruma wyjaśniałem, gdy się dowiedziała, z jakich elementów Scrum się składa, z jakich wydarzeń, to się ten człowiek strasznie zdziwił, bo jego zdaniem od Refinementu trzeba zacząć – że to jest taki pierwszy krok i zdziwił się, że Frameworku jest to… Sprint zaczyna się planowaniem. Ale to jest też takie niedopowiedzenie, że tak naprawdę do planowania trzeba mieć Product Backlog, ten Product Backlog musi być gotowy do rozpoczęcia pracy, no i skądś on się musiał wziąć.Ale faktem jest to, co mówisz, że z racji tego niedodefiniowania, z racji tych takich trochę otwartych opcji, no, sprawia to kłopot. Sprawia to w zasadzie kłopot prawie każdemu zespołem, z którym rozpoczynam pracę czy do którego docieram jako Agile Coach.

Jacek: Ja myślę, że tutaj nie pomaga też taki mit panujący w środowisku, że skoro pracujemy zwinnie, no to po prostu siadamy i robimy, no i w trakcie pracy wyjdzie tak naprawdę to, co mamy do zrobienia – i tak z jednej strony ta dowolność taka w tym, żeby kształtować w trakcie pracy w Sprincie to, co budujemy – komunikacja z właścicielem produktu – to jest, uważam, dobre. Natomiast przerysowanie takie negatywne tej sytuacji jest takie, że po prostu tego procesu pracy z Backlogiem w ogóle nie ma i bardzo często obserwuję zespoły, dla których takich pierwszy moment, kiedy zaczynają się zastanawiać, co tak naprawdę jest w tym Backlogu, no to to jest planowanie Sprintu. No i zwykle ten czas, który zespoły powinny przeznaczyć na zaplanowanie Sprintu, na przygotowanie jakiegoś sensownego planu, zjadają całkowicie na to, żeby dogadać się, o co tak naprawdę chodzi w pracy, która jest w Backlogu, przez co na właściwe zaplanowanie Sprintu już nie ma czasu, więc te Sprinty często kończą się kiepsko, no i tutaj kółko takie zamknięte, właściwie tak dosyć wyraźnie, że brakuje tego oddechu, dosłownie, w skali, nie wiem, tygodnia – mówimy tutaj o godzinach, żeby jednak poświęcić czas na to i spojrzeć w Backlog i zastanowić się, co robimy, po co robimy, dlaczego to robimy i co to tak naprawdę miałoby być.

Kuba: Też odwracając sytuację – czasem widać zespoły, które nawet na planowaniu tego Refinementu nie zrobią, no i wtedy albo się nie rozumieją między sobą, nie rozumieją po co, więc nie rozumieją też potrzeby klienta, czy użytkownika, czy tej biznesowej potrzeby, no i później może być też bardzo duże nieszczęście na Przeglądzie Sprintu, gdy się okazuje, że zespół z dumą prezentuje jakiś rezultat, który jest kompletnie czym innym niż to, co było zamówienie, co wraca do tej anegdotycznej, już dosyć wiekowej ilustracji, że jedna osoba myśli o trójkącie, inna myśli o kwadracie, a jeszcze ktoś inny o kole, ale póki nie pogadamy o tym, to wszyscy twierdzimy, że się ze sobą zgadzamy, wszystko jest jasne, wszystko zrozumiałe – po prostu bierzcie się do roboty. No i to jest zdecydowanie mniej, tak, jak mówisz.

Jacek: Ja myślę, że jeszcze takim jednym ważnym aspektem regularnego prowadzenia Refinementu w zespole jest umożliwienie zespołowi współtworzenia produktu, czyli zespół ma wtedy okazję nie tylko wysłuchać właściciela produktu, o jest do zrealizowania, ale tak naprawdę ma czas, żeby się zastanowić, jakie opcje są możliwe, jakie rozwiązania są możliwe, jaki jest koszt tych rozwiązań, co to tak naprawdę znaczy, że ta konkretna praca została wykonana, jakie są kryteria akceptacji, no i na bazie moich obserwacji, pracując jako Agile Coach z zespołami, widzę, że zupełnie inaczej funkcjonują zespoły, które samodzielnie odpowiadają za tworzenie i pielęgnację Backlogu produktu, zupełnie inaczej pracują zespoły, które po prostu dostają, nazwijmy to, takie zalecenia, czyli bardzo dokładnie już rozpisane zadania, właściwie od A do Z, od kogoś tam, od Product Ownera, analityka, najstarszego Dewelopera, no i po prostu tę pracę wykonują – tak więc ten wątek współtworzenia, brania odpowiedzialności, kształtowania produktu, uważam, że zwykle można tanio, łatwo zbudować, właśnie realizując proces Refinementu.

Kuba: No taka ukryta też okazja, która przy braku Refinementu lub przy jego słabej postaci znika w wielu organizacjach, to też okazja do tego, żeby oddzielić potrzebę od możliwego rozwiązania i też zagłębić się w różne opcje, włącznie z tymi szybkimi, prostymi rozwiązaniami na jakąś wielką potrzebę. Nie raz, nie dwa widziałem przypadki, że przychodzi czy Product Owner, czy nawet jeszcze jakiś interesariusz ze zleceniem na: „Zróbcie mi wyszukiwarkę na tej liście”, a kończymy z wybudowaniem sortowania albo jakiegoś prostego stronicowania, bo nagle się okazuje, że ten, kto zleca prace, umie wyrazić swoją potrzebę wyłącznie przez pryzmat szczegółowego rozwiązania, jednego z wielu opcji. I teraz, jeśli nie damy okazji zespołowi przepracować sobie tego, jaka jest potrzeba, jak można ją rozwiązać, na jak różne sposoby to zrobić, jakie są alternatywy, też koszty korzyści do tych różnych opcji, to nie poświęcamy tego czasu, teoretycznie go zaoszczędzamy, co może też oznaczać, że powiedzmy umownie, zrobimy pracę na 10 Sprintów, bo tak się wbiliśmy w pewne tory, zamiast poszukać jakichś bardzo bystrych, bardzo sprytnych rozwiązań, które w jeden lub kilka Sprintów załatwiają temat i zaspokajają albo całą potrzebę, albo znaczną jej część – i zostawiają przestrzeń czy moc przerobową zespołu na kolejne wartościowe rzeczy.

Jacek: Ja myślę, że powiedzieliśmy już dosyć dużo, dlaczego warto poświęcić czas na Refinement Backlogu, zanim przejdziemy do tego, jak realizować ten proces, to chciałbym jeszcze poruszyć wątek tego, ile czasu powinniśmy na ten proces poświęcić. Jakie są twoje doświadczenia? „Scrum Guide” mówi o ok. 10% czasu Sprintu, natomiast jak to z twojej perspektywy wygląda w praktyce?

Kuba: No, z mojej perspektywy to wygląda tak, jak to mówi „Scrum Guide”, a „Scrum Guide” tam dokładnie to mówi, że zespoły zazwyczaj przeznaczają „nie więcej niż” – i to może zależeć bardzo mocno od naszego produktu, od tego, jak złożony on jest, jak odkrywczy, jak różnorodne wymagania wzajemnie się na siebie nakładają. No, znam zespoły, które są w stanie w krótszym czasie niż te wspomniane 10% przerobić tyle, ile potrzebują, żeby mieć tę perspektywę dobrze przygotowanego Backlogu na najbliższy Sprint i być może przegadanego również na kilka Sprintów wprzód. Natomiast coś, co bym dopowiedział to to, że te 10% to ja traktuję jako średnią w dłuższym okresie, czyli jeśli zespół siada do jakiegoś większego epica, jeśli tak porządkują Backlog – czy jakiejś większej inicjatywy, jakiegoś większego przedsięwzięcia, projektu, jakkolwiek to nazwiemy – jeśli jest to coś nowego, większego, w co w ogóle się trzeba wgryźć, to możliwe, że ten proces Refinementu powinien zjeść ciutkę więcej czasu w danym Sprincie, żeby też dosyć płynnie przejść do dostarczania kolejnych przyrostów w jak najszybszym tempie.Czyli, tak sobie myślę, że jeśli np. mamy sytuację, że zespół w ogóle od zera powstaje czy zaczyna jakiś projekt, zaczyna jakiś feature, zaczyna jakiś rozwój nowego produktu, to tutaj nie trzymałbym się kurczowo tej wytycznej 10%, bo możliwe, że duża część tego, co wykonujemy w ramach Sprintu, to de facto jest szeroko rozumiany proces Refinementu, wgryzanie się w jakieś dane, poznawanie użytkownika, poznawanie jego potrzeb, rozmowy z interesariuszami, przygotowywanie Backlogu – nie tylko takie całozespołowe, ale również indywidualne zapoznawanie się z tym, co tam jest.

Jacek: Ja myślę, że ten czas poświęcany… on zwykle jest większy na początku, natomiast im bardziej zespół zna produkt, im lepiej się rozumieją z Product Ownerem, im bardziej znają stakeholderów, no to ten czas, powiedziałbym, się gdzieś wyrównuje i dla tygodniowego Sprintu te 10% to jest jakieś tam 3,5 godziny. To z mojego doświadczenia zespoły, które – tak jak powiedziałeś – dużo tego Refinementu robią mimowolnie w trakcie Sprintu, to tak myślę sobie, że okolice 2-3 godzin (w zależności od potrzeb) okazują się wystarczające. Natomiast zespół, który nigdy nie robił Refinementu, nie zna produktu, nie rozumie, ma silne silosy wewnętrzne, no to niestety tego czasu będzie zdecydowanie więcej. Nie zdziwiłbym się, gdyby nawet to przyjmowało formę takich konkretnych dni warsztatowych, gdzie po prostu próbujemy zrozumieć, co jest do zrobienia i jak możemy to zrobić.

Kuba: Dla równowagi, nie znam zespołu, który nie potrzebowałby Refinementu w ogóle. To znaczy, są czasem takie pokusy – i tu właśnie ta ironia losu polega na tym, że to są pokusy w zespołach bardzo początkujących, że „W sumie to nie potrzebujemy, wiemy, a Zdzisiek to już dwa lata pracuje w tym produkcie, więc wszystko znamy na wylot. Po co gadać? Róbmy!”. Nigdy to nie jest dobry sposób i mówię to z bardzo mocnym przekonaniem, w sensie: rzadko używam tak mocnych sformułowań, ale w tym przypadku to powiem. Nawet jeśli faktycznie robimy to już dłuższy czas, to nadal jakaś forma uporządkowania, poukładania, podzielenia, wycenienia – tak, żeby planowanie było bardzo sprawne. Naprawdę godzina w tygodniu to nie wyobrażam sobie, że mogłaby wystarczyć tylko na ten proces „zapoznajmy się z tym, co jest do zrobienia i upewnijmy się, że tak samo to rozumiemy”, więc każdy zespół tego potrzebuje. Są zespoły, które robią to tak sprawnie, że nawet tego nie zauważają, ale nie znam zespołu, który by tego wcale nie potrzebował. Jeśli jest zespół, który wcale tego nie potrzebuje, to obawiam się, że tutaj jest trochę grubszy temat, czy oni w ogóle są zespołem, czy współpracują, czy jest zdefiniowany produkt, który rozwijają, czy tam w ogóle jest przyrostowość, jest jej potrzeba, bo może się okazać, że pod przykrywką Scruma jest realizacja jakiegoś długofalowego, kaskadowego projektu. Ale nie o tym ten odcinek.

Jacek: Dokładnie. No dobrze, to jakbyś miał zarekomendować słuchaczowi, który tutaj razem z nami odkrywa właśnie wartość i sens robienia Refinementów, no to pierwsze pytanie, które przychodzi do głowy: „No dobrze, no to jak konkretnie ten proces realizować w zespole?”.

Kuba: Taki najbardziej popularny sposób, który spotykam – i już nie wnikam, dlaczego on jest popularny – to jest po prostu jakieś warsztatowe spotkanie całego zespołu, gdzie zespół zapoznaje się z tym, co jest na spotkanie przyniesione – najczęściej to będzie przez Product Ownera – i rozmawiają sobie o tym, jak to rozumieją, rozbijają to na jakieś części pierwsze, cała ta dyskusja jest też zbierana w postaci albo to jakichś przygotowanych elementów Backlogu, albo chociaż jakiejś formy notatki czy wizualizacji, no i warsztatowa forma całego zespołu, która ma też swoje ograniczenia, w skrócie: im większy zespół, tym trudniej utrzymać uwagę i utrzymać energię też w dłuższym okresie czasu. Stąd bywają też inne, alternatywne metody realizacji tego procesu. No, nasuwa się jedna dosyć oczywista.

Jacek: Tak, możemy – jeżeli mamy duży zespół, który często jest moderować (dużo opinii, dużo pomysłów) – czasem ciężko jest to wszystko uchwycić, to taką popularną metodą czy prostym sposobem jest po prostu dzielenie zespołu na grupy. Czyli jak mamy, powiedzmy, zespół dwunastoosobowy. Zdarzają się takie zespoły…

Kuba: Dosyć duży.

Jacek: Dosyć duży, taki bym powiedział już „na skraju”. No to dzielimy taki zespół na dwa podzespoły, w trakcie tego spotkania czy warsztatu, no i zyskujemy dwie grupy sześcioosobowe. No i teraz tutaj możemy pójść też różnymi ścieżkami – może dać te same tematy do tych dwóch grup, żeby je przepracowały – i po jakimś tam umówionym czasie zaprezentowały sobie wyniki, podyskutowały, być może rozwiązania czy pomysły są podobne, być może się wykluczają, być może na skutek w ogóle połączenia tych pomysłów z różnych grup wyłoni się coś zupełnie nowego. To jest jedno popularne podejście, z którym mam doświadczenie. Inne podejście polega na tym, że dajemy do grup zupełnie inne elementy Backlogu Produktu. Pierwsze trzy do grupy pierwszej, kolejny trzy do grupy drugiej, grupy pracują jakiś czas nad tymi elementami, no i na koniec dzielą się między sobą efektami pracy, gdzie oczywiście jest przestrzeń na to, że grupa, która nie pracowała nad konkretnymi elementami, może mieć jakieś swoje uwagi, przemyślenia, jakieś tam… głębsze pytania.

Kuba: Modyfikacją, którą ja też znam, to jest też taka jakaś forma inspirowana ze Strategii Disneya, jeśli chodzi o techniki kreatywne, że można też nie tylko zaprezentować drugiej grupie, ale wręcz dać tej drugiej grupie do dalszej pracy. Czyli taka technika, która polega na tym, że jedna grupa przepracowuje te elementy Backlogu i koniecznie zapisuje efekty tego przepracowania, po czym ten… no nie wiem… kartka papieru czy jakieś post-ity przekazywane są do drugiej grupy i ta druga grupa albo ma poprawić, albo ma skrytykować, albo ma poszukać dziury w całym – w zależności od tego, jak sobie w grupie ustawimy taką moderację, ale w każdym razie może być też tak, że koniec końców przepracowanie jest efektem całej grupy, ale niekoniecznie jednocześnie cała sala czy wszyscy członkowie zespołu nad tym pracują. Czyli, w skrócie, to jest technika, która usprawnia to pierwsze z podejść całozespołowe, że praca odbywa się w sposób równoległy i, co ważne, w tych mniejszych grupach trochę prościej o aktywizację wszystkich. Powiedzmy, że ekstremalny przypadek to te sześcioosobowe podgrupy, a takie realne, z mniejszych zespołów, no to mniejsze zespoły podzielimy na trzy- może czteroosobowe grupy i wtedy to praktycznie każdy uczestniczy. Jedna osoba pisze, druga mówi, trzecia pyta. No, tam nie sposób się schować w tłumie, co jest realne i bardzo proste przyciąć komara na takim Refinemencie całozespołowym.

Jacek: To, co warto powiedzieć, na co osobiście zwracam uwagę to to, żeby tworząc te grupy stworzyć je w sposób taki najbardziej różnorodny. Czyli jeśli mamy różne kompetencje w zespole, no to zapewnić, żeby te kompetencje było równo rozłożone pomiędzy grupami – tak, żeby z jak najróżniejszych perspektyw patrzeć na konkretny problem. Alternatywą wersją tego pomysłu, o którym mówimy, jest również podejście, które opiera się na pracy w grupach, jednakże w tym przypadku ta praca grupowa dzieje się offline, czyli poza tym naszym konkretnym spotkaniem, warsztatem refinementowym, gdzie grupy dostają wcześniej jakieś konkretne zadania do przepracowania i na jakimś konkretnym, umówionym spotkaniu prezentują reszcie grupy, co przygotowały. Czyli to jest takie zapewnienie, że przyjdziemy na te konkretne spotkanie/warsztat/wydarzenie przygotowani, żeby uniknąć sytuacji, w której jest tak dużo niewiadomych, że nie jesteśmy w stanie ruszyć z miejsca, bo musimy ich zapytać, dopytać, zaprosić kogoś, iść do innego zespołu, poprosić stakeholdera czy jakąś inną osobę, żeby nam pomogła.

Kuba: I taka technika uwypukla jedną ważną radę czy zasadę, która można się kierować w czasie Refinementu, że dane zagadnienie czy dany epic, dany feature, dany projekt nie musimy wejść na pojedynczy warsztat refinementowy i wyjść jako natychmiast gotowy do developmentu, bo w tym schemacie postępowania, o którym przed chwilą powiedziałeś, Jacek, uwidacznia się wtedy etap w ogóle pierwsze podejście do tematu, że go poznajemy, powiedzmy, jakiś środkowy etap – rozbijamy go na jakieś elementy bardziej szczegółowe, wycenione, już właściwie podzielone, jakoś tam przemyślane. I być może jeszcze jest jakiś taki etap „I całym zespołem zgadzamy się, że to rozumiemy, że nie mamy więcej pytań, że pozwala nam to na rozpoczęcie pracy”. No i można to zorganizować właśnie w taki sposób, że pierwszy i trzeci krok z tego, co powiedziałem, dzieje się na jakiejś formie spotkania wspólnego, ale ten etap środkowy, czyli taka praca powiedzmy kreatywna, ale też taka praca polegająca mocno na myśleniu, sprawdzaniu różnych rzeczy, też jakimś przeanalizowaniu tego w różnych miejscach, no, może wymagać skupienia, może wymagać spokoju i niekoniecznie najlepszym sposobem wtedy na taką pracę jest praca na spotkaniu. Aczkolwiek ten schemat, o którym powiedziałem, można też przeprowadzać na kolejnych spotkaniach warsztatowych z poprzednich metod, o których wspomnieliśmy, czyli też się nie silić na to, że nie możemy sobie pozwolić na to, że z danego Refinementu po prostu wychodzimy… Znaczy… Dobrze jest i to jest okej, że wychodzimy z tematem: „Słuchajcie, tu są jeszcze znaki zapytania, musimy to jeszcze sprawdzić, rozpoznać, w przyszłości to jest możliwe”.

Jacek: Plusem tego podejścia iteracyjnego, o którym wspominasz, jest to, że zyskujemy ten czas pomiędzy tymi konkretnymi, nazwijmy to, iteracjami. Bardzo często – i to znam z własnego doświadczenia – pewne pomysły przychodzą nam w momencie, kiedy nie wykonujemy pracy – w tramwaju, w domu – i to są takie momenty, w których nasz mózg mimowolnie zaczyna łączyć kropki, tak więc osobiście jestem fanem tego, żeby – w szczególności, jeśli mówimy o takiej pracy kreatywnej, gdzie trzeba coś wymyślić – robić sobie takie przerwy, gdzie pozornie nie zastawiamy się nad rozwiązaniem, ale na szczęście nasz mózg gdzieś tam sobie na jakiejś tam pętli, rdzeniu czy jakkolwiek to nazwiemy, przetwarza temat i ten czas często jest potrzebny i wartościowy, żeby na to kolejne spotkanie przyjść i powiedzieć: „Wiecie co, wpadłem na taki fajny pomysł” albo „Przemyślałem sobie dobrze ten temat”, no i wtedy zaprezentować możliwe rozwiązanie.

Kuba: I taką ostatnią szczegółową metodą pracy w takich podgrupach, to jest praca w podgrupach jednoosobowych, czyli mamy jakąś wytypowaną osobę do danego aspektu, która po prostu bierze na siebie przemyślenie tego i przynosi do grupy rezultat końcowy. Ta metoda – od razu powiedzmy sobie głośno – może mieć duże niebezpieczeństwo po prostu jednoosobowe rozpracowywanie tematu zawsze będzie miało jakieś tam swoje ograniczenie i jedna osoba nie będzie widział wszystkiego, a już szczególnym niebezpieczeństwem jest pomysł na to, że zawsze to będzie jedna i ta sama osoba, np. jakiś ekspert najstarszy w zespole z doświadczeniem lub np. jakiś analityk, który doskonale się tym zajmuje i się w tym specjalizuje, co jest fajne, ale niestety może też zamknąć możliwość kreatywnego wkładu, zamknąć możliwość też przejścia tego procesu odkrywania, co jest w ogóle do zrobienia i przynosi zespołowi gotowce, które może nawet i są akceptowane i w sumie nawet może przyspieszają – jeśli patrzeć tylko tą perspektywą – ale mogą też zamknąć te pozytywy czy te korzyści, o których wspominaliśmy na samym początku odcinka.

Jacek: No to też może być bardzo fajne ćwiczenie, które może pokazać nam, czy w ogóle zespół jest gotowy na to, żeby członkowie zespołu samodzielnie podchodzili do tematu. Może się okazać, że różnica w wiedzy pomiędzy członkami w teamie jest tak dużą,. że znajdą się osoby, które samodzielnie po prostu nie będą w stanie ruszyć z tematem, przy czym uważam, że odkrycie tego jest wartościowe. No i tutaj warto się zastanowić nad tym, jak poradzić sobie z tą konkretną sytuacją, żeby nie było tak, że są osoby, które nie są w stanie po prostu takiej analizy przygotowania przygotować. Powiedzieliśmy o tym, dlaczego, powiedzieliśmy też, jak konkretnie można realizować proces Refinementu, no to kolejne pytanie jest takie: kto powinien brać w tym udział?

Kuba: Na pewno zacznijmy od ważnej zasady, że: cały zespół. Czasem… O tym już wspomnieliśmy chwilę temu, że może być pokusa specjalizowania się, przekazania odpowiedzialności za ten proces wybranym osobom – zdecydowanie warto, żeby przynajmniej na którymś z etapów tego – w zależności od metody, jaką stosujemy – uczestniczył faktycznie cały zespół. Różne osoby ze swojej perspektywy, ze swojej specjalizacji czy doświadczenia są w stanie wnieść dużo na temat Backlogu Produktu, na temat tego, co potrzebują, żeby też wykonać już efektywnie pracę w Sprincie.

Jacek: Co rekomendujesz zespołom, które pytają Ciebie, jako Agile Coacha, czy czy to jest spotkanie obowiązkowe? Czy muszą być wszyscy?

Kuba: No, szczerze mówiąc, to zazwyczaj jest prowokowanie mnie do głębszego coachingu (ale dobrze rozumianego, nie takiego, jak z Facebooka). No bo jeśli ktoś ma poczucie, że jest to obowiązkowe spotkanie, no to może tu jest coś nie tak. Tak naprawdę ja bym odbił pytanie, czy tutaj praca całym zespołem jest obowiązkowa. Jeśli ktoś ma ochotę się wypisać z tematu rozumienia, co robimy, po co to robimy, ale może nie ironizowałbym. W sensie, to jest proces, który mam w głowie, a nie na zewnątrz, natomiast na zewnątrz raczej chciałbym zrozumieć, co takiego sprawia, że ktoś nie chce w tym uczestniczyć. No i to wtedy wychodzi. Myślę, że jeszcze zdążymy w tym odcinku trochę na końcu dać parę porad, ale tu chyba najczęściej widzę, że tu wychodzi temat wysokiej nieefektywności tego spotkania odczuwanej przez daną osobę – i to często będzie tak, że ten, kto ma odwagę zapytać mnie o coś takiego, daje się też wciągnąć w rozmowę, jak by poprawił to spotkanie, żeby miał sens uczestniczenia całego zespołu, ale nie jakiejś tam wybranej grupy zapatrzonej w ekran czy analizującej jakiegoś Excela czy ściubiących coś na kartce.

Jacek: Czyli z jednej strony mamy Zespół Scrumowy, inne osoby, które mogą się pojawiać podczas Refinementu, to często są osoby, które mają wiedzę domenową. Są ekspertami w pewnych obszarach. To np. mogą być – obszar architektury albo jakiś konkretny obszar domenowy, funkcjonalny, dotyczący produktu, który rozwijamy. I częstą praktyką jest to, że te osoby dopraszamy na konkretne spotkanie, na konkretny warsztat. Co ważne, też podajemy jakiś tam orientacyjny czas i godziny, w jakich ta konkretna osoba będzie potrzebna, na zasadzie, że właśnie wtedy planujemy o tych konkretnych rzeczach rozmawiać. I wtedy taki ekspert czy osoba, która po prostu ma wiedzę, której nam brakuje – taką wiedzę, którą chcemy sobie dociągnąć do zespołu, pojawia się, fajnie, jeśli wie, o czym będziemy rozmawiać – o jakim aspekcie – więc wtedy też może się przygotować, no i po prostu zasilić nas jako zespół wiedzą, opowiedzieć o czymś, przedstawić, wypunktować słabsze strony, pokazać szerszy horyzont – czyli taki „zewnętrzny” ekspert, zasilenie wiedzą spoza Zespołu Scrumowego.

Kuba: Na to mam bardzo ciekawy przykład, bardzo mocno mnie inspirujący już od lat. Pamiętam, jak w jednym zespole, z którym współpracowałem, był duży temat prawniczy, no i niestety załatwiali go poprzez „głuchy telefon”. Coś tam Product Owner przekaże, tu trochę analityk przyniesie, w ogóle prawnik raczej komunikował się dokumentami, no i bardzo proste usprawnienie, które zrealizowaliśmy, zasadzie na telefon, od ręki, to czy ten prawnik mógłby do nas przyjść na ten Refinement Backlogu – w zasadzie od ręki się ta osoba pojawiła, szybka rozmowa: „Aha, teraz rozumiem, to możecie zrobić inaczej”, „Czy to zapewni?”, „Tak, zapewni. A tutaj pamiętajcie o dołożeniu klauzuli informacyjnej” – i w 15 rozwiązany problem, który się ciągnął za zespołem już od kilku tygodni. I myślę, że to jest też taka praktyka – faktyczna realizacja zasady komunikacji twarzą w twarz. Nawet jeśli jacyś eksperci są trochę trudniej dostępni, to może dlatego, żeby móc z nimi bezpośrednio pogadać, warto trochę się zespołem dostosować, właśnie poprzez np. wyznaczenie bardzo krótkiego okienka czasowego dopasowanego do tej osoby, żeby wyciągnąć tę informację i sprawnie dogadać potrzebę, możliwe zakresy rozwiązań i może nawet zgodzić się już na konkretne jedno, które będzie implementowane w kolejnym Sprincie.

Jacek: Czyli mamy cały zespół, mamy ekspertów zewnętrznych, do tych osób dołożyłbym taką kolejną grupę, czyli wszelkiego rodzaju stakeholderów, interesariuszy produktu/projektu, który rozwijamy. Tutaj myślę, że w przeciwieństwie do tych ekspertów, oni częściej mogą dostarczyć nam taki szerszy kontekst biznesowy – zrozumieć osadzenie konkretnej inicjatywy w firmie, pokazać takie aspekty, które może czasem rzadziej są komunikowane, czyli: trochę może przejść na poziom jakichś celów strategicznych, kierunku rozwoju firmy, rzucić światło zespołowi na to, dlaczego ta konkretna inicjatywa, dlaczego ten konkretny feature, czy ta konkretna cecha naszego produktu, jest ważna. Myślę sobie, że to często może być taka wiedza czy taka perspektywa, która nie jest tak na co dzień dostępna dla Zespołu Deweloperskiego, w takim sensie, że może być tak, że nawet właściciel produktu nie jest w stanie przekazać tego kontekstu, którym mogą obdarować zespół stakeholderzy. Z drugiej strony – nawet jeśli potrafi, no to w myśl tej zasady, żeby nie robić „głuchego telefonu”, zaprośmy tego stakeholdera, zróbmy slot na 15-20 minut, niech ten stakeholder zobaczy zespół, zobaczy, jak pracują, niech zespół zobaczy stakeholdera, niech się ze sobą „oswoją”. Myślę, że to jest taka fajna inwestycja na przyszłość, żeby podchodzić do siebie z mniejszą dozą obaw, z większym zaufaniem i z większą otwartością.

Kuba: Przy czym ze stakeholderami z praktyki dorzuciłbym taką przestrogę, żeby pomóc tym osobom sprawnie uczestniczyć w spotkaniu. Z jednej strony – trochę przemoderować to, czego od nich oczekujemy i też nie łapać ślepo wszystko to, co oni nam przekazują – to już też zdążyłem wspomnieć, że np. niektórzy stakeholderzy nie mają takich doświadczeń w pracy developerskiej, więc siłą rzeczy nie będą tak sprawnie się komunikować, a my możemy to przegapić i np. faktycznie myśleć, że oni naprawdę chcą mieć tą wyszukiwarkę, a oni po prostu chcą realizować swój proces biznesowy w taki sposób, żeby to było efektywne. Takim specyficznym przykładem stakeholderów, których bym dorzucił, to też czasem interesariuszem naszej pracy mogą być inne zespoły – zwłaszcza jak jesteśmy częścią jakiejś większej organizacji, jakiejś grupy produktów czy produktu rozbudowanego, też nie wzbraniajmy się przed tym, że zamiast właśnie polegać na „głuchym telefonie”, że się dwóch Ownerów ze sobą dogada, zaprośmy po prostu reprezentację albo nawet cały zespół inny, z którym mamy jakieś punkty styku, musimy się połączyć przez interfejs albo my wystawić im nasz interfejs, czy razem stworzyć coś większego. Jeśli ten drugi zespół też pracuje Scrumem, to powinno być w miarę oczywiste „po co”. Pewnie trzeba będzie wtedy tylko wyjść trochę przed szereg i wzajemnie się dopasować terminowo, ale zdecydowanie warto tę współpracę rozpocząć na etapie, gdy uwspólniamy Backlogi Produktów przed rozpoczęciem pracy, a nie zdziwić się w trakcie jakiegoś procesu planowania, że oni nie robią nam tego, co my chcemy, albo nie mają dla nas czasu – wszystkie te rzeczy da się dogadać w procesie doskonalenia Product Backlogu, zamiast rozpoczniemy pierwszy Sprint realizacji takiej pracy w kilku zespołach realizowanej równolegle.

Jacek: Myślę, że taką ostatnią reprezentacją, której bym się spodziewał na Refinemencie, to jest po prostu reprezentacja użytkownika i tutaj możemy podzielić tego użytkownika na takie dwie opcje – pierwsza opcja, to jest użytkownik wewnętrzny – i myślę… tak na bazie mojego doświadczenia, jest to grupa, którą o wiele prościej jest mieć na Refinemencie, czyli rozwijając wszelkiego rodzaju narzędzia, które są użytkowane wewnętrznie, wszelkiego rodzaju intranety, CRM-y, jakieś takie precyzyjne narzędzia o konkretnych kompetencjach w firmie, no to zwykle tutaj nie ma najmniejszego problemu – no bo to… idziemy po Tomka czy idziemy po Kasię na drugie piętro, na piąte piętro – no i mamy superokazję, żeby posłuchać z pierwszej ręki o tym, jak użytkownik wyobraża sobie produkt, co go boli, jakie ma oczekiwania. Taką grupą trudniej dostępną – i tak się zastanawiam, czy w ogóle miałem szansę doświadczyć czegoś takiego – to jest pojawienie się użytkownika naszego produktu. Nie widziałem takiego użytkownika na Refinemencie, widziałem kilku użytkowników produktów biorących udział w szeroko rozumianym procesie odkrywania produktu, natomiast wyobrażam sobie, że jeżeli mamy grupę zaufanych użytkowników, jakichś early adoptersów, jakichś beta-testerów – to tak z jednej strony to może być superokazja, żeby dowiedzieć się od nich naprawdę fajnych rzeczy, fajnych przemyśleń – z drugiej strony, myślę, że to może być też wartościowe i takie nobilitujące dla tych użytkowników, że oni – właśnie oni! – zostali zaproszeni, poproszeni, żeby wesprzeć Zespół Deweloperski, żeby ich zdanie miało wpływ na to, jak rozwija się produkt.

Kuba: A jeśli nie mamy takiej możliwości zaproszenia użytkownika albo wydaje nam się, że jest to jakiś kosmos kompletnie nierealizowalny, no to nie zapomnijmy o tym, żeby ten użytkownik był chociaż reprezentowany przez właściciela produktu – no i tą reprezentację można zwłaszcza w świecie produktów cyfrowych zrobić poprzez pokazanie statystyk wykorzystania narzędzia, poprzez jakąś formę badań, ankiet, różnego rodzaju narzędzi, które sprawią, że trochę lepiej zrozumiemy tego użytkownika i dostarczymy wartość jemu, a nie w naszym takim wewnętrznym, biurowym „sosie” sobie się dogadamy, departament z departamentem są zgodni, a potem na końcu się okaże, że klient wcale tego nie potrzebuje.

Jacek: Zgadza się. No dobrze, to myślę, że możemy przejść do ostatniej części dzisiejszego odcinka, czyli chcielibyśmy podzielić się z Tobą konkretnymi poradami dotyczącymi tego, jak robić Refinement Backlogu dobrze, jak robić go porządnie.

Kuba: No to najważniejsza rada: robić go. Są zespoły, o których już wspominałem, które mają poczucie, że go nie potrzebują. Są czasem też Scrum Masterzy, którzy nie czują się do końca pewnie, nie chcą zaproponować, zespół jakoś tak jest na wstępie niechętny. Zdecydowanie warto, zdecydowanie trzeba. To jest pewna droga, żeby się tego nauczyć. To jest pewna też może sztuka, żeby dobrze to zrealizować, dobrze to poprowadzić, jako Scrum Master. Zespół też pewnie musi się z tematem oswoić, ale zdecydowanie warto, trzeba robić ten proces, no, tracimy dużo, nawet jeśli jakoś nam się realizują te Sprinty bez tego procesu, to prawdopodobnie zrobilibyśmy o wiele więcej wartości biznesowej – to podkreślę – gdybyśmy ten proces sprawnie sobie zrobili. No i tracimy, jeśli go nie robimy.

Jacek: Ja myślę, że ta porada na zasadzie: róbmy Refinementy, róbcie Refinementy – to w moim rankingu to jest takie absolutne „top 3” sugestii czy porad, którymi dzielę się ze swoimi klientami. W sensie: bardzo często źródłem wielu problemów jest po prostu to, że tego Refinementu nie ma. Tak więc zdecydowanie jest to takie… prosta? Łatwa do zaimplementowania rzecz, która może dać bardzo dużo wartości.

Kuba: No i, co ważne, te negatywne rezultaty mogą być w zupełnie innym miejscu niż w okolicy procesu Refinementowego, bo skutkiem braku Refinementu może być to, że nie dostarczamy produktu albo on jest bardzo niskiej jakości, albo jest on opóźniony, bo da się dosyć prosto pokazać związek przyczynowo-skutkowy, że nie do końca rozumiemy, nie do końca przemyśleliśmy, nie do końca to rozpisaliśmy, obiecujemy coś, czego nie jesteśmy w stanie dostarczyć – szereg konkretnych, nawarstwiających się problemów, u których podstaw leży brak Refinementu.

Jacek: Kolejną taką poradą jest, aby dbać o formę. Czyli warto, żeby to spotkanie miało konkretną strukturę, warto zadbać o to, żeby było jasne, co chcemy podczas tego spotkania osiągnąć, ważne, żeby cały zespół miał przestrzeń na to, żeby się wypowiedzieć. Jeżeli pojawiają się jakieś osoby z zewnątrz, to też warto zaplanować. Nie ma nic gorszego, niż takie spotkanie, po prostu, że się spotkamy, „nasiadówka”, jedna osoba mówi przez połowę czasu, reszta nie słucha.

Kuba: Aż nam się skończy tlen w salce.

Jacek: Tak [śmiech]. Ktoś tam uśnie w końcu. Tak więc… Wtedy zwykle się słyszy, że te spotkania nie mają sensu, po co przychodzimy itd., no i tutaj świetna przestrzeń dla Scrum Mastera, który swoimi zdolnościami facylitacji, moderacji może bardzo łatwo nadać strukturę temu spotkaniu, no i spowodować, że po prostu wejdziemy z konkretnymi problemami, no i dbając o jakiś tam rytm, nieodpływanie za bardzo od tematu, możemy wyjść naprawdę z fajnym efektem, po prostu z przepracowanymi elementami Backlogu Produktu, no i z takim wspólnym zrozumieniem tego, co tak naprawdę jest do zrobienia.

Kuba: Sąsiednią radą do dbania o formę jest też eksperymentowanie z tą formą. Nie znam zespołu, który by nie popróbował kilku rzeczy, żeby znaleźć coś naprawdę fajnego, więc nawet jeśli dzisiaj realizujemy ten Refinement Backlogu tak samo, jak od pierwszego Sprintu, to spróbujmy czy czasami jakaś forma – albo te, które wymieniliśmy, albo jakaś szczegółowa wariacja wewnątrz tego – czy zaczerpnięcie z jakichś technik kreatywnych, czy zaczerpnięcie jakichś technik ze świata User Experience chociażby, no, nie pomoże, nie otworzy czegoś, nie rozszerzy perspektywy… czy nawet chociaż nie złamie rutyny. Więc tutaj eksperymenty z różnymi technikami – świadome, publiczne, nazwane wprost przed całym zespołem – mogą dać fajny rezultat, nawet jeśli jakaś jedna konkretna technika nam się nie sprawdzi, to przynajmniej już po porównaniu tej, która się nie sprawdza z tą, którą się sprawdza, już wiemy, czy lepiej umiemy nazwać co nam się sprawdza. No i to jest kopalnia inspiracji, to jest świetny temat na rozmowę na społecznościach zwinnych, w jaki sposób Refinement Backlogu realizujemy i podsłuchiwanie, jak różne zespoły się do tego zabierają, jak na różne sposoby można to zrealizować.

Jacek: Ja myślę, że takim super małym, prostym eksperymentem dla każdego do zastosowania od jutra jest wyłączenie monitora, rzutnika, nieużycie Jiry czy jakiegokolwiek innego narzędzia, tylko podejście do tematu offline. Sama taka drobna rzecz może spowodować, że to spotkanie zyska zupełnie inną dynamikę. Kolejną poradą, którą chcemy się podzielić jest bardzo prosta porada polegająca na tym, że warto się przed tym spotkaniem przygotować – po to, żeby nie tracić czasu na tym konkretnym spotkaniu/wydarzeniu/warsztacie na szukanie odpowiedzi, których być może w ogóle w tym danym momencie nie będziemy w stanie czasowo zdobyć, tak więc przygotowanie siebie, jako uczestnika, zapoznanie się z tym, o czym będziemy rozmawiać, być może zaciągnięcie jakiejś wiedzy od osób z zewnątrz, po to, żebyśmy na tym spotkaniu mieli wystarczający poziom wiedzy, który pozwoli nam dokonać syntezy i po prostu przygotować te konkretne elementy bez problemu pod tytułem: „tego nie wiemy”, „o to musimy zapytać”, „na to jeszcze nie ma zgody”, „a tutaj czekamy na konkretną decyzję”.

Kuba: I ostatnią radą, którą bym dał przy Refinemencie, to jest ta, żeby nie spinać się na to, że w ramach jednego spotkania załatwimy całkowicie temat danego elementu Backlogu Produktu. Po pierwsze: może być to proces rozłożony w czasie. Jacek też o tym wspomniał, że może być tak, że w tym odstępie pomiędzy jedną rozmową a drugą będziemy mieli spokojny czas na pomyślenie o tym, ale z drugiej strony też nie zamykajmy się na to, że przed rozpoczęciem pracy musimy mieć absolutnie każdy jeden szczególik, każde jedno rozpisanie, każdą jedną wątpliwość totalnie rozwianą, żeby się też nie okazało, że zamęczamy się wszyscy procesem Refinementu, doprowadzając Backlog do takiej perfekcji, która nie jest już potrzebna, zamykam nam też możliwość pracy w sposób eksploracyjny już w czasie developmentu.

Jacek: I myślę, że to byłoby tyle, jeśli chodzi o dzisiejszy odcinek. Powiedzieliśmy trochę, dlaczego warto w ogóle poświęcić czas na proces doskonalenia Backlogu Produktu, porozmawialiśmy trochę o tym, jak to spotkanie przeprowadzić, porozmawialiśmy o tym, kto powinien brać udział, kogo można zaprosić oraz podzieliliśmy się kilkoma poradami z naszego doświadczenia, co wpływa na to, żeby to konkretne wydarzenie przebiegło w sposób efektywny. Jeżeli macie jakiekolwiek pytania odnośnie do Refinementu, jako że zwykle dosyć dużo pytań słyszymy – czy widzimy też w mailach, które od Was dostajemy – napiszcie do nas na adres kontakt@porzadnyagile.pl, użyjcie naszych kanałów społecznościowych – jeżeli któryś z aspektów Refinementu jest dla Was interesujący, po prostu dajcie nam znać, a my postaramy się poświęcić jakiś odcinek na to, żeby jeszcze pogłębić.

Kuba: Możecie też mieć sprawdzone techniki na Refinemencie lub swoje własne odkrycia, którymi warto się podzielić. Koniecznie wpiszcie to w komentarzu pod odcinkiem na naszej stronie porzadnyagile.pl.

Jacek: I to by było wszystko na dzisiaj. Dzięki, Kuba.

Kuba: Dzięki, Jacek.

Jacek: I do zobaczenia…

Kuba: …wkrótce.