Skalowanie agile, może nie być najlepszym sposobem wdrażania zwinności do organizacji.
LeSS (Large Scale Scrum), Nexus i SAFe (Scaled Agile Framework), to najbardziej popularne frameworki skalujące zwinne wytwarzanie produktów do poziomu grup zespołów lub nawet całych organizacji. O ile w przypadku LeSSa i Nexusa nie mam wątpliwości co do tego, że intencją autorów było przyniesienie na większą ilość osób mechanizmów agile stosowanych w przypadku pojedynczych zespołów, to w przypadku SAFe nie jest to już dla mnie takie oczywiste. Agile w skali traktowany jest przez niego znacznie szerzej.
Owszem pokazuje on jak skalować znane powszechnie role: Scrum Mastera, Product Ownera i Developera:
a także rytuały takie, jak: Sprint Planning, Daily Scrum, Sprint Review i Sprint Retrospective, ale wprowadza też parę mechanizmów adresowanych bezpośrednio do poziomu zarządzania strategicznego organizacją i portfelami projektów. Mechanizmy te nie były do tej pory elementami frameworków agile i w ich przypadku ewidentnie mamy do czynienia z kaskadowaniem wartości i inicjatyw sterujących rozwojem firmy, a nie skalowaniem czegoś używanego do tej pory na poziomie zespołów.
Za najważniejsze z nich uważam:
- Zwinne budżetowanie (Lean, Agile Budgeting)
- Podejście do zarządzania wymaganiami
- Koncepcja rozwiązania (Solution Intent)
Zwinne budżetowanie (Lean, Agile Budgeting)
Agile wywraca do góry nogami klasyczny trójkąt projektowy:
Więcej przeczytasz o tym w dedykowanym artykule:
czytaj więcej …
AGILE CZYLI WATERFALL DO GÓRY NOGAMI
Z sytuacji, w której zakres prac reprezentujący wymagania stanowił punkt odniesienia, a jego pochodnymi, czyli wartościami planowanymi, były koszt i czas realizacji, przechodzimy do środowiska, w którym to wartościami zadanymi są: koszt i czas, a ich pochodną, którą optymalizujemy przy zadanym koszcie i czasie jest zakres przyrostu wartości produktu. Może to wyglądać absurdalnie na pierwszy rzut oka, ale właśnie dzięki zwinnemu budżetowaniu nabiera to sensu. Budżetowane są strumienie wartości, którymi mogą być np. linie produktowe. Budżet na dany strumień, w zadanym czasie, określa nam ilość zasobów, jakie jesteśmy w stanie utrzymywać na zadanym poziomie na dany moment (np. rok, albo dwa). Te koszty poniekąd stają się kosztem stałym. Prace realizujemy w stałych cyklach (sprintach i grupach sprintów zwanych Przyrostami Programu), więc każdy taki cykl będzie charakteryzował się takim samym czasem trwania i zbliżoną pojemnością. Pochodną tego będzie ilość wymagań, jakie zespoły dadzą radę przetworzyć w Przyrost (Increment). Dzięki temu, że nie musimy każdorazowo wyceniać pakietów wymagań, a stabilny wolumen zasobów mamy zagwarantowany, zespoły mogą elastycznie reagować na zmiany wymagań. Unikamy dzięki temu dysfunkcyjnej sytuacji, w której agile ograniczony jest ramami wyznaczonymi przez etapy, kamienie milowe i budżety narzucone planami waterfallowymi i powiązanymi z nimi kontraktami. Dzięki temu nie planujemy z bardzo dużym wyprzedzeniem, tylko budujemy wizję produktu, a w ramach niej, w poszczególnych Przyrostach Programu i Sprintach przygotowujemy szczegółowe plany uwzględniające najpilniejsze i najbardziej potrzebne elementy budujące produkt. Takie podejście do budżetowania wspiera agile w skali i jest niezbędne, jeśli do hierarchizowania backlogów chcemy używać takich metod, jak WSJF (Weighted Shortest Job First), która faworyzuje wymagania o korzystnym stosunku wartości biznesowej do pracochłonności, przez co stymuluje podejście MVP (Minimum Viable Product) i quick-win’ów. Budżety, w tym budżety strumieni wartości, przydzielane są na poziomie strategicznego zarządzania organizacją i kaskadowane w dół do poziomów zarządzania programami i zespołami. Nie jest to wartość wyznaczana podejściem bottom-up.
Wymagania
Wymagania reprezentowane przez elementy backlogów nie są definiowane na poziomie zespołów i skalowane, tylko wynikają z inicjatyw uruchamianych w celu realizacji strategii. Inicjatywy strategiczne, nazywane w SAFe nieco niefortunnie Epics, dekomponowane są na mniejsze wymagania (Capabilities, Features, Stories) i delegowane do realizacji na niższe poziomy zarządcze (kolejno Large Solution, Program, Team). Aby to delegowanie nie było klasyczną dekompozycją tylko zachowało agile’owy charakter, na każdym z poziomów zarządczych funkcjonuje proces Kanban, który zarządza ewaluacją i hierarchizacją wymagań, każdy poziom zachowuje w uzgodnionym zakresie pewną autonomię decydując, w jakiej kolejności będzie realizował zagadnienia. Poniższa tabela przedstawia hierarchię wymagań w SAFe z przypisaniem do właściwych poziomów zarządczych:
W SAFe wymagania nie są tworzone na poziomie zespołów tylko zstępują przez wszystkie poziomy zarządcze od strategii poprzez strumienie wartości i programy do poziomu zespołów na którym są przetwarzane w rozwiązania.
Koncepcja Rozwiązania (Solution Intent)
Bardzo cennym elementem SAFe rozwijanym centralnie dla całego rozwiązania, a następnie kaskadowanym na programy i zespoły jest Solution Intent (tak, wiem, “koncepcja”, nie jest najwierniejszym tłumaczeniem słowa “intent”, ale w tym kontekście wyjątkowo mi pasuje). Stanowi ono repozytorium wiedzy na temat tego, co chcemy wytwarzać w ramach programów agile oraz jak będziemy To budować. Zawiera zarówno całość wymagań biznesowych począwszy od wizji produktu i roadmapy jego rozwoju, jak również dokumentację techniczną od poziomu architektury systemów. Obejmuje opis stanu obecnego oraz plany jego rozwoju. Osoby odpowiedzialne za zarządzanie rozwojem produktów znajdą tam materiały źródłowe stanowiące podstawę do definiowania wymagań, deweloperzy z kolei odnajdą wszelkie modele, projekty i kluczowe ustalenia definiujące, które komponenty systemów zostały zdeterminowane odgórnie przez architektów, a których rozwój podlega autonomicznej decyzyjności zespołów deweloperskich.
Zatem skalowanie czy kaskadowanie?
Skalowane są mechanizmy znane ze Scrum, XP i innych popularnych frameworków agile, regulujące pracę zespołów realizacyjnych, kaskadowane z kolei są te mechanizmy, który nadają agile’owy charakter procesom strategicznym, które w nieskalujących frameworkach nie występują.
Przedstawiłem pobieżnie kluczowe elementy oddające kaskadowy charakter budowania zwinności w organizacjach, szczegóły oraz informacje na temat pozostałych komponentów znajdziesz na oficjalnej stronie opisującej framework SAFe – http://www.scaledagileframework.com/.
Więcej na temat głównych mechanizmów SAFe możesz dowiedzieć się na akredytowanym szkoleniu Leading SAFe, zachęcam do najświeższej jego wersji.
