Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Product Owner największym wrogiem Scruma

David Pereira Head of Product Management
Sprawdź argumenty obu stron i zdecyduj sam, który Ci bardziej odpowiada. Decyzyjny product owner czy niedecyzyjny zespół Scrum.
Product Owner największym wrogiem Scruma

W ostatnich latach zaobserwowałem, że wiele zespołów odchodzi już od Scruma. Ta tendencja mnie zadziwia. Wygląda na to, że tracą oni wiarę w obiecane rezultaty tego frameworku.


Natknąłem się też na wiele artykułów kwestionujących sposób, w jaki framework ten jest wykorzystywany w rzeczywistości. Jest to dla mnie dość smutna sytuacja. Jednak dlaczego tak się właśnie dzieje? Jakie czynniki powodują, że zespoły mają wątpliwości co do pracy ze Scrumem?


Możecie się nie zgodzić z tym, co powiem, ale uważam, że Product Owner jest jednym z najgorszych wrogów Scruma. Byłem świadkiem wielu sytuacji, w których zespół Scrum poniósł porażkę, ponieważ Product Owner poprowadził ich w złym kierunku. W niektórych z tych sytuacji sam byłem Product Ownerem.

Dopóki zespół scrumowy nie będzie miał silnego Product Ownera, nie będzie w stanie osiągać dobrych wyników.


Pozwólcie, że podzielę się z Wami moimi argumentami na to, dlaczego Product Owner jest jedną z głównych przyczyn niepowodzeń. Mam nadzieję, że będziesz wiedział, czego unikać, jeśli wcielasz się zawodowo w taką rolę.


1. Zaangażowanie w pracę zespołu

Interesariusz: Aby odciążyć nasz zespół obsługi klienta, musimy wdrożyć chatbota. Czy możecie to zrobić?

Product Owner: Pewnie! Programiści są obeznani w temacie.

Interesariusz: Świetnie! Jak myślisz, jak długo to potrwa?

Product Owner: Hm. Myślę, że możemy zobowiązać się do dostarczenia projektu w dwóch Sprintach. Przygotuję User Stories i przekażę je zespołowi.


Taka sytuacja jest częsta w dysfunkcyjnych zespołach scrumowych. Product Ownerzy uzgadniają rozwiązanie z terminem realizacji bez rozmowy z żadnym programistą. Kiedy tak się dzieje, programiści nie angażują się w rozwiązanie, ponieważ nie mieli w nim nic do powiedzenia. Bez zobowiązania, zaangażowanie jest niskie.

Relację tę nazywam umową o świadczenie usług. Programiści nie są właścicielami rozwiązania, ponieważ ktoś inny zdefiniował, co powinno być przez nich zaimplementowane. Mimo to wywiera się na nich presję, aby rozwiązanie to zadziałało. Jednak czy Product Ownerzy lub interesariusze są właściwymi osobami do określania rozwiązania? Nie wydaje mi się.

Dobry Product Owner definiuje istotne problemy do rozwiązania, podczas gdy cały zespół scrumowy definiuje, JAK je rozwiązać!


2. Nie wie, jak ustalać priorytety

Ustalanie priorytetów jest koszmarem dla prawie każdego Product Ownera. Problemem nie jest podjęcie decyzji, co robić; wyzwaniem jest określenie, czego nie robić. Interesariusze wywierają presję, aby dostarczać coraz więcej i więcej. Bez względu na to, co zespół dostarczy, nigdy nie spełni to oczekiwań.

„Do zrobienia zawsze jest więcej, niż wystarczy na to czasu i środków”.
Jeff Patton, Mapowanie historyjek użytkownika: Przepis na produkt idealny


Niestety, HiPPO (Highest Paid Person Opinion) często decyduje o tym, co jest priorytetem, a co nie. Mimo to Product Owner pozostaje odpowiedzialny za maksymalizację wartości. Wielu ludziom brakuje umiejętności niezbędnych do odwrócenia tej sytuacji.

Kiedy Product Owner nie radzi sobie z ustalaniem priorytetów, zespoły scrumowe nie różnią się niczym od chomików biegających w kołowrotku.


3. Wprowadzanie zespołu w błąd

Pozwól, że zadam Ci pytanie. Jak często widujesz zespoły scrumowe z poniższymi cechami?

  • Wizja produktu nie istnieje lub jest zapomniana.
  • Celem Sprintu jest zawsze dostarczenie wszystkich zadań przed końcem terminu.
  • Więcej funkcji = sukces.
  • Więcej Story Pointów = postęp.


Widziałem wiele zespołów, w których występowały wszystkie te antywzorce. Niestety, często to właśnie Product Owner był głównym odpowiedzialnym za takie niefortunne sytuacje. I w tym miejscu zastanawiam się, czy Product Ownerzy wiedzą, czym jest wartość.

Przed moim ostatnim webinarem stworzyłem ankietę, w której pytałem o główne wyzwania stojące przed osobą na stanowisku Product Owner. Z ponad 30% odpowiedzi, zwycięzcą został: „Skup się na wartości, a nie na funkcjach”.

Więc dlaczego Product Ownerzy zakochują się w funkcjach? Często dzieje się tak, że wiele osób ląduje na tym stanowisku bez wcześniejszego doświadczenia w zarządzaniu produktem, a to nieuchronnie prowadzi do błędnych przekonań. Najpierw musimy zrozumieć dlaczego, a potem co. Nie tworzymy funkcji dla samego ich posiadania; tworzymy je po to, aby dostarczać wartość. Dopóki wpływ, jaki chcemy osiągnąć, nie jest jasny, nie powinniśmy rozmawiać o funkcjach.

„Najważniejszym, czego nauczyłam się w zarządzaniu produktem, jest to, aby zawsze skupiać się na problemie. Jeśli zakotwiczysz się w pytaniu „dlaczego?”, będziesz bardziej skłonny do budowania tego, co właściwe”.
Melissa Perri, Ucieczka z pułapki budowania: Efektywne zarządzanie produktem


4. Posłuchajcie proszę

„Mój Boże! Mam tak wielu interesariuszy, którymi muszę się zająć”.

„Muszę czemuś nadać priorytet. W przeciwnym razie ktoś przekaże to wyżej do szefa”.

„Muszę uszczęśliwić interesariuszy, wtedy wszystko inne będzie hulało”.


Często słyszę takie zdania wypowiadane przez osoby na stanowisku Product Ownera. Irytuje mnie to, ponieważ:

  • Interesariusze nie są klientami.
  • Szczęście interesariuszy nie ma nic wspólnego z dostarczaniem wartości.
  • Robienie po trochu dla wszystkich to doskonały przepis na przeciętność.


Faktem jest, że osoby na stanowisku Product Owner muszą radzić sobie z wieloma interesariuszami, ale to, jak sobie z nimi radzisz, ostatecznie definiuje Twoje szanse na sukces. Liczy się współpraca, a nie szczęście.

Dobry Product Owner nie zadowala interesariuszy, ale buduje poważne partnerstwa, w celu dostarczenia udanego produktu.


5. Unikanie konfliktów

Słowo konflikt przeraża wielu ludzi, ponieważ postrzegają je jako coś złego. Ale czy konflikt jest rzeczywiście czymś złym? Dla mnie współpraca bez konfliktów prowadzi do fałszywej harmonii. Ludzie mają różne opinie. Jeśli nie czujemy się wysłuchani, nie będziemy się niczemu poświęcać w całości.

Często obserwuje się, jak Product Ownerzy unikają konfliktów. Na przykład, przy podejmowaniu decyzji, które rozwiązanie jest najlepszą opcją dla danego problemu, ludzie będą mieli różne punkty widzenia. Jak zatem podjąć decyzję? Możesz albo dążyć do konsensusu, albo uwidocznić konflikty i je rozwiązać. Rezultaty byłyby podobne do tych poniżej:

  • Konsensus: grupa będzie dostosowywać rozwiązanie do momentu, aż wszyscy się zgodzą. Rozwiązanie będzie ostatecznie opcją nie optymalną, ponieważ każdy poszedł na kompromis.
  • Konflikt: każdy podzieli się swoją perspektywą, konflikty zostaną wyjaśnione, a grupa zdecyduje o najlepszych opcjach. Zespół zgadza się nie zgadzać.


„Poszukiwanie konsensusu jest często przeszkodą w działaniu”.
Marcia W. Blenko


Przemyślenia końcowe

Scrum nigdy nie zadziała, jeśli Product Owner nie jest odpowiednio przygotowany do takiej pracy. Często zdarza się, że firmy nie rozumieją, na czym polega ta rola i ktoś niedoświadczony bierze na siebie tę ogromną odpowiedzialność.

Z zamiłowania jestem Product Ownerem i wiem, że wiele zespołów, z którymi pracowałem, poniosło porażkę właśnie z mojego powodu. Nie posiadałem odpowiednich umiejętności, aby sprostać wyzwaniom, przed którymi stanąłem, i ostatecznie wyniki były rozczarowujące. Dla kadry kierowniczej Scrum był czarną owcą; winą obarczano framework. Ja jednak wiem, kto był prawdziwym wrogiem.

Organizacje będą nadal osiągać przeciętne wyniki, dopóki nie zrozumieją, kim jest Product Owner.

Zespół scrumowy potrzebuje do takiej roli dobrego profesjonalisty. W przeciwnym razie sukces będzie tylko nieosiągalnym marzeniem.

Oryginał tekstu w języku angielskim przeczytasz tutaj.

1 komentarz

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej