PI Planning od kuchni

1,K

PI Planning, czyli jak planować prace wielu zwinnych zespołów na dłużej niż sprint.

Dlaczego warto przeczytać artykuł o PI Planning

Ten artykuł jest długi, a jego czytanie może być męczące. Z PI Planningiem jest podobnie, to wyczerpujące dwudniowe spotkanie, które potrafi dać ostro w kość. Może uda mi się tym podsumowaniem wzbudzić u Ciebie zaciekawienie, które da Ci motywację do przebrnięcia przez te wszystkie linijki tekstu. Myślę, że warto nawet jeśli nie interesuje Cię SAFe, ani Agile w Skali, bo znajdziesz tutaj opis tego, jak planować pracę dla wielu zespołów. Żadne rocket science, ale za to parę praktycznych wskazówek z życia wziętych.

Program Increment Planning, to jedno z ciekawszych narzędzi, z jakimi miałem do czynienia podczas mojej pracy w zarządzaniu projektami, programami i portfelami. Pokazuje ono, że przy zachowaniu pewnych standardów i dobrych praktyk można zaplanować pracę powiązanym ze sobą zespołom zwinnym na okres dłuższy niż sprint, niż dwa sprinty, a nawet trzy. Konkretniej, na mniej więcej kwartał. W niewielu organizacjach doświadczyłem czegoś podobnego. W niektórych nie spotkałem się nawet z czymś zbliżonym do takiego planu, nawet w przypadku programów waterfallowych, a co dopiero zwinnych. Wiąże się to z ogromem pracy, a synchronizacja zespołów przed i podczas tego rytuału jest bardzo męcząca. Każde niedociągnięcie organizacyjne skutkuje przepalaniem dużej ilości czasu deweloperów, a wiadomo jak drogi jest to czas. Presja jest duża, ale mimo to jest w tym całym natłoku prac jakiś urok. Biegający ludzie, latające karteczki, zamazane tablice, charczące głośniki, zapach pizzy i kawy, brak tlenu…  atmosfera jest niesamowita, a poczucie satysfakcji, kiedy choć częściowo jesteśmy w stanie zapanować nad tym szałem twórczym i wiemy jak będzie wyglądała praca dziesiątek deweloperów w ciągu najbliższego kwartału, jest ogromne.

No to teraz możemy zaczynać

Jeśli Agile Release Train, czyli Pociąg Wydań, albo inaczej zwinny Zespół Zespołów, jest głównym mechanizmem napędowym SAFe’a, to PI Planning jest jego silnikiem napędowym. W tym, dość sporym, artykule dzielę się swoimi praktycznymi doświadczeniami z realizacji tego rytuału. Zakładam, że trochę już wiesz o SAFe, muszę tak zrobić, bo gdybym chciał inaczej, gdybym miał wyjaśniać dokładniej każdy element SAFe’a, który pojawia się w kontekście PI Planningu, to nie napisałbym artykułu tylko mini podręcznik tego frameworka. Zakładam zatem, że orientujesz się Czytelniku, czym jest Scaled Agile Framework i do czego służy, albo chociaż czym jest Agile w Skali, a czytając ten artykuł chciałbyś dowiedzieć się jak w praktyce wygląda to wydarzenie, czemu służy, jak się do niego przygotować, jak je poprowadzić i jak wpływa ono na pracę zespołów. Tak od kuchni. Od teorii do praktyki. Jeśli jednak nie znasz SAFe’a, to nic. Możesz śmiało odpuścić sobie te wszystkie niezrozumiałe hasła i patrzeć na PI Planning, jako po prostu sposób na planowanie prac wielu deweloperom. Jestem przekonany, że podobne podejście można zastosować do planowania na przykład etapu lub fazy w projekcie klasycznym. Oczywiście pojawią się istotne różnice, ale znajdziesz też parę cennych analogii.

Czym jest PI Planning

PI Planning (Program Increment Planning, czyli Planowanie Przyrostu Programu), można by w dużym uproszczeniu nazwać wyskalowanym Sprint Plannigniem. Tak jak pojedyncze zespoły agile’owe planują swoje Sprinty i ich Przyrosty oraz prace realizowane w ich ramach, tak Zespół Zespołów, czyli Agile Release Train w ciągu dwóch dni planuje wspólny Przyrost Programu i składające się na niego prace realizowane podczas sumy sprintów zespołów. SAFe zaleca aby Program Increment trwał 8 do 12 tygodni, a jednocześnie zachęca, żeby sprint trwał 2 tygodnie. Najczęściej zatem w ramach PI’a mieści się 4 do 6 sprintów. Z tych sprintów ostatni nazywany jest Innovation and Planning i przeznacza się go na prace nie tworzące bezpośrednio Przyrostu Produktu, czyli takie, jak badania, tworzenie Proof of Concept, czy Proof of Technology, eksperymenty, szkolenia i planowanie kolejnego Program Incrementu. Ze względu na tą specyfikę, z moich obserwacji wynika, że optymalne są Program Increment’y sześcio-sprintowe. Te mniejsze mają narzut innowacyjno-organizacyjny zbyt duży do udźwignięcia dla większości organizacji, z kolei te większe niż sześcio-sprintowe niosą ze sobą ryzyko tego, że ujęte w ich ramach wymagania biznesowe mogą nie być dostatecznie przygotowane i stabilne w tak długim horyzoncie. Dodatkowo, sześć dwutygodniowych sprintów daje nam trzymiesięczne, czyli kwartalne Przyrosty Programu, co ładnie zamyka się w ramach roku kalendarzowego i wprowadza fajny rytm prac.

Poniższy obrazek ilustruje zależność między Przyrostem Programu a Sprintami i umiejscowienie PI Planningu:

Źródło: http://www.scaledagileframework.com

Zanim zacznie się PI Planning

Najważniejsze nie jest samo wydarzenie, podczas którego spotykają się wszystkie zespoły realizujące wspólnie program, tylko to, co dzieje się przed PI Plannigiem. Jeśli liczymy na to, że zespoły są w stanie w dwa dni poznać wymagania i ich kontekst biznesowy, a następnie zdekomponować je, oszacować i zaplanować prace na najbliższy kwartał łącznie z powiązaniami między zespołami, to jest duża szansa, że zarówno samo planowanie, jak i cały PI okażą się porażką. Żeby zespoły mogły zaplanować swoje backlogi na kilka sprintów do przodu i na koniec planowania móc podpisać się pod tym planem, to wymagania muszą poznać już wcześniej. Muszą mieć czas na ich zrozumienie, zdekomponowanie, uzupełnienie, oszacowanie, czy przeprowadzenie rozpoznania w używanych technologiach. To jest też czas, w którym przynajmniej na poziomie ogólnej architektury, tworzone są koncepcje rozwiązań. Na wszystko to nie będzie czasu na samym PI Planningu, na którym deweloperzy powinny skupić się połapaniu zależności między zespołami, weryfikacji wszelkich wątpliwości i rozplanowaniu w czasie prac na cały Program Increment z dokładnością do sprintów i kamieni milowych. Przy dużej ilości zespołów pracujących nad jednym rozwiązaniem, jakiej architektury byśmy nie wypracowali, to sama ilość powiązań będzie na tyle duża, że zespoły powinny właśnie na nie zwrócić największą uwagę, a swoje własne backlogi powinny mieć już zawczasu przygotowane. Przynajmniej na ogólnym poziomie. Dobre przygotowanie przekłada się na sukces spotkania i całego Przyrostu Programu, warto na nie wykorzystać, co najmniej, cały sprint Innovation and Planning.

Jeszcze jedna rzecz, która powinna wydarzyć się przed właściwym PI Planningiem

Drugim bardzo ważnym aspektem przygotowania PI Planningu jest podjęcie decyzji odnośnie tego, które elementy Program Backlogu trafią do estymacji do poszczególnych zespołów i być może ostatecznie do ich Team Backlogów. Nie możemy po prostu pokazać wszystkim zespołom pełnej listy wymagań i liczyć na to, że same się nimi podzielą. Częściowo oczywiście tak będzie, bo nawet wstępnie przydzielone tematy, według np. kompetencji, znajomości poszczególnych istniejących komponentów rozwijanego produktu, pojemności czy używanych technologii, mogą zostać po przeanalizowaniu przekazywane między zespołami. Nie możemy jednak pozwolić sobie na dawanie wszystkiego do zapoznania się wszystkim. Zawsze dysponujemy ograniczonym czasem i wstępnie musimy zdecydować, komu zostaną dane wymagania przydzielone do estymacji. Zanim więc do elementów backlogu siądą zespoły, trafią one do architektów, którzy przygotują zarys planu. Planowanie bowiem też ma w Agile iteracyjny charakter.

Oczekiwane rezultaty PI Planningu

Zanim wejdziemy w szczegóły konstrukcji PI Planningu warto przedstawić, jakie produkty/efekty powinien wygenerować ten rytuał:

• cele na cały Program Increment
  • PI Objectives wspólne dla całego Agile Release Train
  • Team PI Objectives dla poszczególnych zespołów
• zaplanowane wstępnie sprint backlogi na cały PI
• mapa powiązań między zespołami
• synchronizacja pomiędzy biznesem i produkcją
  • dewelopment poznaje aktualną wizję rozwiązania, kluczowe wymagania i plany biznesowe
  • biznes otrzymuje feedback określający ile zespoły są w stanie dostarczyć w ramach danego Przyrostu Programu (w oparciu o ten feedback może urealnić swoje plany)

Rekomendowana agenda spotkania

Dzień 1		Dzień 2
8:00-9:00	Prezentacja kontekstu biznesowego	8:00-9:00	Prezentacja korekt wymagań
9:00-10:30	Wizja tworzonego rozwiązania	9:00-11:00	Planowanie w zespołach
10:30-11:30	Wizja architektoniczna i standardy tworzenia kodu	11:00-13:00	Finalny przegląd planów i lunch
11:30-13:00	Omówienie zasad planowaniai przerwa na lunch	13:00-14:00	Zarządzanie ryzykami programowymi
13:00-16:00	Planowanie w zespołach	14:00-14:15	Głosowanie poparcia dla planu
16:00-17:00	Przegląd planów zespołów	14:15-???	Wprowadzanie zmian do planu
17:00-18:00	Przegląd menedżerski planów i warsztat rozwiązywania problemów	???	Retrospektywa planowania

PI Planning krok po kroku

DZIEŃ PIERWSZY

Prezentacja kontekstu biznesowego

Jedną z wielu fajnych rzeczy w SAFe jest to, że patrzy on bardzo szeroko na to, jak powstają produkty. Nie skupia się na części dotyczącej stricte zespołu, tylko obejmuje powiązania z szeroko pojętym biznesem, nawet do poziomu strategii. Jest to coś, czego brakowało mi w innych frameworkach. Oczywiście inne metody nie zabraniały patrzeć szerzej na dostarczanie wartości biznesowej w organizacji, ale zdecydowanie nie kładły na to tak dużego nacisku i nie proponowały przekonujących narzędzi. Przynajmniej mnie nie przekonywały.

Przedstawienie kontekstu biznesowego jest właśnie jednym z tych miejsc, w których SAFe dba o synchronizację między różnymi poziomami i obszarami organizacji. Oczywiście zespoły mają do dyspozycji swoich Product Ownerów, którzy zarządzają wartością biznesową dostarczanych rozwiązań, ale przy zwinności w skali oprócz informacji o konkretnych zachowaniach produktów, ich komponentów, czy modułów, deweloperom przydaje się świadomość tego, dla kogo jest to rozwiązanie dedykowane, z czego wynika pomysł na jego wytwarzanie, jak planowane jest wejście na rynek lub ekspansja na istniejącym itd. Istotne też jest, jakie są oczekiwania organizacji wobec rozwiązania rozwijanego przez obszar wytwórczy, gdzie chcemy być w tym roku, w przyszłym, co jest potrzebne jeszcze w tym kwartale. Chodzi o informacje, które w wielu firmach dystrybuowane są niemal wyłącznie na poziomie komitetów sterujących. Dzięki takiemu podejściu deweloperzy nie są klepaczami kodu z magicznej skrzynki, tylko częścią większej całości, o takiej samej świadomości biznesowej, jak sprzedaż, czy marketing. Działa to bardzo motywująco i pozytywnie wpływa na utożsamianie się tworzonym rozwiązaniem, z firmą i jej klientami, wiemy dzięki temu jak ważna jest nasza praca i na co się w firmie przekłada. Oczywiście ma to też korzystne odzwierciedlenie w jakości tworzonych produktów.

Wizja dostarczanego rozwiązania

Po zapoznaniu się z kontekstem, w jakim osadzony jest produkt oraz celami strategicznymi, zespołom znacznie łatwiej jest zrozumieć koncepcję rozwiązania. Ten punkt PI Planningu prowadzony jest najczęściej przez Product Management lub w przypadku bardzo dużych rozwiązań przez Solution Management, czyli grupę ludzi którzy projektują rozwiązanie na poziomie strategicznym i całych strumieni wartości (np. linii produktowych). W tym miejscu przekazywane są już precyzyjne informacje na temat tego, jak wygląda rozwiązanie obecnie, jakie mamy role użytkowników, jak wyglądają poszczególne moduły, jak komunikują się między sobą i jak przebiegają główne procesy end to end. Kulminacją tej części jest określenie tzw. Top Features, czyli listy funkcjonalności, jakie powinny być dostarczone w ramach nadchodzącego Przyrostu Programu. Bardzo ważne jest to, że ta lista nie stanowi celu w klasycznym projektowym rozumieniu. Jest to raczej lista potrzeb biznesu, które w zestawieniu z perspektywą technologiczną jest podstawą do planowania prac zespołów. Podczas PI planningu będzie miało miejsce parę iteracji składających się z przedstawienia oczekiwań osób zarządzających rozwojem produktu oraz informacji zwrotnej od zespołów na temat ilości wartości, jaka może być dostarczona w ramach PI’a. Pojawią się kompromisy i korekty, zapewne też małe spory ;] Ostatecznie powstanie zakres prac, pod którym będą mogły “podpisać się” obie strony – biznes i dewelopment.

Wizja architektoniczna i standardy tworzenia kodu

W SAFie duży nacisk kładzie się na synchronizację pomiędzy poziomami zarządczymi i domenami. Każde rozwiązanie powinno wynikać ze strategii, a jego założenia biznesowe, powinny być spójne z wizją technologiczną. To zapewnia zdrowe podstawy do stabilnego, płynnego i przewidywalnego rozwoju produktów. Zaburzenie tej równowagi wyklucza zwinność. Dla przykładu, jeśli w ramach kompromisów kładziemy zdecydowanie większy nacisk na zakres funkcjonalny kosztem narastającego długu technologicznego, to z czasem okaże się, że rozwijanie nowych cech produktu obarczone jest zbyt wielkim narzutem na radzenie sobie z ograniczeniami architektonicznymi. W pewnym momencie może uczynić to rozwój produktu, nawet o małe przyrosty funkcjonalne, zbyt wolnym, zbyt nieprzewidywalnym i zbyt kosztownym, żeby szybko nadążać za rynkiem lub go wyprzedzać. Możemy utracić zdolność do elastycznego reagowania na bieżące potrzeby biznesowe. W zwinnej realizacji projektów w skali, od nagłych zrywów dostarczających duże przyrosty funkcjonalności ważniejszy jest płynny, stabilny rozwój z zachowaniem równowagi pomiędzy korzyściami biznesowymi, jakością rozwiązania z perspektywy użytkownika i jego koszernością w wymiarze technicznym (czyli optymalizacja kodu, otwartość architektury, poziom udokumentowania rozwiązań, stabilność, bezpieczeństwo czy możliwość skalowania).

W związku z tym po wystąpieniu biznesu i zaprezentowania jego potrzeb, czas na odniesienie się do nich przez architektów systemowych. Skoro zatem powstaje lista wymagań funkcjonalnych, równolegle przygotowywana jest też lista tzw. enablerów, czyli rozwiązań technicznych umożliwiających dostarcznie mechanizmów niewidocznych z poziomu użytkownika. SAFe wyróżnia następujące rodzaje enablerów:

• eksploracyjne
• architektoniczne
• infrastrukturalne
• zapewniające zgodność (z przepisami, z politykami wewnętrznymi organizacji, ze standardami branżowymi, itp.)

Omówienie zasad planowania i przerwa na lunch

Po wysłuchaniu kontekstu biznesowego, głównych wymagań oraz koncepcji realizacji wraz z ogólnymi wytycznymi technologicznymi, zespołom pozostaje już niemal tylko rozejść się, złapać oddech i brać się do planowania. Zanim to jednak zrobią przyda się garść informacji organizacyjno-technicznych odnośnie tego, gdzie znajdują się materiały źródłowe, jak planować sprinty, jak przygotować prezentację zakresu, jak uzupełniać Program Board, czyli tablicę ilustrującą ogólny plan prac wszystkich zespołów na cały Program Increment. Każda wskazówka jest cenna i pomaga zapanować nad tym, co będzie się działo w zespołach i między nimi. Trywialne rzeczy mogą zadecydować o tym, czy uda się właściwie zobrazować zakres prac zespołów i relacje między nimi: czy zespoły zaprezentują swoje plany na wspólnej tablicy, czy na arkuszach i karteczkach post-it, a może w Jirze, Redmine, czy we wspólnym arkuszu kalkulacyjnym. Istotne będzie też określenie, jak zaznaczamy relacje, do jakiego poziomu szczegółowości schodzimy, jak formułować cele zespołów na ten PI, co będziemy prezentować na forum? Jest tego cała masa drobiazgów. Te drobiazgi jednak budują produkt końcowy tego spotkania. Żeby można to było zintegrować i uzyskać big picture, plany zespołów muszą być spójne nie tylko merytorycznie, ale też technicznie. Scrum Masterzy będą oczywiście dbali o to, żeby zespoły mogły skupić się na merytoryce i wezmą na siebie facylitację prac, ale będzie tego mnóstwo, a czas bardzo ograniczony, muszą to robić przy zachowaniu spójności i pewnej unifikacji. Im więcej elementów zdefiniujemy, im więcej technikaliów wyjaśnimy, lepiej przygotujemy szablony i podamy przykłady, tym sprawniej pójdzie praca zespołów, a jej wyniki będą bardziej przejrzyste.

Planowanie w zespołach

Zespoły mają około 3 godzin na przygotowanie draftów swoich planów na dany Program Increment i zadbanie o to, żeby te plany były spójne. Można wygospodarować nieco więcej czasu, jeśli skrócimy poprzednie bloki, ale cudów nie ma, jeśli chcemy mieć jeszcze czas na ich prezentacje na forum oraz weryfikację, jeśli mamy się z tym wszystkim zmieścić w jednym dniu, to dużo więcej czasu nie będzie dane zespołom. To jest ten moment, w którym spijamy śmietankę, albo gorzką pianę z piwa, którego sobie nawarzyliśmy podczas sprintu Innovation and Planning. To jest jest ten moment, w którym wychodzi, jak dobrze zespoły poznały i zrozumiały zakres, który chcemy wypracować. Jeśli będziemy teraz czytać historyjki użytkownika po raz pierwszy, jeśli dopiero teraz zapoznamy się z opisami funkcjonalności, to jesteśmy w lesie. Wątpliwe jest, aby zdążyć z zaplanowaniem pracy dla własnego zespołu, a co dopiero zrozumienie tego, co robią inni, żeby połapać zależność. Do tego momentu jasne powinny być nie tylko intencje biznesowe, ale też konkretne wymagania i koncepcje ich realizacji. W idealnym rozwiązaniu, powinniśmy mieć już zdekomponowane i oszacowanie swoje elementy backlogów i skupiać się na zależnościach z innymi zespołami. Ciężko bowiem rozmawiać o relacjach organizacyjnych i technicznych jeśli poszczególne zespoły nie są w stanie pokazać co robią i jaki mają na to pomysł.

W międzyczasie mają miejsce synchronizacje Scrum Masterów Product Ownerów i Architektów, w ramach których weryfikowana jest na bieżąco spójność i kompletność planów.

Przegląd planów zespołów

Zaplanowanie prac na cały PI przez poszczególne zespoły dla siebie samych, jakkolwiek jest sporym wyzwaniem, to tylko połowa sukcesu. Nie mniej ważne jest upewnienie się, jak te wstępne, zespołowe plany prac, zdekomponowane do poziomu historyjek użytkownika i zadań, mają się do wymagań biznesowych i do planów innych zespołów. Plan dla całego Agile Release Train nie jest tylko sumą planów poszczególnych zespołów, tylko wspóldzielonym, zintegrowanym planem. Top management musi uzyskać spójny obraz całości, który może zaakceptować, z kolei poszczególne zespoły muszą upewnić się, ile nieprzewidzianej dotąd przez nich pracy kryje się w relacjach z innymi zespołami. Zaprezentowanie swojego planu prac przez zespół, w taki sposób, żeby zaspokoić te wszystkie potrzeby nie jest łatwe, a im więcej zespołów bierze udział w PI Planningu, tym mniej czasu na wchodzenie w szczegóły. Zespół raczej nie przytarga ze sobą tablicy z miejsca, w którym ją tworzył na salę, w której zbierają się wszyscy interesariusze, odręcznie opisane karteczki post-it i arkusze papieru raczej nie zapewnią odpowiedniej czytelności, narzędzia elektroniczne są bardzo użyteczne, ale współdzielone aplikacje i dokumenty potrafią klęknąć przy takim ruchu. Jako Release Train Engineer odpowiedzialny za przygotowanie i prowadzenie PI Planningu parę siwych włosów zawdzięczam martwieniu się tym, jak zorganizować pracę zespołów. Od narzędzi jeszcze ważniejsze jest wsparcie Scrum Masterów, to o czym zapomni, przekręci, nie zrozumie deweloper, może być jeszcze naprawione przez osobę opiekującą się zespołem. Oczywiście są zespoły, które dodatkowej pomocy nie potrzebują, ale przy realizacji pierwszych PI Planningów lepiej wyjść z założenia, że wszyscy uczestnicy, a może i organizatorzy, będą się poruszali nieco jak goryle we mgle.

Przegląd menedżerski planów i warsztat rozwiązywania problemów

Zespoły zaprezentowały swoje wstępne plany. Teraz top management (właściciele biznesowi, menedżerowie produktów, architekci…) ma chwilę dla siebie, żeby go zrozumieć i odnieść się do niego. Możliwych reakcji jest wiele, z czego najbardziej prawdopodobne, to:

• rozwiązanie problemów zgłaszanych przez zespoły,
• zmiana planów biznesowych,
• wprowadzenie korekt wymagań,
• zmiana decyzji architektonicznych
• wzmocnienie zespołów

W najlepszym scenariuszu może mieć miejsce akceptacja planu bez uwag i z uśmiechem na ustach, ale proponuję nie nastawiać się na to.

Cokolwiek  zostanie postanowione, musi być zakomunikowane zespołom na początku drugiego dnia, żeby to mogły się do tego odnieść i wprowadzić korekty do swoich planów.

DZIEŃ DRUGI PI PLANNINGU

Prezentacja korekt wymagań

Dzień pierwszy PI Planningu zaczął się od wizji i oczekiwań top managementu, potem zespoły tworzyły plan będący odpowiedzią na te oczekiwania, na koniec dnia biznes i architekci przyglądali się temu planu i widzieli, jak symulacja rzeczywistości weryfikuje ich pomysły. Przedstawiony im plan mógł być zgodny z ich życzeniami, ale mógł też mocno od nich odbiegać. W zależności od tego jak bardzo przekonujące było to, co zaprezentowały zespoły, top management programu może wprowadzić korekty do swoich oczekiwań lub oczekiwać korekt po stronie zespołów, wspierając ich w tym. Może to być równie dobrze miks obu podejść. Cokolwiek postanowią osoby zarządzające programem, pierwszym punktem drugiego dnia jest zakomunikowanie tego zespołom.

Planowanie w zespołach po raz drugi

Zespoły ponownie rozchodzą się korygując, dokańczając i szlifując swoje plany. Ten blok może wyglądać bardzo różnie w przypadku poszczególnych zespołów. Jedne będą na spokojnie dokańczały swoje plany, inne będą tworzyły je na nowo, bo zmiany mogą okazać się fundamentalne, reszta znajdzie się gdzieś pomiędzy, bliżej jednego lub drugiego bieguna.

Finalny przegląd planów i lunch 

Finalne plany są ponownie prezentowane na forum. O ile pierwszego dnia to prezentacje mogły być jeszcze lekko chaotyczne, być może nie przedstawiały kompletnych planów, mogły zawierać trochę błędów, przez co traktowane były z pewną dozą pobłażliwości, o tyle w drugim dniu te plany muszą pokazać, że zespoły wiedzą co mają do zrobienia, jak się za to zabrać oraz jak zapewnić spójność rozwiązań z innymi zespołami. Pytań do prezenterów jest zdecydowanie mniej niż pierwszego dnia, bo większość uwag zostało wprowadzonych, ale każde pytanie, czy wątpliwość zgłoszone na tym etapie są bardzo istotne, a odpowiedzi nie powinny pozostawiać wątpliwości.

Autorzy SAFe’a sugerują że jest to dobry moment na lunch. Ja mam jednak nieco inne doświadczenia z serwowaniem posiłków podczas PI Planingu. Są oczywiście niezbędne. Kiedy ktoś myśli o pustym żołądku, to nie myśli o backlogu. Dobrze jest też jeśli te posiłki są zorganizowane, żeby uczestnicy PI Planningu nie kminili “co by tu zjeść” i nie bawili się w logistykę. Sprawdzającym się rozwiązaniem jest dostarczenie pizzy i zagwarantowanie zakąsek dostępnych wtedy, kiedy zespoły rozchodzą się na planowanie. Wtedy czas “lunchowy” jest wykorzystany na pracę, chociażby nawet z pizzą w ręku na kanapie. Jedzenie jest pod ręką i każdy po nie sięgnie w odpowiadającym mu momencie.

Zarządzanie ryzykami programowymi

To zarządzanie ryzykami, to dość szumna nazwa. Skoro mówimy o ryzykach, które zespoły eskalują od razu, bo nie czują się na siłach do zarządzenia nimi, to są to z natury rzeczy skomplikowane i trudne do ujarzmienia. Mało którym z nich jesteśmy w stanie skutecznie zaradzić już podczas PI Planningu, więc ten punkt polega bardziej na zaadresowaniu ryzyk. Najważniejsze z nich są omówione i przypisane do następujących grup:

• rozwiązane – w przypadku ryzyk, które uda się skutecznie rozpracować już na PI Planningu
• zaadresowane – kiedy nie możemy zbyt wiele zrobić z danymi ryzykami, ale potrafimy przypisać je do osoby, która posiada wiedzę i zasoby, żeby się nimi zaopiekować
• zaakceptowane – kiedy nie mamy pomysłu jak zaradzić zmaterializowaniu się tego ryzyka, a nawet może to być niemożliwe, nie pozostaje nam nic innego jak zaakceptować jego istnienie i przygotować się na jego konsekwencje
• mitygowane – w odniesieniu do ryzyk, których co prawda nie możemy wyeliminować, ale już na ten moment wiemy, że możemy minimalizować prawdopodobieństwo ich materializacji, bądź orientujemy się jakimi działaniami możemy łagodzić skutki pożaru

Głosowanie poparcia dla planu

Kiedy uznajemy, że mamy plan, istotna jest wspólna jego akceptacja i przekonanie o jego sensowności. Mówimy tu zarówno o nastawieniu do planu własnego zespołu, jak i pozostałych oraz ogólnie dla całego Agile Release Train. SAFe proponuje głosowanie, tzw. fist of five, w ramach którego każdy pokazuje od 1 do 5 palców, im więcej, tym większa nasza wiara w sukces. W istocie, nie tak ważna jest dokładna znajomość wyników głosowania, jak możliwość podzielenia się swoimi uwagami, przez osoby, które po dwóch dniach pracy wciąż widzą słabe punkty planu. Otwartość i odwaga w komunikacji może zaoszczędzić sporo problemów w przyszłości.

Wprowadzanie zmian do planu

Jeżeli uwagi okazują się bardzo poważne, to nie możemy tak po prostu rozejść się z wypracowanym planem i od kolejnego dnia roboczego zacząć go realizować, jak gdyby nigdy nic. Powinniśmy wprowadzać korekty do momentu, w którym plan stanie się przekonujący. Tak mówią autorzy SAFe’a. Rzeczywistość mówi, że ludzie są już w tym momencie bardzo zmęczeni i myśl o kolejnych godzinach, ba, nawet minutach poświęconych na planowanie jest myślą, którą z całą zawziętością przeganiamy. Bardziej prawdopodobny jest scenariusz, w którym plan mimo pewnych niedociągnięć jest akceptowany, a liderzy skupiają się na jego podsumowaniu i przygotowaniu najbliższych kroków, które ten plan wzmocnią.

Retrospektywa planowania

Oczywiście fajnie jest spisywać wszelkie uwagi i pomysły na usprawnienia na bieżąco i podsumować sobie na gorąco zakończony rytuał. Co się udało? Co było lepsze niż ostatnio? Co można by poprawić? Ale pamiętasz… ludzie są już naprawdę zmęczeni. Osobiście wolę robić takie retro na spokojnie w czasie realizacji Program Incrementu.

Zamiast podsumowania

Chcesz wiedzieć jak PI Planning wygląda u innych?

O doświadczeniach Lego we wdrażaniu SAFe’a i o tym jak wyglądają ich PI Planningi możesz przeczytać tutaj i obejrzeć w podlinkowanym filmiku:

http://atscale.pl/o-paladynach-krzyzowcach-i-gorze-glupcow/