Artykuły o technologiach IT, programowaniu, testowaniu i nie tylko

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 jako framework nie jest nowy. 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. i wszystkiego innego, co potrzebne jest aby zacząć – czyli uruchomić swój pierwszy pociąg.

Pierwszy Program Increment 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).

Przygotowanie pierwszego PI Planningu wymagało kilkunastu dni intensywnej pracy. 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 i 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 Program Increment nie będzie idealny, ale wykorzystamy go maksymalnie do nauki i ulepszenia się na przyszłość. Czas ruszać z peronu!


Nawigacja