SAFe – nie tylko dla zwinnych

SAFe (Scaled Agile Framework) jest najpopularniejszym frameworkiem skalującym Agile. Nie ma co do tego wątpliwości, tak jak Scrum jest najpopularniejszym frameworkiem agile’owym, tak SAFe jest najpowszechniej używanym podejściem do wdrażania zwinności w skali całej organizacji. Mimo tego wciąż pojawiają się głosy zwątpienia, czy w ogóle powinno się go nazywać agile’owym, czy coś tak dużego i złożonego można rozważać w kategorii zwinności, czy taki moloch może zapewnić zwinność w dostarczaniu złożonych rozwiązań. A gdybym powiedział, że to czy SAFe jest Agile, czy nie, może nie mieć absolutnie żadnego znaczenia?

Niemal od początku mojej przygody z project managementem, z klasycznym zarządzaniem pojedynczymi projektami przeplatają się dwa wątki: zarządzanie grupami projektów (programami i portfelami) oraz zwinne zarządzanie projektami. SAFe jest czymś, co łączy te dwa obszary, więc już od pierwszego kontaktu mocno przykuł moją uwagę. Na co dzień zajmuję się wdrażaniem SAFe’a, prowadzeniem szkoleń oraz orkiestrowaniem pracy zespołów deweloperskich, jako SAFe’owy odpowiednik Program Managera, czyli Release Train Engineer (taki Uber Scrum Master). W związku z moją pracą niemal codziennie prowadzę dyskusję na temat ilości Agile’a w Agile’u, jak również Agile’owości SAFe’a, a nawet ilości SAFe’a w SAFie, ale w tym artykule na chwilę zapominam o Agile’u i stawiam taką tezę:

Załóżmy, że SAFe nie jest frameworkiem zwinnym, tylko sposobem na organizację wielu zespołów deweloperskich i biznesu w ramach realizowanych inicjatyw, projektów, programów i portfeli.

Załóżmy, że Agile nie istnieje. Jakie zatem korzyści może zatem przynieść SAFe organizacji realizującej duże przedsięwzięcia, wymagające zaangażowania wielu obszarów biznesowych i zespołów? Poniżej 6 przykładów takich mechanizmów.

1. Core Values i SAFe Principles, czyli kultura projektowa organizacji

Niezależnie od tego, czy promowane przez SAFe zasady SAFe Core Values i SAFe Principles są bardziej Lean, czy bardziej Agile reprezentują coś, co powinna mieć każda organizacja. Niezależnie od tego, jakiego podejścia używamy, warto żeby składała się ona nie tylko z narzędzi, procesów i ról, ale także z pewnych bardziej ogólnych pryncypiów, które budują jej kulturę i projektowe DNA. W momentach, gdy procesy robią się skomplikowane, a narzędzia trudne do opanowania, te wartości stanowią drogowskazy i wskazują intencje z jakimi powinno się tych narzędzi używać.

SAFe Core Values

Core Values, czyli: Alignment, Built-in Quality, Transparency i Program Execution, są na tyle ogólne i uniwersalne, że wspierają nie tylko Lean i Agile ale też, a może nawet przede wszystkim, zdroworozsądkowe podejście do realizacji złożonych przedsięwzięć. Poniżej parę słów o tych wartościach:

Alignment odnosi się do spójności rozwiązań wypracowywanych w różnych obszarach biznesowych organizacji i na różnych jej poziomach z kierunkami strategicznymi, wizją rozwoju produktów i ich roadmapą. Poszczególne wydarzenia i narzędzia używane na poziomie operacyjnym służą temu, żeby regularnie synchronizować biznes i nadawane przez niego kierunki rozwoju z obszarem wytwórczym, który dostarcza konkretne rozwiązania. Brak tej synchronizacji powoduje, że część rozwiązań pisanych jest do szuflady, okazuje się zdezaktualizowanymi już w momencie wdrażania albo mogłoby być zrealizowane lepiej, gdyby deweloperzy posiadali lepsze rozumienie biznesu i interesariuszy.

Przypomnij sobie, jak często spotykasz się z sytuacją, w której programiści tworzą rozwiązania w oparciu o lepiej lub gorzej przygotowane wymagania, nie wiedząc przy tym zbytnio, czemu konkretnie służyć ma produkt projektu, kto będzie go używał, jak wygląda jego biznes, w jakim otoczeniu funkcjonuje, jak się mają cechy produktu i jego plan rozwoju z planami rozwoju organizacji, jakie cele mają być dzięki temu rozwiązaniu osiągnięte, co będzie się działo z produktem za rok, dwa, przynajmniej na ogólnym poziomie? Istnieją w SAFie konkretne mechanizmy korespondujące z tą wartością, jest nim między innymi PI Planning, o którym przeczytasz jeszcze w tym artykule, a szczególnie jego część dotycząca wyznaczania celów i przydzielania im wartości biznesowej.

Built-in Quality mówi o tym, że jakość musi być dostarczana poprzez dobre praktyki zespołów deweloperskich, nie może być efektem procesów monitorowania i kontroli. Ta wartość odnosi się bardzo mocno do praktyk deweloperskich wywodzących się wprost z Extreme Programming, ale zahacza też o podejście Dev-Ops oraz Continuous Integration i Continuous Deployment.

Transparency oznacza otwartość w komunikacji na wszystkich poziomach organizacji i również pomiędzy nimi, jak również przejrzystość narzędzi i planów. Najwyraźniejszym tego przykładem są Kanbany funkcjonujące na wszystkich poziomach zarządczych i powszechnie dostępne dla interesariuszy. Rozwinę ten wątek poniżej.

Program Execution podkreśla wagę dostarczania faktycznej, namacalnej wartości dla biznesu i użytkowników rozwiązań. Przekłada się, między innymi, na takie mechanizmy, jak Value Streams oraz Agile Release Train. Przypomina biznesowi i obszarowi wytwórczemu jak ważne jest regularne dostarczanie działających rozwiązań, chociażby i cząstkowych, ale przynoszących już częściowe korzyści i umożliwiających zbieranie informacji zwrotnych od interesariuszy.

SAFe Principles

O ile SAFe Core Values mogę być postrzegane, jako bardzo ogólne i mocno odległe od codziennej, operacyjnej pracy, o tyle SAFe Principles są już tym, co możemy dość łatwo bezpośrednio przełożyć na sposób, w jakich podchodzimy do naszych zadań i obowiązków. Jednocześnie są jednak wciąż na tyle ogólne, że stanowią raczej pewne uniwersalne wskazówki niż konkretne role, procesy i narzędzia.

Wpis nieco bardziej przebliżający Pryncypia SAFe znajdziesz tutaj. W tym artykule z kolei wskazuję jedynie, jak uniwersalne są to zasady i jakie z grubsza idee odzwierciedlają.

SAFE Principle 1: Take an economic view / Przyjmuj ekonomiczny punkt widzenia

Pryncypium to łączy w sobie dwie wytyczne:

A. Dostarczaj wcześnie i często
B. Bądź świadom zależności ekonomicznych

O ile pierwsza ma charakter wybitnie zwinny i promuje iteracyjne podejście we wdrażaniu rozwiązań, o tyle druga mówi już o czymś abstrahującym od konkretnej doktryny projektowej, mianowicie o znaczeniu świadomości ekonomicznych powiązań między poszczególnymi elementami realizacji projektów. Podczas tworzenia rozwiązania podejmujemy mnóstwo decyzji. Sterujemy aspektami, które są od siebie uzależnione. Idziemy na kompromisy. Np. czy inwestujemy więcej czasu w testowanie, czy zapłacimy potem więcej przy usuwaniu błędów; czy wypuszczamy niezoptymalizowane rozwiązanie i ponosimy wysokie koszty jego utrzymania (np. reklamacje) czy dajemy sobie więcej czasu na zagwarantowanie wyższej jakości? Wszystko co robimy podczas realizacji projektu przekłada się na uzasadnienie biznesowe. Musimy być świadomi tych zależności, by podejmować optymalne decyzje. Nie musimy być Agile, żeby dostrzegać wagę patrzenia przez pryzmat ekonomii, mając na uwadze nie tylko bieżące korzyści, ale też wpływ naszych decyzji na koszty pozostałych obszarów.

SAFE Principle 2: Apply systems thinking / Stosuj podejście systemowe

Zasada ta uczy patrzenia na system, jako całość i na powiązania pomiędzy jego składowymi zamiast na jego pojedyncze elementy. Dla przykładu: nie ma sensu usprawniać procesów związanych z pisaniem kodu i zwiększać ich wydajność, jeśli wąskim gardłem są testerzy. Inny przykład: nie ma sensu zwiększać wolumenu sprzedaży, jeśli system jest niewydolny i nie potrafi obsłużyć takiej ilości użytkowników. Skupiajmy się zawsze w pierwszej kolejności na najsłabszych punktach procesu. Takie myślenie wywodzi się z filozofii Lean i przynosi wartości niezależnie od tego, czy realizujemy nasze projekty według doktryny Agile czy waterfall. Warto je stosować niezależnie od tego, co wytwarzamy i jakie usługi dostarczamy.

SAFE Principle 3: Assume variability; preserve options / Zakładaj zmienność; zachowuj opcje

Zasada ta odnosi się głównie do projektowania systemów. Podczas tworzenia rozwiązań naturalnym zachowaniem jest zawężanie opcji. Im wcześniej wybierzemy technologię, im wcześniej domkniemy jakiś element architektury, tym pewniej się czujemy i budujemy przekonanie o kontrolowaniu projektu. Nie zawsze jest to jednak najlepsze podejście. Jeśli chcemy zwinnie reagować na wymagania biznesowe, to zbyt sztywna architektura może to mocno utrudnić lub nawet uniemożliwić. Jeśli zbyt szybko zdeterminujemy rozwiązanie, które na dany moment wydaje się optymalne, to z czasem jednak może okazać się, że nie jest ono w stanie sprostać aktualnym oczekiwaniom. W takim przypadku koszt zawrócenia z obranej ścieżki może być zbyt dotkliwy. Podejście, w którym decyzje architektoniczne i ogólnie technologiczne podejmujemy najpóźniej jak się da, pozostawiając do ostatniego momentu opcje, które zapewniają nam jeszcze możliwość dostosowania się do wymagań wspiera co prawda Agile i środowisko, w którym wymagania zarządzane są bardzo dynamicznie, ale jego stosowanie może być nie mniej cenne w przypadku podejścia klasycznego.

SAFE Principle 4: Build incrementally with fast, integrated learning cycles / Buduj przyrostowo w ramach krótkich, zintegrowanych cykli uczenia się

Myśl stojąca za tą regułą jest jednym z tych punktów, w których SAFe trochę przesadza w jeżdżeniu po waterfallu. W paru miejscach, w których autorzy piszą o wyższości podejścia Agile’owego zachowują się jakby klasyczne projekty zawsze zamykały się w sztywnym i liniowym procesie:

1. Zdefiniuj wymagania
2. Zaprojektuj rozwiązanie
3. Wykonaj, przetestuj
4. Wdróż
5. Zbierz feedback

Udają trochę, że nie wiedzą, że jest coś takiego, jak Proof of Concept czy Proof of Technology, ignorują to, że projekt klasyczny często dzieli się na fazy, które kończą się cząstkowymi wdrożeniami. Trochę nieładnie z ich strony, bo nie tędy droga, żeby promować swoje rozwiązanie na bazie oczerniania innego. Nawet jeśli Agile jest bardziej nastawiony na iteracyjność i wytwarzanie produktu w możliwie krótkich cyklach, w których zamykamy się ze wszystkimi waterfallowymi etapami, od wymagań do feedbacku, to stosowanie waterfalla nie wyklucza skupiania się w początkowych etapach projektu na dostarczanie MVP i wcześniejszego oddania częściowego rozwiązania do rąk użytkowników.

Agile nie ma też wyłączności na wykorzystywanie doświadczeń, jakie nabywamy integrując poszczególne komponenty rozwiązania. Często zdarza się w projektach klasycznych, że przez relatywnie długi czas rozwijamy poszczególne podsystemy osobno, a do integracji dedykujemy końcowe fazy projektu, ale nie jest to sztywna reguła. Agile, a w szczególności SAFe dąży do tego, żeby poszczególne składowe rozwiązania: komponenty, moduły, podsystemy integrować jak najszybciej, budując faktyczny obraz realizowanych prac. W SAFie integracja prac poszczególnych zaangażowanych zespołów ma miejsce na koniec każdego sprintu. Oczywiście, każdy kto ma trochę projektów za sobą wie, że podobną rolę w waterfallu pełnią PoC i PoT, prototypy lub dedykowane fazy, nawet jeśli w Agile’u jest na to kładziony szczególny nacisk.

SAFE Principle 5: Base milestones on objective evaluation of working systems / Zaliczaj kamienie milowe na bazie obiektywnej oceny działających systemów

Reguła ta mocno nawiązuje do poprzedniej. Jeśli już zauważamy potrzebę podziału projektu w taki sposób, żeby jego produkty cząstkowe odbierać i wdrażać na bieżąco, najwcześniej jak to możliwe, to z pewnością zauważymy też, że rzetelne informacje na temat postępu naszego projektu daje nam nie zaliczanie takich etapów, jak: definiowanie wymagań, analiza wymagań, projektowanie, itd. tylko obiektywna ocena, najlepiej dokonywana przez użytkowników dostarczanych komponentów rozwiązania. Oczywiście z pełną świadomością tego, że małymi kroczkami nie da się przeskoczyć przepaści i czasami ten minimalny zakres rozwiązania, stanowiący jakąkolwiek sensowną wartość dla użytkownika, jest i tak relatywnie duży.

SAFE Principle 6: Visualize and limit WIP, reduce batch sizes, and manage queue lengths / Wizualizuj i ograniczaj pracę w toku, redukuj zakresy przyrostów, zarządzaj długością kolejek prac

Mierzenie i wizualizowanie pracy w toku, a następnie ograniczanie jej, zarządzanie długościami kolejek i walka z przesadną wielozadaniowością są co prawda najbardziej kojarzone z Kanbanem, ale odnoszą się do wszystkich działań podejmowanych w organizacjach niezależnie od tego, na jakim poziomie zarządczym i w jakim obszarze domenowym są realizowane. Ta reguła jest po prostu dla każdego, do stosowania nawet w życiu prywatnym.

SAFE Principle 7: Apply cadence, synchronize with cross-domain planning / Wdrażaj rytmiczność prac, synchronizuj w ramach planowania międzydomenowego

O ile rytmiczność prac wprowadzana przez Scrum na poziomie zespołów, jest czymś co docenia większość osób zaangażowanych w procesy wytwarzania oprogramowania, o tyle z jakiś względów na wyższych poziomach (program, czy portfel projektów) jest to na ogół słabo implementowalne. Stały, wspólny dla biznesu i dewelopmentu, rytm prac oraz cykliczna synchronizacja przynosi masę korzyści (lepsze zrozumienie kontekstu biznesowego, szybszy feedback ze strony deweloperów, lepiej zdefiniowane wymagania, większa przewidywalność projektów, itd.) nie potrzebujemy Scruma, ani w ogóle Agile’a żeby to stosować. Jeśli inne frameworki i systemy pracy nie potrafią tego upowszechnić, to niech to zrobi SAFe, bo liczyć się rezultat, a nie koszerność narzędzia.

SAFE Principle 8: Unlock the intrinsic motivation of knowledge workers / Uwolnij wewnętrzną motywację Pracowników Wiedzy

Ta reguła jest piękna. Zachęcam do głębszego zapoznania się z nią, bo nie znam osoby, której nie przypadłaby ona do gustu. Projekty z natury są innowacyjne i w znacznej mierze biorą w nich udział Pracownicy Wiedzy. Sposób podejścia do nich może szybko przełożyć się na sukces albo porażkę naszych inicjatyw. O wewnętrznej motywacji możesz przeczytać więcej tutaj.

SAFE Principle 9: Decentralize decision-making / Decentralizuj podejmowanie decyzji

Nie da się skutecznie skalować niczego w organizacjach, czy to Agile’a, czy to projektów, czy też procesów, jeśli wszystkie inicjatywy mają jeden wąski punkt decyzyjny. Tak się po prostu nie da, a takie centralne miejsca podejmowania decyzji (np. Zarząd, albo Komitety Sterujące) stają się wąskimi gardłami albo podejmują nieracjonalne decyzje bazujące na ograniczonej wiedzy i koniecznością podejmowania wielu decyzji w tym samym czasie. O tym jest ta reguła. Ja bym ją wyrył na ścianie każdej organizacji, która chce osiągać globalne sukcesy.

Podsumowanie SAFe Core Values i SAFe Principles

I jak? Czy ma znaczenie to, jak jesteś zwinny, w kontekście używania tych zasad lub tworzenia podobnych, może lepiej oddających specyfikę Twojej organizacji? Ważne, żeby takie ogólne reguły były spisane, rozumiane i konsekwentnie wdrażane do organizacji. Często brakuje czasu żeby je spisać, a to że przychodzą wraz z gotowymi (lub na wpół gotowymi) frameworkami jest bardzo wygodne.

2. Skalowanie ról

Mimo, że hasło “skalowanie” pojawia się od paru lat bardzo często w kontekście skalowania zwinności, to nie Agile je wprowadził. Grupowanie projektów w programy i portfele, by zarządzać nimi w sposób skoordynowany funkcjonuje od wielu lat. Bez znaczenia czy projekty, a co za tym idzie – zespoły, koordynujemy w oparciu o wspólny cel biznesowy, produkt, technologię, region, rynek czy zasoby, istotne jest to, że zarządzamy dużą liczbą deweloperów i interesariuszy biznesowych. W takiej sytuacji wraz z mnożeniem zespołów pojawiają się role niezbędne do koordynacji ich prac, na różnych poziomach zarządczych.

O ile metod i dobrych praktyk zarządzania projektami nie brakuje na rynku, a jakość najpopularniejszych z nich nie budzi raczej wątpliwości, to z frameworkami podpowiadającymi jak radzić sobie z programami i portfelami jest dużo gorzej. Przed moją przygodą z SAFem, za każdym razem, kiedy zarządzałem grupami projektów, nie mogłem liczyć na realne wsparcie standardów, żaden z nich nie przekonał mnie na tyle, żeby wdrożyć go w istotnym zakresie do jakiejkolwiek organizacji. Za każdym razem brałem udział w tworzeniu autorskiej metodyki, jedynie inspirując się światowymi standardami. Tworzenie takiej metodyki jest bardzo pracochłonne, a jej wdrożenie wymaga wiele czasu. Aż się prosi o jakiekolwiek gotowe mechanizmy, które zmniejszą choć trochę te nakłady, zwłaszcza jeśli są w miarę uniwersalne i nasi pracownicy mogli się już z nimi spotkać w swoich poprzednich miejscach pracy. Taka oszczędność czasu i energii jest istotna.

SAFe wprowadza taki ład i standardy w obszarze ról. Skaluje zarówno te biznesowe: Product Owner – Product Management – Solution Management – Portfolio Management, jak i te organizacyjne: Scrum Master – Release Train Engineer – Solution Train Engineer, a także te techniczne: Development Team – System Architect – Solution Architect – Enterprise Architect. Wprowadza też inne role nie będące bezpośrednim efektem skalowania ról znanych z poziomu zespołu a będące ich uzupełnieniem, takie jak: Business Owner, Epic Owner, System Team itd. Tych ról jest mnóstwo, a każdy z nich ma swoje miejsce w procesach, swoje narzędzia i określony zakres odpowiedzialności.

Można powiedzieć, że przez to SAFe nie jest Agile, że tych ról jest za dużo, że zbytnio komplikuje to procesy zarządcze, ale to nie jest prawda. Funkcjonowania dużych obszarów projektowych pracujących nad dużymi rozwiązaniami nie da się zamknąć w trzech rolach: Scrum Master (czasem Agile PM), Product Owner, Developer. W takich przedsięwzięciach bierze często udział armia ludzi, z różnych domen i z różnych poziomów zarządczych. Zapominanie o nich, nie przydzielanie im roli, nie definiowanie im obowiązków, udawanie że nie są istotni w kontekście realizacji projektów jest ogromnym oszukiwaniem siebie i proszeniem się o kłopoty.

Nie jest oznaką żadnej zwinności definiowanie procesu dla garstki ludzi, wprowadzenie u nich niezrozumiałego dla otoczenia żargonu i rytuałów, zapominając o całej reszcie z nią współpracującej. Duże przedsięwzięcia angażują wielu ludzi. Wraz ze wzrostem ilości ludzi rośnie złożoność interakcji między nimi i wysiłek, jaki musimy w nią włożyć. Dodatkowe role są niezbędne i lepiej jeśli są one zdefiniowane, niż pozostają w szarej strefie. Jeśli jakiś framework odwala za nas przynajmniej część roboty, to warto rozważyć wykorzystanie jego mechanizmów. Żaden inny niż SAFe nie przekonał mnie na tyle żebym go wdrożył, a interesuję się mocno tematem i nie są mi obce standardy PMI, IPMA, czy AXELOSowe.

3. Skalowanie rytuałów, zdarzeń, spotkań

Wraz ze wzrostem liczby zespołów zaangażowanych w realizację przedsięwzięć rośnie też potrzeba skalowania spotkań. Niestety. Nie można oczekiwać, że tymi samymi rytuałami i procesami będziemy potrafili zarządzać zarówno pojedynczym zespołem deweloperskim, jak i dwudziestoma takimi zespołami. Nie możemy przeciążać deweloperów pracami organizacyjnymi, pojawiają się zatem dodatkowi koordynatorzy, a wraz z nimi dodatkowe narzędzia i dodatkowe spotkania, bo mimo rozwoju technologii wciąż cenimy sobie kontakt osobisty.

Najczęściej będą to spotkania synchronizujące, monitorujące i raportujące będące wprost skalowaniem wydarzeń mających miejsce na poziomie zespołów deweloperskich. Przykład takiego skalowania może być następujący: Sprint Review [przegląd efektów pracy zespołu] – System Demo [przegląd zintegrowanych efektów prac wszystkich zespołów biorących udział w pracach nad danym systemem] – Solution Demo [przegląd zintegrowanych efektów prac całych programów składających się na duże rozwiązanie].

Mimo, że tematyka danego skalowanego wydarzenia jest podobna, to na każdym poziomie zarządczym potrzebne są inne lub inaczej zagregowane informacje, które służą podejmowaniu różnego rodzaju decyzji. Najbardziej charakterystycznym przykładem takiego skalowania zdarzeń jest PI Planning, czyli planowanie iteracji na poziomie programu, ale o tym parę punktów dalej.

4. Kanbany na każdym poziomie zarządczym

Nie brakuje firm, które zarządzają grupami projektów – programami, portfelami. Najczęściej pojawia się wtedy jakiś lejek do obsługi rodzących się pomysłów na projekty, jakiś system ich priorytetyzacji i kryteria udzielania im zgody na uruchomienie. Problemy, jakie często się wtedy pojawiają, to mało obiektywne kryteria uruchamiania i oceny projektów, mała transparencja mechanizmów, według których zarządzane są projekty na poziomie portfela oraz nie zawsze czytelny mechanizm kaskadowania priorytetów i decyzji z poziomu portfela do poziomu programu, a następnie do poziomu zespołu. SAFe proponuje rozwiązanie, w ramach którego na każdym poziomie zarządczym funkcjonuje Kanban obsługujący pełen cykl życia obiektów na danym poziomie. W SAFie tych poziomów jest 4, a inicjatywy i pakiety prac na nich występujące, to kolejno, zaczynając od poziomu portfela: Portfolio Epic, Capability, Feature i Story.

W waterfallowych organizacjach będą to pewnie portfele, a w ramach portfeli poszczególne programy i ich projekty. Rodzaj i charakter inicjatyw nie jest aż tak istotny. Liczy się to, że w każdym takim Kanbanie odzwierciedlone są kluczowe etapy życia obiektów na danym poziomie, sprecyzowane jest jak te obiekty powinny być opisane na każdym z tych etapów (czyli w każdej z kolumn kanbanowych), jakie są reguły przejścia do kolejnego etapu oraz w jaki sposób dokonuje się ich priorytetyzacji. To z jednej strony tak mało, ale jednocześnie tak wiele. Przykładowe etapy życia Epików, a jednocześnie kolumny Kanbana na poziomie portfela, to: Lejek, Przegląd, Analiza, Backlog Portfela, Implementacja, Zakończone.

Ważnym mechanizmem jest to, że inicjatywy na poziomie portfela, kiedy dojrzeją do etapu Backlog, czyli mają zielone światło na realizację i czekają tylko na swoją kolej (np. ze względu na dostępność zasobów), to ich priorytety ustala się za pomocą metody WSJF. Kolejnym ważnym mechanizmem jest to, że taka inicjatywa zarządzana do tej pory na poziomie portfela (dajmy na to program), gdy przechodzi do etapu Implementacji jest dekomponowana na mniejsze inicjatywy (w tym przypadku niech to będą projekty), co odbywa się już na poziomie programu, gdzie w towarzystwie innych projektów funkcjonują w ramach Kanbana Programu przechodząc analogiczne etapy.

Dojście na poziomie programu do etapu Implementacji oznacza “spadnięcie” do poziomu zespołu, co wiąże się z kolejną dekompozycją, tym razem na pakiety pracy, produkty cząstkowe, etapy, które już faktycznie są realizowane operacyjnie. Oczywiście na wcześniejszych poziomach i na wcześniejszych etapach taka wstępna dekompozycja była realizowana, ale służyła jedynie ułatwieniu estymacji i podjęciu decyzji o przejściu do kolejnego etapu lub uruchomienie, a nie do zlecenia konkretnych prac wytwórczych. Taki mechanizm wydaje się jak najbardziej logiczny, ale niestety bardzo często jest na odwrót – najpierw uruchamia się projekty, czasem niemal hurtowo, a następnie na podstawie różnych kryteriów układa się je w programy i portfele. Nie ma w takich przypadkach kaskadowania strategii na działania, tylko podciągania działań pod kierunki strategiczne (zakładając że, takie zostały w organizacji spisane).

5. Podejście MVP, MMP, do wprowadzania zmian

Agile, a co za tym idzie również Agile w Skali, podkreśla wagę szybkiego dostarczenia MVP (Minimum Viable Product) użytkownikowi, żeby móc możliwie szybko zebrać feedback odnoszący się do używania rozwiązania w rzeczywistych warunkach. Funkcjonuje też określenie MMP (Minimum Marketable Product), które odnosi się już konkretnie do wprowadzenia rozwiązania na rynek i czerpania z niego korzyści finansowych. To jest istota podejścia empirycznego. Nie widzę, absolutnie żadnych przeszkód, żeby kierować się takim podejściem przy projektach klasycznych, bądź przy inicjatywach biznesowych nie będących formalnie projektami. Gdyby zespoły projektowe, Komitety Sterujące i Sponsorzy zawsze myśleli w ten sposób być może uchroniłoby to część projektów od porażki tudzież od nadmiernego palenia zasobów.

6. PI Planning

Nawet jeśli nie mamy do czynienia w danym przypadku z projektami zwinnymi, to bardzo często okazuje się w rzeczywistości, że cele i zakresy na poziomie programu i portfela nie są tak dokładnie zdefiniowane, jak powinno to faktycznie mieć miejsce w projektach waterfallowych. Często roadmapy projektów waterfallowych w swojej szczegółowości nie różnią zbytnio od roadmap agile’owych, choć różni je z kolei “zafixowany” budżet. W takich przypadkach planujemy szczegółowo jedynie najbliższy etap projektu, podobnie jak w Agile’u, gdzie też szczegółowo planujemy jedynie najbliższy sprint, może dwa, czasem trzy, raczej nie więcej. Oczywiście te interwały czasowe są bardzo różne, ale jeśli popatrzymy na Agile na poziomie programu i na planowanie iteracji programu (Program Increment), a następnie porównamy je do wyprzedzenia czasowego, z jakim realnie planujemy w projektach klasycznych, to możemy dostrzec że te horyzonty planistyczne zaczynają wyglądać podobnie.

Oczywiście jeśli przymkniemy na chwilę oko na inne, de facto niezmiernie ważne, aspekty, takie jak zdeterminowany od początku zakres prac versus podejście iteracyjne, czy fixed price projektu vs Lead-Agile Budgeting. W waterfallu często realne i precyzyjne jest planowanie tylko na mniej więcej kwartał, a w Agile’u w skali, często potrzebne jest wybieganie nieco dalej w przód niż na sprint-dwa. To co jest natomiast równie istotne w obu podejściach, to synchronizacja pomiędzy biznesem a developmentem i pomiędzy zespołami deweloperskimi. O tym mówi PI Planning, o którym piszę tutaj i z którym polecam się zapoznać niezależnie od tego, czy realizujemy projekty zwinnie, czy klasycznie.

Podsumowując

SAFe mimo swoich oczywistych intencji może być użyteczny nie tylko dla organizacji zwinnych. Jest co prawda jak najbardziej sposobem na wdrażanie zwinności w skali całej firmy i powinien być wdrażany w miarę możliwości w całości, zarówno narzędzia, procesy i role, jak i lean-Agile mindset. Wtedy ma to największy sens. Tym artykułem chcę jednak pokazać, że od świętej wojny Agile-Waterfall, która niektórych konsultantów angażuje niemal w całości, ważniejsze jest wprowadzenie ładu i transparentności do organizacji realizujących duże przedsięwzięcia, angażujące wiele zespołów. Warto korzystać przynajmniej częściowo z gotowców, oczywiście w sposób przemyślany, bo zaooszczędza to części ogromu pracy, jaką trzeba włożyć w opracowanie własnej metody zarządzania dużymi przedsięwzięciami i ich grupami.