"Profesjonalny Właściciel Produktu. Jak Scrum zwiększa przewagę konkurencyjną" | McGreal Don i Jocham Ralph - opinia o książce i luźne rozważania na temat roli PO

Przygotowuje się i tak daleko jeszcze nigdy nie byłem… PSPO I. 

Książka polecana przez www.scrum.org jako jedna z niezbędnych do przejścia, aby przygotować się i podejść do certyfikacji PSPO I. 

Sama certyfikacja nie jest dla mnie celem (niepotrzebna mi laurka). Bardziej skupiam się na merytoryce jaką z tej książki mogę wyciągnąć i wdrożyć do realnej pracy z zespołem. 

Od 1,5 roku mam przyjemność współpracować z fantastycznym zespołem scrumowym o pełnym zakresie ról (UX/UI design, Analitycy, FE DEV, BE DEV, Testerzy manualni i automatyczni). 

Jesteśmy jednym squadem spośród kilkunastu w TRIBE. Pracujemy nad rozwojem systemu do rozliczania płatności. 

Ogólnie nasze podejście opiera się na modelu Spotify (o którym więcej możesz poczytać tutaj: https://www.qagile.pl/scrum/model-spotify-na-obrazku/).

Product Ownerze, na początku trzeba umiejętnie się osadzić w tym, jakim PO jesteś. Czy rozwijasz bardziej produkt na rynku i skupiasz się na działaniach komercjalizacji, czy bardziej skupiasz się na zbieraniu wymagań od wewnętrznych interesariuszy i budujesz nowe funkcjonalności w celu optymalizacji procesów biznesowych. 

W tej książce każda z tych ról znajdzie coś dla siebie

Oczywiście, ogólny opis czym rola się zajmuje, jakim PO można być oraz jakim lepiej, aby się nie było, ponieważ sam zespół może nie dostrzec wartości z takiej roli. 

W książce opisywane są wartości podejścia SCRUM, jego kluczowe artefakty i ceremonie. Krotki opis, jak się do nich przygotować, jaki jest ich cel i po co one są. 

Na pewno znajdziesz ciekawe podejścia do zarządzania backlogiem prac, za który jesteś odpowiedzialny jako PO. Tutaj dochodzimy do bardzo kluczowej sprawy. Znam firmy w których za backlog będziesz odpowiedzialny, ale nie masz na niego kompletnie wpływu, znam też takie w których wręcz musisz stworzyć go sam, ponieważ nawet nie ma żadnego wsparcia i ról które mogłyby Ci w tym pomóc. Natomiast w książce przedstawione są ciekawe narzędzia i sposoby prowadzenia warsztatów User Story Mappingu – POLECAM! Do tego sposoby opisywania samych User Stories i metody ich dekompozycji. User Stories to nie koniec zabawy i czasami trzeba mocno się angażować w działania zespołu, w celu wypracowania planu jak dane user story jest realizowane. Dlatego też uważam, że mimo wszystko PO powinien mieć wiedzę techniczną z IT, aby wnosić wartość do zespołu (oczywiście nie tak dużą, jak z zakresu znajomości biznesu i procesów jakie w nim zachodzą). 

Jak już zbudujesz backlog prac i w miarę go dopracujesz pojawiają się kolejne wyzwania… czyli, co robić najpierw? Na czym się skupić? Tematów jest dużo, każdy z nich jest ważny (ważniejszy dla kogoś innego), a zespół ma określone moce przerobowe. Do tego można nałożyć możliwość wejścia na produkcję (nie każda firma daje możliwości wdrażania się na produkcję na koniec każdego sprintu 🙂 ). 

W tej książce również znajdziesz kilka ciekawych inspiracji do tego, jak kategoryzować pracę, jak nawet określać jej priorytet i zderzać to z określeniem wysiłku, jaki zespół musi poświęcić na wypracowanie funkcjonalności. 

Przestrzegałbym jednak przed modelowym podejściem i brnięciem w pełny proces, ponieważ może to zajmować dużo czasu… a jak wiadomo w tej branży go nie ma (mimo iż wszyscy współpracujący z IT non stop powtarzają, że Ci z IT to tylko się spotykają).

Moim zdaniem kluczowe, abyś miał to w głowie i tak facylitował dyskusje zespołu, aby wplatać pytania lub poszczególne elementy do waszej pracy. 

„A na kiedy to będzie?” – pytanie które słyszy każdy PO i to nie ważne w którym Agile będziesz pracował, musisz znać na nie odpowiedź i tyle. Odpowiedzi, że to Agile i idziemy w dobrym kierunku, w kierunku naszej Gwiazdy Północy, nie satysfakcjonują Sponsorów. Ludzie którzy pytają Cię o terminy zarządzają biznesem, a nie kosmosem (chociaż być może ktoś z was pracuje w branży kosmicznej 🙂 ). 

W książce opisane są również metody, w jaki sposób na podstawie danych można określić prędkość zespołu wytwórczego w danym sprincie. 

Powiem wprost. Jeżeli ktoś ma porządek i niezależny zespół w JIRA, to fajnie jest na to patrzeć. Im więcej powiązań, realizacji prac we współpracy z innymi zespołami, tym ciężej takie rzeczy zbierać, aby dawały poprawne dane na których można bazować.

Jednak uważałbym, czy jak już zbierasz dane, to umiesz je czytać i podejmować na ich bazie decyzje.  

Robienie czegoś sztuka dla sztuki, to obciążenie dla zespołu, a jak wiadomo – czas to pieniądz… więc jak macie robić coś, aby tylko było, to ja jestem zwolennikiem, aby za bardzo się na tym nie skupiać (delikatnie mówiąc) 🙂 

My z zespołem wyceniamy zadania, omawiamy plany na wdrożenia i wiemy, co kiedy możemy dołożyć. Czy bazujemy na wykresie spalania per sprint ? Nie. Nie daje nam to wartości. Jednak być może wam tak. Pracujemy nad tym, aby badać inne parametry, które dadzą nam wartość. 

Wracając do książki. 

Nawet jeżeli nie podchodzisz do certyfikacji to polecam ten tytuł. Zarówno tym, którzy zaczynają swoją rolę PO, jak i dla zaawansowanych wyjadaczy. Jedni zobaczą, co można robić, zainspirują się, a Ci drudzy przypomną sobie, że są pewne podejścia, o których być może zapomnieli albo inaczej podchodzą do tematu. 

Chętnie poznam wasze opinie o tej książce, ale też o samej roli PO w firmach w których pracujecie. Co zgadza się z podejściem Agile/Scrum, na ile macie swój własny system i wyzwania z nim związane. 

Moja ocena: 8/10 

Pozdro

Oskar