Proxy Product Owner to rola, która nie występuje w czystym Scrumie. Jest to jednak jedna z bardziej popularnych modyfikacji tej metodyki. Proxy Product Owner często znajduje się w jednym worku razem z takimi tworami jaki Area Product Owner czy Tribe Leader.
Permanentny brak czasu
Oto obiecana kontynuacja tematu z zeszłego tygodnia, w którym opisywałem 3 Grzechy Product Ownera. Jednym z nich był permanentny brak czasu dla Zespołu Deweloperskiego. Co prawda główna odpowiedzialność PO to zarządzanie Backlogiem Produktu, ale to nie znaczy, że nie ma on wspierać Zespołu Deweloperskiego i rozwiewać ich wątpliwości co do obranego kierunku i szczegółów realizacji wymagań.
W wielu firmach to już nawet nie jest żart, że PO głównie jest „na spotkaniach”. Konieczność planowania kilku wydań do przodu i zaspokajania wielu interesariuszy powoduje, że biedny Product Owner zwykle biega od spotkania do spotkania. Rzeczy takie jak utrzymywanie backlogu często lądują na głowach zespołowych analityków.
Taka sytuacja ma miejsce tym częściej, im więcej zespołów pracuje nad produktem, którym dany PO się zajmuje. Łatwo sobie wyobrazić, co się stanie, gdy niedostępny dla jednego zespołu Product Owner będzie musiał komunikować się z kilkoma na raz. A co, jeśli będzie musiał zarządzać kilkoma backlogami i kilkunastoma zespołami?
Aż chciałoby się go sklonować…
Jeden Backlog – Jeden Product Owner
Zanim wyjaśnimy, kim może być Proxy Product Owner, rozprawmy się z pomysłem zdublowania „zwykłego” Product Ownera. Scrum Guide wyraźnie mówi, że rola ta powinna być pełniona jednoosobowo. Od tej zasady nie ma absolutnie żadnych wyjątków.
„Właściciel Produktu to pojedyncza osoba, nie komitet.” – Scrum Guide
Product Owner odpowiedzialny jest za kolejność wymagań w Backlogu Produktu. Nie możemy mieć dwóch osób, które ją ustalają, bo natrafimy na dobrze znany problem „każda z dwóch osób mówi mi, że to jej wymaganie jest najważniejsze”.
Zespoły nie powinny się zastanawiać nad tym, co ma priorytet. To powinno wynikać z Product Backlogu i z wizji PO. Sam Product Owner to rola, która powstała właśnie po to, żeby pogodzić interesy wielu klientów i odseparować zespoły od tych problemów.
Pamiętajmy też, żeby przypadkiem nie odciąć w ogóle zespołów od kontaktów z klientami i użytkownikami końcowymi. Powinni oni współpracować ręką w rękę i komunikować się jak najczęściej, najlepiej codziennie. Ale to nie zespół ma wybierać, czym w danej chwili będziemy się zajmować i to nie on ma godzić interesy wielu interesariuszy.
Trzymajmy się więc zasady Jeden Backlog – Jeden Product Owner. A co, jeśli mamy kilka(naście) zespołów pracujących nad jednym backlogiem? Jeżeli PO brakuje czasu, zainteresujmy się rolą Proxy Product Ownera.
Kim jest Proxy Product Owner?
Tak jak PO jest przedstawicielem klienta dla zespołów, tak Proxy Product Owner jest przedstawicielem PO dla konkretnego zespołu. Oznacza to, że w jakimś zakresie przejmuje on część obowiązków Product Ownera, szczególnie tych związanych z pracą na rzecz zespołu.
W praktyce ta rola zwykle ląduje u kogoś w rodzaju głównego analityka dla danego obszaru bądź eksperta systemowego lub biznesowego. Skoro Proxy Product Owner ma za zadanie wspierać zespół, to najlepiej byłoby gdyby był on członkiem Development Teamu. Dodatkowo, powinna to być osoba znająca się na temacie i faktycznie potrafiąca wyręczyć „głównego” PO.
PO w dalszym ciągu pozostaje odpowiedzialny za Product Backlog, ale to Proxy Product Ownerzy zwykle będą wspierać jego udoskonalenie. To oni będą wyjaśniać wątpliwości w trakcie Product Backlog Refinementu i pracować bezpośrednio z zespołami. Pewnie też pojawią nam się dodatkowe spotkania synchronizujące na linii PO – PPO.
Szczególnie ważne jest, aby Proxy Product Owner miał swoją specjalizację. Tematy, które trafiają do niego (a więc i do jego zespołu) powinny być powiązane tematycznie i tworzyć całość. Na pewno nie powinniśmy rozdzielać ich losowo na zasadzie „parzyste ID w backlogu na lewo, a nieparzyste na prawo”.
Podobnie jak zwykły PO, tak i Proxy PO będzie miał dobre znajomości po stronie klienta. Nawet jeśli nie zna odpowiedzi na trapiące zespół pytanie, to powinien przynajmniej wiedzieć, kto wie (poza samym PO). Proxy PO dobrze żyje zarówno z interesariuszami, jak i SME. Oczywiście, wszystko w ramach swojej specjalizacji.
Krótko mówiąc: Proxy Product Owner to proxy (pośrednik) pomiędzy niedostępnym PO, a zespołami które bardzo go potrzebują. W praktyce rzadko jest to pełen etat. Najczęściej ktoś dzieli pełnienie tej funkcji z byciem profesjonalistą w Zespole Deweloperskim.
Proxy Product Owner inaczej
Ci z Was, którzy znają metody na skalowanie Scrum mogą zauważyć podobieństwa pomiędzy Proxy Product Ownerem, a rolami znanymi z innych pomysłów na zapanowanie nad kilkoma zespołami.
W podejściu mającym swoje źródła w firmie Spotify („Spotify model”) Proxy Product Owner nazywa się… „Product Owner”, a „główny” PO zwany jest tam Tribe Leaderem. Echa tego sposobu myślenia można znaleźć w roli Area Product Ownera (APO). W niektórych podejściach APO odpowiada za cały obszar oraz podległych mu (Proxy) Product Ownerów, którzy wspierają go w poszczególnych tematach.
Krótko mówiąc, większość pomysłów na skalowanie Scrum zakłada dwa poziomy Product Ownerów. „Ogólny” – odpowiadający za wizję, plan i negocjacje oraz „zespołowy”, który zajmuje się określonym wycinkiem tematycznym backlogu i lokalnie wspiera zespół. Tę drugą rolę my zwykliśmy nazywać Proxy Product Owner.
Przypominamy też, że z wszystkimi odstępstwami od Scrum Guide’a należy uważać. Bardzo łatwo jest przekształcić sprawnie działający Scrum w bardzo dziwnie funkcjonujący ScrumBut. Z drugiej strony, wielokrotnie wspominaliśmy o tym, że a) nie jesteśmy ewangelizatorami Scruma b) czysty Scrum działa dobrze tylko dla dwóch-trzech zespołów.
Jeżeli więc mamy do czynienia z otoczeniem, w którym kilka czy kilkanaście zespołów pracuje nad jednym backlogiem, to nie ma wyjścia – czysty Scrum nie wystarczy. Nasze doświadczenie mówi też, że w takiej sytuacji lepiej sprawdzi się rozszerzenie (ScrumAnd) niż modyfikacja (ScrumBut).
A podział Area Product Owner – Proxy Product Owner po prostu działa.
Proxy Product Owner to tylko jedno z zagadnień, jakie poruszamy na naszym szkoleniu Skalowanie Scrum. Zapraszamy!
