O SAFe (Scaled Agile Framework)

Garść informacji o frameworku skalującym agile, który przypadł mi jak na razie najbardziej do gustu.

Jakkolwiek jestem otwarty na różne punkty widzenia i bardzo chętnie uczę się nowych rzeczy, to spośród wszystkich znanych mi (czasem pobieżnie) podejść najbardziej przekonuje mnie SAFe. Sprawia na mnie wrażenie najbardziej przemyślanego i kompleksowego. Porusza zagadnienia zwinności z różnych perspektyw i w różnych wymiarach. Nie tylko jestem akredytowanym konsultantem SAFe, ale też używam go w praktyce na co dzień z efektami dużo lepszymi niż jakiekolwiek moje wcześniejsze doświadczenia związane z wdrażaniem zwinności w organizacjach, czy zarządzaniem programami i portfelami. Wydaje się, że nie jestem odosobniony w tych doświadczeniach, bo szukając informacji na temat popularności i ilości implementacji frameworków skalujących agile, jakkolwiek z  doświadczenia jestem ostrożny odnośnie wszelkich publikacji i raportów internatowych, to odnoszę wrażenie, że sporo osób podziela moje przekonania i odczucia.

Poniżej link do jednego z fajniejszych raportów odnośnie stanu agile, a w tym skalowania, według którego SAFe jest najpopularniejszą metodą, choć dopiero raczkującą w Polsce.

 

Zanim przeczytasz co ja sądzę o podstawach SAFe’a, zamiast męczyć oczy tekstem, obejrzyj może krótką, 5 minutową animację.

Poniżej z kolei nieco dłuższy filmik, ale z to po Polsku. Pochodzi z wystąpienia Małgorzaty Czerwińskiej na temat „Skalowanie Scruma przy pomocy Scaled Agile Framework (SAFe®)”.

Scaled Agile Framework, w swojej pełnej wersji, może na pierwszy rzut oka odrzucać, a nawet lekko przerażać, swoją wielkością. To jest jeden z powodów, dla których przez niektórych nazywany jest mało zwinnym. Na szczęście można go wdrażać w jednym z czterech wariantów, co już na starcie pomaga dostosować go do charakteru danej organizacji. Osobiście uważam, że ciężko oczekiwać kompaktowego wydania od frameworka, który wdraża agile’owy sposób myślenia i agile’owe mechanizmy w skali całej organizacji, ma po prostu do obsłużenia wiele ról, wiele obszarów i poziomów, przez co siłą rzeczy musi adresować wiele zagadnień.

Poniżej kluczowe elementy SAFe’a, a jeszcze niżej link do strony szczegółowo, a nawet bardzo szczegółowo, opisującej framework. Nie jest to z pewnością właściwe miejsce do opisywania wszystkich komponentów SAFe’a: ról, procesów, rytuałów, narzędzi, wszystko to widać już na pierwszy rzut oka po wejściu na jego stronę www, chciałem natomiast zwrócić uwagę na te elementy, które nie są tak rzucające się w oczy, a które budują charakter SAFe’a i kulturę Lean-Agile.

Ideologiczne podstawy SAFe

Główne założenia, postawy i przekonania, na których bazują wszystkie komponenty SAFe'owe.

Warstwy
Podstawowe wartości
Nastawienie Lean-Agile

SAFe ma warstwy, jak cebula... i ogry... no dobra, może nie warstwy, raczej poziomy. Ma cztery poziomy zarządcze:

  • Poziom Zespołu
  • Poziom Programu
  • Poziom Dużego Rozwiązania - tak wiem, nieco koślawa nazwa, oryginalne Large Solution Level nie wygląda jednak dużo lepiej, moim zdaniem nazwa z poprzedniej wersji SAFe'a była bardziej trafiona: Value Stream Level - Poziom Strumienia Wartości, najczęściej używam obecnie określenia Solution Level, oddaje charakter tego poziomu zarządzania, a nie kłuje w oczy
  • Poziom Portfela

Każdy z poziomów jest zsynchronizowany z pozostałymi zachowując jednak pewną autonomię wspierającą zwinność. Każdy z nich jest transparentny dla organizacji i uwzględnia mechanizmy agile, np. na każdym poziomie funkcjonuje backlog i kanban. Inicjatywy strategiczne przechodzą przez lejek od pomysłów, poprzez zdefiniowanie do realizacji, a następnie spływają przez wszystkie poziomy podlegając dekompozycji i uszczegółowieniu. Projekty nie pojawiają się dzięki temu z powietrza.

SAFe posiada dużo mechanizmów budujących zwinne i "szczupłe" (ang. lean) podejście do zarządzania rozwojem produktów. Są one dość precyzyjnie opisane w Lean-Agile Mindset i SAFe Lean-Agile Principles wszystkie jednak mniej lub bardziej bezpośrednio korespondują z kluczowymi wartościami. To one powinny przyświecać każdej roli zaangażowanej realizację SAFe'owego portfela. Te wartości, to:

  • Wbudowana jakość
  • Spójność
  • Transparencja
  • Realizacja programu

Poniżej krótko, a nawet bardzo krótko, o każdej wartości.

Wbudowana jakość

Zagwarantowanie wysokiej jakości rezultatów prac powinno być podstawowym elementem każdego dostarczanego przyrostu. Jakość nie może być wartością dostarczaną w osobnych etapach, osobnymi mechanizmami. Musi być rzeczą zagwarantowaną przez zespoły deweloperskie każdorazowo w ramach sprintów. Bez tego nie osiągniemy płynności pracy i nie będziemy w stanie zwinnie reagować na potrzeby biznesu.

Spójność

Zachowania poszczególnych poziomów muszą być ze sobą spójne. Jeśli mamy do czynienia z podziałem obowiązków związanych z zarządzaniem produktem, to rozwój każdego z częściowo niezależnych, ale składających się na duże systemy komponentów (np. produktów cząstkowch), to każdy z nich musi być spójny z inicjatywami strategicznymi organizacji, z wizją rozwiązania i roadmapą jego rozwoju. Każdy dostarczany podsystem musi być spójny z architekturą rozwiązania. Każdy proces musi być zsynchronizowany, mniej lub bardziej, z innymi procesami. W innym przypadku będziemy skalować chaos, czyli suma drobnych odchyleń będzie skutkowała istotną desynchronizacją.

Transparencja

W zwinnym wytwarzaniu produktów liczy się przyrost, rozumiany przede wszystkim jako działające rozwiązanie. Nie zawsze jednak wszystko idzie zgodnie z planem. W takich przypadkach bardzo istotne jest rozumienie mechanizmów dostarczania rozwiązań. Aby można było zrozumieć to, jak realizowane są prace i jak wytwarzane są efekty potrzebna jest transparencja. Zapewnia ona lepszą współpracę na wszystkich poziomach. Obowiązuje nie tylko zespoły deweloperskie, ale także biznes, a nawet poziom zarządzania portfelem. Transparentne i dostępne backlogi oraz kanbany funkcjonują na każdym poziomie SAFe'a.

Realizacja programu

Podstawową cechą wszystkich SAFe'owych zespołów jest umiejętność dostarczania zadeklarowanych efektów. Dużo uwagi przykładane jest do działających produktów i generowanej przez nie wartości biznesowej. Odpowiedzialność za to nie jest przypisana li tylko do zespołów deweloperskich ale skalowana jest przez wszystkie poziomy zarządcze. Sercem SAFe'a jest poziom programu, który bezpośrednio integruje zespoły i wprowadza mechanizmy wspólnego planowania, wytwarzania, monitorowania i uczenia się. Konstruktem obsługującym współpracę między zespołami i biznesem jest Agile Release Train - odpowiednik procesu scrumowego na poziomie programu.

 

Kolejnym poziomem stanowiącym bazę dla mechanizmów SAFe jest nastawienie Lean-Agile. Jest to zbiór kanonów myślenia czerpiący ze szczupłej produkcji i Manifestu Agile. Opisany jest konstruktem o nazwie SAFe House of Lean, na który składają się następujące elementy:

  1. Cel:

Stałe dostarczenie maksymalnej wartości biznesowej w najkrótszym możliwie czasie, przy zachowaniu najwyższej jakości, zarówno użytkownikom naszych rozwiązań, jak i społeczeństwu jako całości. Rezultat ten ma być osiągany przy wysokim morale i poczuciu bezpieczeństwa pracowników. Cel ten wydaje się nieco górnolotny i przekombinowane, ale jeśli spojrzymy na rynek, to największe organizacje mają w swoich misjach dużo więcej niż generowanie wysokich przychodów.

  1. Filary:
    • Szacunek dla ludzi i kultury organizacji
    • Płynność - oznacza stabilność i ciągłość przepływu pracy, stąd też praca w SAFe nie ma charakteru projektowego, oznaczającego wyodrębnione etapy i wyraźne momenty start-stop, tylko przypomina bardziej taśmy produkcyjne o stabilnej konstrukcji (np. możliwie stałe składy zespołów) i przewidywalnej mocy przerobowej
    • Innowacyjność -  nie istnieje coś takiego jak stanie w miejscu. Jeśli się nie rozwijamy, to cofamy się, bo rozwija się nasza konkurencja. SAFe kładzie duży nacisk na wygospodarowanie przestrzeni na prace rozwojowe (szkolenia, nowe pomysły, badania, eksperymenty, itp.) dedykując tej kategorii prac cały sprint w ramach kwartalnego cyklu.
    • Nieustanne doskonalenie - oznacza ciągłe optymalizowanie systemu produkcyjnego, jako całości, a nie tylko skupianie się na jego wybranych komponentach. Wzbudzenie w sobie w pewnym sensie wiecznego poczucia zagrożenia motywującego do wyszukiwania dysfunkcji, odnajdywania ich przyczyn i wprowadzaniu korekt do procesów.
  2. Podstawa:

Fundamentem, na którym stoi SAFe'owy dom jest Przywództwo. Kultura lean oraz agile musi być wdrażana z mocnym wsparciem top managementu, przy pełnym zaangażowaniu i odpowiedzialności, których nie da się delegować.

Pryncypia SAFe

O ile SAFe Core Values i SAFe House of Lean mogą wydawać się mało namacalne, o tyle SAFe Principles jest już czymś bardzo konkretnym. Są to mechanizmy i reguły postępowania, dzięki którym komponenty frameworka (role, rytuały, narzędzia, procesy) używane są zgodnie z przeznaczeniem i w sposób budujący zwinność w organizacji i jej przedsięwzięciach. Stanowią bardzo ważny element SAFe'a, w dużej mierze wyróżniający go na tle innych podejść.

Przyjmij ekonomiczny punkt widzenia
Stosuj myślenie systemowe
Zakładaj zmienność, zachowuj opcje
Buduj przyrostowo w ramach krótkich, zintegrowanych cykli uczenia się
Zamykaj kamienie milowe na bazie obiektywnej ewaluacji działających rozwiązań
Wizualizuj i ograniczaj pracę w toku, redukuj zakresy przyrostów, zarządzaj długością kolejek prac
Wdrażaj rytmiczność prac, synchronizuj w ramach międzydomenowego planowania
Uwolnij wewnętrzną motywację pracowników
Decentralizuj podejmowanie decyzji

Nie jest przypadkiem, że ta zasada jest na pierwszym miejscu. Twórcy SAFe'a podkreślają tym, że nie możemy myśleć o stałym, zwinnym budowaniu rozwiązania jeśli nie realizuje ono założeń finansowych. Jakkolwiek przyczyn porażek projektów jest wiele, to brak finansowania jest jednym z podstawowych.

Wskazane są dwa następujące aspekty tego pryncypium:

  • Dostarczaj wcześnie i często
  • Bądź świadom parametrów kompromisów ekonomicznych na poziomie Programu i Strumienia Wartości

Dostarczaj wcześnie i często

Chodzi o to, żeby nie zwlekać z dostarczeniem do użytkowników elementów, które mogę już przynosić korzyści. Zastanawiamy się zatem, czy jesteśmy w stanie wydzielić z całości projektowanego rozwiązania jakiś element o minimalnym zakresie, ale realizujący częściowe oczekiwania użytkowników na tyle, żeby chcieli je używać. Dostarczamy to MVP, użytkownicy czerpią korzyści z narzędzia, my czerpiemy korzyści z jego dostarczenia, a w międzyczasie rozbudowujemy rozwiązanie. Na banalnym przykładzie z rowerkiem dziecięcym: nie tworzymy komponentów, które dopiero złożone w całość pozwalają na używanie (pierwszy etap to rama i koła, drugi to zębatki, łożyska, łańcuch i przerzutki, w trzecim etapie dodajemy kierownicę i siodełko, pewnie też hamulec... i dopiero teraz możemy jeździć) tylko dostarczamy jak najszybciej coś co jeździ (czyli w pierwszym sprincie prosta, acz potencjalnie rozbudowalna, rama, koła i kierownica... i już mamy hulajnogę, która możemy używać do poruszania się na specyficznych warunkach, potem zmieniamy ramę i koła, dodajemy siodełko i mamy rowerek biegowy, potem modyfikujemy ramę, dodajemy pedały i mechanizm, który napędzają, może zmieniamy kierownicę, dodajemy hamulec i mamy rowerek)... dla uproszczenia przyjmijmy, że z technicznego punktu widzenia to jest wykonalne. 

Bądź świadom parametrów kompromisów ekonomicznych na poziomie Programu i Strumienia Wartości

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.

Produkowane rozwiązanie jest systemem. Organizacja, która je dostarcza też jest systemem. SAFe wyróżnia dwa rodzaje systemów (nazywając je też strumieniami wartości):

  • Operacyjne
  • Deweloperskie

Operacyjne stanowią proces angażujący personel, urządzenia i systemy informatyczne, które obsługują użytkownika od pierwszego kontaktu, do zakończenia jego doświadczenia z produktem, czyli np. od reklamy, poprzez założenie konta, obsługę narzędzia, płacenie abonamentu za usługę, do zamknięcia konta.

Deweloperskie, to procesy które dostarczają, utrzymują i rozwijają systemy, które biorą udział w operacyjnych strumieniach wartości, czyli np. system CRM, kasa, system płatności, produkt (np. serwis www), system windykacyjny.

Usprawnienie systemów ma sens jedynie jeśli patrzymy na ich całość oraz powiązania między nimi, a nie kiedy optymalizujemy ich lokalne odcinki. Dla przykładu: nie ma sensu usprawniać procesy związane z pisaniem kodu i zwiększać ich przepustowość, jeśli wąskim gardłem są testerzy, 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.

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, z czasem jednak może nie być w stanie sprostać aktualnym oczekiwaniom, to koszt zawrócenia z obranej ścieżki może być zbyt dotkliwy. Tym, co wspiera agile, jest 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ń. 

Myśl stojąca za tą regułą jest jednym z tych miejsc, 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 procesie:

zdefiniuj wymagania, zaprojektuj rozwiązanie, wykonaj, przetestuj, wdróż, zbierz feedback

Udają trochę, że nie wiedzą, że jest coś takiego, jak Proof of Concept, czy Proof of Technology, że można projekt klasyczny podzielić 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. Nie mniej jednak faktem jest, że agile bardziej nastawiony jest na iteracyjność i wytwarzanie produktu w możliwie krótkich cyklach, w których zamykamy się ze wszystkimi waterfallowymi etapami, od wymagań do feedbacku. Jednym z powodów jest chęć szybszego osiągania korzyści z, chociażby częściowego, rozwiązania, by następnie je rozbudowywać i czerpać jeszcze większe korzyści. Drugi powód wiąże się z doświadczeniem 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 osobny, a na integrację dedykujemy końcowe fazy projektu. 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 lub dedykowane fazy, ale w agile'u jest na to kładziony szczególny nacisk.

Autorzy SAFe'a, powołując się na historię małej rewolucji Lean w Harley-Davidson (nie bedę spoil'ował, bo jest to użyte w licencjonowanych materiałach szkoleniowych), zauważają że w wielu klasycznych projektach sukces całości przedsięwzięcia nie za bardzo idzie w parze z zamykaniem, z sukcesem, poszczególnych jego etapów. Czyli działa mniej więcej taki mechanizm:

  • wymagania zebrane? zebrane, check, zielona lampka
  • projekt techniczny wykonany? wykonany, mucha nie siada, check, zielona lampka
  • kod napisany? napisany, check, zielona lampka
  • testy integracyjne/testy akceptacyjne? danger, danger, czerwono!, ogień!

Mało tego, okazuje się wręcz bardzo często, iż im więcej lampek na zielono w pierwszych etapach, tym większa porażka na końcu.

Dlaczego tak się dzieje?

Bo zielone lampki usypiają czujność i prowadzą do skupiania mniejszej uwagi na adnym projekcie. A przecież na jakiej podstawie mamy określić np., że zebraliśmy wszystkie wymagania? Bo Zamawiający powiedział "Tak, to już wszystko"? Po czym stwierdzimy, że architektura rozwiązania jest ok? Bo wygląda sensownie? To wszystko jest bardzo subiektywne i może być mylące.

Właściwe podejście

Dopiero weryfikacja, najlepiej przez końcowych użytkowników, działającego rozwiązania na środowisku produkcyjnym, w jego naturalnym otoczeniu, jest w stanie dać nam obiektywny obraz kompletności i jakości dostarczonego rozwiązania. Dlatego SAFe, biorąc w pełni pod uwagę złożoność i skalę dostarczanych rozwiązań, zaleca żeby jak najszybciej doprowadzać do integracji wszystkich komponentów, najlepiej co iterację. Mówi też, w wielu miejscach, o tym żeby możliwie szybko wyjść z MVP na produkcję, żeby jak najszybciej przekazać produkt użytkownikom i zebrać informacje zwrotne, a na ich bazie, już na wczesnym etapie, skorygować dostarczone rozwiązanie oraz jego docelowa wizję. Daje to prawdziwy obraz stanu rzeczy i zmniejsza zakres oraz koszt poprawek końcowych.

 

Multitasking jest zły. Dużo pracy w toku jest złe.

Długie kolejki zagadnień/zleceń/ticketów są złe. Jeśli chcemy robić więcej i szybciej, to wrzucenie większej ilości zagadnień do naszego lejka procesowego nie jest dobrym pomysłem. Lejek się zapcha, częściowo, bądź całkowicie. Większa ilość prace w toku to więcej czasu straconego na przekalibrowanie się, odpowiadanie na maile odnośnie zalegających rzeczy, analizowanie czegoś co i tak jeszcze jakiś czas nie będzie ruszone, monitorowanie obiektów w których nic się nie dzieje i raportowanie tego stanu itd. to wiecej obsługi organizacyjnej, za którą idzie mniej pracy wytwórczej. Wydaje się to mało intuicyjne, ale mniej znaczy więcej. Mniej pracy w toku, to sprawniejszy przepływ tego, co do pracy zostało przyjęte. Można by rzec, że nie ma większej różnicy, czy kolejka zrobi się u deweloperów, czy jeden status przed nimi, ale to błędne myślenie. Nie zawracajmy ludziom głowy rzeczami, których i tak nie mają szans robić a najbliższej przyszłości. Nie łapmy zbyt wiele srok za ogon, bo zbyt wiele będzie nas to kosztowało. Pozwólmy się skupić na tu i teraz. Mechanizmy które dotyczą pojedynczych osób skalują się do poziomu zespołu i do grupy zespołów. Kiedy np. przygotowujesz ważną umowę, to lepiej Ci się pracuje gdy siedzisz nad nią 4 godziny z rzędu, czy kiedy w międzyczasie odpowiadasz na maile, na czacie, odbierasz telefon, odpowiadasz koledze na pytania... itd. Ile wtedy wynosi faktyczny czas spędzony nad dokumentem? 4 godziny? 5 a może 6? Można by tak długo ;] Znasz zapewne pojęcie Flow, stanu w którym pracujesz jak w transie, nie czujesz zmęczenia, nie czujesz głodu i stajesz się hiper-produktywny? Przenieś ten stan na poziom zespołu. Badania mówią, że średnio potrzebujemy około 23 minut żeby powrócić do Flow, kiedy zostaniemy z niego wyrwani. Kalibracja między zadaniami, to bardzo duży koszt.

Świadomość procesu

Aby jednak wiedzieć jak bardzo dotyka nas szkodliwy multitasking, musimy być świadomi tego, jak wygląda proces. Gdzie są wąskie gardła, które zadania zalegają, ile tak naprawdę mamy tej pracy w toku, a ile faktycznie jesteśmy w stanie realizować na raz?

Korekty

Jak już będziemy mieli wierny obraz tego, jak funkcjonują zespoły to możemy zastanowić się jak możemy wstrzyknąć parę usprawnień, bo co innego znać dobre praktyki, a co innego wiedzieć jak je zastosować. Te dobre praktyki, to:

  • ograniczenie pracy w toku (mniej znaczy więcej, szybciej, z szybszym feedbakiem, z szybciej dostarczoną wartością)
  • krótsze kolejki, to sprawniejszy przepływ (do tego też jest cała teoria, na którą tutaj nie ma miejsca, a którą warto poznać)
  • redukcja wielkości przyrostów - im większe mamy przyrosty softu, czyli większa jest ilość funkcjonalności, jakie dostarczamy z każdym kolejnym wydaniem produktu, tym mniejsze koszty transakcyjne (czyli w skrócie koszty dostarczania na kolejne środowiska), ale większe koszty utrzymywania tego przyrostu (więcej pracy w toku, więcej zależności organizacyjnych, bardziej skomplikowane powiązania merytoryczne, trudniejsze testy - koszt obsługi tych relacji zazwyczaj rośnie nieproporcjonalnie szybciej niż wielkość przyrostu, w skrajnym przypadku skala zależności może sparaliżować, ludzi po prostu przestaną ogarniać to co się dzieje). Z kolei mniejsze przyrosty, a co za tym idzie częstsze dostarczanie ich na środowiska, to większy koszt obsługi transportu, czyli więcej pracy dla adminów. Cała zabawa polega na znalezieniu optimum.  

 

 

Zarządzanie projektami to zabawa w kontrolowanie bardzo zmiennego środowiska. Zwłaszcza w agile'u. Zmienne wymagania, zmienny zakres prac, zmienne koszty (to w sumie niekoniecznie, ale o tym więcej w tym artykule), nieznany czas realizacji całości projektu... w całym tym szaleństwie zmienności ustabilizowanie jednej z tych zmiennych jest jak zbawienie. Pomysłem na to jest, między innymi, okiełznanie czasu. Skoro zmieniają się wymagania, to nie jesteśmy w stanie przewidzieć daty końcowej oddania produktu. Możemy jednak ustalić rytm prac. Możemy przyjąć, że zespoły planują i wykonują pracę w cyklach np. dwutygodniowych, zawsze. Możemy też przyjąć, że cała grupa zespołów planuje i wykonuje swoje przyrosty w nieco dłuższym horyzoncie, np. kwartalnym. Ile będziemy mieli takich iteracji, tego tak do końca nie wiemy, wiemy jednak ile będą te iteracje trwały, jakim wolumenem pracy w nich dysponujemy i jak wiele możemy dostarczać każdorazowo. Wprowadzamy tym samym pewną stabilność pozwalającą planować prace w nieco dłuższym horyzoncie i realizować je w ramach danych iteracji z względnym spokojem.

Ważna przy tym jest synchronizacja. Planujemy wspólnie (cross-zespołowo, cross-poziomowo i cross-domenowo), realizujemy wspólnie, razem (a przy tym regularnie i często) przeglądamy zintegrowane rezultaty, wspólnie wyciągamy wnioski i wspólnie wdrażamy korekty.

Czas staje się ustalony, koszt stabilizuje się, zmienną pozostaje tylko wartość jaką dostarczymy w ramach tych parametrów. Nie wiemy z dużym wyprzedzeniem, które to będą funkcjonalności, ale wiemy że w każdej iteracji będą to te, które mają na dany moment najwyższy priorytet biznesowy i są najbardziej potrzebne w całości rozwiązania na tym etapie.

 

Zarządzanie jest często mocno przereklamowane. Realizując ambitne projekty mamy często do czynienia z pracownikami, którzy wiedzą dużo więcej na temat swojej pracy niż managerowie. Jeśli takich ludzi mamy "pod sobą" mnóstwo, to próba ścisłej ich kontroli i ciągania za sznureczki nie jest najbardziej efektywnym podejściem. Życie pokazuje, iż ludzi mądrzy i kreatywni potrafią znaleźć w sobie dużo więcej motywacji, niż może jej zapewnić klasyczne zarządzanie i systemy nagradzania. Im wiedza i doświadczenia są większe, tym od pieniędzy bardziej motywują:

  • chęć rozwoju
  • chęć pokazania się
  • chęć pozostawienia czegoś po sobie
  • chęć zrobienia czegoś pożytecznego dla społeczeństwa
  • dążenie do doskonałości

Jeśli zagwarantujemy takim ludziom bezpieczne warunki pracy (fizycznie i psychicznie), damy przestrzeń, damy nieco zaufania, to zarządzanie stanie się z czasem bardziej współpracą niż machaniem paluszkiem władzy. Ja w swojej pracy, jako Release Train Engineer (taki Scrum Master Scrum Masterów) mam marne szanse na kontrolowanie zespołów, których prace koordynuje w ramach programu.  Nie staram się też "pilnować" Scrum Masterów i Project Managerów, mają tyle obowiązków że to nie ma sensu. Ważniejsze jest to, żeby mieć pewność, że myślimy podobnie, że mamy takie same cele... że zachowaliby się podobnie jak ja bym się zachował, a nawet lepiej, czasem dużo lepiej. Przy takim podejściu można nieraz zostać zaskoczonym odpowiedzialnością, kreatywnością i zaangażowaniem ludzi. O tym jest ta zasada. O wyzwalaniu wewnętrznej motywacji. Tylko tak można dokonywać wielkich rzeczy.

 

To już 9 zasada SAFe'owa, trochę się ich naczytałeś, więc napiszę krótko, zwięźle i na temat. Nie wszystkie decyzje trzeba podejmować centralnie, nie wszystkie jednak można pozostawić w decyzyjności na poziomie zespołów. Cała sztuka by zachowywać się elastycznie i dobierać podejście do charakteru decyzji. Te strategiczne dla programu, czyli mające duży wpływ na budżet, na założenia odnośnie produktu, na współdzielone komponenty i na szkielet architektury podejmujemy centralnie. Te które wpisują się w ramy wizji i architektury, a których podjęcie wymaga znajomości detali na poziomie operacyjnym powinny być decentralizowane. Bez zdefiniowania zakresu samodzielności na każdym poziomie zarządczym nie ma mowy o zwinności, nie ma też mowy o prawdziwej motywacji pracowników, niestety nie ma też mowy o skutecznej realizacji projektów.