#009 – Porządny Refinement

Rozmawiamy o tym, dlaczego warto przeprowadzać proces doskonalenia Backlogu Produktu, zwany potocznie refinementem lub groomingiem. Dyskutujemy o tym, jak często pracować nad Backlogiem Produktu, w jakim składzie oraz po jakie konkretne sposoby realizacji tego procesu sięgać. Całość podsumowujemy kilkoma praktycznymi poradami na bazie naszych własnych doświadczeń w pracy z zespołami.

Przeczytaj artykuł

Czym jest Refinement i jak go realizować w zespole, aby uzyskać jak najlepsze efekty? Jak sprawnie udoskonalić Backlog produktu? Poznaj nasze wskazówki i dobre praktyki.

Czym jest Refinement?

„Przewodnik po Scrumie” Refinement 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 to po prostu proces tworzenia, rozbudowywania i ciągłego pielęgnowania Backlogu produktu. 

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

Zwrócić uwagę, że Refinement jest procesem. Oznacza to, że jest to coś ciągłego, coś c się nie kończy i zespół w kolejnych Sprintach rozbudowuje lub rozwija Backlog. Ponadto świadomie w Scrumie nie jest dodefiniowanie, w jakiej formie ma się odbywać, spotkania, warsztatu, czy może jakiejś czynności. Dlatego w praktyce może Refinement różnie wyglądać

Z uwagi na ten brak dodefiniowania w wielu zespołach, z którymi mamy do czynienia, proces Refinementu sprawia kłopot. Nie pomaga tu też taki mit panujący w środowisku, że skoro pracujemy zwinnie, to po prostu siadamy i działamy, a w trakcie pracy wyjdzie co tak naprawdę mamy do zrobienia. Pozytywna jest tu ta dowolność w tym, żeby kształtować w trakcie pracy w Sprincie to, co budujemy, natomiast takie negatywne przerysowanie tej sytuacji jest takie, że po prostu proces pracy z Backlogiem w ogóle nie zachodzi. Często przez to 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ół powinien przeznaczyć na zaplanowanie Sprintu, przeznaczają w całości, żeby dogadać się, o co tak naprawdę chodzi w pracy, która jest w Backlogu. Czasu na zaplanowanie Sprintu nie ma, Sprinty kończą się kiepsko i mamy zamknięte koło. 

A przecież wystarczy tylko kilka godzin w skali tygodnia, aby spojrzeć w Backlog i zastanowić się, co robimy, po co robimy, dlaczego to robimy i co to tak naprawdę miałoby być.

Spotykamy też zespoły, które nawet na planowaniu Sprintu nie robią Refinementu i wtedy albo nie rozumieją się między sobą, albo nie rozumieją, po co coś robią, albo nie rozumieją też potrzeby klienta lub użytkownika. W rezultacie, na Przeglądzie Sprintu może się okazać, że dumnie prezentowany wynik jest kompletnie czym innym niż to, co było zamówione.

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, ale ma też czas, żeby się zastanowić, jakie rozwiązania są możliwe, jaki jest koszt tych rozwiązań, co to tak naprawdę znaczy, że ta konkretna praca została wykonana i jakie są kryteria akceptacji. 

Osobiście widzimy, że zupełnie inaczej funkcjonują zespoły, które samodzielnie odpowiadają za tworzenie i pielęgnację Backlogu produktu, a zupełnie inaczej pracują zespoły, które po prostu dostają bardzo dokładnie już rozpisane zadania od Product Ownera lub kogoś innego i po prostu tę pracę wykonują. Brak tu więc współtworzenia i brania odpowiedzialności za kształtowanie produktu.

Refinement to też okazja do tego, żeby oddzielić potrzebę od możliwego rozwiązania. Przykładowo Product Owner lub inny interesariusz przychodzi i mówi: „Zróbcie mi wyszukiwarkę na tej liście”. W sytuacji, gdy zlecający umie wyrazić swoją potrzebę wyłącznie przez pryzmat szczegółowego rozwiązania, jednego z wielu opcji, to jeśli zespół nie ma okazji przepracować sobie tego, zrozumieć potrzeby, przeanalizować różnych opcji i korzyści z nich wynikających, to tylko teoretycznie oszczędzamy czas. W efekcie jednak praca zajmuje np. 10 Sprintów, bo tak się wbiliśmy w pewne tory, zamiast 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ęść – i zostawiają przestrzeń na realizację kolejnych rzeczy.

Prawdę mówiąc, nie znamy zespołu, który nie potrzebowałby Refinementu w ogóle. 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. Są zespoły, które robią to tak sprawnie, że nawet tego nie zauważają. Jeśli jest zespół, który twierdzi, że wcale tego nie potrzebuje, to  pytanie, 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ść? Być może, pod przykrywką Scruma realizują jakiś długofalowy, kaskadowy projekt.

Ile czasu powinniśmy przeznaczyć na proces Refinementu?

„Scrum Guide” mówi, że ok. 10% czasu Sprintu, powinniśmy przeznaczyć na Refinement. W praktyce może to jednak zależeć bardzo mocno od naszego produktu, od jego złożoności i innowacyjności, od tego, jak różnorodne wymagania wzajemnie się na siebie nakładają. 

Warto te 10% traktować jako średnią w dłuższym okresie, czyli jeśli zespół siada do jakiegoś większego epica, inicjatywy lub projektu, to ponieważ jest to nowe i duże, to potrzeba trochę więcej czasu, aby w ogóle się w ten temat wgryźć, poznać użytkownika i jego potrzeby, porozmawiać z interesariuszami. Stąd też proces Refinementu powinien zjeść trochę więcej czasu w tym Sprincie, żeby też dosyć płynnie przejść do dostarczania kolejnych przyrostów w jak najszybszym tempie.

Można powiedzieć, że czas poświęcany na Refinement jest zwykle większy na początku, natomiast im bardziej zespół zna produkt, im lepiej rozumie się z Product Ownerem, im bardziej zna stakeholderów, to ten czas wyrównuje się i dla tygodniowego Sprintu te 10% to jest jakieś tam 3,5 godziny. Z kolei zespoły, które dużo Refinementu robią mimowolnie w trakcie Sprintu, to 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, ma silne silosy wewnętrzne, to niestety tego czasu będzie potrzebował zdecydowanie więcej. Może to nawet przyjmować formę takich konkretnych dni warsztatowych, gdzie po prostu próbujemy zrozumieć, co jest do zrobienia i jak możemy to zrobić.

Jak realizować Refinement w zespole?

Jednym z najbardziej popularnych sposób na przeprowadzanie Refinementu jest spotkanie warsztatowe całego zespołu, gdzie zespół zapoznaje się z tym, co jest na to spotkanie przyniesione-najczęściej przez Product Ownera. Na spotkaniu członkowie zespołu rozmawiają o tym, jak to rozumieją, rozbijają to na jakieś części pierwsze, a cała dyskusja jest zebrana w postaci przygotowanych elementów Backlogu, albo chociaż jakiejś formy notatki czy wizualizacji. 

Niestety ta warsztatowa forma ma niestety swoje ograniczenia i wady, m.in. dlatego, że im  większy zespół, tym trudniej utrzymać uwagę i energię w dłuższym okresie. Stąd też realizowane są alternatywne sposoby przeprowadzania Refinementu.

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 czym po ustalonym czasie, grupy te spotykają się, prezentują swoje wyniki i je omawiają, co 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. 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, gdzie jedna grupa przepracowuje te elementy Backlogu i zapisuje efekty tej pracy, po czym przekazuje je do drugiej grupy, której zadaniem jest ich poprawienie, skrytykowanie lub znalezienie jakiegoś problemu, w tym, co otrzymali. 

Ostatecznie, przepracowanie jest efektem całej grupy, ale niekoniecznie jednocześnie cała sala czy wszyscy członkowie zespołu nad tym pracują. Technika ta usprawnia podejście pracy całego zespołu, praca odbywa się w sposób równoległy i, co ważne, w tych mniejszych grupach trochę prościej o aktywizację wszystkich. 

Wcześniej wspomniane sześcioosobowe grupy to raczej ekstremalny przypadek, zwykle są to trzy- może czteroosobowe grupy, dzięki czemu każdy uczestniczy w pracy. Jedna osoba pisze, druga mówi, trzecia pyta. Nie da się tam schować w tłumie, co jest bardzo proste na Refinemencie cało-zespołowym.

Warto pamiętać, aby tworząc te grupy stworzyć je w sposób taki najbardziej różnorodny pod kątem kompetencji. To pozwoli spojrzeć na konkretny problem z jak najróżniejszych perspektyw.

Alternatywą wersją poprzedniego podejścia, jest również praca w grupach, jednak praca ta odbywa się tak jakby offline, czyli poza tym naszym konkretnym warsztatem refinementowym. Grupy dostają wcześniej jakieś 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, bo muszą o coś dopytać, iść do innego zespołu, poprosić stakeholdera czy jakąś inną osobę, żeby im pomogła.

Technika ta pokazuje, że do Refinementu można podejść w sposób trochę iteracyjny. Chodzi o to, że z warsztatu nie musimy wyjść z rozwiązaniem gotowym od razu dla developmentu. Można to zorganizować właśnie w taki sposób, że pierwszy i trzeci krok, czyli zapoznanie z tematem i prezentacja efektów pracy, dzieją się podczas wspólnego spotkania, a praca bardziej kreatywna i wymagająca skupienie oraz zgłębienia tematu, dzieje się poza nim. 

Plusem takie podejścia iteracyjnego, jest to, że zyskujemy ten czas pomiędzy tymi konkretnymi etapami. Bardzo często przecież 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. Dlatego warto robić sobie takie przerwy, gdzie pozornie nie zastawiamy się nad rozwiązaniem, ale nasz mózg w tle przetwarza temat.

Inną metodą pracy w takich podgrupach, jest praca w podgrupach jednoosobowych. Mamy tu jakąś wytypowaną osobę do danego aspektu, która po prostu bierze na siebie przemyślenie tego i przynosi do grupy rezultat swojej pracy. Ta metoda ma dużą wadę polegającą na tym, że po prostu jednoosobowe rozpracowywanie tematu zawsze będzie miało jakieś ograniczenie, a ta jedna osoba nie będzie widziała wszystkiego. Szczególnym niebezpieczeństwem w tym podejściu 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. 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. 

Kto powinien brać udział w Refinemencie?

Odpowiedź jest prosta: w Refinemencie powinien brać udział cały zespół. 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. 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 robić Refinement? – zbiór porad

  1. Róbcie Refinement – 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.
  1. 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.
  1. Eksperymentu 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ę.

  1. 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ę”.
  1. 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.

Materiały i techniki, o których m.in. wspominamy w nagraniu:

O czym usłyszysz w odcinku?

  • 01:04 – Czy jest Refinement?
  • 05:29 – O micie panującym w środowisku.
  • 07:57 – Ważny aspekt regularnego prowadzenia Refinementu.
  • 10:49 – Ile czasu powinniśmy poświęcić na Refinement?
  • 15:45 – Jak realizować ten proces w zespole?
  • 18:37 – Propozycja modyfikacji.
  • 20:33 – O pracy offline.
  • 24:25 – O pracy w podgrupach jednoosobowych.
  • 26:21 – Kto powinien brać w tym wszystkim udział?
  • 37:33 – Jak robić Refinement? – zbiór porad

Zobacz wersję wideo

Jeśli odcinek Ci się podobał, koniecznie podziel się nim z innymi osobami, które Twoim zdaniem mogą go potrzebować.

Daj nam znać co sądzisz o samym odcinku:

Chcemy usprawniać podcast z każdym kolejnym odcinkiem, więc podpowiedz nam, jakie niedoskonałości Twoim zdaniem powinniśmy poprawić.

Mamy sporo pomysłów na to, co jeszcze moglibyśmy nagrać, ale jesteśmy bardzo otwarci na Twoją sugestię – przekaż nam hasło albo temat, o którym moglibyśmy opowiadać w kolejnych odcinkach.

TRANSKRYPCJA:

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. 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, jak byś go nazwał?

Kuba: „Przewodnik po Scrumie” Refinement 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, 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 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, 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 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, 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 – 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 dla tego, ż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 Refinemecie, 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 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 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 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.


Jeden komentarz do wpisu “#009 – Porządny Refinement”

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.

Newsletter „Porządny Agile”

.

Jesteśmy też tutaj

Podcast od kuchni. Tak nagrywamy dla Ciebie!

Jacek Wieczorek i Kuba Szczepanik
scenariusz do nagrania podcastu
Jacek Wieczorek Kuba Szczepanik podcast

Opinie naszych słuchaczy.

„To jest to! Ekstremalnie dobra dawka potrzebnej wiedzy. Część podcastów otwiera oczy, część porządkuje wiedzę. Polecam!”

„Mimo iż nie jestem bardzo związany z agilem/scrumem, jakieś doświadczenia z nim miałem („retrożale” ;), to bardzo przyjemnie się Panów słucha. Duża i bardzo konkretna dawka wiedzy, bez przynudzania, widać „napracowanie” przy każdym odcinku, jakość ścieżki audio na poziomie, całość w odbiorze sprawia profesjonalne wrażenie. Życzę obu prowadzącym sił do kontunuowania tego (nie)małego dzieła. :)”.

„Takich podcastów nam potrzeba!”

Oceń podcast. Kliknij poniżej.

Apple Podcast logo
logo stitcher
Wordpress Social Share Plugin powered by Ultimatelysocial