#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.

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 odcinka:

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.


One Reply to “#009 – Porządny Refinement”

Dodaj komentarz

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

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