Siedem grzechów głównych Product Ownera (przy współpracy z Zespołem Developerskim)

book

Wiedza | ORGANIZACJA

Kto nie popełnia błędów, niech pierwszy rzuci Backlogiem. Zastanówmy się wspólnie, gdzie pojawiają się błędy w roli Product Ownera i jak można ich uniknąć. Gotowi na stanięcie twarzą w twarz ze sobą?

Jeden: Biegniemy nie wiadomo dokąd

Zespół, który nie ma wypracowanego Celu Sprintu na Sprint Planningu, nie umie się zorganizować, a tym samym realizować wartościowych przyrostów. Pozbawieni sensu działania tracimy wartość, którą niesie praca w Scrumie i biegamy wkoło, by tylko przetrwać od spotkania do spotkania. Sprinty stają się do siebie bliźniaczo podobne, Zespół pracuje mechanicznie, zaczyna dominować indywidualizm, a zamiast współpracy pojawiają się rozproszenie i nuda. Czy o to nam chodzi? Na pewno nie. Poza tym Cel Sprintu daje nam elastyczność w Sprint Backlogu.

 

O tym, jak Planować Sprint oraz o skutkach biegania bez celu możecie przeczytać tutaj.

 

Ważny jest nie tylko jasno sformułowany Cel Sprintu, ale również dobór zadań, które odpowiednio ze sobą powiązane, powinny przynieść należytą wartość. Wszystko po to, aby członkowie Zespołu Scrumowego mieli się wokół czego zorganizować.

Niedobra jest nie tylko sytuacja chaosu, ale też zbyt ambitny cel w myśl: „zróbmy teraz wszystko”. Nie, nie w tym rzecz. Po to mamy Sprint Backlog i Cel Sprintu, aby z głową podchodzić do zadań. Robienie wszystkiego naraz w Scrumie to nicnierobienie.

W pierś musi uderzyć się często Product Owner, który nie potrafi przedstawić wizji tego, co chce osiągnąć w Sprincie i co staje się źródłem wspomnianych sytuacji. Podpowiadam też, że losowanie zadań do Sprint  Backloga nie jest dobrym pomysłem – trudno jest bowiem zarządzać rozproszonym Przyrostem.

Dwa: Sukcesy na chybił trafił

Dojrzałe organizacje, które pracują w Scrumie, są świadome, że sukces jest czymś mierzalnym. Podczas Planowania Sprintu należy wziąć pod uwagę: Definition of Done czy Metryki, jakie mierzy Zespół (niektóre z Evidence-Based Management, Kanban, Velocity, Capacity). Dzięki temu można zaprognozować, co Zespół dostarczy. Ponadto dla organizacji, która korzysta z EBM, szczególnie ważna jest odpowiedź na pytania: po co to robimy, co chcemy osiągnąć, jaką decyzję podejmujemy w oparciu o dane albo jaki eksperyment przeprowadzić.

Nie zapominajmy również o Retrospektywach Sprintu. Jeśli nam umkną, zmniejszymy szansę Zespołu, na wprowadzenie wcześniej przez niego ustalonych zmian, i tworzymy okoliczności do popełnienia tych samych błędów. Tym samym uniemożliwiamy ciągły rozwój Zespołu (continuous improvement).

Konsekwentne mierzenie sukcesów i porażek pozwala wyciągnąć wnioski na przyszłość. Lessons learned nie służą szukaniu winnych, ale pozwalają na nieustanne stawanie się lepszymi. Zaobserwowałam, że to podejście staje się u nas coraz bardziej popularne (i to w różnych branżach!). Ważne jest to, aby otwarcie rozmawiać o porażkach i wyciągać z nich cenną lekcję. Do tego potrzebna jest odwaga i zaufanie.   

Trzy: Zagubione Backlogi

Przy naszej pracy w Scrumie musimy brać pod uwagę Backlog Sprintu i Backlog całego Produktu. Wyobraźmy sobie, że nie mamy zdefiniowanego Product Backlogu. Co się wówczas dzieje? Nie mamy nad czym pracować podczas Planowania Sprintu i nie mamy Prognozy (Forecast) tego, co będzie efektem danej Iteracji.

Działanie w myśl zasady „jakoś to będzie” zazwyczaj nie wychodzi. To strategia niedoświadczonego laika, a nie wytrawnego Członka Zespołu Scrumowego. Doświadczeni w Scrumie wiedzą, jak dużą rolę odgrywa posiadanie uściślonych Product Backlogów (Product Backlog Refinement)

Cztery: Product Owner upaja się władzą

Tak, tak, wszyscy znamy takich ludzi, których dominująca osobowość utrudnia pracę innym. Bywają Product Ownerzy, doprowadzający Zespół Scrumowy do szewskiej pasji słowami: „zrobiłbym to szybciej” ( to moje ulubione 🙂 ). Taki Product Owner naciska na większe Velocity i Capacity, a nieasertywny Zespół nie jest w stanie dostarczyć w iteracji odpowiedniej jakości.

Product Owner to rola, nie władza. W dodatku to rola jedna z wielu i Product Owner, który zbytnio koncentruje się na „zarządzaniu ludźmi”, ostatecznie przegrywa – nie osiąga regularnie Celu Sprintu, wartościowego produktu, zabija współpracę w Zespole i traci własną pozycję. Rola Product Ownera opiera się na współpracy nie tylko ze Zespołem, ale również na pracy z organizację, stakeholderami (interesariuszami), klientami, użytkownikami. Współpracy, nie władzy.

Czasem wraz z rozwojem organizacji Product Ownerami zostają nieraz byli Deweloperzy. I znów to samo. Estymują sami zadania lub twierdzą, że przecież oni „zrobiliby to szybciej”. Tak, mogli robić szybciej, jak byli Deweloperami. Na zewnątrz Zespołu Deweloperskiego perspektywa się zmienia, nie znamy wszystkich uwarunkowań. Dajmy pracować Zespołowi i pracujmy w ramach swojej roli. Wątpliwości? Zajrzyj do Scrum Guide!

Pięć: Sami sobie poradzicie

Ekhm, ale czy na pewno? To nad czym dziś mamy pracować? Takie pytania słusznie zadają sobie uczestnicy Sprint Planningu, na którym nie pojawił się Product Owner. Nieobecny, nieosiągalny, niekomunikatywny, zapomniał przekazać, co chciałby osiągnąć. Jaki wpływ na produkt, organizację i zespół ma taki Product Owner?

Jeśli Product Owner regularnie nie pojawia się podczas Planowania Sprintu, nie jest w stanie spełniać swojej roli, a inni uczestnicy spotkania nie mogą dowiedzieć się m.in. czy Product Backlog jest wciąż aktualny.

Sześć: Demokracja, wszędzie demokracja

Czasami dochodzę do wniosku, że możliwość wysyłania zaproszeń na Sprint Planning powinna mieć swój limit. Kto się wypowie na spotkaniu? Wszyscy. Co z tego wyjdzie? Nic dobrego.

To ważne poznać cele Interesariuszy i ustalić ich rolę w dostarczaniu produktu. Robić to ciągle, w sposób empiryczny. Później Product Owner musi umieć odpowiednio zarządzać Stakeholderami. Niedopuszczalne jest pozwalanie na powtarzające się, bezproduktywne dyskusje pomiędzy Interesariuszami podczas Planowania Sprintu. Nie można wówczas ustalić Backlogu Sprintu i zaplanować, nad czym będziemy pracowali podczas Iteracji. Kto ma ostateczne zdanie w temacie Product Backloga (i kolejności zadań w nim)? Product Owner. Tylko ta osoba ma pełny obraz sytuacji, ponieważ współpracuje z organizacją (i stakeholderami, dlatego układa elementy Product Backloga m.in. pod kątem wartości i ryzyka.

Siedem: Nie znam się na komputerach

Jeśli jesteś dobrym Product Ownerem, uwierz mi, nie musisz (choć znajomość technologii, w której pracuje Zespół znacznie ułatwia pracę). Chodzi o Twoje podejście do technologii i uwzględnianie technicznych uwag Zespołu w codziennej pracy.

Szczególnie, gdy Product Owner jest przypadkiem człowieka dominującego i niepotrzebnie nalega na przyśpieszenie postępu pracy. Narasta wówczas dług techniczny, który trudno nadrobić. Zespół to sygnalizuje. Jak zachowuje się często „nietechniczny” Product Owner? Zapomina albo gorzej – nie chce uwzględnić długu technicznego w Backlogu Sprintu, a Zespół pewnych kwestii nie nadrobi. Stanu Przyrostu nie da się przewidzieć. Kiepska jakość. Product Owner nie jest w stanie wydać Przyrostu w takim stanie, a zatem go zwalidować i uzyskać feedback. Może też się zdarzyć, że przez dług techniczny Zespół dużo wolniej lub mniej dostarcza. Mamy błędne koło, z którego całemu Zespołowi bardzo trudno szczęśliwie wyjść na prostą.

Podobnie bywa z podejściem do wdrażania nowych technologii. Dzisiaj możemy pracować w starszej wersji oprogramowania, ponieważ mamy takiego, a nie innego klienta. Jutro możemy nie mieć klientów, gdyż za późno zdecydujemy się na zmianę i zdobywanie nowych kompetencji.

W biznesie, zwłaszcza w IT, liczy się innowacyjność i efektywność. Pamiętajmy, że pomijanie aspektów technicznych krok po kroku prowadzi do porażki projektu i frustracji Zespołu.

Dajcie znać, z którymi sytuacjami spotkaliście się w swoim otoczeniu. A może sami popełniliście kiedyś któryś z błędów będąc w roli Product Ownera? Na pocieszenie dodam, że błędów nie popełnia ten, kto nic nie robi. Kluczowe jest wyciąganie z nich cennych lekcji i zbieranie doświadczeń. Powodzenia!

Najlepsze artykuły:

Najlepsze artykuły: