Ostatnimi czasy coraz więcej słyszę i widzę osób spierających się o zasadność utrzymywania roli Product Ownera w firmie. Dla przykładu: w zeszłym miesiącu David Anderson, twórca Kanbana, opublikował artykuł Czy Agile kosztuje cię zbyt dużo? (swoją drogą polecam jego publikacje, bo choć jako remedium na każde zło wskazuje li i jedynie Kanbana, to podaje również przepiękne przykłady źle stosowanego Scruma), otwarcie krytykując koszty Scruma i jego przerost formy nad treścią. Uzasadnia to między innymi przypadkami, w których konsultanci scrumowi każą zatrudnić 400 Product Ownerów, bo w firmie jest 2400 programistów, a więc musi być jeden PO dla 6 developerów, żeby było lege artis, i takich, w których Product Ownerzy tak naprawdę okazali się być analitykami biznesowymi, spisującymi jedynie wymagania dla zespołów. Oczywista oczywistość – koszty utrzymania tylu i takich pracowników były znaczącym elementem dla budżetów firm i często kończyły się rezygnacją z osobnej roli PO w przedsiębiorstwie.
Drugi, ciekawy przykład na eliminowanie roli PO dostarczył mi Jacek Wieczorek, który podczas styczniowego spotkania poznańskiej społeczności Agile wysłuchał opowieści Piotra Trojanowskiego o zmianach, które dzieją się w firmie Currency One. Najciekawszym punktem prezentacji była część dotycząca właśnie roli Product Ownerów w firmie, a precyzując – decyzja o zlikwidowaniu tej roli na poziomie zespołów. W dużym skrócie, rolę Chief Product Ownera przejął jeden z członków zarządu, natomiast na poziomie zespołów rolę PO zastąpili liderzy projektu w myśl zasady “MKPL”, czyli “osoba z największą wiedzą dowodzi” (ang. most knowledgeable person leads). Powód zmiany wg. Piotra był prozaiczny – wcześniej urzędujący Product Ownerzy często pełnili rolę “proxy”, i funkcjonowali bardziej jako Product Managerowie.
Jak zatem jest? W mojej skromnej opinii powyższe przypadki powyżej świadczą nie o braku uzasadnienia dla roli Product Ownera, ale o nadal pokutujących nadinterpretacjach i nieumiejętności właściwego wykorzystania tej roli dla dobra firmy. Rozprawiając się zatem z nimi po kolei:
- 400 PO, bo musi być jeden PO dla 6 developerów? Gdyby do mnie przyszedł konsultant Agile z podobnym pomysłem, przede wszystkim poprosiłabym o wskazanie, gdzie w Scrum Guidzie, czy innej oświeconej księdze wyczytał podobne przykazanie. A potem bym mu uprzejmie podziękowała za konsultacje. Jeden Product Owner może współpracować i z 9 zespołami – pisze o tym Ken Schwaber w NexusGuide, czyli przewodniku po skalowaniu Scruma. Również Scrum Guide wskazuje jedynie, że w zespole scrumowym powinien być PO, ale nie wymaga, by każdy zespół scrumowy miał osobnego PO. To właśnie szkodliwa nadinterpretacja.
- PO jako analityk biznesowy spisujący jedynie wymagania? PO jako proxy i Product Manager? Wyborny strzał w stopę. Jeśli Product Owner nie ma autonomii, nie może samodzielnie podejmować decyzji i wskazywać, co jest dla rozwoju produktu najważniejsze, jeśli nie odpowiada własną głową za błędy i jednocześnie nie firmuje swoją osobą sukcesów, to nie mówcie, że macie PO. Product Owner to nie jest osoba do zarządzania czasem pracy, wrzucania elementów do backlogu, czy przekazywania poleceń od innych. Product Owner to wizja produktu, to jego roadmapa, to znajomość konkurencji, trendów, przewidywanie preferencji klientów, analizowanie rynku, współpraca z użytkownikami i głęboka, ekspercka wiedza na temat produktu, którym się zajmuje. Jeśli pozwolicie Product Ownerowi być Product Ownerem pełną gębą, wówczas może się zdziwicie, jak dobrze wasze produkty mogą być rozwijane.
Oczywiście, ile jest firm i ile jest produktów, tyle jest zupełnie niepowtarzalnych przypadków. Niemniej jednak, zanim zaczniecie się zastanawiać nad zwolnieniem Product Ownera, lub jego zatrudnieniem – zapytajcie sami siebie, czy rola ta w waszej firmie jest, lub będzie wykorzystywana, jak należy. Czy potraficie stworzyć takie środowisko pracy, by Product Owner faktycznie mógł wznieść się na wyżyny, czy może potrzebujecie następnego przesuwacza dokumentów. Jeśli to ostatnie – ok, ale nie mówcie naokoło, że macie Product Ownera i mimo to wasz Agile, czy Scrum nie działają.
P.S. Tak, wiem, znalezienie bądź wykształcenie prawdziwego Product Ownera wymaga rokującego człowieka, czasu i odrobiny cierpliwości ze strony pracodawcy, co jest zadaniem trudnym, ale nadal łatwiejszym od poszukiwań świętego Graala.