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. Podczas tego 4- dniowego maratonu przeszliśmy przez, jak się zdaje, większość zakamarków tego frameworka. Pierwsze wrażenie: jest tego ogrom! O ile w przypadku innych metod czy podejść, ilość ‘przepisów’ jest ograniczana do minimum, to w przypadku SAFe wydaje się królować podejście: “dajmy na start wszystko, aby ludzie mogli bezpiecznie zacząć, nawet od zera”. Mamy tutaj bardzo szczegółowe opisy wartości, praktyk, metod, spotkań (agendy podane już nawet co do godziny!), ról, backlogów i wszystkiego innego, co potrzebne jest aby zacząć - czyli uruchomić swój pierwszy pociąg.
SAFe mocno stawia nie tylko na opis ‘krok po kroku’, ale także podkreśla, że bez nastawienia zwinnego, (Agile Manifesto, Lean House) nie uda się poprawnie wdrożyć tego framework’a w organizacji. Jestem bardzo ciekawy jak to nam się sprawdzi w dalszej pracy (patrząc na realizację celów, dostarczonej wartości i innych metrykach typu cycle time, lead time). Z tyłu głowy mam gdzieś oczywiście emocjonalny wpis Kena Schwabera o SAFe, jednak jestem daleki od ferowania wyroków bez spróbowania implementacji tego i ocenienia rezultatów.
Duża część szkolenia jest też poświęcona propagowaniu postawy servant-leader’a. Czyli w sumie wszystko się zgadza (zwinność) i do tego jest podane na tacy (implementacja, ramy i przewidywalność dla biznesu :).
A jak jest w praktyce? Dopiero zaczynamy, ale pierwszymi ciekawymi obserwacjami mogę się już z Wami podzielić.
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) tak, aby zespoły mogły się 'oswoić' z proponowanymi funkcjonalnościami
- 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
- Pizza, jeszcze więcej pizzy 🙂
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ść.
A jakie są wasze doświadczenia z SAFe lub innymi frameworkami do skalowania zwinnego podejścia?
Artykuł opublikowany po raz pierwszy na blogu RST Software Masters.