• Home
  • Blog
  • Pierwszy PI Planning Program Increment

TRENDY

Pierwszy PI Planning Program Increment

25.01.2017 - Przeczytasz w 3 min.

Wiemy, że to początek naszej drogi - nasz pierwszy Pi Planning nie był idealny, ale wykorzystamy go maksymalnie do nauki i ulepszenia się na przyszłość. Czas ruszać z peronu!

Scaled Agile Framework

Pi planning? Czemu nie! Z punktu widzenia Scrum Mastera, wypróbowywanie nowych sposobów zarządzania procesem wytwarzania oprogramowania jest zawsze ekscytujące. Tym bardziej, kiedy przypomnę sobie początek Agile Manifesto:

 

We are uncovering better ways of developing
software by doing it and helping others do it.

 

SAFE framework

Powstawał w pierwszej dekadzie XXI wieku jako propozycja skalowania zwinnego/przyrostowego wytwarzania produktu i pogodzenia tego z długo i średnio- terminowymi planami biznesowymi (cele strategiczne, roadmapa produktu, portfolio). W założeniu pozwala on (przy zastosowaniu wartości i metod związanych z Lean, Agile, Scrum, XP) na dostarczanie rozwiązań, które wymagają zaangażowania większej ilości zespołów, dostawców i innych interesariuszy i jednoczesne zwiększenie przewidywalności dla biznesu.

Podstawowym mechanizmem zapewniającym synchronizację, współbieżność celów i średnioterminowe plany na poziomie programu w SAFe jest ART – czyli Agile Release Train.
Pociąg pędzi przed siebie po niekończących się torach (póki wartość jest dostarczana 🙂 i zatrzymuje się punktualnie na z góry określonych stacjach – Program Increment’ach.

W pociągu znajdują się wszyscy, którzy potrzebni są do dostarczenia wartości:

  • zespoły scrumowe (i kanbanowe),
  • przedstawiciele biznesu, marketingu, sprzedaży, wsparcia, reprezentanci klienta,
  • inni dostawcy,
  • architekci,
  • wszelkiej maści servant-leaderzy i właściciele produktu.

Całość kierowana jest przez zawiadowcę, czyli RTE (Release Train Engineer – pieszczotliwie zwany Chief Scrum Master). Moje pierwsze zetknięcie z SAFe odbyło się w grudniu 2016, w trakcie szkolenia na SAFe Program Consultant. 

Pierwszy Pi planning odbył się w dniach 16-17 stycznia. Zaledwie miesiąc po naszym szkoleniu SPC4. Całe szczęście na szkoleniu mieliśmy przedstawicieli zarówno części ‘technicznej’
jak i ‘biznesowej’. Dzięki temu mogliśmy stworzyć odpowiednio umocowaną grupę implementującą SAFe już na samym starcie. Mówiliśmy tym samym językiem i mogliśmy uzyskać ‘buy-in’ całej organizacji. Uniknęliśmy w ten sposób pułapki wprowadzania zmian ‘top-down’ (gdzie zwykle jest opór, niezrozumienie, rozmycie celów) czy ‘bottom-up’ (partyzantka, brak widocznych korzyści dla biznesu, sub-optymalizacja lokalna).

 

Pi planning – przygotowania

Od dostarczenia backlogu programu (duże feature’y, wstępnie rozbite na User Stories), poprzez szkolenia dla leaderów i zespołów (w okrojonej formie niestety) do przygotowania samej lokalizacji (miejsca dla kilkunastu zespołów). Nie wszystko udało się idealnie, ale efekt i tak był niezapomniany 🙂
Fascynujące było brać udział (jako SM zespołu i jako SPC dla całej organizacji) w takim wydarzeniu. Zaangażować się w wytworzenie wspólnego planu na następne 5 sprintów (Program Increment). Mimo rozgardiaszu, lekkiego chaosu i hałasu dało się wyczuć niesamowitą pozytywną energię, zaangażowanie i… samoorganizację. Wykrywaliśmy błyskawicznie zależności, mogliśmy je przegadać technicznie z innymi zespołami, negocjować zakres i priorytety z biznesem oraz względy architektoniczne (interfejsy, api, dane wejściowe/wyjściowe, bazy danych). Nie na wszystko byliśmy gotowi i nie wszystko dało się przygotować przed planowaniem – wiele rzeczy musieliśmy dogrywać ‘ad-hoc’. Było to w ogóle możliwe tylko dzięki temu, że mieliśmy WSZYSTKICH w jednym miejscu.

Planowanie zakończyliśmy wspólnie wypracowanym planem na Program Increment, który powstał poprzez zagregowanie planów zespołowych (i “przefiltrowanie” ich przez kluczowych interesariuszy).
Z jednej strony biznes wie, czego może się spodziewać w średniej perspektywie czasu (kwartał). Z drugiej strony zespoły wiedzą, że nie pracują w izolacji i rozumieją jak ich mniejsze funkcjonalności łączą się w całość – przyrost produktu (w skali programu).

 

Wnioski, usprawnienia na przyszłość:

Wcześniejsze przepracowanie backlogów zespołowych (refinement)
Lepsza wizualizacja postępów planowania i ‘dużego obrazka’ (program board) w jednym miejscu dla wszystkich na planowaniu
Estymacje zgrubne już przegadanych backlogów za pomocą metody affinity estimation
Większy nacisk na przygotowanie środowisk lokalnych, do integracji i typu staging PRZED rozpoczęciem prac
Stworzenie System Team na starcie – tak, aby wspomóc tematy integracji softu (różni dostawcy, środowiska, sposoby pracy)
Zaadaptowanie tworzenia celów programowych (PI Objectives) zamiast ograniczać się do zaplanowanej zawartości backloga, aby jeszcze mocniej zaznaczyć wspólny kierunek pociągu.

Wiemy, że to początek naszej drogi – nasz pierwszy Pi Planning nie był idealny. Wykorzystamy go maksymalnie do nauki i ulepszenia się na przyszłość. Czas ruszać z peronu!

Ocena artykułu

Udostępnij

Paweł Słowikowski-RST Software

Paweł Słowikowski

Professional Scrum Master

Misją jego życia jest tworzenie środowiska, w którym ludzie mogą się rozwijać i wykorzystywać swoje talenty w pełnym zakresie. Zajmuje się promowaniem zwinności, ekstremalnej samoorganizacji, tworzenia wiedzy i dzielenia się w organizacjach, które tworzą oprogramowanie. Fascynat koncepcji organizacji na poziomie turkusowym. Inspirują go wielkie pomysły i motywacja do pracy z ludźmi, którzy chcą pozytywnie wpływać na otaczającą ich rzeczywistość.

Newsletter

Newsletter

Dziękujemy, Twój email został wysłany.

Nasz serwis internetowy używa plików cookies do prawidłowego działania strony. Korzystanie z serwisu bez zmiany ustawień dla plików cookies oznacza, że będą one zapisywane w pamięci urządzenia. Ustawienia te można zmieniać w przeglądarce internetowej. Więcej informacji udostępniamy w Polityce plików cookies.