Współpraca Product Ownera ze Scrum Masterem

Współpraca Product Ownera ze Scrum Masterem

Może się wydawać, że Product Owner to dość samotna rola. Ale czy aby na pewno tak musi być? Scrum Masterzy często w pierwszej kolejności skupiają się na poprawianiu efektywności Zespołu, poprzez pracę z Developerami nad usprawnianiem procesu wytwarzania Produktu. Jednak wsparcie, które Scrum Master może dać Product Ownerowi jest równie ważne i istotne z punktu widzenia ostatecznego celu – dostarczenia wartościowego Produktu.

Do napisania tego artykułu zainspirował mnie warsztat o nazwie „Współpraca popłaca” prowadzonego przez Bogumiłę Kwiatkowską-Koterbę, który odbyłam podczas konferencji ABELight 2023 (Agile By Example Light). Bogumiła zdobyła swoje doświadczenie pełniąc w swojej karierze zawodowej zarówno rolę Scrum Mastera, jak i Product Ownera. Znając obie perspektywy zaproponowała warsztat ukierunkowany na identyfikację konkretnych sposobów, w których Scrum Master może wspierać Product Ownera. Wiedzę zdobytą na warsztacie uzupełniłam o swój pogląd na tę współpracę oraz inne materiały dostępne w sieci.

Rola Scrum Mastera

Scrum Master odpowiedzialny jest za efektywność Scrum Teamu [1]. Dba o to by każdy w procesie rozumiał w teorii Scruma oraz idące za nią praktyki. SM współpracuje z Developerami, Product Ownerem, oraz z Managementem i Interesariuszami.

SM dba o dobrą współpracę w Zespole. Pomaga odkrywać sposoby na usprawnienia. Wspiera i daje przestrzeń na samoorganizację. Pomaga identyfikować i likwidować przeszkody. Często przygotowuje i pomaga prowadzić spotkania.

Jak Scrum Master może wspierać Product Ownera?

Scrum Master powinien wspierać Product Ownera – nie tylko jako członka Zespołu, ale również jako osobę odpowiedzialną za maksymalizację wartości Produktu.

Scrum Master i Product Owner to dwie osobne role mające własne odpowiedzialności, które jednak dobrze się uzupełniają. Product Owner odpowiedzialny jest za sukces Produktu, a Scrum Master za sukces procesu [2]. Mimo różnych dziedzin działalności, powinni mieć jeden cel – sprawnie dostarczyć wartościowy Produkt.

Scrum Master może wspierać Product Ownera w każdym aspekcie jego pracy. Dobry Scrum Master będzie pomagał przezwyciężać pojawiające się problemy, dzięki czemu Product Owner będzie skupiać się na swoim najważniejszym zadaniu, czyli na maksymalizacji wartości Produktu.

Product Owner i Scrum Master powinni tworzyć zgrany duet. Współpraca powinna opierać się na obopólnym zaufaniu. Kluczowa w tej relacji jest jedna z Wartości Scrumaotwartość. Otwartość na współpracę, ale również na myśl, że jako człowiek mogę być w błędzie [3].

Potrzeby Product Ownera (w kontekście współpracy ze Scrum Masterem) można rozważyć z trzech perspektyw: Produktu, Zespołu i roli PO.

jakieGo wsparcia od Scrum MAstera Może oczekiwać Product Owner?

#1 Współpraca z Developerami

Podstawą dobrej i efektywnej współpracy w Zespole jest jeden z filarów Scruma, czyli transparencja. Jest ona szczególnie istotna na linii komunikacji Product Owner – Developerzy, gdyż różnice w wykonywanych zadaniach mogą generować niedomówienia. Sprawna komunikacja z Developerami jest aspektem, który niezwykle ułatwia realizowanie wielu aspektów pracy PO.

Szczególnie na początku współpracy w każdym Zespole istotne jest zrozumienie odpowiedzialności poszczególnych ról. Ważne by mieć wspólny pogląd na to czego możemy od siebie wzajemnie oczekiwać. Scrum Master, jako osoba wspierająca transparentną współpracę całego Zespołu, może zorganizować warsztat, który pomoże osiągnąć ten stan w Zespole.

Scrum Master może również wspierać Product Ownera w przekazywaniu wizji produktu. Transparentna wizja, to taka, którą członkowie Zespołu nie tylko znają, ale również rozumieją [4]. W szczególności jak przekłada się ta wizja na zadania, które realizuje Zespół. Jeżeli Product Owner zapomina przekazać kontekst biznesowy, jako SM zadaj wprost pytanie: jak te zadania spełniają wizję Produktu? Jak przybliżą nas do oczekiwanego rezultatu? Jaką wartość przyniosą?

Proaktywne działania Developerów

Proaktywne działania Zespołu są istotną częścią sprawnie działającego procesu wytwórczego. Grupa Developerów, którzy aktywnie szukają możliwości na usprawnienia i wychodzą z własnymi inicjatywami są złotem dla pracy Product Ownera. PO nie musi wszystkiego pokazywać palcem, czy „dostarczać” idealnych wymagań, ponieważ wszyscy jako Zespół opracowujemy najlepsze rozwiązania, czując odpowiedzialność za tworzony Produkt.

Scrum Master odgrywa ważną role w kreowaniu takich zachowań w Zespole, pomagając poszczególnym członkom przyjmować taką postawę. Tak facylituje spotkania, by zachęcać Developerów do działania. Nie wyręcza Zespołu, tylko wspiera ich samoorganizację w kierunku rozwiązywania napotkanych przeszkód.

#2 Prognozowanie i estymata pracy

Product Owner jest osobą, która standardowo będzie pytana o termin dostarczenia funkcjonalności. Często jest to trudna komunikacja, gdyż w Scrumie mówimy o prognozach (ang. forecast), a koncept ten bywa trudny do zrozumienia dla Interesariuszy. Słysząc daty, mają oni w głowie obraz zobowiązania (ang. commitment). Natomiast w życiu doświadczamy niespodziewanych wydarzeń, które powodują, że prognoza staje się nieaktualna.

By ułatwić Product Ownerowi komunikację, Scrum Master może pomóc w edukowaniu Interesariuszy o procesie Scrumowym. Przy każdej nadarzającej się okazji może podkreślać różnicę miedzy „forecast” a „commitment”.

Istnieją jednak narzędzia, które pomagają Zespołom Scrumowym określać przewidywany czas dostarczenia i budować rzetelne prognozy. SM i PO mogą wspólnie przeanalizować dostępne metody i narzędzia oraz wybrać te, które będą najlepiej sprawdzały się dla danego Zespołu.

Wchodzą w to różne metody estymowania (Story Points, metody koszulek, Monte Carlo, Planning Poker etc.) i tworzenia prognozy dostarczania (np. burndown chart).

#3 Metryki procesu i Produktu

Scrum jest metodą opartą na empiryzmie. Jako taka, zakłada, że uczymy się na podstawie doświadczeń. Ważną częścią tej nauki jest wykonywanie pomiarów interesujących nas elementów procesu. Scrum Master, jako osoba wspierająca Zespół w poprawnym praktykowaniu Scruma, powinna pomagać w definiowaniu odpowiednich miar, by umacniać empiryczne podejście do planowania pracy nad Produktem [1].

Z perspektywy Product Ownera szczególnie istotne powinny być miary powiązane z wartością Produktu. O tym jak można podejść do jej definiowania pisałam w tym artykule. Przykłady innych miar, które mogą być interesujące z punktu widzenia PO to: poziom długu technicznego (np. w postaci ilości błędów), Return on Investment (ROI), Usage Index czy Time to Market.

Zanim jednak zdefiniujemy wszystkie możliwe miary i będziemy je śledzić, warto sobie odpowiedzieć na pytania: po co chcemy daną rzecz mierzyć? Jaki cel chcemy osiągnąć? Czego chcemy się dowiedzieć? Scrum Master jest osobą, która może stać na straży dobrego wykorzystywania miar i pomagać Product Ownerowi w definiowaniu tych, które będą pomocne w podejmowaniu decyzji produktowych.

O podejściu związanym z podejmowaniem decyzji bazujących na empirycznych danych mówi Evidance Based Management.

#4 Praca z wymaganiami (Product Backlog, priorytetyzacja)

Jedną z głównych odpowiedzialności Product Ownera jest podejmowanie decyzji produktowych, które są następnie przejrzyście odwzorowywane w Product Backlogu. PO dba o to by Product Backlog był aktualny, miał wystarczająco dużo szczegółów i był odpowiednio zpriorytetyzowany, by umożliwiać Zespołowi pracę nad najbardziej wartościowymi elementami.

I choć odpowiedzialność leży po stronie Product Ownera, to nic nie stoi na przeszkodzie by Scrum Master wspierał działania PO, wypracowując wspólnie najskuteczniejsze metody zarządzania Product Backlogiem [4].

Istotnym elementem Product Backlogu jest Cel Produktu. Scrum Master może pomóc znaleźć techniki pozwalające na skuteczne określenie Celu Produktu. Podobną pomoc może oferować przy definiowaniu Celu Sprintu podczas Planowania.

Scrum Master może proponować Product Ownerowi różne metody pomocne w priorytetyzacji Backlogu. Przykładowo mogą to być: MoSCoW (Must Have, Should Have, Could Have, Will Not Have), Model Kano (podział na funkcjonalności fundamentalne, wydajności, atrakcyjne i obojętne) czy „Buy a Feature”.

I na koniec – Scrum Master powinien wspierać w swoim Product Ownerze rozwój umiejętności delegowania zadań. Nie każdy PBI musi być stworzony i dokładnie opisany przez Product Ownera zanim pojawi się na Refinemencie lub trafi w ręce Developerów.

#5 Zarzadzanie Interesariuszami

Product Owner jest odpowiedzialny za kontakt z Interesariuszami i zapewnienie, że ich głos jest brany pod uwagę podczas pracy nad Produktem. Scrum Master może w tych działaniach wspierać Product Ownera, kiedy zostanie o to poproszony lub kiedy zachodzi taka potrzeba [1].

Działania te zwyczajowo nazywają się „Zarządzaniem Interesariuszami” i zawierają w sobie: ich identyfikację (mapa Stakeholderów) oraz budowanie strategii komunikacji z poszczególnymi osobami. Wpisuje się w to również komunikacja sama w sobie. Pomoc Scrum Mastera może polegać na zorganizowaniu warsztatu, facylitacji spotkań, czy poprowadzeniu angażującego Sprint Review.

Jeżeli na naszej wspólnej drodze pojawi się „trudny”, wysoko postawiony Interesariusz, to Scrum Master może pomóc Product Ownerowi opracować strategię komunikacji, a następnie wspomóc poprowadzenie jej w efektywny sposób. Scrum Master może również wytłumaczyć Scruma takiej osobie (jeżeli problem wynika z braku zrozumienia procesu).

#6 Rozwoj kompetencji miękkich i nie tylko

Product Ownerzy są zazwyczaj zajętymi osobami. Prawdopodobnie rozwój własnych umiejętności miękkich i innych potrzebnych do realizowania roli nie stoją na pierwszym miejscu ich listy TODO. Scrum Master może być osobą, która motywuje Product Ownera do pogłębiania wiedzy i umiejętności oraz wskaże odpowiedni kierunek tych działań.

Jako osoba patrząca na rolę PO pod kątem efektywności dostarczania wartości, Scrum Master może dostrzec miejsca wymagające największej uwagi. Możecie wzajemnie wymieniać się pomysłami na udział w meetupach i szkoleniach. Dzielić się znalezionymi materiałami, newsletterami i książkami. SM może pomóc w znalezieniu mentora.

#7 Wymiany myśli

Jeżeli relacja Product Ownera i Scrum Mastera jest wyjątkowo bliska i zbudowana na zaufaniu, to korzystne dla obu stron może być zwyczajne spędzanie czasu razem na luźnych rozmowach. Product Owner może mieć również potrzebę odbicia swoich pomysłów od innej osoby, czy wspólnego rozpracowania napotkanych wyzwań.

Spotkanie 1-1 SM – PO jest dobrym miejscem na burze mózgów. Wspólnie można zastanawiać się jak usprawniać poszczególne elementy procesu np. jak poprawić Refinement? jak bardziej zaangażować Interesariuszy podczas Sprint Review?

Przyczyny niezadowolenia ze współpracy

Kluczem do każdej dobrej współpracy jest jasne określenie wzajemnych potrzeb i oczekiwań. Zdarza się jednak, że strony nie są zadowolone ze współpracy, bo nie czują jej wymiernej korzyści. Dlaczego tak się dzieje?

Powodów może być wiele. Jednym z dość często spotykanych jest brak czasu Product Ownera. I choć wydaje się dość trywialny, to wynikać mogą z tego poważniejsze problemy, takie jak np. brak zaufania w relacji. To z kolei przekłada się często na brak przejrzystej komunikacji

Relacja ta, żeby dobrze funkcjonowała musi bazować na zaufaniu i otwartości – wymaga szczerego przyznawania się do braków i proszenia o pomoc, jeżeli jest to konieczne.  Obie osoby musza być otwarte na zmiany, chętne do testowania hipotez i eksperymentowania. Bez takiego nastawienia ciężko będzie usprawniać cokolwiek, czy to w zakresie procesu, czy zarządzania Produktem.

Inny rodzaj problemów w relacji może wynikać z braku zrozumienia zakresu odpowiedzialności poszczególnych ról. To może powodować, że PO i SM będą wchodzić sobie w drogę i generować tarcia. Niezadowolenie może wynikać również z braku kompetencji po stronie PO lub SM. Obie ze stron mogą mieć oczekiwania, które nie są spełniane ze względu na brak doświadczenia w danej roli.

Problemy w relacji mogą być również spowodowane zwyczajnym brakiem dopasowania charakterów. Nie z każdym czujemy „flow” i świetnie się dogadujemy. W tej relacji 1-1 to czy jesteśmy dopasowani i lubimy się wzajemnie ma niemałe znaczenie.

Co możesz zrobić żeby naprawić tę współpracę?

Spotkajcie się. Jeszcze raz szczerze porozmawiajcie o swoich potrzebach i oczekiwaniach. Spróbujcie otwarcie podejść do współpracy, określając jej cel. Wybierzcie na początek jeden aspekt, którym się zajmiecie. Określcie plan działania.

Jeżeli nie da się relacji naprawić, to porozmawiaj z organizacją o zmianach w Zespole. Współpraca PO – SM może przynieść wiele wartości, z której nie warto rezygnować.

Podsumowanie

Scrum Master i Product Owner to dwie istotne role zdefiniowane w Scrumie. I choć mają rozłączne odpowiedzialności, to cel działań powinni mieć jeden i wspólny – efektywne dostarczanie wartościowego Produktu. Łącząc siły w owocnej współpracy mogą osiągnąć wiele dobrego, wymiernie wpływając na rezultaty osiągane przez Zespół. 

Bibliografia

[1] Przewodnik po Scrumie; https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf

[2] Why Product Owners need effective Scrum Masters; https://www.romanpichler.com/blog/why-product-owners-need-effective-scrum-masters/

[3] YDS: How Does a Scrum Master and Product Owner Collaborate?; https://www.youtube.com/watch?v=2feds95K_24

[4] Scrum Master service to Product Owner; https://www.knowledgehut.com/blog/agile/scrum-master-service-to-product-owner

Leave a Comment

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *