Product Owner na retrospektywie

Zdziwiło mnie pytanie jakie usłyszałem od jednego z początkujących Scrum Masterów, który jednak miał już na swoim koncie kilka ładnych miesięcy praktycznej pracy na tym stanowisku: „Czy macie w zwyczaju zapraszać Product Ownerów na retrospektywy?” Jakież było jego zdziwienie, kiedy skierowałem go do „Przewodnika po Scrumie”, a tam przeczytał:

Retrospektywa Sprintu jest okazją dla Zespołu Scrumowego do przeprowadzenia inspekcji swoich działań i opracowania planu usprawnień, który zostanie wcielony w życie w najbliższym Sprincie.

Kolega zdumiał się i mocno zawstydził, przyznając, że był pewien, że chodzi wyłącznie o zespół deweloperski… W ramach osłody opowiedziałem mu swoje początki. Też pamiętam swoje skonfundowanie, kiedy przygotowując się do swojego pierwszego sprintu przeczytałem gdzieś, że Product Owner uczestniczy w retrospektywie. Jak to, to jakaś pomyłka! Pamiętam, że szybko sięgnąłem do Przewodnika, gdzie… jak byk – powyższe słowa, w które ciężko było mi uwierzyć. Bo przecież Product Owner to jednak „obcy”, jak tu przy nim grać w otwarte karty i prać wewnętrzne brudy. Takie myślenie jest częste i naturalne na początku drogi pracy w metodykach zwinnych. Ale zdarza się, że i pozostaje na dobre – nieraz spotkałem się również z zespołami, które w pełni świadomie „zmodyfikowały” Scruma, pozbywając się niewygodnej osoby z retrospektyw.

Dlaczego Product Owner jest często traktowany jako persona non grata na tym spotkaniu? Oto najczęstsze argumenty:

Retrospektywy służą przede wszystkim zespołowi deweloperskiemu. Product Owner jest tu tylko zbędnym gościem, zakłócającym otwartość spotkania.
Product Owner nie ma pojęcia o czym my tu w ogóle rozprawiamy, będzie się tyko i wyłącznie nudził.
Product Ownera interesuje nie proces wytwórczy, tylko jego efekty.
Przy Product Ownerze nie możemy przyznać się do jakichkolwiek słabości, potknięć i grzechów, bowiem wykorzysta on zdobytą wiedzę przeciwko zespołowi.
Nasz Product Owner pełni również rolę superważnego dyrektora. Samą swoją obecnością zniweczy cel spotkania, jak przy kimś takim powiedzieć, że się lekko obijaliśmy i mogliśmy zrobić więcej.
Czysty Scrum jest oderwany od rzeczywistości i zbyt nastawiony na amerykańskie realia pracy (uniwersalna wymówka, nie tylko dla tego przykładu).

Przyjrzyjmy się zatem tematowi nieco bliżej i wyjaśnijmy dlaczego, nolens volens, Product Owner jest osobą niezbędną na retrospektywie.

Zespół Scrumowy. Mało się o nim mówi, często zapomina. Wydaje się, że wszystkie te zasady samoorganizacji, wzajemnego zaufania, pracy w grupie, nowej jakości i nowego, wspaniałego świata dotyczą tylko zespołu deweloperskiego. Tymczasem Scrum nieprzypadkowo wprowadza wspomniane pojęcie drugiego zespołu, który zawiera tenże pierwszy, a na pokład dorzuca jeszcze Scrum Mastera i Product Ownera. O ile jednak Scrum Master w większości przypadków od razu jest traktowany przez deweloperów jako „swój”, o tyle do Product Ownera podchodzą z reguły ze sporą dawką dystansu i nieufności. Bo to niby nasz sojusznik, ale z trochę innej bajki, innego kręgu kulturowego. To przecież on zleca nam zadania do wykonania, a potem dokonuje ich odbioru. On ma decydujące znaczenie w kluczowych dla nas sprawach. Cóż, niby jest fajnie, a za chwilę będziemy chodzić z nożem w plecach…

Nie ma w tym nic niezwykłego, z reguły osoba na tym stanowisku to typowy „przedstawiciel biznesu”, często odbierany a priori jako ktoś, kto chce żeby było szybciej i tyle, nie dbający o jakość kodu i zaciągany dług technologiczny. W wielu organizacjach dochodzi do tego niechlubna „historia” i rany po dawnych bitwach, a czasem i wojnach międzydziałowych. Startuje się wówczas niemalże z pozycji jawnej wrogości. Niezależnie jednak od tego czy zespół zaczyna z Product Ownerem, który jest „znanym wrogiem” czy stanowiącym „jedną wielką niewiadomą”, od samego początku Scrum Master ma bardzo ważne zadanie i prawdziwe pole popisu. Konsekwentna, przemyślana praca z zespołem i Product Ownerem nad zbudowaniem zespołowości, nieustanna obserwacja i reagowanie na to co się dzieje, krok po kroku, w odpowiednim tempie powinna doprowadzić do zasypania dawnych urazów czy początkowych okopów. Cierpliwość, inspekcja i adaptacja. Wiadoma sprawa. Jednak wielu Scrum Masterów zbytnio skupia się na rozkręceniu i stworzeniu chemii, zespołowości wśród deweloperów, kompletnie zapominając o Product Ownerze, który pozostaje mocno „z boku”, co prędzej czy później przyniesie negatywne konsekwencje. Od samego początku należy dbać o to, aby był on blisko zespołu, a nie pozostawał wyłącznie gościem, pojawiającym się na początek sprintu – przy okazji jego planowania, i na końcu – przy okazji przeglądu i retrospektywy. Im więcej wspólnej pracy, wspólnych dyskusji, tym większe wzajemne zrozumienie i zaufanie.

Retrospektywa to z punktu widzenia dewelopera najtrudniejsze i często niechciane spotkanie, na które chodzi się często z poczucia obowiązku. W zawodzie programisty nie brakuje introwertyków czy osób nieśmiałych, którym ciężko jest otwarcie mówić o swoich odczuciach, emocjach, a co dopiero odnosić się do konkretnych sytuacji czy osób. W tym drugim przypadku dochodzi jeszcze poczucie swojej wartości i hierarchii w zespole. Osoby z mniejszym zasobem wiedzy czy o niewielkim stażu wolą schować się w kącie i nie poruszać niewygodnych tematów, które mogą kogoś zaboleć. Z kolei inni brylują na spotkaniu co rusz wykazując drzazgi w cudzych oczach. Dodajmy do tego naszą rodzimą specyfikę i kulturę, która nie sprzyja bezpośredniej, szczerej rozmowie „bez ograniczeń”. Tutaj znów dużo pracy przed Scrum Masterem, który musi zbudować odpowiednią atmosferę, wzajemne zaufanie w zespole i poczucie bezpieczeństwa jego członków. Pamiętając o tym, że nawet w gronie „samych swoich”, czyli tych „technicznych”, retrospektywa jest czymś dla wielu osób niełatwym, przed jej pierwszymi edycjami, szczególnie w zespołach, które dopiero startują, konieczne jest dobranie odpowiedniej strategii. Zawsze należy tu brać pod uwagę charakterystykę zarówno samego zespołu, jak i osób go tworzących.

Pierwsza z nich, to po prostu przyzwyczajenie deweloperów do obecności Product Ownera na tym spotkaniu. Product Owner przychodzi na spotkanie i normalnie w nim uczestniczy. Konieczne jest jednak to, żeby dobrze rozumiał on istotę spotkania i przychodził na nie dobrze przygotowany, w czym musi, szczególnie na początku, pomóc mu Scrum Master. Należy także dobre przedstawić zasady gry samemu zespołowi. Skutki źle przeprowadzonych retrospektyw mogą znacząco wpłynąć na nieodwracalne zerwanie cienkiej linii zaufania już na samym początku projektu, stąd trzeba tu zachować szczególną ostrożność.

Warto, pierwsze spotkania potraktować jako „przełamywanie barier” i skupić się na pozytywach, co nie znaczy, że wszelkie błędy należy traktować ulgowo. Jest okazja, żeby podziękować zespołowi za włożoną pracę i jej efekty, podkreślić pozytywne aspekty, a negatywy przedstawić jako asumpt do dyskusji, do której włączą się kolejne osoby. Od samego początku należy też oczekiwać, a wręcz domagać się informacji zwrotnej od zespołu. To przecież najlepsza okazja, żeby Product Owner posłuchał, jak jest postrzegany, co powinien zmienić, a co wyśmienicie się sprawdza. Potem, kiedy rozmowa skupia się bardziej na technicznym przebiegu sprintu, samym procesie wytwórczym, Product Owner powinien zmienić się w uważnego słuchacza, stroniącego od wtrącania wszędzie swoich pięciu groszy albo moralizatorstwa. Z drugiej strony, nie ma nic gorszego niż okazywanie swojego znudzenia, siedzenie z wypisanym na twarzy poczuciem zmarnowanego czasu. Należy docenić unikalną możliwość posłuchania o problemach jakie napotyka zespół i sposobach, jakie proponuje, aby temu zaradzić. Buduje to większą świadomość tego na czym polega jego praca i ułatwia zrozumienie pewnych sytuacji.

Innym podejściem jest podział retrospektywy na dwie części – pierwszą w pełnym składzie, drugą – bez Product Ownera. To droga, którą raczej należy unikać, ale która sprawdzi się w sytuacji, gdzie obie strony mają za sobą różnego rodzaju nieciekawe historie, wzajemne animozje i wyobrażenia, które ciężko wyplenić z dnia na dzień. Niemniej jednak jest to rozwiązanie wyłącznie na kilka pierwszych sprintów, aż do momentu zbudowania wzajemnego poczucia bezpieczeństwa i zaufania. Należy pilnować, aby nie stało się ono regułą. Znów – trzeba tu zadbać o dobre wyjaśnienie reguł gry, żeby Product Owner wychodząc ze spotkania nie mówił: „no to teraz możecie mnie obgadywać” albo wychodził z poczuciem, że jest nieproszonym gościem. Niebezpieczeństwem tego podejścia jest także pielęgnowanie w zespole poczucia, że Product Owner to owszem, sprzymierzeniec, ale traktowany z ograniczonym zaufaniem.

Na dobrze przeprowadzonej retrospektywie zyskują obie strony – przede wszystkim zyskując informacje zwrotną na temat swojej codziennej pracy. Jako, że Product Owner niekoniecznie codziennie widuje się z zespołem, często ma on ciekawe spojrzenia na jego prace, dostrzegając sytuacje, które umykają uwadze również Scrum Mastera. Warto na sam koniec spotkania trochę odejść od samego projektu, rozwiać jakieś krążące plotki, czy opowiedzieć co nowego w dziale biznesowym i firmie się dzieje. Ale i wyjść poza zaklęty krąg tematów pracowniczych. Z każdym udanym spotkaniem znikają podziały – z dwóch stron robi się jedna.

Wracając do wylistowanego na samym początku zestawu argumentów przeciwko Product Ownerowi na retrospektywie, zwróćmy uwagę na wyraźnie bijące z niego te same problemy. Brak poczucia bezpieczeństwa, brak zaufania i złe doświadczenia z dotychczasowej pracy. Ale i niepełne zrozumienie pracy w Scrumie lub podejście do niej z dużym dystansem. Dobry Scrum Master musi pracować nad wyeliminowaniem tych elementów.

#ProductOwner #retrospektywa #Scrum