Najczęstsze błędy popełniane przez Product Ownera

Najczęstsze błędy popełniane przez Product Ownera

Podczas mojej już prawie 10-letniej przygody z metodykami zwinnymi, współpracując jako Agile Coach i Scrum Master z różnymi firmami, pracowałem z wieloma Product Ownerami – początkującymi, czy doświadczonymi, skutecznymi, czy nieskutecznymi, bardziej lub mniej „umocowanymi” w organizacji. Pozwoliło mi to zebrać pewną subiektywną pulę wniosków odnośnie najczęstszych błędów przez nich popełnianych.

Chciałbym się tymi wnioskami podzielić w tym artykule. Pełnisz rolę PO? Świetnie! Potraktuj je jako wskazówki, co mógłbyś zmienić lub usprawnić w swojej pracy. Jeśli któreś z poruszanych przeze mnie zagadnień nie będzie dla Ciebie jasne, napisz do mnie lub poproś o pomoc Scrum Mastera, z którym współpracujesz. Zanim przejdę do praktyki - najpierw trochę teorii.

Kim jest Product Owner i czym się zajmuje?

Jak nazwa wskazuje, jest właścicielem produktu i zgodnie z opisem roli przez scrum.org, jest przede wszystkim odpowiedzialny za maksymalizację wartości tego produktu, wynikającej z pracy Zespołu. Sposób, w jaki jest to osiągany, może się znacznie różnić w zależności od konkretnej organizacji, zespołu, czy nawet poszczególnych osób.

Product Owner jest jedyną osobą zarządzającą wymaganiami (Product Backlogiem) poprzez:

• jasne i zrozumiałe opisanie wymagań,
• ustalanie kolejności realizowania wymagań w sposób pozwalający osiągać założone cele,
• optymalizowanie wartości pracy wykonywanej przez Zespół,
• zapewnianie, że Product Backlog jest dostępny, przejrzysty i jasny dla wszystkich, a także, że pokazuje nad czym Zespół będzie pracował w dalszej kolejności,
• zapewnianie, że Zespół w ten sam sposób rozumie elementy Product Backloga w wymaganym stopniu, żeby mógł go przekształcić w produkt.

Product Owner może wykonywać powyższe zadania samodzielnie lub zlecać je np. Zespołowi, jednak to PO ostatecznie za nie odpowiada. PO to pojedyncza osoba, a nie komitet - może reprezentować interesy różnych osób, lecz jeśli ktoś chce zmienić priorytet lub opis elementu w Product Backlogu, to musi zwrócić się bezpośrednio do PO (lub przynajmniej go poinformować, że coś zostało zmienione). PO jest jedyną decyzyjną osobą, jeśli chodzi o treść i priorytet elementów Product Backloga. Nikt inny nie powinien wymagać od Zespołu, aby pracował nad innymi wymaganiami lub zadaniami.

Powyższy opis jest dość enigmatyczny. Jest to celowa zagrywka ze strony twórców frameworka Scrum, żebyśmy pamiętali o tym, że jest to tylko ramowy zbiór zasad i reguł do uniwersalnego zastosowania. W skrócie można go podsumować 3 wnioskami:

1) Product Owner maksymalizuje wartość produktu
2) Jest jedyną osobą, która zarządza Product Backlogiem
3) Jest jedyną osobą decyzyjną dla Zespołu

Sam framework Scrum nie daje gotowych odpowiedzi na pytanie, jak Product Owner powinien działać w ramach danego otoczenia biznesowego, organizacji, produktu, czy zespołu, z którym współpracuje.

Do tego podstawowego zbioru opisanego w Scrum Guide dodałbym jeszcze, że w praktyce jest to niezwykle trudna i wymagająca rola. Odpowiedzialność za tworzenie wizji, rozwijanie mapy drogowej produktu, bieżąca praca nad wymaganiami, planowanie wydań, czy zarządzanie budżetem. Dodatkowo, ciągła  komunikacja z klientami, użytkownikami, czy innymi osobami zaangażowanymi w proces tworzenia i rozwoju produktu. Nie zapominając oczywiście o uczestniczeniu w ceremoniach Scrumowych i byciu dostępnym dla zespołu, żeby odpowiadać na ich bieżące pytania. To tylko wierzchołek góry lodowej, jeśli chodzi o obowiązki Product Ownera.

Tyle z teorii – przejdźmy do praktyki.

Jak być dobrym Product Ownerem?

Tak miał brzmieć pierwotnie tytuł tego artykułu, ale doszedłem do wniosku, że nie jestem w stanie napisać gotowej „recepty” jak być dobrym Product Ownerem, ponieważ jest to mocno relatywne określenie. W związku z tym, postanowiłem spisać listę najczęściej (w mojej opinii i z moich obserwacji) popełnianych przez PO błędów wraz z propozycjami, co można zrobić, żeby je poprawić (kolejność nie ma znaczenia):

• „Bałagan” w Product Backlogu

Product Backlog jest podstawowym narzędziem pracy Product Ownera, dlatego jako PO, niezależnie od natłoku obowiązków, powinieneś dbać o to, żeby cały czas był:

• jeden - pamiętaj, JEDEN Product Backlog! Nawet, jeśli nad produktem pracuje więcej, niż jeden zespół. Wiem, że jest to dość oczywiste, ale bardzo często zdarza się, że oprócz „oficjalnego” Product Backloga, „gdzieś tam” są kolejne, dodatkowe listy wymagań,
• przejrzysty - Product Ownerzy zazwyczaj albo zaniedbują Product Backlog, albo zbyt mocno go rozpisują. Jeśli problem polega na zaniedbywaniu Backloga, znajdź osobę, która pomoże Ci w jego utrzymaniu (najlepiej spoza Zespołu), ale pamiętaj, że ostatecznie to Ty jesteś odpowiedzialny za to, co się w nim znajduje. Z kolei zbyt szczegółowo rozpisane wymagania i Sprinty zaplanowane z dużym wyprzedzeniem w praktyce powodują małe zaangażowanie Zespołu i słabą komunikację, bo przecież wszystko jest już spisane i zaplanowane,
• zrozumiały dla zespołu – pytaj Zespół, czy sposób w jaki opisałeś wymagania wraz z kryteriami akceptacji jest dla nich zrozumiały. Kiedy? Kiedy tylko jest na to sposobność – np. na Planowaniu Sprintu, czy Refinemencie,
• uporządkowany – skoro jako PO jesteś odpowiedzialny na maksymalizowanie wartości produktu, zadbaj o to, żeby Product Backlog był spriorytetyzowany, wg. określonych przez Ciebie kryteriów. Nie musisz porządkować od razu całego Backloga – przede wszystkim powinien być on przygotowany na 1-2 Sprinty do przodu. Możesz skonsultować się z Zespołem, natomiast pamiętaj, że ostateczną decyzję podejmujesz Ty!
• wyestymowany – jako Product Owner odpowiadasz za to co jest do zrobienia i w jakiej kolejności, natomiast Zespół za dostarczenie gotowego rozwiązania i estymat – nie rób tego za nich! Możesz natomiast przypominać im o uzupełnianiu tych estymat, ponieważ w połączeniu ze średnią prędkością Zespołu, pomoże Ci to w strategicznym planowaniu wydań i Sprintów,
• dostępny – każdy członek Zespołu i osoby zainteresowane tworzonym produktem wiedzą gdzie jest Product Backlog i w dowolnym momencie mogą na niego spojrzeć.

• Mikrozarządzanie, ciągła kontrola i brak zaufania

Pamiętaj, że zespół jest interdyscyplinarny i stanowi grono ekspertów. Zgodnie z zasadą samoorganizacji, sam potrafi „zamienić” Twoje wymagania na wysokiej jakości produkt i w większości sytuacji nie potrzebuje Twojego „zarządzania”. Nie musisz ich cały czas kontrolować. Nie pytaj kilka razy dziennie, kiedy w końcu stworzą rozwiązanie – mają na to czas do końca Sprintu i to od nich zależy, jak zaplanują swoją pracę.

Jako PO nie jesteś i nie powinieneś być team managerem, line managerem, czy project managerem. Bądź przewodnikiem, skup się na wyznaczaniu kierunku (wizji, mapy rozwoju produktu), dawaj autonomię odnośnie tworzonych rozwiązań, buduj poczucie celu, umożliwiaj dążenie do mistrzostwa, zapewnij bezpieczeństwo i stabilizację, zaufaj samoorganizacji, zarażaj kreatywnością… podsumowując – bądź liderem!

• Brak czasu dla Zespołu

Jak już wcześniej wspomniałem i pewnie wiesz to również z własnego doświadczenia, rola Product Ownera jest mocno wymagająca i czasochłonna. W związku z tym, często czas przeznaczony na rozmowę z Zespołem w trakcie Sprintu ustępuje, jeśli chodzi o priorytety, innym obowiązkom.

„Nasz PO wiecznie nie ma dla nas czasu”, „PO notorycznie wszystkich zbywa i unika odpowiedzi”, „wysłaliśmy już 5 maili i dalej nie wiemy, czy jest sens dalej realizować to wymaganie”, „znowu nie ma PO – po co mamy robić Review i Planowanie?” – to tylko kilka przykładów wypowiedzi od członków zespołów.

Sytuacja jeszcze bardziej się komplikuje, kiedy fizycznie nie znajdujesz się w tej samej lokalizacji, co Zespół. Zadbaj o to, żeby brać udział w ceremoniach Scrumowych i żeby spędzić przynajmniej 20% czasu Sprintu, aby być dostępnym dla Zespołu.

• Brak zwracania uwagi na koszty i zwrot z inwestycji (ROI)

Być może jest to spowodowane tym, że nie zarządzasz budżetem, być może do tej pory nie myślałeś o Sprincie jako o inwestycji. Fakt jest taki, że każdy Sprint jest małym projektem, który ma swój koszt i oczekiwany zwrot z inwestycji.

Jako koszt rozumiem wszystkie wydatki, czyli wynagrodzenie członków zespołu, koszt software’u, hardware’u, infrastruktury, licencji itd. Zatem, jako świadomy Product Owner, rozważnie dysponuj czasem Zespołu, a pracę nad tworzeniem, czy rozwijaniem produktu potraktuj, jakbyś prowadził własny biznes, inwestując swoje pieniądze.

• Niekorzystanie z informacji zwrotnych

Czy jako PO potrafisz odpowiedzieć na pytanie, czy Twój produkt przynosi wartość? Zastanawiałeś się kiedyś, czy wymaganie które właśnie przekazałeś Zespołowi będzie miało wartość? Pamiętaj, że wartość, to nie tylko zysk.

Jak zatem zbadać o wartość produktu? Oddaj go jak najszybciej użytkownikowi i zapytaj o feedback, porozmawiaj z osobą, która profesjonalnie zajmuje się badaniami doświadczeń użytkownika (UX), używaj wskaźników, a dzięki temu, będziesz mógł stworzyć własną definicję wartości dla swojego produktu.

• „Wrzutki”

Jedną z najczęstszych przyczyn braku motywacji w zespole są nieustanne „wrzutki” wymagań w trakcie trwania Sprintu. Ważna reguła – podczas Planowania Sprintu „podpisujesz” pewnego rodzaju kontrakt z Zespołem. Kontrakt dotyczy zakresu, który uważasz za najważniejszy do wykonania w Sprincie, który właśnie zaczynacie. Tym samym obiecujesz, że nie będziesz go zmieniał, dopóki nie zmienią się okoliczności otoczenia biznesowego.

Dobrą praktyką, jest zostawienie jakiegoś buforu, jeśli wrzutki miałby się pojawić. Jeśli zakres Sprintu zmienia się cały czas, być może trzeba się zastanowić, czy nie wybrać innego frameworka – np. Kanbana lub Scrumbana?

• Brak decyzyjności i „umocowania” w organizacji

Słabo umocowany Product Owner prawdopodobnie nie będzie w stanie skutecznie poprowadzić rozwoju produktu, żeby jak najszybciej spełnił potrzeby i oczekiwania klientów. Jako skuteczny PO powinieneś móc podejmować decyzję samodzielnie i mieć autonomię, jeśli chodzi o rozwijanie produktu.

• Brak wiary w swój produkt

Będę szczery - jeśli nie wierzysz w swój produkt, nie jesteś do niego przekonany lub masz inne, negatywne emocje z nim związane, lepiej będzie dla wszystkich (łącznie z Tobą), jak zrezygnujesz z bycia jego właścicielem. Nic tak nie demotywuje Zespołu, jak wiecznie niezadowolony, zdenerwowany, nieprzewidywalny, czy wybuchowy PO z wysokim poziomem długu emocjonalnego.

• Zbyt duże „zakochanie” się w produkcie

W przeciwieństwie do poprzedniego podpunktu, to sytuacja, kiedy jako Product Owner, jesteś zbyt pewien swoich pomysłów. Wiem wiem… chcesz stworzyć COŚ wielkiego... produkt, z którego będą korzystały miliony użytkowników! Jesteś przekonany, że wszystko, co znajduje się w Product Backlogu jest absolutnie konieczne do wykonania, bo przecież precyzyjnie określiłeś wszystkie potrzeby i wszystkie oczekiwania użytkowników końcowych.

Brzmi znajomo? Jeśli tak, to przynajmniej teraz jesteś świadomy, że nie jest to dobre podejście, a już na pewno nie jest zwinne. Nie twórz od razu „ogromnego” rozwiązania dla wszystkich, zbadaj grupę docelową, stwórz MVP (Minimum Viable Product), a następnie stopniowo dodawaj kolejne funkcjonalności.

• Brak zainteresowania prędkością zespołu

Uwaga! Nie mylić z kontrolą zespołu, bo nie o to chodzi. Jako PO, powinieneś używać wskaźników takich jak wykres średniej prędkości zespołu (Velocity Chart), czy wykres „spalania” wymagań (Product Burndown Chart). Ważne tutaj jest, aby Product Backlog był wyestymowany i jeśli dodasz do tego informację o średniej prędkości zespołu, to dostajesz zestaw, który pomoże Ci w ramowym wyznaczeniu zakresu Sprint, czy nawet planu wydań.

• Błędy? Defekty? Dług techniczny? Kiedyś się poprawi…

Jeśli wychodzisz z takiego założenia, to jesteś na dobrej drodze, żeby w szybkim tempie „uśmiercić” swój produkt. Pamiętaj, że wymaganie skończone to takie, które zostało stworzone, PRZETESTOWANE i POPRAWIONE oraz spełnia wszystkie kryteria akceptacji i elementy Definicji Ukończenia (Definition of Done).

Uważnie słuchaj Zespołu. Jeśli mówi, że potrzebuje przestrzeni w zakresie Sprintu na poprawienie błędów, defektów, czy popracowania nad długiem technicznym, zadbaj o to, żeby mogli się tym zająć. Pamiętaj, że błędy i defekty również są elementami Product Backloga jako elementy utrzymania produktu.

• Presja czasu

To również popularny problem, szczególnie w sytuacji, kiedy zbliża się tzw. „deadline”. Zdarza się też kiedy produkt został wydany i na skutek feedbacku z rynku pojawiło się dużo zmian lub/i sporo defektów. Często pojawia się ciśnienie i konflikty wewnątrz Zespołu lub na linii Zespół – PO.

Dużo zadań zostaje rozpoczętych, a na koniec Sprintu prawie nic nie jest skończone. Jeżeli jest skończone, to często niskiej jakości (zawiera dużo błędów). Znajoma sytuacja? Zapewne. Jeśli mierzysz się z takim problemem, to musisz sobie przede wszystkim uświadomić fakt, że czas nie jest z gumy i Zespół nie zrealizuje nagle 2-3 krotnie większego zakresu w tym samym czasie.

Chwilowe wypożyczenie 2 kolejnych członków zespołu, również nie pomoże, a co więcej, narobi więcej szkód, niż pożytku. Pomoże natomiast częstsza rozmowa z Zespołem, oparta na chęci wzajemnej współpracy, czy ustalenie i przestrzeganie reguł zespołowych. Zrezygnuj również z wielozadaniowości, bo się nie sprawdza. Skończ zaczynać, zacznij kończyć.

Podsumowanie

Powyższe zachowania brzmią znajomo? Nie martw się. Każdy z nas popełnia błędy. Najważniejsze, żeby być ich świadomym i ich nie utrwalać. Sam również miałem okazję być Product Ownerem inwestując własne pieniądze i nie uniknąłem takich zachowań pod wpływem presji czasu, czy natłoku obowiązków. Teraz, kiedy jestem ich świadomy, na pewno w niektórych sytuacjach zachowałbym się inaczej. Jak to mówią - „człowiek uczy się na błędach”.

Powyższa lista na pewno nie wyczerpuje tematu. Moją intencją jest przede wszystkim zainicjowanie dyskusji i zwrócenie uwagi na niektóre problemy, które widziałem w różnych środowiskach. Zapraszam do komentowania i do kontaktu. Podoba Ci się? Nie podoba Ci się? Chciałbyś coś dodać z własnego doświadczenia? Napisz i daj swój feedback.