Jak wspominałem w zapowiedzi artykułu, chciałbym tym razem oprzeć wywód na zagadnieniu, które prawdopodobnie wierciło szkorbut w myślach niejednego Scrum Mastera: Jak żyć? Cóż teraz począć, skoro Product Owner nie umie w Jirę?
Już spieszę z odpowiedzią: nic.
Koniec. Dziękuję za uwagę.
Dobra, ściemniałem.
Tak naprawdę Jira – bądź jakiekolwiek inne narzędzie, które jest kontenerem dla backlogu produktu – była dla moich refleksji jedynie naskórkowym pretekstem. Kto stoi za backlogiem? Product Owner, ma się rozumieć. A zgodnie z zapisami Scrum Guide’a, jedną z jego zasadniczych – choć oczywiście nie jedyną – odpowiedzialnością jest maksymalizowanie wartości produktu będącego efektem pracy Scrum Teamu. W sumie brzmi sensownie, moje dotychczasowe doświadczenie prowadzi mnie jednak do wniosku, że organizacje interpretują tę kluczową odpowiedzialność na przeróżne sposoby.
Chciałbym dziś podzielić się trzema najczęściej spotykanymi przeze mnie wariantami, z tym jednak zastrzeżeniem, że i one są pewnymi uogólnieniami i jako takie nie pokrywają pełnego spektrum możliwości – w końcu ludzka kreatywność nie zna granic, a i specyfika rynków/organizacji/charakterów nie pozwala zamknąć się w kilku akapitach. Listę przedstawiam od najwyższego do najniższego stopnia zaawansowania, a wszystkie pogrubione nazwy są oczywiście umowne:
Product Owner – Wizjoner:
| Co robi? | • Potrafi wyartykułować, w jakim stadium rozwoju produkt powinien znaleźć się w przyszłości (formułuje zarówno Cel Produktu, roadmapę jak i długoterminową wizję); • Aktywnie współpracuje z wszystkimi interesariuszami i potrafi inkorporować ich zapotrzebowania do Backlogu; • Maksymalizuje wartość pracy wykonywanej w Zespole; • Przychodzi do Zespołu nie z opisem funkcji do zbudowania, ale z problemami do rozwiązania (outcomes vs outputs); |
| Z kim współpracuje? | Interesariusze, Zespół Developerski, Scrum Master |
| Minimalne warunki sukcesu | Samozarządzający się Scrum Team skoncentrowany na pełnym spektrum Produktu i odpowiedzialny za jego jakość |
Product Owner – Koordynator Feature’ów:
| Co robi? | • Potrafi wyartykułować, jakie funkcje powinny pojawić się w systemie/produkcie w perspektywie sprintu i dłuższej; • Pełni rolę pośrednika pomiędzy Zespołem a Interesariuszami, prerogatywa maksymalizacji wartości Produktu leży jednak poza obszarem jego wpływu – reaguje na oczekiwaną wartość listą spodziewanych funkcji systemu; • Koncentruje się na dostarczaniu wszystkich funkcji; |
| Z kim współpracuje? | Interesariusz (Wizjoner), Zespół Developerski, Scrum Master |
| Minimalne warunki sukcesu | Scrum Team odpowiedzialny za jakość Produktu; |
Product Owner – Koordynator Backlogu:
| Co robi? | • Wprowadza zapotrzebowania do Backlogu Produktu, jednak bez weryfikacji, które realnie wpływają na maksymalizację wartości Produktu; • Zarządza priorytetami z punktu widzenia pilności, nie wartości; • Operacjonalizuje pracę w formie zadań utrzymywanych w Backlogu (na przykład w Jira); |
| Z kim współpracuje? | Koordynator Feature’ów (na przykład przełożony), Zespół Developerski, Scrum Master |
| Minimalne warunki sukcesu? | Grupa wykonawców zadań |
Jak widać, jeżeli główne odpowiedzialności Product Ownera sprowadzają się wyłącznie do przesuwania klocków w backlogu, szanse na uwalnianie wartości dla klientów/interesariuszy/organizacji drastycznie maleją. Co więcej, im niżej Product Owner w tym zestawieniu, tym więcej ścian dzieli go od źródła realnej wiedzy o potencjalnej wartości (np. Koordynator Backlogu przesuwa klocki w oparciu o zalecenia Koordynatora Feature’ów spoza zespołu, Koordynator Feature’ów konstruuje natomiast zawartość Backlogu na podstawie pomysłów Wizjonera spoza zespołu, który najpewniej pozostaje w bezpośrednim kontakcie z klientem).
Oczywiście miejsce na powyższej drabince uzależnione jest nie tylko od kompetencji osoby, która bierze na siebie odpowiedzialność Product Ownera, ale również od umocowania tej osoby w strukturze organizacji, a niezwykle często nawet od kultury organizacyjnej. Im wyżej jednak, tym bliżej idei Scrum Teamu jako samozarządzającej się jednostki i bliżej zaczerpniętego ze Scrum Guide’a założenia, że jego [PO] decyzje muszą być respektowane przez całą organizację.
Ach, jeszcze jedno. Wobec powyższego znikoma biegłość PO w obsłudze Jiry naprawdę nie jest najgorszym, co może ci się przytrafić.