Product Increment Planning w SAFe

Z uwagi na to, że od 01.01.2021 staliśmy się Brązowym partnerem Scaled Agile Framework (SAFe) rozpoczynamy cykl nowych wpisów na naszym blogu wprowadzających do świata skalowania produktów o dużym stopniu złożoności, gdzie istnieje konieczność synchronizacji pracy wielu Zespołów Agile. W naszym pierwszym wpisie poruszymy temat głównego wydarzenia SAFe, czyli PI Planning (Product Increment Planning). Poniżej dowiecie się co to jest za wydarzenie i jaki jest jego cel, jak się do niego przygotować oraz jakie aktywności są wykonywane podczas dwudniowego PI Planningu. 

PI Planning – co to jest?

PI Planning, czyli Planowanie Przyrostu Programu jest głównym wydarzeniem dla wszystkich członków Agile Release Train(ART). Celem PI Planningu jest wypracowanie wspólnego zrozumienia wizji i celów produktu, czego efektem jest utworzony przez Zwinne Zespoły Agile plan w postaci Program Board osadzony w Timeboxie przyjętym przez ART. Rekomendacja ze strony SAFe dla długości PI to 8-12 tygodni. Możemy zatem powiedzieć, że optymalne planowanie to jeden kwartał w przyszłość. Dodatkowo SAFe zaleca również, aby podczas planowania przyszłej pracy kadencje sprintu trwały 2 tygodni, co daje nam od 4-6 sprintów. 

Kolejnym ważnym elementem wydarzenia jest współpraca. Podczas PI Planningu Zespoły Agile mają doskonałą okazję synchronizacji swoich planów między sobą, dzięki temu rozwiązywane są zależności oraz wskazywane są ryzyka, które mogą się pojawić podczas tworzenia planu na następny kwartał.

Przygotowanie do PI Planning

Przed każdym PI Planningiem musimy się przygotować jako Zespół Agile, Product Ownerzy oraz inne osoby biorące udział w planowaniu w ramach Agile Release Train (ART). Dobre przygotowanie może ułatwić zespołom wykorzystanie dwóch dni na zaplanowanie pracy na 8-12 tygodni. Więc co robimy? Przed PI Planningiem warto zaplanować czas, tak aby każdy Zespół Agile mógł wykonać Refinement Funkcjonalności (Features), które zostały wytypowane przez Product Management jako kluczowe. SAFe rekomenduje wybranie tzw. Top 10 Features. Dobrą praktyką podczas Refinementów jest to, aby w drodze do poznawania wymagań i szczegółów zadań, jest ocena stopnia ich złożoności, np. poprzez głosowanie. Możemy tutaj użyć techniki T-Shirt size, czyli estymujemy Funkcjonalności (Features) od XS aż po XL. 

Wydarzenie PI Planning

Musimy tutaj zaznaczyć jedną bardzo ważną rolę w całym PI Planningu jak i SAFe. Jest to mistrz całego zamieszania, czyli Release Train Engineer. RTE jest odpowiedzialny za organizację i facylitację PI Planningu. Upewnia się, że cele i oczekiwany wynik jest jasny dla wszystkich, dba o jego sprawny przebieg oraz pomaga Zespołom Agile w rozwiązywaniu przeszkód napotkanych podczas wydarzenia. 

Wydarzenie PI Planning powinno trwać dwa dni, gdzie wszystkie aktywności powinny być wykonane. Przykładowy “rozkład jazdy” prezentujemy poniżej:

Dzień 1Dzień 2
08:00-9:00Kontekst Biznesowy (Business Context)08:00-09:00Korekta Planowania – przegląd (Planning Adjustments)
09:00-10:30Produkt – Wizja Rozwiązania (Product/Solution Vision09:00-11:00Planowanie w Zespołach Agile – II runda (Team Breakouts II)
10:30-11:30Wizja Architektury & Standard Developmentu(Architecture Vision & Development Practices11:00-13:00Finalny przegląd planów & Lunch(Final Plan Review & Lunch) 
11:30-13:00Zasady Planowania & Lunch (Planning Context & Lunch)13:00-14:00Ryzyka Programowe (Program Risks)
13:00-16:00Planowanie w Zespołach Agile – I runda (Team Breakouts I)14:00-14:15Głosowanie n.t. wykonalności planu (Confidence Voting)
16:00-17:00Wstępny Przegląd Planu Zespołów Agile (Draft Plan Review)14:15-????Zmiany do planów Zespołów Agile (Plan Rework)
17:00-18:00Przegląd planów przez management oraz rozwiązywanie problemów (Management Review and Problem Solving)????Retrospektywa PI Planningu (Planning Retrospective and Moving Forward)
SAFe PI Planning: https://www.scaledagileframework.com/pi-planning/

Pomijając agendę PI Planningu dobrą praktyką dla RTE jest Scrum of Scrums, czyli synchronizacja wszystkich Scrum Masterów dotycząca sprawdzenia postępu planowania oraz rozmowy na temat ryzyk i przeszkód.  

Jeśli chodzi o szczegółowość planowania na 8-12 tygodni, dobrą praktyką jest wykorzystanie metody EDUF (Enough Design Upfront), czyli planowanie dwóch najbliższych sprintów z większą ilością szczegółów. Pozostałe sprinty mogą zawierać historyjki na poziomie bardziej ogólnym z naciskiem na identyfikację zależności. Pamiętajmy, że w ramach kadencji Przyrostu Programu zespoły będą uczestniczyć w wydarzeniach na poziomie zespołu np. Planowania Sprintu. Więc wraz z nabyciem większej wiedzy plany najprawdopodobniej ulegną zmianie. 

Dzień 1 PI Planningu

Przejdźmy zatem do opisu poszczególnych aktywności podczas Planowania Przyrostu w trakcie pierwszego dnia:

Kontekst Biznesowy – jest to spotkanie otwierające PI Planning, gdzie Właściciel Biznesowy (Business Owner) lub osoby z Managementu (Senior Executives) przedstawią informacje na temat warunków biznesowych otaczających produkt, oraz wizję całego portfolio produktowego. 

Produkt Wizja Rozwiązania – Product Management przekazuje informacje na temat obecnej wizji produktowej oraz zaznacza zmiany które miały miejsce od ostatniego PI Planningu. Omawiane są również jak wygląda obecnie rozwiązanie, jak wyglądają poszczególne części produktu (Features), jak się ze sobą komunikują itp. 

Wizja Architektury & Standard Developerski – Architekci systemowi (System Architects/Engineering) prezentują wizję architektury rozwiązania systemowego. Dodatkowo osoba która pełni funkcję Senior Development Manager przedstawia wspierające Agile praktyki jakimi mogą być jak automatyzacja testów, DevOps, CI/CD.  

Zasady Planowania & Lunch – Release Train Engineer przedstawia proces planowania oraz jakie spodziewany wynik na koniec PI Planningu. 

Planowanie w Zespołach Agile (I Runda) – po wysłuchania wszystkich informacji odnośnie Pi Planningu oraz Produktu Zespoły Agile rozchodzą się do swoich grup, gdzie rozpoczyna się pierwsza iteracja planowania przyszłych sprintów. Zespół Agile wraz z Scrum Masterem oraz Product Ownerem współpracują nad ułożeniem planu dla poszczególnych części Produktu. Scrum Master podczas tego wydarzenia jest osoba która facylituje dyskusje oraz działania Zespołu Agile. Podczas tego wydarzenia Zespoły Agile tworzą pierwszą wersję planu na najbliższy kwartał. 

Warto tutaj wspomnieć o bardzo ważnym elemencie jakim są zależności. W momencie planowania Features na przyszłe sprinty może się okazać, że dany Zespół Agile będzie potrzebował wsparcia innego zespołu, aby móc ukończyć swoje zadanie/a. Dlatego też podczas PI Planningu wykonujemy 2 czynności: 

  1. Ustalenie zależności oraz “dogadanie” się z innymi Zespołami Agile odnośnie sekwencji i synchronizacji pracy.
  2. Uzupełnienie Tablicy Zależności / Tablicy Programu (Dependency Board/ Program Board) między Zespołami Agile, w celu zapewnienia transparencji i ułatwienia monitorowania zmian podczas kadencji Przyrostu Programu

Wstępny przegląd planów – Zespoły Agile prezentują wstępny plan na przyszłe sprinty lub to co im się udało stworzyć podczas planowania. Dodatkowo informują o ewentualnych problemach z planowaniem, ryzykach, zależnościach. Interesariusze czyli Właściciele Biznesowi, Managerowie Produktu oraz inne Zespoły Agile komentują lub pomagają w wyjaśnieniu kwestii podniesionych przez Zespół Agile. 

Przegląd planów przez management oraz rozwiązywanie problemów – po każdym Wstępnym Przeglądzie Planów management spotyka się w celu ich omówienia oraz znalezienia jakieś rozwiązania danych sytuacji ale również negocjacji zakresu zadań dla Zespołów Agile. Release Train Engineer (RTE) odpowiada za facylitację tego spotkania oraz również za pomoc w znalezieniu rozwiązań tzn. dba o to aby management wypracował rozwiązania które są możliwe do osiągnięcia przez Zespoły Agile. 

Dzień 2 PI Planningu

Dzień pierwszy planowania został zakończony. Wszystkie aktywności wykonane. Przejdźmy zatem to dnia drugiego czyli finalnego dnia PI Planningu: 

Korekta Planowania (przegląd) – Management prezentuje wynik spotkania Przeglądu Planów oraz Sesji Rozwiązywania Problemów. Zostają przekazane informacje na temat zmiany zakresie planowania, rozwiązania ryzyk, problemów. 

Planowanie w Zespołach Agile (II Runda) – po poznaniu przez uczestników ewentualnych zmian z PI Planningu, Zespoły Agile rozchodzą się do swoich grup, gdzie kończą planowanie przyszłych sprintów. Podczas tej części, Zespoły Agile finalizują swoje prace oraz dopracowują zależności z innymi Zespołami Agile. 

Finalny przegląd planów & Lunch – Zespoły Agile prezentują swoje plany na przyszłe sprinty (przypominamy planowanie optymalne dla 4-6 sprintów). Na koniec prezentacji każdego z planów, Zespoły Agile przekazują informację odnośnie ryzyk, zależności. Dodatkowo Zespół Agile podczas tego spotkania uzyskuje zgodę Właściciela Biznesowego na swój plan. W momencie kiedy Business Owner nie akceptuje planu, Zespół Agile dostaje możliwość jego zmiany/aktualizacji. Po wykonaniu zmian, plan jest jeszcze raz przedstawiany do akceptacji. 

Ryzyka programowe – tak jak wspomnieliśmy Zespoły Agile również informują o ryzykach i problemach. Każde z nich jest rozwiązywane, tak aby nie stanowiło przeszkody w osiągnięciu celu przez Zespoły Agile. Aby pomóc przy ich rozwiązaniu oraz kategoryzacji, korzystamy z podejścia ROAM (Resolved, Owned, Accepted, Mitigated)  

Głosowanie n.t. wykonalności planu – tak zwany Confidence Voting jest wykonywany praktycznie na końcu PI Planningu. Każdy Zespół Agile korzystając ze swojej dłoni głosuje na plan swojego Zespołu Agile przez pokazanie palcami poziomu zaufania od 1-5. Gdzie jeden oznacza, że plan praktycznie jest nie do wykonania, a 5 oznaczacza wykonanie go w 100%. 

Zmiany do planów Zespołów Agile – jeżeli jest taka potrzeba, Zespoły Agile w swoich grupach dokonują zmian w obecnym planie aby zminimalizować ryzyka, zależności lub stał się on wykonalny. 

Retrospektywa PI Planningu – wydarzenie jest prowadzone przez Release Train Engineer (RTE) w celu zebrania informacji co poszło dobrze, co nie do końca się udało i co można zrobić inaczej podczas następnego PI Planningu.  

Wynik PI Planningu

Po zakończeniu PI Planningu, Release Train Engineer (RTE) i inni interesariusze Agile Release Train (ART) podsumowują indywidualne cele PI (PI objectives) każdego z Zespołów Agile w zestaw celów programu PI i używają ich śledzenia postępów w realizacji celów. Tablica Programu (Program Board) jest często używana podczas Scrum of Scrums do śledzenia zależności oraz postępu prac.

Na koniec najważniejsze, Agile Release Train (ART) przystępuje do wykonania PI, śledząc postępy prac i dostosowując się w razie potrzeby do zmian, które zachodzą, gdy pojawia się nowe informacje dotyczące produktu. Wykonywanie PI rozpoczyna się od zaplanowania przez wszystkie Zespoły Agile pierwszej iteracji, wykorzystując swoje plany PI jako punkt wyjścia. 

O tym jak wygląda PI Planning oraz framework SAFe dowiesz się więcej na naszych szkoleniach