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 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.
