258

Jak monitorować i rozliczać projekty agile.

Wyzwanie w monitorowaniu projektów zwinnych

Zwinne podejście do realizacji projektów stawia do góry nogami klasyczny trójkąt projektowy (czas, zakres, koszt) przy okazji podważając zasadność stosowania klasycznego podejścia do monitorowania i rozliczania prac (np. Analiza Wartości Wypracowanej). Z pomocą przychodzi miernik  – Program Predictability Measure. Jest to kolejny z ciekawych mechanizmów używanych przez SAFe i propagowanych przez niego, a mogących być z powodzeniem stosowanych w oderwaniu od SAFe’a.

Monitorowanie realizacji projektów i ich końcowe rozliczanie jest w waterfallu dość łatwe. Mamy zdefiniowany oczekiwany rezultat, mamy plan który uwzględnia kluczowe zmienne: czas realizacji, zakres prac i budżet. Na bieżąco rejestrujemy odchylenia od tego planu, które akceptujemy tworząc nowy plan bazowy lub przyjmujemy do wiadomości odnotowując jak bardzo oddaliliśmy się od pierwotnego celu. Projekty oczywiście bywają bardzo złożone i wtedy dużo energii kosztuje nas liczenie tych wartości, ale ich konstrukcja jest banalnie prosta.

Z projektami zwinnymi, tudzież ogólnie ze zwinnym rozwojem produktów, jest dużo trudniej. W tym przypadku nie fixujemy się tak mocno na zakresie prac, ba, nawet sam cel może być dość płynny. Podobnie pływa nam czas i koszt realizacji. To, co stanowi podstawę naszego funkcjonowania to stały rytm prac i cykliczne dostarczanie coraz większej, sprzedawalnej wartości na bazie aktualnych priorytetów. Dokładniej opisałem ten mechanizm tutaj:

Próby stosowania klasycznego sposobu monitorowania i rozliczania projektów, w tak zmiennej konfiguracji czasu realizacji, zakresu i kosztu jest koszmarem. Przynajmniej dla mnie. Z uwagą przyjrzałem się zatem wskaźnikowi Program Predictability Measure, który daje bardzo ciekawą alternatywę, mimo iż jest dość wymagający i specyficzny.

Czym jest Program Predictability Measure?

Jak sama nazwa wskazuje Program Predictability Measure odnosi się do:

po pierwsze – programu (a konkretniej zwinnego programu, czyli zbioru prac zdecydowanie większego niż Sprint, a nawet projekt)

po drugie – jego przewidywalności

Dlaczego Program Predictability Measure a nie “Sprint Predictability Measure”? Jeśli w naszych projektach zwinnych koncentrujemy się na sprintach i to one stanowią kluczową jednostkę naszego cyklu PDCA (Plan Do Check Adapt, tak, tak, celowo napisałem Adapt zamiast Act ;]) to Sprint Goal i Increment są świetnymi wartościami, które mówią nam o relacji zamierzeń do efektów. W dużej skali chcemy jednak monitorować w dłuższym horyzoncie niż dwu-, czterotygodniowym. Dlatego interwałem do którego będziemy się odnosić jest Program Increment, który agreguje kilka sprintów i pozwala nam stawiać sobie i realizować większe cele integrujące prace wielu zespołów zwinnych. O Program Increment i PI Planningu możesz poczytać tutaj:

Stosując Program Predictability Measure porównujemy zatem plan na Program Increment z jego wykonaniem. A konkretniej będziemy porównywać cele Program Increment (PI Objectives) do poziomu ich realizacji.

Co istotne, aby nadać celom wartości liczbowych, nie posługujemy się ich pracochłonnością, tylko wartością biznesową, jaką dostarczają. W związku z tym, rozliczając cel “Obsługa płatności internetowych”, nie będziemy porównywać liczby zadań, roboczodni, czy Story Points, tylko oczekiwaną przez biznes, versus dostarczoną przez zespoły, wartość biznesową.

Wzór wygląda następująco:

Program Predictability Measure  = Delivered Business Value/Planned Business Value*100%

Oczekiwana wartość metryki PPM to od 80 do 100 procent. Jeśli PPM mieści się w tym przedziale oznacza to, że zespół realizujący program jest przewidywalny i wiarygodny. Wiarygodny nie w rozumieniu stosunku estymowanej pracochłonności do faktycznie włożonej pracy, czy zaplanowanego czasu realizacji do faktycznego czasu trwania zadań, tylko oczekiwanej wartości, jaka zostanie dostarczona interesariuszom do faktycznej wartości wytworzonego Przyrostu. Zlecając mu prace w trybie zwinnym możemy z dużym prawdopodobieństwem zakładać, że dostarczy on zadeklarowaną wartość biznesową, nawet jeśli w trakcie realizacji zmieni się zakres zadań lub pojawią się inne pomysły na sposób implementacji funkcjonalności. Czas realizacji (w rozumieniu rytmu pracy i timeboxów) mamy zadany, koszt pracy również jest znany bo wiemy ile kosztować nas będzie dana iteracja, to czym gramy, to zakres prac, a celem nie jest odbębnienie roboczogodzin, tylko wytworzenie wartościowego rozwiązania.

Wyznaczanie Program Predictability Measure

Nie wchodząc na razie w pikantne szczegóły, sposób wyznaczania PPM jest następujący:

Definiujemy cele iteracji (Program Increment)

Dodajemy cele drugorzędne, które będą stanowiły dla nas bufor, do nich jeszczę wrócę

Przypisujemy celom oczekiwaną/planowaną wartość biznesową

Na koniec iteracji oceniamy dostarczoną wartość biznesową dowiezionych (lub nie dowiezionych) celów

Sumujemy wartości i wyznaczamy metrykę Program Predictability Measure

Jak widać przy liczeniu PPM przy dostarczonej wartości biznesowej bierzemy pod uwagę cele drugorzędne, a przy oczekiwanej nie, w związku z tym wyliczenia wyglądają następująco:

Program Predictability Measure  = Delivered Business Value/Planned Business Value*100%

Program Predictability Measure  = 20/23*100% = 87%

Nie dam sobie nic za to uciąć, ale podejrzewam, że w trakcie czytania pojawiły się u Ciebie takie pytania:

1. Jak wyznaczamy Business Value?
2. Dlaczego przy dostarczonej wartości biznesowej bierzemy pod uwagę cele drugorzędne, a przy oczekiwanej nie?

Wyznaczanie Business Value

Bazowanie na Wartości Biznesowej jest tyleż ciekawym i atrakcyjnym konceptem, co kontrowersyjnym i bardzo trudnym w implementacji. Business Value nadawane jest dla obu rodzajów celów, zarówno PI Objectives jak i Stretch Objectives, przez Właścicieli Biznesowych i jest ich subiektywną oceną w skali 1 do 10. Pomysł żeby w zwinnym środowisku rozwijania produktów bazować przy ocenianiu nie na ilości włożonej pracy, poświęconego czasu, na koszcie, czy odzwierciedleniu planowanego pierwotnie zakresu, tylko na dostarczanej wartości biznesowej, jest świetny. Motywuje to do koncentrowania się na rezultacie i maksymalizacji wartości rezultatu zamiast na trzymaniu się planów, które z czasem mogą okazać się nieaktualne, źle skonstruowane, bądź bazujące na błędnych założeniach. Problem z BV polega jednak na tym, że wartość ta jest subiektywną oceną Właściciela Biznesowego, a co za tym idzie może być mało zrozumiała i trudna do wyjaśnienia interesariuszom. SAFe niestety nie pomaga zbytnio w nadawaniu tej wartości, nie instruuje jak to robić …. a przynajmniej nie wprost, ale ciekawe podejście do określania wartości biznesowej można zaczerpnąć z WSJF (Weighted Shortest Job First), które jest metoda priorytetyzacji backlogów. Samą metodę opisuję tutaj:

To co moim zdaniem można próbować z niej wyciągnąć w kontekście kwantyfikowania Business Value, to potraktowanie Cost of Delay jako Business Value. Po małej modyfikacji, możemy na przykład przyjąć, że wzór na Business Value jest następujący:

Business Value =  User Value + Time Criticality + Risk Reduction and/or Opportunity Enablement

gdzie poszczególne parametry mogą przyjmować następujące wartości:

User Value – od 0 do 4

Time Criticality – od 0 do 3

Risk Reduction and/or Opportunity Enablement od 0 do 3

Przy tych wartościach maksymalna suma może wynieść 10 czyli tyle, ile autorzy SAFe’a przewidują dla Business Value. Jak widać przyjąłem nieco większą wartość maksymalną dla parametru User Business Value (a konkretnie 4, a nie tak jak dla innych 3), żeby nadać wagę wartości użytkowej dostarczanej użytkownikowi końcowemu. Oczywiście takie podejście nie rozwiewa wątpliwości, jak nadawać wartości poszczególnym parametrom dla poszczególnych celów, ale w takiej postaci Business Value jest już trochę bardziej zrozumiałe i transparentne. Możemy wykorzystać metodę WSJF do jeszcze jednej rzeczy. Wartość biznesową poszczególnych celów możemy nadawać w sposób komparatywny, patrz akapit “Praktyczne wyliczanie wskaźnika WSJF“ w artykule o WSJF:

Stretch Objectives

Podczas liczenia Program Predictability Measure przy wartości planowanej nie uwzględniamy Wartości Biznesowej celów drugorzędnych (tzw. Stretch Objectives).

Realizacja tych celów jest planowana, a prace związane z ich dowiezieniem pojawiają się w backlogach zespołów. Przyjmujemy jednak, że nie oczekujemy od zespołu realizacji wszystkich celów, zarówno PI Objectives, jak i Stretch Objectives, wystarczą same PI Objectives, by móc uznać że jesteśmy w pełni zadowoleni z efektów pracy zespołu. Stretch Objectives stanowią więc automatycznie bufor na nasze prace. Jeśli realizacja celów głównych staje się zagrożona, to zespół poświęca na ich realizację więcej sił, kosztem Stretch Objectives.

Istnieje parę przypadków, w których rekomendowane jest potraktowanie danego celu, jako Stretch Objective, możemy wśród nich wymienić następujące:

• nie mamy wystarczających informacji do wypracowania wiarygodnych estymacji
• powiązany z celem zakres prac dotyka mało znanych technologii
• istnieje duże ryzyko zmiany wymagań biznesowych dla danych elementów rozwiązania

Takie podejście do wyznaczania celów wpływa na funkcjonowanie zespołu  na parę sposobów :

• zespół może dowieźć wszystkie PI Objectives i żadnego Strech Objective i uzyskać ocenę PPM wynoszącą 100%
• zespół może uzyskać ocenę 100% nawet jeśli nie zrealizuje w całości celów głównych ale za to dostarczy odpowiednio wysoką wartość biznesową celów drugorzędnych (tak, wiem, wydaje się do bezsensowne, co to za cele drugorzędne skoro mogą zastąpić cele główne, a zespół wciąż będzie oceniany wysoko i chwalony? zaraz to wyjaśnię
• zespół dostarczając odpowiednio dużą wartość PI Objectives i Stretch Objectives może, i jest to całkiem realne w tym modelu, dostarczyć sto ileś procent normy (historia zatacza koło? ;] )

Żeby Stretch Objectives pełniły swoją rolę, powinno się trzymać następujących zasad:

• praca związana z ich realizacją nie powinna stanowić więcej niż 10%-15% posiadanych przez zespół mocy przerobowych
• planujemy ich realizację tak samo, jak planujemy realizację celów głównych, nie zakładamy już na starcie, że zrobimy je jak nam starczy czasu, po godzinach lub w tzw. międzyczasie
• ich dowiezienie ma mniejszy priorytet niż PI Objectives

Kiedy warto używać Program Predictability Measure?

PPM jest bardzo ciekawą metryką oddającą zwinny charakter rozwoju produktów. Koncentruje się na dwóch krytycznych dla interesariuszy aspektach: przewidywalności planów i wartości biznesowej. Przewidywalność jest tutaj specyficznie rozumiana, bo odnosi się ją nie do zasobów, czy harmonogramu, tylko do dostarczanej wartości biznesowej. Ta specyfika jest wielkim atutem tego wskaźnika, ale jest też jego największą wadą. Jest on praktycznie nieużywalny w organizacjach, która na danym etapie rozwoju produktu nie są w stanie powiązać wymagań biznesowych z korzyściami, jakie przynosi ich realizacja. Jeśli natomiast posiadamy produkt, w którym dostarczanie użytkownikowi jego kolejnych wersji jest związane z monitorowaniem rezultatu, jaki przynosi, mierzonego w jakikolwiek sposób (przychód, wskaźnik zadowolenia, współczynnik pobrań itp.) to będziemy posiadali fajne narzędzie dające dużo cenniejsze informacje, niż odchylenie od harmonogramu bazowego, bądź zakładanych kosztów.