Ładnych parę lat temu, gdy pracowałem jeszcze jako Scrum Master byłem na szkoleniu organizowanym przez Scrum.org. Na jednym z ćwiczeń analizowaliśmy skutki posiadania kilku Product Ownerów w jednym projekcie. Wtedy uważałem taki scenariusz za zupełnie nierealny i sztuczny. Kto w ogóle wpadłby na taki pomysł w prawdziwym projekcie? Przecież nikt nie chciałby kilku kierowców w jednym samochodzie albo kilku kapitanów na jednym okręcie. To wręcz oczywiste proszenie się o problemy.
Tego typu sytuacje zacząłem spotykać dopiero jako konsultant/Agile Coach. Najczęściej w projektach, które wyciągałem z tarapatów. Niedawno miałem okazję zetknąć się z tego typu przypadkiem kolejny raz. Tym razem ilość Product Ownerów w jednym projekcie była rekordowa. Było ich aż sześcioro! Poniżej przedstawiam problemy, jakie zrodziła ta sytuacja.
Ciągła rywalizacja 6 Product Ownerów
Każdy Product Owner reprezentował inny dział w firmie. W związku z tym miał zupełnie inne cele biznesowe. To co było istotne dla jednego z nich nie miało większej wartości dla jego kolegi. Jak łatwo przewidzieć tego typu sytuacja jest świetną pożywką dla konfliktów i rywalizacji. Dużo energii było marnowanej na niepotrzebne przepychanki.
Co jednak najgorsze, osoby o słabszej pozycji w organizacji czekały na realizację swoich zadań bardzo długo, nawet gdy zadania te miały największą wartość biznesową dla firmy jako całości. Z drugiej strony, jeżeli ktoś uważał, że jego feature nie jest jakoś specjalnie istotny, nie marnował okazji. Wiedział, że jeżeli nie „przepchnie” go teraz to może to się już później nie udać.
Product Ownerzy nie mają czasu na projekt
Początkowo może się to wydawać dziwne. W końcu jeżeli mamy aż tylu Product Ownerów w jednym Projekcie to jak mogą nie mieć wystarczającej ilości czasu? Wynika to z faktu, że przy takiej liczbie osób nikt w firmie nie pozwoliłby, aby wszystkie te osoby zajmowały się tylko zarządzaniem produktem. Każda z nich miała również inne obowiązki, najczęściej o wysokim priorytecie.
Zorganizowanie Sprint Planningu, Product Backlog Refinementu oraz Sprint Review, na którym byliby wszyscy Product Ownerzy graniczyło z cudem. Na dodatek Ci, którzy przychodzili, często byli nieprzygotowani. Było regułą, że deweloperzy zaczynali pracować nad zadaniami nie wiedząc za bardzo co mają zrobić. Oczywiście prowadziło to do sytuacji, że efekt ich pracy nie odzwierciedlał potrzeb określonego Product Ownera – robili nie to co trzeba.
„Dodatkowa praca na boku”
Jeżeli PO nie pojawił się na Sprint Review „odbierał” efekt pracy deweloperów dopiero kilka dni po rozpoczęciu kolejnego Sprintu. Często okazywało się, iż dany feature wymagał jeszcze kilku poprawek. Product Owner w takim przypadku nie za bardzo chciał czekać na kolejny Sprint, tym bardziej, że mógłby nie załapać się „na swoją kolej”. Podobnie osoby pomijane przez wiele Sprintów nie za bardzo miały ochotę dłużej zwlekać.
W związku z tym nagminne były prośby do deweloperów o zrobienie „jednej małej rzeczy” ponad zaplanowany zakres. Jak wiadomo w dewelopmencie „małe rzeczy” mogą być większym wyzwaniem niż się wydaje. Tym bardziej jeżeli z taką prośbą zgłaszały się 3-4 osoby. Całkowicie rozbijało to pracę. Efektywność i morale deweloperów drastycznie spadały. Kolejne Sprinty nie kończyły się sukcesem.
Brak transparencji
Ponieważ rzeczy robione „na boku” były często przekazywane nieoficjalnym kanałem, nie było widoczne, ile pracy faktycznie zostało wykonane. Wyższy management miał ogromne zastrzeżenia wobec teamu deweloperów. Uważał, że bardzo mało „dowożą” co prowadziło do pewnych spięć.
Bardzo ciężko było odpowiedzieć na pytanie, w którym miejscu jest teraz projekt. Dodatkowo zespół miał problem z przewidzeniem, ile jest w stanie wziąć na następny Sprint. W związku z czym nie dało się stworzyć prognoz na kilka Sprintów do przodu. Projekt „szedł na ślepo”.
Brak jasnego kierunku
Rozproszona odpowiedzialność, ciągła rywalizacja oraz brak transparencji spowodował, że trudno było skutecznie zarządzać rozwojem produktu. Praktycznie rzecz biorąc nie można było określić, jak produkt ma wyglądać np. za pół roku. Projekt „dryfował” bez określonego kierunku. Dużo rzeczy było zaczynanych, jednak zanim zaczęły przynosić konkretną wartość biznesową następowały spontaniczne zwroty i realizacja nowej koncepcji. To bardzo niebezpieczna sytuacja. Istniały nawet podejrzenia, że przez niektóre miesiące praca, którą wykonali deweloperzy przyniosła więcej szkody niż pożytku. Nie wytworzyli zbyt dużo wartości biznesowej, a utrzymanie kodu zawsze kosztuje. Lepiej, aby w tym czasie mieli płatny urlop.
Rozwiązanie:
1. Jeden Product Owner
Rolę Product Ownera powinna obejmować tylko jedna osoba. Może mieć osoby do pomocy, jednak to ona podejmuje ostatecznie decyzje w sprawie rozwoju produktu. To ona określa, jaka praca będzie wykonywana i w jakiej kolejności. Innymi słowy określa, co będzie w Product Backlogu i jakie będą w nim priorytety.
Wszyscy dotychczasowi Product Ownerzy stają się steakholderami 1. Celem Product Ownera jest spełniać ich potrzeby w sposób zorganizowany i niewymagający „przepychania się”. Product Owner i wszyscy stakeholderzy muszą wspólnie określić sprawiedliwe z ich punktu widzenia kryteria, determinujące kolejność pracy, która będzie wykonywana przez zespół deweloperów.
2. Wysoka pozycja Product Ownera
Product Ownrer musi mieć bardzo silną pozycję w firmie, aby nie ulegać naciskom wysoko postawionych kolegów. Nie może być podwładnym nikogo kto jest stakeholderem. Jego bezpośrednim przełożonym powinien być prezes firmy.
3. Jasna wizja produktu
Należy określić wizję produktu na kilka miesięcy do przodu (np. 6 miesięcy). Może w tym pomóc np. road mapa 2. Bardzo ważne jest też posiadanie Product Backlogu z gotowymi do rozpoczęcia zadaniami3. Najlepiej na 2-4 Sprinty do przodu. Oczywiście Product Backlog powinien odzwierciedlać potrzeby organizacji. Jego zawartość oraz priorytety mogą ulegać zmianie.
4. „Pogadaj o tym z Product Ownerem”
Następuje całkowity zakaz „wrzutek” dla deweloperów. Każdy deweloper powinien się zobowiązać, że gdy ktoś go poprosi o wykonanie pracy niezaplanowanej na trwającą akurat iterację powie: „porozmawiaj o tym z Product Ownerem”. Powinien istnieć bufor na zadania krytyczne4 jednak to Product Owner decyduje, czy to zadanie krytyczne czy „wrzutka”.
Terminologia i dodatkowe uwagi:
1. Steakholder – inaczej interesariusz. Osoba bezpośrednio zainteresowana wynikami projektu. To on ma być na końcu zadowolony z produktu.
2. Road Mapa – inaczej harmonogram. Określenie mniej więcej kiedy i co będzie gotowe.
3. Bardzo przydatne może się tutaj okazać Definition od Ready. Należy jednak pamiętać jakie może nieść zagrożenia. Polecam świetny artykuł Mike’a Cohn’a na ten temat.
4. Bufor na zadania krytyczne. Czasami planując, co zrobimy w następnej iteracji jesteśmy świadomi ogromnego ryzyka, że będziemy musieli szybko wykonać niespodziewane zadanie krytyczne w trakcie prac. Najczęściej jest to poważny błąd na produkcji. Aby nie zaburzyć prac „bierze” się mniej zadań na Sprint, a niezagospodarowany czas jest przeznaczony właśnie na takie przypadki. Jeżeli bufor staje się naprawdę duży (np. więcej niż 50%) miałbym poważne wątpliwości, czy w takim wypadku nie sprawdzi się lepiej podejście beziteracyjne (np. Kanban).