Podobieństwa i różnice między inicjatywami na poziomie portfela projektów.
Kiedy brałem udział w szkoleniu Implementing SAFe przygotowującym do roli SAFe Program Consultant nasz trener Joe Valone (takie Danny de Vito w wersji IT) nie miał ze mną łatwego życia. Bardzo chciałem poznać SAFe’a tak dobrze, jak tylko się dało podczas tych czterech dni, a dodatkowo motywował mnie fakt, że szkolenie kosztowało z grubsza 12000 PLN… no za taką kasę, to już naprawdę głupio byłoby nie wycisnąć z trenera całej wiedzy, jaką mógłby się potencjalnie podzielić. Chciał, czy nie chciał. Wierciłem mu zatem dziurę w brzuchu o różne rzeczy, między innymi o projekt, a wyglądało to mniej więcej tak:
Ja: Joe, a gdzie w SAFie są projekty?
Joe: Nie ma w SAFie projektów.
Ja: Acha… no ale jak to? Nie może nie być. Taka kobyła? Tyle poziomów zarządzania, tyle domen zaangażowanych, tyle zespołów, no wiesz, software development i w ogóle… i nie ma projektów?
Joe: No nie ma.
[po jakiś czasie]
Ja: A ten cały Agile Release Train to nie projekt przypadkiem? Wygląda mi to nieco jak projekt. Taki duży projekt.
Joe: Nie, to jest program. Agile Program.
Ja: Acha….
[jakiś czas później]
Ja: Joe, a czy …?
Joe: Nie to też nie jest projekt! W SAFie nie ma projektów!
[później na tym samym szkoleniu]
Joe: To jest Portfolio Epic [patrząc na mnie, a przynajmniej taka jest moja wersja, że mówiąc to patrzył mi prosto w oczy]. Co prawda w SAFie nie ma projektów, ale jeśli istniałyby to byłyby nimi Portfolio Epiki Można powiedzieć, że to takie SAFe’owe projekty.
Ja: ;]
O samych Epicach w rozumieniu SAFe’owym możesz przeczytać tutaj:
więc nie będę się bardzo rozpisywał szczegółowo na temat ich konstrukcji. Niestety na potrzeby zrozumienia tego artykułu będziesz musiał zapomnieć o tym czym w powszechnym rozumieniu zwinnego zarządzania wymaganiami jest Epic, bo SAFe podchodzi do niego dość specyficznie, wprowadzając przy tym niemałe zamieszanie.
Bez zbędnej beletrystyki zatem, poniżej znajdziesz wypunktowane argumenty, które według mnie świadczą o tym, że Portfolio Epic, czyli Epic zdefiniowany i zarządzany na poziomie portfela projektów i programów, to zwinny projekt i tak można go traktować w codziennej pracy z agile w skali.
Jest dużą inicjatywą powoływaną na poziomie portfela projektów.
Portfolio Epic jest zmianą, której zainicjowanie odzwierciedlone jest w Kanbanie Portela i na tym poziomie jest on definiowany, analizowany, szacowany, priorytetyzowany w sąsiedztwie innych Portfolio Epiców, aż uzyskuje zgodę na uruchomienie i czeka w Portfolio Backlogu na swoją kolej w realizacji. Specyfika SAFe’a, a konkretnie Pryncypium mówiące o decentralizacji podejmowania decyzji (Decentralize Decision Making) oraz mechanizm skalowania ról, przekłada się na to że zanim taki Portfolio Epic trafi do backlogów zespołów zostanie po drodze zdekomponowany na Capabilities, Features, Stories i Enablers, a na każdym poziomie zarządczym te wymagania nabiorą lokalnych kontekstów i będa konkurowały z innymi elementami dedykowanych danym poziomom backlogów. Nie mniej jednak rola Epic Ownera będzie czuwała nad spójnością tych działań z pierwotną intencją Epica.
Zapraszamy na szkolenie
Szkolenie SAFe POPM Product Owner Product Manager
Posiada coś na kształt Project Business Case
Tak jak w Project Management Body of Knowledge w wersji 6 (PMBoK 6ed.) pierwszym poważnym dokumentem określającym kontekst i potrzebę biznesową jest Project Business Case, tak jego SAFe’owym odpowiednikiem jest Epic Hypothesis Statement. O ile ten pierwszy nie jest jakoś specjalnie ściśle zdefiniowany, o tyle w przypadku tego drugiego autorzy proponują zwięzłą formatkę bardzo dokładnie określającą jakie informacje są potrzebne na tym etapie, układając ją w dość przyjemną formę. Prosty szablon Epic Hypothesis Statement wygląda następująco:
Przypomina nieco styl User Story, który prowadzi nas za rękę? Jako….., chciałbym……, żeby…. Intencja jest podobna – żeby jak najbardziej uprościć sposób definiowania podstawowych założeń biznesowych, a jednocześnie żeby nie pominąć kwestii zasadniczych. Przykładowo taki Epic Hypothesis Statement mógłby wyglądać następująco:
Dla klientów korzystających z wielu naszych produktów,
którzy są zmuszeni do tworzenia nowych kont użytkownika każdorazowo, kiedy nabywają nową aplikację webową z naszej oferty
proponowane rozwiązanie, czyli* jedno konto logowania do wszystkich produktów
jest uproszczonym mechanizmem autentykacji naszych klientów,
który pozwala użytkownikom na logowanie się do wszystkich oferowanych przez nas aplikacji za pomocą jednego konta użytkownika
W przeciwieństwie do rozwiązań, które wymagają tworzenia osobnych kont dla każdego z produktów
nasze rozwiązanie będzie wymagało od użytkownika posiadania jedynie jednego konta, za pomocą którego będzie logował się do wszystkich naszych produktów, które będą mu udostępniane na podstawie wykupionych przez niego usług. Takie rozwiązanie uprości użytkownikowi sposób logowania, zwiększy bezpieczeństwo, a przy okazji uporządkuje naszą bazę klientów i naszą wiedzę odnośnie używanych przez nich rozwiązań.
*to zamiast “the” ;]
Kolejnymi elementami, już nie tak ciekawymi w sposobie formułowania, ale nie mniej pożytecznymi w kontekście definiowania Portfolio Epica są:
- Hipotezy odnośnie spodziewanych korzyści biznesowych
- Wstępne propozycje mierników
- Wymagania niefunkcjonalne
Zdefiniowanie hipotez odnośnie potencjalnie możliwych do osiągnięcia korzyści biznesowych, z podkreśleniem tego, że na tym etapie możemy co najwyżej domniemywać ich pojawienia się w przyszłości, jest istotą podejścia zwinnego. W kontekście Portfolio Epiców objawia się ono tym, że nie będziemy definiować projektu od A do Z, tylko pokornie godzimy się z faktem, że rzeczywistość biznesowa jest czasem mało przewidywalna, a proces tworzenia oprogramowania też potrafi mocno zaskakiwać nawet bardzo mądrych i doświadczonych ludzi. Staramy się zatem zdefiniować MVP/MMP (Minimum Viable Product, czasem inaczej nazywane Minimum Marketable Product), które pochłonie minimalną konieczną ilość nakładów, a jednocześnie będzie stanowiło rozwiązanie nadające się do użycia i sprzedaży. Dopiero realny feedback z rynku, nie głos biznesu, nie wyobrażenia UXów, nie interpretacja programistów i testerów, pokaże nam na ile nasze założenia są słuszne. Wtedy będziemy podejmowali decyzje o dalszym rozwoju produktu lub jego zredefiniowaniu, bądź nawet zagrzebaniu. Ten cykl wygląda następująco, niech Cię nie zwiedzie słowo “startup”, tu nie chodzi stricte o uruchomienie nowych biznesów, tylko “startupowe” myślenie:
Jest zdefiniowany w Karcie Projektu
Mimo, że zakres Portfolio Epica nie jest tak ściśle zdefiniowany, jak w przypadku klasycznego projektu (o różnicy między podejściem sterowanym planem, a tym opartym o wartość biznesową pisałem w tym artykule https://project-management.pl/agile-czyli-waterfall-do-gory-nogami/), to nie można powiedzieć, że Portfolio Epic jest uruchamiany na łapu-capu. Dokument definiujący jego podstawowe założenia, cele i intencje – Lean Business Case (do pobrania tutaj https://www.scaledagileframework.com/epic/ ) mimo że z definicji powinien być lekki, to zawiera nie mniej informacji niż Project Charter w postaci, w jakiej funkcjonuje w większości znanych mi organizacji. Leanowość nie polega w tym przypadku na uszczupleniu dokumentacji, tylko na zdefiniowaniu MVP rozwiązania i postawieniu hipotez odnośnie oczekiwanych korzyści oraz zaproponowaniu sposobów weryfikacji ich osiągnięcia.
Lean Business Case składa się z niemałej liczby pozycji więc nie będę tu ich przepisywał, zachęcam do zapoznania się z szablonem.
Zarówno Lean Business Case, jak i Karta Projektu (czy też Project Charter) definiują intencje, cele biznesowe oraz na bardzo ogólnym poziomie główne produkty Portfolio Epica/Projektu, ale tutaj pojawia się największa różnica…
Portfolio Epic nie posiada Planu Projektu
W przypadku klasycznego projektu, zanim dostanie on zielone światło, przygotowywany jest jego plan opisany w dużo bardziej złożonej i precyzyjnej dokumentacji – w Planie Projektu integrującym poszczególne plany subsydiarne, takie jak: plan zarządzania wymaganiami, zakresem, harmonogramem, w tym harmonogram bazowy, kosztami, w tym budżet bazowy, interesariuszami, jakością, zakupami, ryzykiem itd. W przypadku Portfolio Epica nie jest to konieczne. Zakres prac nie musi tak ściśle zdefiniowany. Częściowo będzie on odkrywany w miarę tworzenia rozwiązania i weryfikowania założeń. Dając zatem Portfolio Epicowi zielone światło nie ryzykujemy tak wiele, jak w przypadku projektu waterfallowego, dzięki skupieniu się na pracy w ramach szybkich cykli uczenia się i weryfikacji hipotez. Ba. Zielone światło nie jest de facto równoznaczne z uruchomieniem realizacji Portfolio Epica, mówi tylko o tym że trafia on do statusu BACKLOG (oznaczającego w tym przypadku inicjatywy ocenione pozytywnie i przeznaczone do realizacji bez dodatkowej analizy opłacalności), a dopiero tam przeprowadzany jest jego scoring wykonany przy metodzie WSJF (Weighted Shortest Job First, o której piszę tutaj https://project-management.pl/wsjf-czyli-krotsze-znaczy-lepsze/), a wynik zadecyduje o tym, w której kolejności będzie on realizowany. W SAFie nie tworzy się ścisłego planu projektu, tylko dekomponuje go na wymagania agile’owe i deleguje je do niższych poziomów zarządzania, by odpowiedni ludzie, kolejno: Solution Management, Product Management, Product Owners, zdefiniowali rozwiązanie w swoich backlogach i dostarczali kolejne przyrosty budujące MVP…. ale to już temat na niezupełnie inną historię…
I co z tego?
No dobra, niech mi będzie że Portfolio Epic, to Projekt, ale co z tego wynika, na co to się przekłada, co to znaczy w kontekście wdrażania podejścia agile w organizacjach? Otóż znaczyć może bardzo wiele. Ja widzę Portfolio Epic jak pomost łączący nie tylko strategię organizacji z dostarczanymi rozwiązaniami, ale też świat waterfallowy z agileowym. Jeśli Portolio Epicowi blisko do zwinnego projektu, to jednocześnie blisko mu do projektowego sposobu myślenia, czyli takiego który zachęca do zdefiniowania założeń przedsięwzięcia, jego celów, oczekiwanego efektu końcowego i możliwie dokładnie ścieżki dojścia. Od tego wszystkiego Portfolio Epic różni głównie tak ścieżka dojścia, gdyż zamiast skupiania się na przewidzeniu zakresu, koncentruje się na stawianiu weryfikowalnych hipotez, zdefiniowania MVP i wypracowaniu mechanizmów uczenia się i wyciągania wniosków. W założeniu zatem Portfolio Epic daje top managementowi wyraźny kontekst biznesowy, cele i korelację ze strategią oraz zgrubną roadmapę, a następnie szybką, rynkową weryfikację założeń, natomiast Product Managementowi i Zespołom Deweloperskim odpowiedni poziom autonomii w kreowaniu rozwiązania. Dzięki temu może być kluczowym elementem we wdrażaniu agile na każdym poziomie organizacji, zwłaszcza w miejscach gdzie myślenie waterfallowe jest bardzo mocne i może być przeszkodą.
