Odpowiedzialności Zespołu Scrumowego na Refinemencie

Refinement to dość częsty obszar do poprawy w Zespołach Scrumowych. Usprawnianie go bywa problematyczne, choćby z powodu tego, że nie każdy wie, kto i za co jest odpowiedzialny w tym procesie. Podpowiadamy jakie zadania mogą mieć Deweloperzy, Product Owner i Scrum Master w procesie Refinementu. Nasze sugestie będą pomocne w ustaleniu odpowiedzialności Zespołu Scrumowego w procesie doskonalenia Backlogu Produktu.

Jednym z istotnych elementów usprawniania procesu Refinementu jest ustalenie odpowiedzialności Zespołu Scrumowego. Zatem jakie odpowiedzialności leżą po stronie Deweloperów, jakie u Product Ownera, a jakie u Scrum Mastera na etapie doskonalenia Backlogu Produktu?

Odpowiedzialności Deweloperów na Refinemencie

Deweloperzy przede wszystkim odpowiedzialni są za przygotowanie propozycji rozwiązań określonych potrzeb zawartych w Backlogu Produktu i artykułowanych przez Product Ownera. To nie Product Owner ma wiedzieć, czego konkretnie chce, w jego gestii leży klarowne przedstawienie problemu.

Zadaniem deweloperów jest też dogłębne poznanie zagadnienia i przemyślenie zasadności wdrażania różnych funkcjonalności, które przychodzą od klientów czy innych interesariuszy. Zapoznanie się z zagadnieniem przez deweloperów może przynieść lepsze rozwiązania niż te, które zostały zaproponowane przez osoby mniej techniczne. 

Kolejną odpowiedzialnością Deweloperów na Refinemencie jest komunikowanie szans i zagrożeń technologicznych. Chodzi tu o to, aby przedstawić plusy i minusy różnych rozwiązań. Przykładowo coś wydaje się szybkie do wdrożenia, ale jest mało wydajne, natomiast inne rozwiązanie może zająć więcej czasu, jednak być bardziej przyszłościowe i skalowalne na dodatkowe obszary biznesowe. 

Bardzo istotne jest to, aby Deweloperzy mieli postawę aktywną i brali udział w dyskusjach o różnych wdrożeniach, a nie biernie implementowali, to co zostało im zlecone.

Następną funkcją Deweloperów jest pomoc w podzieleniu elementów Backlogu Produktu na mniejsze części. Ich udział w tym jest istotny zwłaszcza wtedy, gdy aby dokonać sensownego podziału niezbędne jest zrozumienie możliwości jakie występują. Deweloperzy często najlepiej wiedzą, co ma sens wydzielić, gdzie będzie z tego zysk, a gdzie tego zysku będzie mniej. 

Znaczenie roli Deweloperów na przykładzie z życia jest historia Kuby z wczesnych etapów jego kariery. Będąc Scrum Masterem w swoim pierwszym zespole Deweloperzy wydewelopowywali pewien system związany z wystawianiem komentarzy. Product Ownerka zaproponowała podział na osobne historyjki do wystawienia komentarzy pozytywnych, negatywnych i neutralnych. Jak się jednak okazało, Deweloperzy używali do tego tylko jednej funkcji, która po prostu przyjmowała odpowiedni parametr w zależności od rodzaju komentarza. Stąd też podział na 3 historyjki nie miało sensu, bo z perspektywy wytwórczej było to jedno działanie. Product Ownerka nie miała świadomości, gdzie te linie podziału idą i jej propozycja bazowała na elementach interfejsu. 

Deweloperzy dzięki swojej wiedzy technicznej i bardzo dobrej znajomości produktu są często w stanie zaproponować bardziej sensowny podział, biorąc pod uwagę np. wydajność, skalowalność czy ewentualne dalsze możliwości rozbudowy.

Ostatnią odpowiedzialnością Deweloperów w procesie Refinementu jest ocena wielkości Backlogu Produktu. Może to dotyczyć oceny czasu pracy, czy oceny w jakiś jednostkach relatywnych typu Story Pointy albo po prostu oceny, czy jest to wystarczająco małe, aby wziąć to do Sprintu, czy jeszcze za duże. 

Ta ocena wielkości jest potrzebna do określenia, ile jesteśmy w stanie zrealizować w trakcie Sprintu i wykorzystywana jest w trakcie planowania. 

Odpowiedzialności Product Ownera na Refinemencie

Pierwszą odpowiedzialnością Product Ownera jest zapewnienie kontekstu biznesowego produktu. Innymi słowy, dba on o to, żeby wszystkie osoby, które uczestniczą w Refinemencie, bardzo dobrze rozumiały, dlaczego i dla kogo budują produkt oraz w jaki sposób chcą osiągnąć określone kroki milowe. Ważne jest też, aby to zrozumienie było na bieżąco aktualizowane. Z czasem oczywiście zespół coraz lepiej rozumie otoczenie biznesowe, a rolą Product Ownera jest wówczas pilnowanie, aby nie stracić tego kontekstu z oczu.

Ten kontekst biznesowy, o którym mówimy, może mieć kilka poziomów. Może to być kontekst całego produktu, czyli jaką mamy wizję, po co budujemy całe to przedsięwzięcie czy nową organizację. Może to być także bardziej przyziemny poziom dotyczący pojedynczych drobnych zmian – dlaczego musimy dodać ten przycisk? Dlaczego klient nie jest zadowolony z danej funkcjonalności? Dlaczego konkretną rzecz chcemy poprawić? Niestety wciąż się spotykamy z sytuacją, że ten szerszy kontekst jest pomijany i zwłaszcza osoby nowe w zespole mogą nawet nie wiedzieć, po co coś robimy. 

Drugą funkcją, którą widzimy dla Product Ownera na Refinemencie, jest pomoc w zrozumieniu konsekwencji i niuansów biznesowych wybranych rozwiązań. To trochę takie lustrzane odbicie szans i zagrożeń technologicznych, o których pisaliśmy w punkcie o odpowiedzialnościach Deweloperów. Deweloperzy mogą określić co jest bardziej lub mniej wydajnym rozwiązaniem, natomiast Product Owner może określić, że np. skala będzie większa o 100%, bo planujemy dużą promocję lub uruchamiamy nowe partnerstwo. 

Zatem w tym przypadku, zarówno Deweloperzy, jak i strona bardziej biznesowa, mogą wymienić się różnymi perspektywami i dopowiedzieć pewne założenia, a także przestrzec przed konsekwencjami, które nie są znane drugiej stronie. Przykładowo z pozoru drobna rzecz jak inwestowanie w kolejne rynki, może mieć szereg reperkusji technologicznych.

Trzecia ważna funkcja Product Ownera to rola łącznika, a nie pośrednika, w procesie docierania do interesariuszy. Chodzi o to, aby nie budować głuchego telefonu i unikać sytuacji, w której w celu uzyskania jakiejś odpowiedzi idziemy do product Ownera, który z kolei pójdzie do osoby X, która to osoba odpowie na pytanie, a Product Owner wróci z odpowiedzią do zespołu. Chodzi o to, aby Product Owner był w stanie wskazać osoby, które znają odpowiedź na pytanie  i do których Deweloper może sam się udać. Dzięki temu Deweloper ma szansę nie tylko poznać tego interesariusza, ale także zadać doszczegóławiające pytania, sparafrazować uzyskana odpowiedź, upewnić się, że rozumie, a przy okazji otrzymać jeszcze feedback do produktu. 

Jednocześnie takim podejściem zrywamy z błędnym założeniem, że Product Owner ma znać odpowiedzi na wszystkie pytania. Unikamy sytuacji, w której Product Owner naprędce wymyśla jakąś odpowiedź, aby nikt mu nie wytknął niekompetencji. Jego rolą jest pomoc w uzyskaniu odpowiedzi, a nie bycie omnibusem w każdej kwestii. 

Ostatnią odpowiedzialnością Product Ownera w procesie Refinementu jest podejmowanie decyzji związanych z Backlogiem Produktu. Może to wydawać się dosyć oczywiste, jednak chcemy tym punktem podkreślić, że to Product Owner podejmuje decyzje o kolejności elementów Backlogu Produktu, że coś jest do niego włożone, a nie odrzucone. 

Rzecz jasna, ostateczna odpowiedzialność w kwestii zarządzania Backlogiem Produktu jest u Product Ownera, jednak nie musi on tego robić własnymi rękami. Całkowicie w porządku jest sytuacja, w której to zespół tworzy i opisuje nowe elementy w Backlogu Produktu, a także zespół jakieś elementy usuwa. To może się wydarzyć tylko wtedy, gdy zespół bardzo dobrze rozumie produkt i jego kontekst biznesowy, a Product Owner i Deweloperzy są na tyle blisko, że mają do siebie zaufanie. 

Odpowiedzialności Scrum Mastera na Refinemencie

Scrum Master przede wszystkim zapewnia, że proces Refinementu jest przeprowadzony w zespole. Wspominamy o tym dlatego, że nie każdy zespół jest w stanie sensownie zdiagnozować, ile tego Refinementu jest potrzebne. Można na to spojrzeć w dwóch płaszczyznach. Pierwsza z nich, to zrozumienie, że Refinement nie musi przybierać formy spotkania. Refinement ma miejsce też wtedy, gdy pojedynczy Deweloper patrzy na konkretny element Backlogu Produktu lub dopytuje interesariusza o dane. Druga płaszczyzna to rezerwowanie salki, co nie jest równoznaczne z zapewnieniem Refinementu. Chodzi tu o zadbanie o to, że zespół rozumie po co ten Refinement się odbywa, jakie korzyści niesie, jakie techniki można na nim wykorzystywać i jakie w danym zespole najlepiej się sprawdzą. Zwłaszcza jeśli dotychczas w zespole nie był przeprowadzany Refinement, to rolą Scrum Mastera jest wyrobienie nawyku jego wykonywania. Scrum Master może być takim liderem zmiany, osobą, która przejdzie przez ten proces, zdiagnozuje przyczyny, przez które Refinement nie jest satysfakcjonujący dla zespołu. Pomoże on usprawnić ten proces czy zwiększyć jego efektywność. I nie chodzi tu tylko o wysłanie do wszystkich zaproszenia na spotkanie, tylko zadbanie o wartościowy efekt, czyli dobry  Backlog Produktu, który może później służyć jako punkt startu do przyrostowego dostarczania rozwiązania.

Drugą odpowiedzialnością Scrum Mastera, jest zadbanie o wcześniej wspomniane techniki przeprowadzania Refinementu. Jego zadaniem jest przedstawienie możliwych technik, wytłumaczenie ich, a także pomoc w wykorzystaniu tych technik w praktyce. Istnieje ogrom różnych podejść na temat tego, jak rozmawiać z klientem, użytkownikami czy interesariuszami. Jak zbierać ich oczekiwania, jak je lepiej zrozumieć, jakie pytania zadawać. Nie wszystkie one muszą być znane w zespole i to właśnie Scrum Master powinien pomóc dobrać najbardziej odpowiednie i wytłumaczyć jak je wykorzystywać.

Dodajmy tutaj, że nie to nie musi być patrzenie tylko z perspektywy pojedynczego elementu w Backlogu Produktu. Mogą to być też takie techniki jak Story Mapping, Impact mapping, czy praca z wizją produktu. I tu właśnie cała umiejętność Scrum Mastera, że potrafi on nimi żonglować i reagować odpowiednie do sytuacji. 

Ostatnia odpowiedzialność Scrum Mastera w przypadku, gdy Refinement ma postać spotkania, to pomoc w przeprowadzeniu spotkania w efektywny sposób. Więcej na temat efektywnego przeprowadzania spotkań mówiliśmy w dwóch wcześniejszych odcinkach podcastu – w odcinku 49. rozmawialiśmy o facylitacji spotkań, natomiast w odcinku 50. o organizacji spotkań online.

Odpowiedzialności Zespołu Scrumowego na Refinemencie

Mimo że poruszamy to jako ostatni wątek, to jest najważniejsza część w ramach omawianego zagadnienia. Pierwsza myśl, jaka przychodzi nam do głowy, to to, że cały Zespół Scrumowy odpowiada jako całość za wszystkie aktywności produktowe. Jest to rzecz jasna fragment definicji Zespołu Scrumowego, jednak świetnie przekłada się też na Refinement Backlogu Produktu. Oznacza on, że cały zespół szuka okazji do tego, aby te aktywności produktowe realizować. W zależności od tego, na jakim etapie rozwoju produktu jesteśmy, mogą to być jakieś eksperymenty produktowe, wzajemna pomoc, wychodzenie z ról, wyspecjalizowane wywiady czy też po prostu sprawdzenie statystyk.

Druga odpowiedzialność Zespołu Scrumowego jako całości jest to, że realizuje on Refinement z perspektywą powstania wartościowego przyrostu co Sprint. Chodzi tu o to, żeby podchodząc do Refinementu spojrzeć całościowo, a nie tylko z perspektywy pojedynczych elementów Backlogu Produktu. Czyli tak dobierać te elementy, aby łączyły się w jakiś sensowny przyrost. Warto tu brać pod uwagę także takie możliwości, jak przetestowanie produktu przez zaprzyjaźnionego klienta i uzyskanie feedbacku nim produkt stanie się on publiczny. 

Kolejna odpowiedzialność Zespołu Scrumowego to po prostu przygotowanie się do Refinementu. Nie należy zakładać, że to ktoś inny się przygotuje, a Zespół czeka, aż wszystko zostanie opisane przez interesariuszy lub przez jakiś inny zespół. Stąd jak już wcześniej wspomnieliśmy, warto zadbać o to, żeby ktoś przemyślał strukturę Refinementów, a jego uczestnicy, rzucili sobie na to luźno okiem przed spotkaniem. Oczywiście może zdarzyć się tak, że nie zawsze jesteśmy w stanie się przygotować z tym, co jest do zrobienia i raczej generujemy pytania, niż oczekujemy, że uzyskamy wszystkie odpowiedzi. Miejmy zatem świadomość, że dojdziemy do momentu, w którym nie dało rady się przygotować i musimy coś jeszcze dodatkowo skonsultować. 

Ostatnia z odpowiedzialności Zespołu Scrumowego to usprawnianie procesu pracy, żeby podnosić efektywność Refinementów. Może to przybierać najróżniejsze formy, np. możemy o tym porozmawiać na Retrospektywie lub całkowicie spontanicznie. Możemy też zrobić sobie też jakieś szybkie podsumowanie czy ewaluacje Refinementu (np. techniką Fist of five).

I jeszcze raz podkreślimy, że to nie sam Scrum Master czy Product Owner odpowiada za efektywny Refinement, jest to zadanie całego Zespołu Scrumowego. Każdy z członków może mieć pomysły co usprawnić, co zmienić, a co według niego nie działa. Mówimy o tym, ponieważ często spotykamy się z takim problemem,  że część członków zespołu narzeka na Refinement, ale niekoniecznie aktywnie uczestniczy, aby coś poprawić. 

Jeśli w Twoim zespole Refinement nie działa tak, jak powinien, to możemy pomóc Ci to zmienić. Ponieważ pomagamy wielu firmom w tym obszarze, to znamy różne rozwiązania i mamy szerokie spektrum doświadczeń w naprawdę różnorodnych zespołach. Działamy zwykle w ten sposób, że na krótki czas dołączamy do zespołu, poznajmy jego specyfikę i na bazie tego razem przeprowadzamy Refinement, ale inaczej niż zespół robił to do tej pory. Jeżeli Twój zespół potrzebuje takiego wsparcia, napisz do nas na adres porządnyagile.pl/kontakt.

A jako krótkie podsumowanie odpowiedzialności na Refinemencie przypomnimy po jednym naszym zdaniem najważniejszym punkcie z wymienionych powyżej. Zatem Deweloperzy proponują opcje na rozwiązanie potrzeb określonych w Backlogu Produktu. Product Owner zapewnia kontakt biznesowy produktu. Z kolei Scrum Master zapewnia, że proces Refinementu, jest przeprowadzany w zespole a Zespół Scrumowy realizuje Refinement z perspektywą powstania wartościowego przyrostu co Sprintu.

Transkrypcja podcastu „Odpowiedzialności Zespołu Scrumowego na Refinemencie”

Jacek: Pracujemy ostatnio z pewną organizacją i jedną ze sfer, która jest usprawniana, to kwestia Refinementów. Pomyśleliśmy, że więcej firm i zespołów miewa tutaj przestrzeń do poprawy, stąd pomysł na ten odcinek. 

Kuba: O czym powiemy w tym odcinku? Powiemy o tym, co może być zadaniem odpowiedzialności scrumowych, co może być odpowiedzialnością, czy zadaniem odpowiedzialności Deweloperów w rozumieniu scrumowym. Co może być zadaniem Product Ownera i jaka może być rola czy funkcja Scrum Mastera w procesie Refinementu Backlogu Produktu.

Jacek: Zaczniemy od odpowiedzialności Deweloperów. Przede wszystkim Deweloperzy proponują opcje na rozwiązania potrzeb określonych w Backlogu Produktu. Można spojrzeć na to zagadnienie z takiej strony, że Product Owner przynosi pewien problem, pewną potrzebę. Definiuje tak bardzo, ogólnie rzecz ujmując, co jest do zrobienia. Natomiast Deweloperzy proponują konkretne rozwiązanie, czyli dają nam odpowiedź na pytanie, jak można zrealizować konkretną potrzebę, konkretne wymagania, konkretny ficzer, jakkolwiek sobie to nazwiemy. 

Kuba: I to jest, wydawałoby się banalne, bo to jest podstawowa funkcja Deweloperów w Zespole Scrumowym. Natomiast to generowanie rozwiązań, to może chodzić też nam na przykład o to, że nie oczekujemy, że ktokolwiek inny niż Deweloperzy w zespole będą te rozwiązania proponować. No i akcent położę też na tę opcję. Czyli przychodzi Product Owner, rozmawiamy z interesariuszami, pojawia się jakaś konkretna potrzeba biznesowa i to Deweloperzy generują te rozwiązania. I mało tego, najczęściej na dane rozwiązanie, na dany problem, na daną potrzebę biznesową, jest więcej niż jedno rozwiązanie. Więc to jest świetny temat do eksploracji, do wygenerowania tych rozwiązań, pokazania ich różnic, czy jakichś wariantów – co daje jakaś jedna opcja, co daje inna opcja. Więc tutaj nie oczekujemy, że ktoś inny wygeneruje te rozwiązania, zwłaszcza nie ktoś spoza zespołu. Czasami spotykam się też z jakimś takim oczekiwaniem, że to na przykład Product Owner będzie wiedział czego chce. Lub inny przypadek. Takie też niedogadanie trochę, że w zasadzie wiernie bierzemy to, co jest nam zlecone. Trochę o tym wspominaliśmy przy odcinku o „Zrozumieniu prawdziwych potrzeb klienta”. Czyli to, że klient na przykład, czy użytkownik, czy Product Owner przynoszą zlecenie na zrobienie nam sortowanej listy. To w zasadzie nic nie znaczy. Powinniśmy wgłębić jako Deweloper, w to, co tam dokładnie jest potrzebne i dopiero na tej bazie wygenerować rozwiązania.

Kuba: Drugą funkcją, którą mają Deweloperzy na Refinemecie, to komunikowanie szans i zagrożeń technologicznych. Mamy tu na myśli taką sytuację, że tak jak wspomniałem, opcje na rozwiązania mogą być różne. I może być też tak, że na przykład rozwiązanie, tak upraszczając do jednego wymiaru, na przykład jedna z opcji jest rozwiązaniem szybkim, ale nie wydajnym. Jakieś rozwiązanie pośrednie, i na przykład opcja super wypas, idealna technologicznie, bardzo skalowalna, bardzo wydajna, ale też na przykład, o wiele dłużej trwająca. I tutaj od Deweloperów oczekuję w czasie procesu Refinementu, że będą umieć pokazać te plusy i minusy. Być może jakiś balans między poszczególnymi wymiarami. Ich jest oczywiście zazwyczaj więcej, niż ten jeden jedyny, który wymieniłem, żeby ewentualnie w toku tej dyskusji, uświadomić interesariuszy Product Ownera. Być może między sobą też przedyskutować te różnice, ale w szczególności, żeby tutaj też znowu przez jakieś niedopowiedzenia, na przykład nie zatrzymać się na etapie – No dobra, zlecili nam, to wkładamy ten przycisk. Oczywiście wszystko padnie, ale bierzemy, bo nam tak zlecają, albo od tego tu jesteśmy, żeby to wiernie zaimplementować, a niekoniecznie dyskutować. 

Jacek: I to jest niestety postawa, z którą się spotykam. Na takiej zasadzie, że zbytnie uproszczenie roli Dewelopera zachodzi, na zasadzie, ja tylko się zajmuję odtąd dotąd. W sumie nikt mi nie płaci za to, żebym z kimś tam rozmawiał, żebym komuś coś tam analizował i przedstawiał. Wszystko ma być ładnie rozpisane i wtedy ja to zaimplementuje. Oczywiście jest to ścieżka donikąd, a już na pewno jest to dalekie od koncepcji zespołu produktowego, który czuje odpowiedzialność za produkt.

Jacek: Idąc dalej, kolejną funkcją Deweloperów, jest pomaganie w podzieleniu elementów Backlogu Produktu na mniejsze części. Bardzo często jest tak, że żeby dokonać sensownego podziału, trzeba rozumieć, jakie są możliwości. Co jest sens wydzielić? Co może niekoniecznie? Gdzie będzie ten zysk? Gdzie tego zysku będzie mniej? I tutaj aktywna postawa Deweloperów, na takiej zasadzie, że są w stanie zaproponować te płaszczyzny cięcia, podpowiedzieć, zastanowić się, czy to jest wystarczająco już mały kawałek pracy, jeżeli chodzi o ryzyka związane z podejmowaniem takiego tematu. Więc zdecydowanie jestem fanem tego, żeby ta praca dotycząca podziału, nie spoczywała tylko na Product Ownerze, tylko raczej, żeby przynosił, być może trochę większe kawałki do zespołu, i żeby ten podział był dokonywany po prostu przy zaangażowaniu Deweloperów. Deweloperów oczywiście, cały czas z Kubą mówimy w rozumieniu odpowiedzialności scrumowych.

 Kuba: I to dzielenie mam taki często używany przeze mnie przykład z mojej kariery wczesnej. W moim pierwszym zespole, w którym byłem Scrum Masterem, mieliśmy taki przypadek związany z komentarzami na Allegro. Programiści wydewelopowywali pewien system związany też z wystawianiem komentarzy, no i Product Ownerka w tym przypadku zaproponowała podział na osobną historyjkę do wystawienia komentarzy pozytywnych, negatywnych i neutralnych. Wtedy tak to jeszcze wyglądało. No i rzecz w tym, że Deweloperzy pod spodem używali do tego jednej funkcji, która tylko po prostu przyjmowała parametr, jaki jest rodzaj komentarza, a cała reszta to była jedna implementacja. Więc bardzo szybko pokazali jej, że co z tego, że podzieliła to na trzy historyjki, jak tak naprawdę z perspektywy wytwórczej, to tak naprawdę jednak jest jedno działanie. I te linie podziału akurat są w innych miejscach. Czasami ta linia podziału, to tak też obrazowo mówiąc, to to właśnie profesjonaliści Deweloperzy widzą, gdzie są te cienkie przerywane linie, po których można ciąć, a gdzie ich nie ma, mimo że wydawałoby się, że faktycznie to są jakieś osobne elementy. Bez tych kompetencji Deweloperskich, ten taki naturalnie nasuwający się sposób podziału, to jest po pojedynczych elementach interfejsu użytkownika. A jeśli mówimy o jakichś produktach cyfrowych, które mają ten interfejs użytkownika, no i to jest trop na dzielenie, ale nie zawsze najlepszy. I to właśnie zaangażowanie Deweloperów da jakiś sensowny, lepszy podział. Włącznie z tymi bardziej zaawansowanymi abstrakcyjnymi metodami. Czy właśnie po wydajności, po jakiejś skalowalności, po możliwościach dalszej rozbudowy? Prostsze, trudniejsze implementacje. Jest tych linii podziału więcej. I tak na końcu to Deweloperzy będą to wykorzystywać. Więc to też Deweloperzy wiedzą lepiej, gdzie ten podział jest możliwy i gdzie jeszcze bardziej da się podzielić na te naprawdę już atomowe cząstki. 

Kuba: Ostatnia funkcja, którą chcemy wymienić, jeśli chodzi o odpowiedzialność Deweloperską w czasie procesu Refinementu, to ocena wielkości elementów Backlogu Produktu. Specjalnie używam tutaj takiego słowa żywcem wziętego ze Scrum Guide’a, bo to jest takie generyczne pojęcie na wszystkie możliwe wersje tego, co różne zespoły realizują. Albo ocena czasu pracy, albo ocena w jakiś jednostkach relatywnych, typu Story Pointy, czy po prostu ocena. To jest wystarczająco drobno podzielone, albo to jest jeszcze za duże, żeby wziąć do Sprintu. Więc tutaj Scrum nie sugeruje ściśle jednej, jedynej słusznej wersji, natomiast jednak wspomina o tym, że to ci, którzy wykonują pracę w Sprincie, będą czy są odpowiedzialni w procesie Refinementu za to, żeby ocenić wielkość elementów. Czyli przez zaprzeczenie. Nie jest to funkcja Product Ownera, zwłaszcza jeśli mówimy tutaj o funkcji, czy odpowiedzialności, która nie jest łączona z żadną funkcją Deweloperską. To też nie jest odpowiedzialność kogokolwiek poza Zespołem Scrumowym. To ci, co wykonują pracę, oceniają jej wielkość.

Jacek: I warto tutaj też rozumieć, po co ta ocena wielkości jest nam potrzebna. Ona występuje bardziej po to, żeby mieć dane do podjęcia decyzji, a nie po to mówiąc wprost, żeby zalogować czas pracy. Ja częściej jednak spotykam się z taką sytuacją, w której ta ocena wielkości, ona raczej służy określeniu, ile jesteśmy w stanie zrealizować w trakcie Sprintu. Bardziej jest wykorzystywana do jakiegoś procesu planowania. Przyznam szczerze, że dawno nie widziałem takiej dyskusji, na zasadzie – Skoro to jest takie duże, no to może niekoniecznie się powinniśmy tym zajmować, albo może w szczególności powinniśmy się przyjrzeć, czy nie ma jakiejś sensownej linii podziału – No bo z perspektywy Product Ownera może być tak, że jak sobie to zważy, wartość tego elementu Backlogu Produktu z ceną, no to po prostu może się to nie zgadzać. I jakby do takiego zastosowania, z mojej perspektywy te oceny nam mogłyby służyć. 

Jacek: Idąc dalej przechodzimy do odpowiedzialności Product Ownera. Co może realizować Product Owner w trakcie Refinementu? Przede wszystkim zapewnia kontekst biznesowy produktu. Czyli z mojej perspektywy dba o to, żeby osoby, które uczestniczą w Refinemencie, bardzo dobrze rozumiały, dlaczego budujemy produkt? Dla kogo budujemy produkt? Jaki problem rozwiązujemy? W jaki sposób chcemy pewne kroki milowe osiągnąć? I to zrozumienie w zespole, powinno być budowane na bieżąco. No i Product Owner wydaje się tutaj takim absolutnie pierwszym punktem, jeśli chodzi o to, żeby taki kontekst zapewniać. Z czasem oczywiście zespół ten kontekst biznesowy może mieć coraz większy. Na zasadzie, może coraz lepiej rozumieć otoczenie biznesowe. Oczywiście może zespół też ten kontekst biznesowy dociągać od wszelkiego rodzaju interesariuszy. Natomiast w sytuacji, gdyby żadna z tych historii się nie wydarzyła, dla mnie Product Owner jest takim bezpiecznikiem, który gdy widzisz, że tego kontekstu brakuje, a może to zdiagnozować na przykład poprzez brak pytań, albo takie bardzo płytkie propozycje rozwiązań, no to wtedy ten kontekst może przypomnieć, wprowadzić. 

Kuba: I ten kontekst, o którym Jacek teraz mówisz, on ma kilka takich warstw, czy może takich poziomów lotu. Bo to może być kontekst, w ogóle całego produktu. Jaką mamy wizję? Po co budujemy całe te przedsięwzięcie, system? Całą, może nową organizację? Ale to też może być, przeskakując do bardzo, bardzo przyjemnego poziomu –  Dlaczego musimy dodać ten przycisk? Dlaczego klient jest niezadowolony z istniejącej zakładki? Dlaczego jednak chcemy poprawić, czy tutaj zmienić? Czy nawet wycofać, zamknąć? Więc tutaj ten kontekst, zarówno na poziomie produktu, jako całości jego większych składowych, aż do poziomu pojedynczych drobnych zmian. Serce mnie boli i uszy i oczy pieką, jak widzę Refinementy, na których bardzo szybko przeskakuje się do tego poziomu – kryteria akceptacji. Lecimy, lecimy, lecimy. Bardzo dokładnie rozpisane. I teoretycznie na poziomie takim zewnętrznym, prawie że wszystko jest dobrze od strony tej technicznej. Natomiast kompletnie brakuje jakiegoś takiego słowa wstępu. Po co, w ogóle to robimy? Dlaczego jest to potrzebne? Jaki jest ten ten szerszy kontekst? No i tak, jak mówisz, później są negatywne konsekwencje. Myślę sobie, że tutaj jest całe spektrum. Zwłaszcza początkujące osoby w zespole, po prostu w ogóle nie potrafią sobie umiejscowić tego czegoś, co robimy, w jakimś szerszym obrazie. Każdego członka zespołu, może zmotywować zrozumienie, po co to robimy. A te bardziej zaawansowane w zespole osoby, jak wiedzą, po co coś jest robione, to też bardziej mogą kontrybuuować tymi swoimi rozwiązaniami, jakimiś alternatywnymi propozycjami, o których mówiliśmy chociażby w kontekście developera, chwilę temu.

Kuba: Drugą funkcją, którą widzimy dla Product Ownera na Refinemencie, czy w procesie Refinemetu Backlogu Produktu to to, że Product Owner pomaga zrozumieć konsekwencje i niuanse biznesowe wybranych rozwiązań. Czyli trochę takie lustrzane odbicie tego, co mówiliśmy o szansach i zagrożeniach wybranych różnych opcji rozwiązań technologicznych. Tak jak Deweloperzy mogą powiedzieć, tu jest bardziej, albo mniej wydajne rozwiązanie, to też Product Owner może powiedzieć słuchajcie, tu będzie skala większa 100%, niż do tej pory, bo tak się spodziewamy. Bo będzie duże promocja, będzie jakaś reklama, uruchamiamy nowe partnerstwo. Więc tutaj, te wybrane rozwiązania, tak naprawdę obie strony tej układanki, zarówno Deweloperzy, jak i ta strona tutaj bardziej biznesowa, tak naprawdę mogą się wymienić tymi perspektywami. Pokazać te zmienne, dopowiedzieć pewne założenia, które być może nie są znane, albo nie są znane konsekwencje tych założeń. Czyli też te często bardziej złożonych tutaj jakichś przedsięwzięciach biznesowych. Wydawałoby się jakaś tam drobna rzecz, typu będziemy bardzo mocno inwestować w kolejne rynki, może mieć szereg reperkusji technologicznych. I o ile nie są one przedyskutowane, to może przez jakiś czas nie wejść i być na przykład nieodpowiednio wcześnie uwzględnione przez Deweloperów. 

Jacek: Ten komentarz odnośnie konsekwencji czy niuansów, on jest możliwy tylko wtedy, jeśli faktycznie wrócimy do punktu pierwszego i jesteśmy w sytuacji, w której Deweloperzy proponują różne rozwiązania. Wtedy można skomentować, że to tak, a to nie, a to jest niemożliwe z powodu X, a to byłoby fajne, gdyby jakiś tam warunek był spełniony. W momencie, kiedy kompletnie wypuszczamy tę dyskusję, tak jak Kuba mówił, czyli bardzo szybko idziemy do kryteriów akceptacji i już rozmawiamy, jak konkretnie coś ma być zaimplementowane, to może być tak, że po prostu stracimy szansę na to, żeby stworzyć sytuację, w której Product Owner tym kontekstem, tymi niuansami, czy konsekwencjami, będzie w stanie zespół nakarmić. 

Jacek: Trzecia ważna funkcja Product Ownera, jest łącznikiem, a nie pośrednikiem w procesie docierania do interesariuszy. Chcielibyśmy doprowadzić do sytuacji, w której, jeżeli jest jakieś pytanie w zespole, trzeba z kimś porozmawiać, zdobyć jakąś dodatkową wiedzę, zrozumieć lepiej proces, który staramy się zaimplementować, no to, żeby nie budować głuchego telefonu. Czyli pytanie. Zamiast iść do Product Ownera, który pójdzie do osoby X, która odpowie i Product Owner wrócił do zespołu, raczej byśmy chcieli sytuację, w której Product Owner jest w stanie powiedzieć – Na to pytanie odpowie ci Tomek z credit risku, z piętra 5. Co powoduje, że Deweloper niezależnie od tego, za co konkretnie odpowiada w zespole, po pierwsze ma szansę poznać tego interesariusza, ma szansę dotrzeć do źródła, ma szansę zadać te pytania, które dla tej osoby, która pyta, są ważne. Sparafrazować, upewnić się, że rozumie. No i też zbudować jakąś tam mikro relację z osobą, która może mieć sensowny feedback do produktu. Wszystko to, co powiedziałem, tracimy w momencie, kiedy spłaszczamy temat, zadajemy pytanie Product Ownerowi, no i on idzie robić swoją robotę. Natomiast, odpowiedź jakąś dostaniemy, ale moim zdaniem nie warto funkcjonować w ten sposób. 

Kuba: I tego wprost Jacek nie mówisz, ale to tak naprawdę tą wytyczną tutaj wychodzimy naprzeciw takiemu oczekiwaniu, które niektóre zespoły mają, że Product Owner zna odpowiedzi na wszystkie pytania, i to jeszcze na miejscu na żywo. W sensie, jak cię zapytam o dowolną rzecz to, ty drogi Product Ownerze masz znać odpowiedź. I to jest ślepa uliczka. Ona generuje czy dąży do tego, żeby mieć takich Product Ownerów omnibusów, albo Product Ownerów świetnych ściemniaczy. Czyli nie znam odpowiedzi, ale szybko coś wymyślę. Przyjmiecie to, później zrobimy i się zobaczy. Eksperyment, iteracje. Niekoniecznie ten kierunek wspieramy, ale też nie wspieramy tego, żeby w ogóle oczekiwać, że Product Owner ma pełną wiedzę, kompletną wiedzę. W większości złożonych produktów, jest to mało realistyczne i zamykające też okazję do bardzo owocnych, bardzo interesujących interakcji. Więc tutaj Product Owner nie spełnia tej mitycznej funkcji omnibusa i czuje się komfortowo z tym, że są pytania, na które nie zna odpowiedzi. Są pytania, na które umie wskazać kto powinien tą odpowiedź udzielić. Zwłaszcza tak, jak mówię w takich złożonych produktach, a spotykam takie chociażby w branży finansowej. To produkt jest skrzyżowaniem tak wielu profesji, że po prostu nie istnieje w firmie osoba, która by pojęła to jako całość. I tak jak Jacek wymienia jest grupa interesariuszy ekspertów, znających się dokładnie na tej wybranej cząstce, do której zespół może się udać, żeby sobie dogadać szczegóły, dopytać, zrozumieć potrzeby. I Product Owner jest tu bardziej właśnie osobą, która zna właściwe osoby, a nie osoba, która zna odpowiedzi na właściwe pytania. 

Kuba: I ostatnią funkcją, którą wskazujemy jako istotną dla Product Ownera w procesie Refinementu, to podejmowanie decyzji związanych z Backlogiem Produktu. To też wydawałoby się dosyć oczywiste. I to jest dla mnie podstawowa funkcja Product Ownera, podejmowanie decyzji, ale chcemy tym punktem tutaj uwypuklić to, że to Product Owner podejmuje decyzje o kolejności elementów Backlogu Produktu, w ogóle o tym, że coś jest włożone do tego Backlogu Produktu, że się w nim znajduje, a nie jest odrzucone. O jakiejś kolejności związanej z wdrożeniami, zakresami tych wdrożeń, jeśli mówimy o jakimś rozwoju kilkukrokowym. To są rzeczy, o które oczekuję, że o których będzie decydował Product Owner. I oczekuje też, że inne funkcje w Zespole Scrumowym będą akceptować tę odpowiedzialność tutaj productownerską.

Jacek: Ale żeby nie było tak kolorowo, no to skoro mówimy o zarządzaniu Backlogiem, no to odpowiedzialność oczywiście ostateczna jest na Product Ownerze, natomiast on nie musi tym Backlogiem zarządzać własnymi rękoma. Więc to jest absolutnie w porządku, że to przykładowo zespół tworzy nowe elementy w Backlogu Produktu, zespół je opisuje, zespół jakieś elementy usuwa. No i oczywiście wszystko to, co mówię, jest możliwe tylko w sytuacji, gdy zespół bardzo dobrze rozumie produkt, który buduje. Bardzo dobrze rozumie kontekst biznesowy. No i Product Owner i developerzy są na tyle blisko, że występuje jakaś tam forma zaufania, która po prostu pozwala, z jednej strony pozwala Product Ownerowi spać spokojnie, z drugiej strony daje wystarczające pole do działania dla Deweloperów. 

Jacek:  Trzecia odpowiedzialność, o której powiemy w kontekście Refinementu, to Scrum Master. Co robi Scrum Master na Refinemencie? Przede wszystkim zapewnia, że proces Refinementu jest przeprowadzany w zespole. Myślę, że takim punktem startu tej myśli jest to, że nie każdy zespół jest w stanie sensownie zdiagnozować, ile tego Refinementu jest potrzeba. To bardzo częste pytanie, ile powinniśmy robić Refinementów? No i oczywiście jest próba poszukiwania tych odpowiedzi w internecie, gdzie można znaleźć różne sugestie jakieś takie, ile godzin w tygodniu, ile procent. I są to jakieś wskazówki, o które można się oprzeć. Natomiast moim zdaniem o wiele lepsze jest podejście, że tyle Refinementu powinno się odbywać, ile zespół potrzebuje. I takie sugestie bym się spodziewał od Product Ownera. Widzę Kuba, że się śmiejesz. 

Kuba: Zespół, który dzisiaj odwiedziłem na Refinemencie, w ramach zaproszenia w Outlooku wkleja Karola Strasburgera z podpisem „Jak często powinno się robić Refinement.? Jak najczęściej”.

 Jacek: Jasne. W każdym razie ten przykład pokazuje, co to z mojej perspektywy oznacza, że zapewnia, że proces Refinementu jest przeprowadzany w zespole. Jakby tutaj na co najmniej dwóch płaszczyznach można spojrzeć. Pierwsza płaszczyzna jest taka, że powinno być zbudowane zrozumienie, że Refinement nie musi przybierać formy spotkania. Na takiej zasadzie, że pojedynczy Deweloper, patrzący sobie w tam jakiś element Backlogu Produktu, czy dopytujący interesariusza, czy jakiegoś eksperta o jakieś dane, to też jest Refinement. Na to warto zwrócić uwagę. Drugi aspekt jest taki, że na pewno nie jest tak, że zapewnianie procesu Refinementu, to jest zarezerwowanie salek i spotkań. Rola, w którą często Scrum Master, albo wpada, albo jest spychany. I to też mówiąc o zapewnianiu, że Refinement jest w zespole. To nie to mamy na myśli, że jest salka, że jest zorganizowane spotkanie. 

Kuba: I pewnie to, co mamy na myśli i tak nie wybrzmi wystarczająco mocno. Ale chodzi nam o to, że w zespole prawdopodobnie trzeba zrobić pewien proces zmiany. Jeśli zespół do tej pory nie robili Refinementu, a teoretycznie korzysta ze Scruma, to trzeba jakoś przejść z tym zespołem przez uświadomienie sobie, po co w ogóle Refinement. Co on nam może dać? Być może przejście przez jakieś techniki, bo być może zespół nie do końca umie to robić, nie zna technik, albo nie ma umiejętności, żeby je realizować. Czy też jakieś takie domknięcie, że zrealizowane próby faktycznie dają jakieś pozytywne efekty? Więc zbudujmy sobie z tego nawyk. I tutaj to Scrum Master może być takim liderem zmiany. Osobą, która razem z całym zespołem oczywiście, ale przejdzie przez ten proces. Zdiagnozuje, z jakiego powodu ten Refinement jest niesatysfakcjonujący dla zespołu i pomoże go użyć. Pomoże ten proces usprawnić, czy zwiększyć jego efektywność. I tutaj nie chodzi tylko o fakt, że w kalendarzu jest zaproszenie, albo że jest ich odpowiednio dużo, albo mają śmieszny obrazek. Tylko chodzi o to, że efektem tego wszystkiego jest efektywny, skuteczny Refinement. Czyli też dobry Backlog Produktu, który może później służyć jako punkt startu do przyrostowego dostarczania rozwiązania. 

Kuba: Drugą odpowiedzialnością Scrum Mastera, już trochę wymieniłem w tym poprzednim punkcie, to opowiadanie technik przeprowadzania Refinementu i pomoc w wykorzystaniu ich w praktyce. Tak, jak na techniki Retrospektywy, techniki planowania, również na Refinement jest mnogość bardzo różnych, bardzo różniących się od siebie podejść. Na temat tego, jak rozmawiać z klientem, z użytkownikami, z interesariuszami. Jak zbierać te oczekiwania, jak je lepiej zrozumieć, jakie pytania zadawać, jak wizualizować to wszystko, co jest tutaj przedmiotem, czy procesem pracy. Ale również te takie bardziej klasyczne techniki, jakieś diagramy, jakieś grafy, jakieś mapy myśli, czy nawet stara dobra dokumentacja. To są wszystko praktyki, to są wszystko czynności związane z procesem Refinementu i może się okazać, że w danym zespole, albo te techniki nie są znane, albo nie są używane w jakiś skuteczny sposób. I to oczekiwałbym od Scrum Mastera, że przynajmniej wybraną grupę tych technik zna, kojarzy. Umie zadawać pytania, umie podpowiedzieć, umie pokazać przykłady. I tak też krok po kroku, przypadek po przypadku, umieć wprowadzić to do zespołu. 

Jacek: I to, co tutaj bym dodał to to, że to nie musi być patrzenie, tylko takie z perspektywy pojedynczego elementu w Backlogu Produktu. Ale Refinement, to może być też spojrzenie trochę szersze. Czyli takie techniki jak Story Mapping, Impact mapping, czy praca z wizją produktu, czy być może przypomnienie sobie persony, którą kiedyś sobie stworzyliśmy, albo próba walidacji, czy ta persona to faktycznie jest to. Tak bezosobowo to zabrzmiało. No to to też są rzeczy, które przybliżają nas do realizacji, do stworzenia lepszego Backlogu Produktu. I myślę, że cała umiejętność Scrum Mastera, to jest umiejętność też żonglowania tym. Żeby móc tym żonglować i potrafić odpowiednio zareagować. No to po prostu trzeba w tym narzędziowniku te wszystkie techniki mieć. Czyli przykładowo, jeżeli Scrum Master diagnozuje, że na przykład Refinementy idą bardzo ciężko i to wprost słychać, albo nie wprost, że zespół tak do końca nie czuje w ogóle, co jest tym, co mają stworzyć. No to być może to jest właśnie moment, żeby sobie użyć przykładowej Story Mapy, która jest świetnym narzędziem właśnie do tego, żeby tę mgłę, mówiąc tak metaforycznie, z tego produktu trochę rozdmuchać i pokazać z lotu ptaka trochę szerszy obrazek.

Jacek: I ostatnio odpowiedzialność Scrum Mastera. Jeżeli Refinement ma postać, czy formę spotkania, no to pomaga przeprowadzić takie spotkanie w efektywny sposób. Więcej o tym, jak przeprowadzić efektywne spotkanie mówiliśmy już w podcaście się z Kubą. To był odcinek 49. i odcinek 50, gdzie mówiliśmy zarówno o facylitacji spotkań, jak i o tym jak przeprowadzić je w formule online. Więc odsyłamy do tego materiału, akcentując tylko to, że jest znacząca różnica, kiedy spotkanie toczy się samo i jest różnica, kiedy ktoś panuje nad spotkaniem, ma pomysł na to spotkanie, ma koncepcję, ma jakiś szkielet. Wie, z czym chcemy wyjść. Być może osoby, które biorą udział dostały wcześniej jakieś materiały do zapoznania się. Suma detali, które robią świetną różnicę.

Kuba: I omówiliśmy trzy odpowiedzialności scrumowe. Czyli funkcję Deweloperów, Product Ownera i Scrum Mastera na Refinemencie. Natomiast nie wspomnieliśmy, a czujemy, że to jest najważniejsza część, to to, jaka jest odpowiedzialność całego zespołu scrumowego w procesie Refinementu. I tutaj pierwsza myśl, to to, że cały Zespół Scrumowy odpowiada jako całość za wszystkie aktywności produktowe. To jest fragment, żywcem wyjęty z definicji czym jest Zespół Scrumowy. I to się świetnie też przekłada na Refinement Backlogu Produktu. To oznacza, że to cały zespół szuka okazji do tego, żeby te aktywności produktowe realizować. I w kontekście Refinementu, tu mogą być naprawdę bardzo różnorodne momenty, różnorodne chwile. To też bardzo zależy od tego, na jakim etapie rozwoju produktu, w ogóle jesteśmy w danym zespole, czy jakichś jego dalszego, kolejnego etapu. To mogą być pewne eksperymenty produktowe, pomoc, wychodzenie wzajemnie z ról, realizowanie czegoś, do czego w sumie nikt się jakoś nie czuje. Wyspecjalizowane jakieś wywiady, jakieś wizyty, jakieś sprawdzenie statystyk. Zwłaszcza te etapy takie bardzo wczesne w produkcie, czy w danym etapie rozwoju danego produktu, mogą oznaczać bardzo ciekawe momenty, ale też te momenty, które wymagają zaangażowania wszystkich uczestników, otwartości na to, żeby zaangażować się w rozwój produktu, szeroko rozumiany, a nie tylko trzymać się swojej ścisłej profesji. Tej, za którą za którą firma płaci, albo tej, którą sobie wpisać wpisujemy w opisie stanowiska na LinkedIn’ie czy w CV.

Jacek: Druga odpowiedzialność Zespołu Scrumowego jako całość jest taka, że realizuje Refinement z perspektywą powstania wartościowego przyrostu co Sprint. I ten punkt może być trudny do wytłumaczenia w jasny sposób, ale spróbuję. Mianowicie chodzi o to, że podchodząc do Refinementu, nie chodzi o to, żebyśmy tylko spojrzeli z perspektywy pojedynczych elementów Backlogu Produktu. Na zasadzie takiego podejścia taśmowego. Czyli wpadają jakieś tam elementy. To trzeba zapytać po co, dlaczego, jaka jest potrzeba? Być może powstanie jakiś User Story, być może powstaną jakieś kryteria akceptacji, być może jakieś scenariusze testowe. Może jakaś makieta? Tylko chodzi, o to, żeby oprócz spojrzenia na pojedynczy element Backlogu Produktu potrafić spojrzeć też na całość. Na takiej zasadzie, które elementy musielibyśmy zrealizować i w jakim stopniu, żeby to się wspięło w jakiś sensowny przyrost, który jeżeli mamy taką możliwość, to być może możemy wydać. Być może możemy komuś pokazać. Być może zaprzyjaźniony klient będzie w stanie tego świeżego produktu poużywać, zanim on stanie się publiczny i da nam informację zwrotną. W skrajnym przypadku może być tak, że wszystkie elementy Backlogu Produktu będą dobrze przygotowane. My je będziemy realizować, ale nasz produkt będzie gotowy dopiero w dniu, kiedy zakończymy ten ostatni element, który jest tym punktem kulminacyjnym produktu. Nie o to chodzi. Tak naprawdę w podejściu zwinnym my chcemy mieć przyrost. Często my chcemy mieć przyrost na koniec Sprintu. No i warto też wchodząc w proces Refinementu mieć z tyłu głowy to, że ten produkt chcielibyśmy, żeby się wyłaniał w trakcie pracy. 

Jacek: Druga odpowiedzialność Zespoły Scrumowego jako całość jest taka, że realizuje Refinement z perspektywą powstania wartościowego przyrostu co Sprint. I ten punkt może być trudny do wytłumaczenia w jasny sposób, ale spróbuję. Mianowicie chodzi o to, że podchodząc do Refinementu, nie chodzi o to, żebyśmy tylko spojrzeli z perspektywy pojedynczych elementów Backlogu Produktu. Na zasadzie takiego podejścia taśmowego. Czyli wpadają jakieś tam elementy. To trzeba zapytać po co, dlaczego, jaka jest potrzeba? Być może powstanie jakiś User Story, być może powstaną jakieś kryteria akceptacji, być może jakieś scenariusze testowe. Może jakaś makieta? Tylko chodzi, o to, żeby oprócz spojrzenia na pojedynczy element Backlogu Produktu potrafić spojrzeć też na całość. Na takiej zasadzie, które elementy musielibyśmy zrealizować i w jakim stopniu, żeby to się wspięło w jakiś sensowny przyrost, który jeżeli mamy taką możliwość, to być może możemy wydać. Być może możemy komuś pokazać. Być może zaprzyjaźniony klient będzie w stanie tego świeżego produktu poużywać, zanim on stanie się publiczny i da nam informację zwrotną. W skrajnym przypadku może być tak, że wszystkie elementy Backlogu Produktu będą dobrze przygotowane. My je będziemy realizować, ale nasz produkt będzie gotowy dopiero w dniu, kiedy zakończymy ten ostatni element, który jest tym punktem kulminacyjnym produktu. Nie o to chodzi. Tak naprawdę w podejściu zwinnym my chcemy mieć przyrost. Często my chcemy mieć przyrost na koniec Sprintu. No i warto też wchodząc w proces Refinementu mieć z tyłu głowy to, że ten produkt chcielibyśmy, żeby się wyłaniał w trakcie pracy. 

Kuba: Następna odpowiedzialność całego Zespołu Scrumowego w procesie Refinementu, to przygotowanie się do Refinementu. Tu mamy tu na myśli tak przez trochę negację nieprzyjęcie założenia, że wszystko odbędzie się dopiero na przykład na spotkaniu. Albo przyjęcie założenia, że ktoś inny się przygotowuje, przyniesie na gotowe, a cały zespół czeka, póki nie zostanie wszystko opisane na przykład przez interesariuszy, przez zlecających, przez jakiś inny zespół. To pasywnie przyjmujemy założenia, że się doczekamy, albo przyjmujemy założenie dopiero w trakcie faktycznej spotkaniowej pracy, czy warsztatowej pracy coś się pojawi. 

Jacek: I to, co Kuba mówi to jest taki smutny generalnie obrazek. Na zasadzie, że Deweloperzy dopiero w momencie, kiedy odbywa się Refinement, zakładając, że ma formę spotkania, dopiero wtedy zaczynają pierwszy raz czytać, zastanawiać się, no co powoduje, że z mojej perspektywy tracimy czas. Oczywiście pomijam skrajne sytuacje, w której coś wpada dosyć późno do tego Backlogu i po prostu nie ma na to czasu. No ale zwykle jest tak, że ten czas od momentu, kiedy jakiś zarys elementu Backlogu Produktu pojawia się w Backlogu do momentu, kiedy jest Refinement, to jest co najmniej kilka dni. I trochę o tym wspominałem, kiedy mówiłem o tym, że warto jednak zadbać o to, żeby ktoś przemyślał strukturę Refinementów, czyli na przykład połączył kropki, że skoro już dzisiaj to wiemy, to może warto, żeby Deweloperzy sobie na to rzucili luźno okiem. Może przeczytali jakąś dokumentację, może jakieś API trzeba sprawdzić? Żeby na kolejnym Refinemencie być już trochę mądrzejszym.

Kuba: Użyłeś przykładów Deweloperskich, ale jesteśmy w punkcie o całym zespole i tak naprawdę cały Zespół Scrumowy niezależnie od odpowiedzialności może przyczynić się do tego przygotowania się do Refinementów. Czy to do struktury, czy do merytoryki, czy po prostu być gotowym do przepracowania pewnych elementów? Natomiast dla równowagi mam tutaj pewną wątpliwość co do takiego przygotowania się, że czasami też po prostu może być tak, że niektóre elementy, zwłaszcza ten bardzo, bardzo wstępny etap procesu Refinementu, może wiązać się raczej z tym, że tak zupełnie na czysto zapoznajemy się z tym, co jest do zrobienia i raczej generujemy pytania, niż oczekujemy, że uzyskamy wszystkie odpowiedzi. I tutaj żadne przygotowanie się, tego akurat nie poprawi. Więc co do zasady przygotowujemy się, ale bądźmy też OK z tym że dojdziemy do momentów w procesie Refinementu momentu, w którym po prostu nie dało rady się przygotować, albo nie znamy odpowiedzi i musimy się na przykład skonsultować, odesłać, wrócić, cokolwiek to oznacza w kontekście danego produktu czy zespołu. 

Jacek: I ostatnia odpowiedzialność Zespołu Scrumowego, to taki nasz porządnoagile’owy klasyk. Czyli zespół usprawnia proces pracy, żeby podnosić efektywność Refinementów. I to może przybierać najróżniejsze formy, no bo możemy o tym porozmawiać na Retrospektywie. Możemy o tym porozmawiać spontanicznie. Mogą jakieś dwie osoby, trzy z zespołu wpaść na jakiś pomysł i przedstawić to reszcie. Możemy sobie zrobić też jakieś szybkie podsumowanie, czy ewaluację Refinementu, na przykład techniką fist of five na koniec Refinementu i szybko na przykład skomentować, że pomysł z tym, że ktoś pisze, a ktoś wyświetla, ktoś jeszcze robi coś tam innego, zakładając, że to akurat miało formę spotkania online, no to, że na przykład to fajnie działa. No i po prostu warto, żeby to wybrzmiało. 

Kuba: I jeszcze raz zaakcentuję, że mówimy o całym zespole. Czyli nie oczekujemy, że to Scrum Master się martwi o dobry Refinement, albo konkretnie profesja, czy kompetencja analityka w zespole. Albo, że to Product Owner coś ma do poprawy. To cały zespół odpowiada za ten proces. Cały Zespół Scrumowy odpowiada za cały swój proces pracy, no i jego częścią są również i Refinementy. Wszyscy mogą zarówno mieć pomysły, co można zmienić, albo chociaż wypowiedzieć, co pasuje, co nie pasuje, co działa, co nie działa. No i doskonalić to otwarcie i tutaj całym zespołem kombinować, czy może mówiąc bardziej dyplomatycznie, biznesowo, eksperymentować z formą i eksperymentować ze strukturami, procesami, żeby ten Refinement lepiej funkcjonował. Mówimy to też po to, żeby trochę przebić taki jeden z kłopotów, że w wielu Scrum Masterów mówi o tym, że na przykład Deweloperzy narzekają na Refinement, ale niekoniecznie aktywnie uczestniczą w tym, żeby cokolwiek z nim poprawić. Tylko jedyny pomysł to krótszy lub jego całkowity brak, rozumiany jako kompletny brak spotkań. No i jest to jakiś pomysł. Na pewno do puli, do przedyskutowania i eksperymentowania, ale szczerze mówiąc, pewnie warto poszukać jakichś lepszych rozwiązań, niż zaprzestanie kompletne Refinementu, jako odpowiedź na to, że to nie jest dzisiaj efektywny sposób pracy w danym Zespole Scrumowym

Jacek: Jeżeli Refinement w Twoim zespole nie działa, tak jak chcesz, to możemy pomóc Ci to zmienić. Pomagamy firmom w usprawnieniu procesu Refinementu. Sprawienie by był efektywny, dawał skutek w postaci dobrego Backlogu i umożliwiał przeprowadzenie sprawnego Planowania Sprintu. Dołączamy na krótki czas do zespołu, poznajmy jego specyfikę i na bazie tego razem przeprowadzamy Refinement. Przepracowujemy fragmenty Backlogu inaczej, niż robił to zespół do tej pory. Jeżeli Twój zespół potrzebuje takiego wsparcia, napisz do nas na adres porządnyagile.pl/kontakt.

Kuba: A jako podsumowanie treści dzisiejszego odcinka przypomnijmy wspomniane w odcinku punkty, po jednym wybranym, najważniejszym naszym zdaniem. Jakie są odpowiedzialności Zespołu Scrumowego na Refinemencie? Deweloperzy proponują opcje na rozwiązanie potrzeb określonych w Backlogu Produktu. Product Owner zapewnia kontakt biznesowy produktu. 

Jacek: Scrum Master zapewnia, że proces Refinementu jest przeprowadzany w zespole. Zespół Scrumowey realizuje Refinement z perspektywą powstania wartościowego przyrostu co Sprintu. 

Kuba: Na koniec jeszcze jedno ogłoszenie organizacyjne dla tych z naszych Słuchaczy, którzy słuchają zaraz po wypuszczeniu odcinka. Wiemy, że część osób czeka bardzo konkretnie na premierę. Przechodzimy od następnego odcinka, czyli odcinka 90., na rytm wakacyjny. Więc jego premiera będzie miała miejsce nie dwa tygodnie od momentu premiery tego odcinka, tylko 6 lipca, czyli 3 tygodnie. No i też przez lipiec i sierpień. Z racji na trochę luźniejszy czas dla nas oraz planowane wyjazdy wakacyjne, będziemy te odcinki wypuszczać trochę rzadziej, czyli co 3 tygodnie. 

Jacek: Notatki do tego odcinka, artykuł, transkrypcje oraz zapis wideo. Znajdziesz na stronie porzadnyagile.pl/89. I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek i do usłyszenia wkrótce.