A co, gdy brak Product Ownera? 

Dziś pytanie od czytelnika, które pozwoliłem sobie nieco zmodyfikować i uogólnić. W tej nowej wersji brzmi ono następująco: „Co zrobić, jak zabraknie nam Product Ownera?” Ale tak naprawdę możemy też zapytać, „Co robić, jak nie wiemy co robić?”

Brak osób decyzyjnych

Oryginalne pytanie od naszego czytelnika, Kuby, brzmiało „Co zrobić jeśli osoba decyzyjna idzie na urlop, a my nie wiemy jak czegoś zrobić?” Jest to rewelacyjne zagadnienie, które pomoże nam pokazać, jak działa dobry Scrum Master i w jaki sposób faktycznie usuwa on problemy pojawiające się w Sprincie oraz na styku współpracy pomiędzy zespołem, a resztą organizacji.

Zacznijmy od pierwszej myśli, która powinna się pojawić w głowie naszego SM-a. Jest problem. Tu i teraz. Zdrowy rozsądek podpowiada, że możemy zrobić wszystko, co zadziała. Zastanówmy się więc, czy na pewno jesteśmy zblokowani przez fakt, że nie wiemy jak coś zrobić? Być może tylko nie chcemy wziąć na siebie odpowiedzialności lub obawiamy się, że zmarnujemy trochę czasu. A może wiedza, której poszukujemy jest gdzieś indziej? Jeżeli odpowiedzi na blokujące nas pytanie może udzielić Project Manager, inny zespół albo nawet klient – tam właśnie powinniśmy sięgnąć.

Najpierw zróbmy tak, żeby było dobrze. Jeżeli możemy się dowiedzieć – dowiedzmy się. Jeśli mamy podejrzenia, jak to „coś” można zrobić – zróbmy. Jeżeli wymaganie jest niejasne – sięgnijmy do źródła, czyli np. do klienta. Natomiast jeśli utknęliśmy w takim punkcie, że nie możemy iść ani w lewo, ani w prawo i naprawdę cokolwiek nie zrobimy, to będzie źle – nie róbmy nic. Poświęćmy dane wymaganie na rzecz pozostałych elementów w Sprint Backlogu. Jeżeli sprawa jest krytyczna – trudno, zadzwońmy do kogoś na urlopie. Tylko, że naprawdę trudno mi sobie wyobrazić sytuację, w której sami nawet nie potrafimy zgadnąć prawdopodobnego rozwiązania.

Źródło problemu

Drugą myślą, która pojawi się w głowie efektywnego Scrum Mastera, będzie rozwiązanie przy tej okazji wszystkich przyszłych problemów z tej kategorii. Ugaszenie pożaru to jedno, ale dla SM-a równie ważne jest, żeby wszystkie tego typu sytuacje mogące się zadziać w przyszłości rozwiązać, zanim w ogóle się zmaterializują. Chcemy tak zorganizować Scrum Team, aby nigdy więcej nie zadawać sobie tytułowego pytania. A to znaczy jedno – przegadajmy to na Sprint Retrospective.

Scrum Masterzy zwykle działają dwutorowo. Z jednej strony pomagamy udrożnić proces Scrum tu i teraz. Z drugiej zaś dbamy o to, aby był on drożny także w przyszłości. Jeśli jakiś problem jest wybitnie jednorazowy, to oczywiście nie ma co sobie nim głowy zaprzątać. Wystarczy go rozwiązać dziś. Natomiast nieobecność osoby decyzyjnej raczej brzmi jak coś, co będzie się powtarzać.

Co więc zrobimy na retro? Zastanowimy się, dlaczego nie wiedzieliśmy jakiejś podstawowej rzeczy o realizowanym wymaganiu. Zastanówmy się, dlaczego nierozpoznane („niezrefinementowane”) wymaganie trafiło do realizacji i jakim cudem na Planowaniu Sprintu nikt nie zadał tych pytań, które nas potem zblokowały? To są prawdziwe problemy, które musimy zaadresować. Może trzeba zająć się grzechami Product Ownera, a może poprawić Product Backlog Refinement? Niektórzy dojdą do wniosku, że rozwiązaniem jest dla nich Proxy Product Owner, a inni skupią się na lepszym opisywaniu kryteriów akceptacji wymagań. Ile zespołów, tyle rozwiązań.

Pamiętajmy jednak, że każdy ma swoją rolę i swoje odpowiedzialności. I nie bójmy się powiedzieć, że ktoś nie wykonuje swojej pracy. W końcu na Planowaniu to „Product Owner gwarantuje, że uczestnicy są przygotowani do omówienia najważniejszych elementów Product Backlogu”.

Analogia jachtowa

Analogią, której najczęściej używam na przedstawienie zależności pomiędzy rolą Product Ownera, a Developerami jest pełnomorski jacht żaglowy. Na takim jachcie znajduje się osoba odpowiedzialna za jednostkę, zdrowie i życie załogi i parę innych rzeczy. Ale ja nie o tym. To sternik, zwany też skipperem, wyznacza kierunek i sposób płynięcia. Nie znaczy to, że zawsze stoi za sterem – bardzo często to właśnie załoga w całości obsługuje jednostkę. Co więcej, w sytuacji gdy sternik jest pod pokładem (bo np. je lub śpi), to załoga decyduje o tym w jaki sposób płynąć do celu określonego przez sternika. To oni decydują o ustawieniu żagli, halsowaniu, odpaleniu silnika, itd.

W sytuacji w której pojawia się problem bądź zmieniają się warunki (np. wiatr), to załoga albo wie jak postąpić albo tego biednego sternika budzi. Tenże zerka na to, co się dzieje, podpowiada bądź pomaga w wykonaniu manewru (w zależności od doświadczenia załogi) i wraca spać. W tej opowieści to właśnie nasz Product Owner jest takim sternikiem. Wyznacza bowiem Cel Produktu oraz uczestniczy w tworzeniu Celu Sprintu. Zna też backlog, czyli nie tylko wie, co się teraz dzieje, ale co się będzie działo niedługo.

Oczywiście opowieść morską znacznie uprościłem i pominąłem np. wachty, zakresy odpowiedzialności, itd. Z drugiej strony możemy zastanawiać się, kim w tym modelu jest Scrum Master. Nie wchodźmy w analogie zbyt głęboko, bo każda się posypie. Ta przytoczona powyżej służy tylko i wyłącznie jednemu – pokazaniu zależności pomiędzy Developerami, a Product Ownerem w kontekście tego, kto nadaje kierunek w którym płyniemy, a kto faktycznie obsługuje łajbę.

Oficjalne stanowisko Scrum.org

Ci, którzy chcą zdać sobie jakiś certyfikat Scrum, mogą trafić na bardzo podobne pytanie na jednym z egzaminów. Oficjalne odpowiedzi są zgodne z tym, o czym dywagowaliśmy dzisiaj. Po pierwsze, Scrum Team powinien działać zgodnie z aktualnym stanem wiedzy. Czyli mówiąc wprost: róbmy tak, jak zostało nam powiedziane i jak dowiedzieliśmy się na przykład na refinementach. Po drugie, jeżeli nieobecność PO staje się permanentna, musimy znaleźć nowego Product Ownera. Nie może być inaczej, bo Product Owner jest nam niezbędny do efektywnej scrumowej pracy.

Mam nadzieję, że rozwiałem wszystkie wątpliwości w kwestii obecności osób decyzyjnych, a w szczególności Product Ownera. Jeżeli chcecie dowiedzieć się jeszcze więcej, zapraszamy na nasz kanał na YouTube oraz na nasze szkolenia Scrum i zwinne warsztaty. Polecamy także naszą #białkową listę mailingową, gdzie rozsyłamy wiadomości z naszymi przemyśleniami, poradami i nie tylko. Czasem poruszamy też tam bardziej drażliwe tematy. Zapraszamy!