Jakiś czas temu miałam okazję wysłuchać ciekawego podsumowania pierwszych miesięcy pracy Scrumem z perspektywy początkującego Scrum Mastera i Zespołu Deweloperskiego. Ważnym elementem wystąpienia były wnioski dotyczące roli Product Ownera i wartości, jaką wniósł, a w tym konkretnym przypadku wniosła do zespołu Product Ownerka. Spodobał mi się wtedy prosty rysunek przedstawiający tę rolę za pomocą metafory anioła, który oddziela swój zespół od natłoku zadań i spraw do załatwienia od ręki; za zgodą autora zamieszczam ją tutaj dla Was. Z czasem ta grafika podoba mi się coraz bardziej, ponieważ przypomina mi, na jakie aspekty pracy Product Ownera zwracają uwagę osoby, które rozpoczynają współpracę z nim zgodnie z regułami Scruma. Choć umyka w niej ważny aspekt roli Product Ownera, do czego  jeszcze wrócę, moim zdaniem oddaje jego 3 kluczowe atrybuty:

1. Product Owner maksymalizuje wartość produktu

Niezależnie od tego, czy pracuje dla klienta zewnętrznego, czy wewnętrznego, rozwija istniejący, czy tworzy nowy produkt, jest Product Ownerem z własnym budżetem, czy nie, to on odpowiada za rozwój i zwiększenie wartości produktu. Zadaniem Product Ownera jest zadbać o klarowną wizję dla produktu, plan, który pozwoli ją zrealizować i KPI będące punktem odniesienia do rozmów o wartości tego produktu, tak, aby i on i zespół wiedzieli, czy idą w dobrym kierunku. Anioł, nie człowiek, prawda?  Podkreślam jednak –  PO powinien „zadbać” o wszystkie wymienione elementy, a nie samodzielnie je przygotować. Pomaga mu w tym Zespół Deweloperski; od niego zależy też, w jakim stopniu korzysta z wiedzy ekspertów dziedzinowych, jak często rozmawia z interesariuszami, czy zbiera feedback, a jeśli tak, w jaki sposób z niego korzysta… Wymieniłam kilka użytecznych narzędzi, które są ważne, ale stanowią zaledwie drogę do celu, którym jest właśnie zwiększenie wartości produktu.

2. Jest jedyną osobą, która zarządza Product Backlogiem

Product Backlog, czyli Lista wymagań produktu jest narzędziem pracy Product Ownera i ważnym elementem komunikacji z Zespołem Deweloperskim i interesariuszami. Dlatego powinien być łatwo dostępny i odzwierciedlać plan działań dla produktu, którym ten Product Owner zarządza w sposób zrozumiały dla wszystkich zainteresowanych. Na ile szczegółowo i z jakim wyprzedzeniem? To zależy, na przykład od specyfiki samego produktu – inaczej wygląda praca nad zupełnie nowym rozwiązaniem, które wymaga rozpoznania technologii i eksperymentowania, inaczej nad wiekowym produktem z siecią zależności wewnątrz organizacji. Z perspektywy Zespołu Deweloperskiego ważne jest, aby Product Backlog pokazywał szerszy obraz tego, co będzie się działo w kolejnych tygodniach i miesiącach (big picture), a zarazem pozwalał szczegółowo zaplanować najbliższe 1-2 Sprinty. Użyteczny Product Backlog ma strukturę rosnącą (od szczegółu –  tematy z największym priorytetem, rozbite na małe zadania, gotowe do wzięcia na Sprint, do ogółu –  większe zadania, bardziej ogólnikowo opisane, aż po tematy opisane hasłowo).



3. Jest jedyną osobą decyzyjną dla Zespołu Deweloperskiego

W Scrum Guide przeczytacie: Nikt nie może nakazać Zespołowi Deweloperskiemu, aby pracował z innym zestawem wymagań, a Zespołowi Deweloperskiemu nie wolno podejmować działań w oparciu o to, co mówią inne osoby. Taki układ zapewnia Zespołowi Deweloperskiego komfort pracy i umożliwia koncentrację na priorytetowych zadaniach z perspektywy rozwoju produktu i dostarczania wartości. W połączeniu z regularnością pracy w Sprintach pozwala z czasem wypracować: optymalną produktywność zespołu i przewidywalność – nieocenione z punktu widzenia Product Ownera. Jedna osoba odpowiedzialna za rozwój produktu umożliwia także sprawne podejmowanie decyzji, co jest szczególnie istotne w szybko zmieniającym się środowisku. Dlatego tak ważne jest, aby była dostępna dla Zespołu Deweloperskiego, kiedy tylko zaistnieje taka potrzeba.

Co natomiast umknęło w grafice?

Na załączonym obrazku komunikacja przebiega jednotorowo (od Product Ownera do Zespołu Deweloperskiego) i kategorycznie (jakby tylko on kontaktował się z interesariuszami). Product Owner odpowiada za to CZYM zajmuje się Zespół Deweloperski, a zespół za to JAK realizuje tematy. Aby ta współpraca była możliwie efektywna, niezbędne jest, aby opierała się na nieustannym dialogu wszystkich zainteresowanych stron. Rozwinę ten temat w kolejnej części, dotyczącej wydarzeń Scrumowych.

Rola Produt Ownera podczas zdarzeń Scrumowych

Zdarza mi się słyszeć pytania o to, jaka jest rola Product Ownera podczas zdarzeń Scrumowych. Na przykład: Czy PO powinien uczestniczyć w Daily i Retrospektywie. Cykliczne spotkania wprowadzają regularność i są motorem napędowym dla Zespołu Scrumowego. Jeśli są konstruktywne, przekładają się na satysfakcjonujące efekty, jeśli nie, to jedna z ważniejszych przyczyn niezrealizowanych Celów Sprintu, frustracji i słabych wyników zespołu. Dlatego zdecydowałam się opisać wyzwania dla Product Ownera właśnie z perspektywy cyklicznych spotkań Scrumowych.

Doskonalenie Product Backloga (Backlog Refinement)

Backlog to główne narzędzie pracy Product Ownera, dlatego Backlog Refinement jest obok Sprint Review kluczowy z perspektywy roli Product Ownera. To tutaj ma szansę odbyć się konstruktywny dialog pomiędzy PO a Zespołem Deweloperskim, a w razie potrzeby także interesariuszami, wymiana opinii i doświadczeń, które mają wpływ na losy i kształt produktu.

Backlog Refinement to współpraca Product Ownera i Zespołu Deweloperskiego przy tworzeniu i doskonaleniu Product Backloga. W zależności od etapu pracy nad produktem, może dotyczyć opracowywania szerszego planu działania, czy nawet wizji albo przygotowania i oszacowania poszczególnych elementów Backloga do wzięcia na kolejne Sprinty. Product Owner może przyjść na takie spotkanie z własną wizją i jej realizacją w postaci rozpisanych elementów Backloga albo z celem do zrealizowania z konkretnymi, uzasadnionymi biznesowo kryteriami. Jak myślicie, do którego z podejść Was zachęcam? Drugie, zakładające zaangażowanie zespołu, pozwala wykorzystać wiedzę i kompetencję całego zespołu, zwiększa motywację (o czym na przykładzie książki Dana Pinka pisał szerzej Jacek) i poczucie identyfikacji z produktem. Pozwala też uniknąć sytuacji, w której to Product Owner  szczegółowo rozpisał zadania, ale ponieważ to nie on jest ekspertem dziedzinowym w zakresie wykorzystanej technologii, architektury i implementacji rozwiązań, okazuje się, że i tak trzeba je podzielić inaczej. A pierwsze z podejść… prawdopodobnie sprawdza się w niektórych trywialnych przypadkach.

Planowanie Sprintu

Podczas pierwszej części Planowania Co może zostać zrobione w Sprincie? Product Owner omawia, jaką wartość chciałby dostarczyć poprzez kolejny Sprint, co oznacza, że zadania, które do niego trafią są częścią większego planu, a nie przypadku. Jego decyzja musi mieć odzwierciedlenie w priorytetach Product Backlogu. Zadaniem PO jest zadbać o to, aby elementy z Backloga, które potencjalnie będą realizowane w danym Sprincie, zostały wcześniej dobrze do tego przygotowane we współpracy z Zespołem Deweloperskim (patrz Backlog Refinement). Sytuacja, w której podczas Planowania Zespół po raz pierwszy słyszy o tematach, którymi ma się za chwilę zająć, nie wróży nic dobrego. Na podstawie informacji od PO Zespół decyduje, ile elementów Product Backloga jest w stanie zrealizować w kolejnym Sprincie i konstruuje Cel Sprintu – jego realizacja będzie oznaczała dostarczenie wartości zdefiniowanej przez PO. Pierwsza część Planowania to także negocjacje na linii PO <> Zespół Deweloperski. Dobry PO potrafi zmotywować Zespół do tego, aby jego deklaracja zakresu była ambitna, a zarazem nie naciskać na niego za mocno.

W drugiej części spotkania: W jaki sposób wybrany zakres pracy zostanie zrealizowany? PO pełni funkcję wspierającą – w razie wątpliwości pomaga zrozumieć cel i kryteria akceptacji rozwiązań. Jeśli w trakcie omawiania planu działania zaistnieje taka potrzeba, Zespół Deweloperski renegocjuje z nim ilość lub zakres zadań. Product Owner może oczekiwać na końcu spotkania, że Zespół Deweloperski wyjaśni mu, w jaki sposób zamierza ze sobą współpracować tak, aby zrealizować cel Sprintu.

Daily Scrum

Daily to nic innego niż planowanie dnia przez Zespół Deweloperski, biorąc pod uwagę ew. problemy, które pojawiły od ostatniego spotkania i tematy, które pozostały jeszcze do zrealizowania w danym sprincie. W założeniach Product Owner w nim nie uczestniczy.

A co mówi praktyka? W wielu przypadkach jest inaczej, co niekoniecznie oznacza, że warto to zmienić. Jeżeli Zespół Deweloperski i Product Owner na bieżąco ze sobą współpracują, daily może być dobrą okazją także do rozstrzygnięcia drobnych wątpliwości, które pojawiły się w toku prac, zasygnalizowania Product Ownerowi problemów z realizacją celu sprintu, czy poinformowania go o zrealizowaniu zadań i poproszenia o feedback jeszcze przed końcem sprintu. Warunek jest jeden – Product Owner pełni tutaj rolę wyłącznie wspierającą. W każdym innym przypadku lepiej, aby nie uczestniczył w daily – np. jeśli deweloperzy raportują mu status prac albo kiedy to Product Owner decyduje, którą z historyjek i kto ma się zająć.

Przegląd Sprintu

Przegląd jest spotkaniem podsumowującym efekty pracy zespołu w Sprincie (inspekcja Przyrostu), a zarazem czasem na konstruktywną dyskusję z Zespołem Deweloperskim i kluczowymi interesariuszami. O obecność na spotkaniu tych ostatnich powinien zadbać Product Ownera.

Podczas Sprint Review Product Owner omawia, co zostało ukończone w Sprincie, a Zespół Deweloperski prezentuje efekty swojej pracy. PO aktualizuje Product Backlog i dba o to, aby zebrać feedback i opinie na temat istniejących rozwiązań tak, aby na ich podstawie podjąć możliwie najlepsze decyzje co do dalszych kroków rozwoju produktu.

Retrospektywa Sprintu

W Retrospektywie powinni uczestniczyć wszyscy członkowie Zespołu Scrumowego, a Product Owner jest jednym z nich. To bardzo ważny, a odnoszę wrażenie, że momentami bagatelizowany aspekt pracy w Scrumie. Na sukces, bądź jego brak, składa się to, w jaki sposób współpracuje ze sobą cały zespół, włączając w to wszystkie role – Product Ownera, deweloperów i Scrum Mastera oraz to, na ile każda z osób wywiązuje się ze swoich obowiązków. To moment zarówno na feedback pozytywny, jak i negatywny – rozwojowy; co jako zespół, ale i jego pojedynczy członkowie powinniśmy zrobić następnym razem inaczej, żeby zwiększyć wartość produktu i efektywniej ze sobą współpracować. Sytuacja, w której Product Owner nie uczestniczy w spotkaniu, żeby „deweloperzy mogli sobie swobodnie porozmawiać” albo „wyprać brudy” sugeruje, że w takim zespole źle się dzieje i tym bardziej trzeba spotykać się razem, aby to zmienić.

Podczas szkoleń z podstaw Scruma jako podsumowanie części dotyczącej Product Ownera zadaję uczestnikom pytanie o to, co ich zdaniem cechuje dobrego Product Ownera; i z drugiej strony – co powinna zapewnić mu organizacja, aby mógł efektywnie realizować swoje zadania. Ich intuicyjne odpowiedzi zawsze są podobne i krążą wokół tematów:

Dobry PO jest:

– Kompetentny w dziedzinie produktu – biznesowo i technologicznie na tyle, aby znać jej możliwości oraz zagrożenia i rozmawiać konstruktywnie z deweloperami,

– Charyzmatyczny – potrafi przekonać do wizji i zmotywować zespół,

– Asertywny – umie otwarcie i jednoznacznie wyrażać swoje opinie i potrzeby; kiedy trzeba zawalczy o swoje,

– Decyzyjny – potrafi wyciągać wnioski, a na ich podstawie szybko podejmować decyzje; bierze za nie odpowiedzialność,

– Komunikatywny – co ułatwia mu efektywną współpracę z zespołem i interesariuszami.

Organizacja powinna mu zapewnić:

– Niezależność i zaufanie – tylko wtedy można mówić o tym, że to faktycznie on zarządza produktem; w Scrum Guide przeczytacie: Aby Właściciel Produktu mógł odnieść sukces, cała organizacja musi respektować jego decyzje.

– Zespół niezbędny do zrealizowania założonego celu,

– Budżet (jeśli to możliwe) – dzięki temu będzie podejmował bardziej odpowiedzialne decyzje,

– Adekwatne wynagrodzenie, ponieważ to odpowiedzialne, niezależne i wymagające stanowisko.

Zgadzam się z tymi odpowiedziami. A Wy?

Postscriptum: Od momentu powstania niniejszego artykułu wydaliśmy ebook ’Jak być dobrym Product Ownerem’.

Jeśli nie wiesz skąd brać Product Ownerów, koniecznie posłuchaj 55 odcinek podcastu Porządny Agile. Kuba i Jacek więli na tapet ten temat.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x