Czym jest ScrumBan? No cóż, jak sięgniemy do Wikipedii to znajdziemy takie podsumowanie: Scrumban to podejście do dostarczania produktów zgodne z zasadami Agile, które jest hybrydą Scrum i Kanban. Scrumban został pierwotnie zaprojektowany jako sposób na przejście ze Scrum do Kanban. Tak powstał pomysł na wystąpienie na webinarium Dolnośląskiej Grupy Regionalnej IPMA Polska.

Co w artykule:

• Scrum + Kanban = ScrumBan
• Czym dla nas jest ScrumBan?
• Czy u nas można zastosować ScrumBan? Kontekst organizacyjny.
• Czym jest Scrum?
• Czym jest Kanban?
• Porównanie Scruma i Kanbana
• Co daje nam ScrumBan?

Zapraszam do lektury.

Prezentacja z webinaru IPMA Polska, 10.12.2020.

Kiedy rozmawiałem z kolegami z IPMA o tematyce mojego wystąpienia, to w pierwszej kolejności pomyśleliśmy o SAFe, bo to jest temat który moim zdaniem robi wrażenie i jest zabawą dla dużych chłopców. Nie mniej jednak jest to tematyka dość specyficzna i nie każdy z potencjalnych uczestników konferencji i webinarów IPMA zetknął się z tematyką rozwijania dużych produktów i systemów, zwłaszcza w podejściu zwinnym. Wciąż dla wielu project managerów w Polsce tematyka agile w skali, w tym np. SAFe, jest dość abstrakcyjna. Kiedy jednak zacząłem się zastanawiać na temat tego, co z systemu w którym pracuje na co dzień jest przyjemne, pożyteczne i lekkostrawne, to jest fajnym usprawnieniem, to moje myśli szybko skierowały się do naszego specyficznego podejścia do ScrumBana. Na szczęście chłopaki z IPMy dali się przekonać do tego skromniutkiego zagadnienia i zgodzili się na razie zaparkować temat tłustego SAFe’a.

Na wirtualnym spotkaniu Dolnośląskiej Grupy Regionalnej IPMA Polska, które miało miejsce 10.12.2020 podzieliłem się swoimi doświadczeniami z wypracowania własnego podejścia do ScrumBana. Poniżej slajdy z tego webinara, z komentarzem.

Agile jest modny i sexi. Jest też trudniejszy niż mogłoby się to wydawać na pierwszy rzut oka. Łatwo się o nim czyta, dużo trudniej używa na co dzień, zwłaszcza w dużych środowiskach wytwórczych i w pracy przy złożonych rozwiązaniach. Nie jest trudne znalezienie przewodnika po Scrumie i przykładów jego implementacji. Nie stanowi wyzwania uczenie się o Kanbanie. To już praktycznie klasyka. Ze ScrumBanem jest nieco trudniej. Potocznie jest to połączenie Scruma z Kanbanem, w ramach którego czerpiemy z obu metod to, co najlepsze. Niewiele to jednak mówi tym, którzy rozważają wdrożenie tego podejścia. Można też wyczytać, że ScrumBan polega na tym, że używamy Scruma, ale w ramach sprintu monitorujemy postęp realizacji za pomocą tablicy Kanban. Owszem, wielu z nas tak robi (pewnie na przykłąd każdy kto używa Scruma w Jirze), ale czy na tym polega metoda ScrumBan? Nie sądzę.

Przez większość mojego życia zawodowego nie zaprzątałem sobie głowy roztrząsaniem tego, czym jest ScrumBan, używałem albo Scruma albo Kanbana w zależności od charakteru pracy i wyzwań zespołu. Zmieniło się to, kiedy w wielozespołowym środowisku, gdzie na poziomie zespołu używamy Scruma albo Kanbana a na poziomie programu i portfela SAFe’a, parę zespołów zwróciło się do mnie z takim wyzwaniem:
“Niby mamy Scruma, ale nie za bardzo spełniamy jego założenia. Myśleliśmy o Kanbanie, ale on też nie oddaje charakteru naszej pracy. Rozważamy ScrumBana, bo czujemy że czerpiemy po trochę z obu metod, ale nie wiemy tak dokładnie czym on jest i jak go stosować. Co Ty na to?”

Musiałem zatem zastanowić się, co w ekosystemie, w którym ponad trzydzieści zespołów pracuje nad jednym rozwiązaniem mógłby oznaczać ScrumBan. Nie znalazłem przekonujących mnie materiałów, więc po swojemu, we współpracy z zespołami i ich Scrum Masterami, ułożyliśmy czym dla nas może być ScrumBan.

Prezentacja była poprowadzona mocno z perspektywy praktycznego zastosowania. Mało było w niej teorii Scruma, Kanbana i SAFe’a. Skupiłem się na przedstawieniu naszego charakterystycznego podejścia do połączenia Scruma i Kanbana, zdeterminowanego naszym specyficznym środowiskiem wytwórczym.

Posłużyłem się studium przypadku z mojej współpracy z Trans Group S.A. właściciela platformy transportu drogowego  https://www.trans.eu/pl/

Liczby, które charakteryzują środowisko omawiane podczas wystąpienia, dające zarys obrazu z jakiej skali produkcją mamy do czynienia, to:

• 30, to liczba zespołów pracujących nad jednym rozwiązaniem, z czego 25 stricte deweloperskich a 5 utrzymaniowych, tudzież rozwijających infrastrukturę,
• 2, to liczba dni potrzebne na przeprowadzenie PI Planningu, czyli SAFe’owego planowania iteracji na poziomie programu (takie powiedzmy kwartalne planowanie rozwoju produktu)
• 160+ oznacza ponad 160 (w porywach do prawie 200)  ludzi zaangażowanych w trybie ciągłym w rozwój jednego produktu

Nie jest to jakaś wielka skala, ale jak na jeden dość prosty produkt, to już powoduje pewne komplikacje.

Scaled Agile Framework narzuca pewien sposób funkcjonowania dla grupy ludzi pracujących nad jednym rozwiązaniem (tzw. Agile Release Train na poziomie programu, czy Solution Train na poziomie naprawdę dużych rozwiązań), jednocześnie pozostawiając pewną swobodę wyboru frameworku używanego na poziomie zespołu.

Rysunek przedstawia zrzut z Confluence części planu zespołu na PI; dane zostały zaciągnięte z backlogu zespołu utrzymywanego w Jira. 

Oczywiście mimo pewnej swobody w pracy z backlogiem zespołu, naturalne jest że pracując wspólnie nad dużym, złożonym rozwiązaniem pojawiają się zależności organizacyjne, funkcjonalne i technologiczne. Dlatego plan zespołu na daną iterację na poziomie programu (Program Increment) jest bardzo mocno powiązany z planem całego ART (Agile Release Train), a wręcz jest jego subsydiarną częścią. Przejawia się to nie tylko listą zależności, ale też koniecznością zaplanowania prac dla wszystkich zespołów, wchodzących w skład ART, na wszystkie sprinty danego Program Increment (zazwyczaj 5 lub 6 sprintów). Obrazek przedstawiający część planu zespołu na PI jest specjalnie zamazany, żeby nie obnażać zbytnio tajemnic TG S.A.

Podczas realizacji codziennych wyzwań okazuje się jednak czasem, że założenia metody nie do końca zbiegają się z rzeczywistością i wspólne zaplanowanie przez tyle zespołów wszystkich sprintów dla danego Program Incrementu stanowi pewne wyzwanie, a czasem nawet nie jest możliwe.

Wtedy okazać się może, że tradycyjne narzędzie nie mają zastosowanie i coś trzeba zmienić w podejściu. W naszych przypadku było to uregulowanie sposobu pracy zespołu, które nie jest do końca scrumowy, ani kanbanowy, choć przejawia wybrane cechy obu metod.

Na dobrą sprawę stosując strasznego, skomplikowanego i w ogóle potworzastego SAFe’a wykorzystujemy niemal jeden do jednego założenia Scruma, nie modyfikujemy go zbytnio, bardziej dodając pewne aspekty wynikające ze sporej skali rozwoju naszych produktów.

Zamiast naginać Scruma, weryfikujemy w jakich sytuacjach nie jest on zbytnio aplikowalny.

Kanban stosujemy głównie w zespołach utrzymaniowych, których wyzwania są nieco innej natury, a praca jest zgoła inaczej zorganizowana niż w przypadku zespołów deweloperskich.

Przez to nie możemy tak po prostu przyjąć że zespół, który nie może pracować w Scrumie z automatu przechodzi na Kanbana.

Skoro wiemy, że w niektórych przypadkach nie będzie to ani Scrum, ani Kanban, to pozostaje tylko uregulować czym jest hybryda obu podejść, żeby nie kazała się jakimś wyrwanym spod kontroli potworem.

Ze Scruma wzięliśmy zatem te mechanizmy, które pozwalają na zaplanowanie sprintów (zakres i cel) zapewniając posiadania planu bazowego obejmującego nie tylko prace „własne” zespołu a także zależności, ze szczególnym uwzględnieniem deadline’ów (zazwyczaj z dokładnością do sprintu). Z Kanbana pewien komfort pozwalający na nie planowaniu sprintów, tylko dobieraniu Product Backlog Itemów na bieżąco na bazie mocy przerobowych i priorytetów.

Przykładowa implementacja wyglądać może następująco, w krótkich żołnierskich bulletach:

• Zespół patrzy na wymagania przygotowane dla niego do zaplanowania na Program Increment Planningu
• leci wiązanka @^#%&@#^%@&#^%@
• część rzeczy jest lepiej opisana, część gorzej, część udało się zdekomponować a nawet oszacować, ale część będzie jeszcze doprecyzowywana w locie (tak już drzewiej w tym zespole bywało, to trzeba dorobić wymagania, a tu dodać kryteria akceptacji, a tam nie ma co szacować zanim będzie przygotowana makieta… życie)
• większość jednak nie nadaje się do zaplanowania prac na 5 sprintów do przodu
• jak zwykle spora część wymagań stanowi zależności od innych zespołów
• planujemy więc tylko część prac, które wymagają konkretnych dat dostarczenia (bo na przykład wspierają kamienie milowe w projektach biznesowych), chociażby te daty ograniczały się tylko do tego, czy zrobimy daną rzecz w sprincie 3 czy 4, żeby uzależniony od nas zespół wiedział, czy swoją częścią może się zająć w sprincie 4 czy 5
• dla tej zaplanowanej części prac pilnujemy dat
• nie planujemy jednak sprintów dla całej naszej pojemności, tylko dla tych właśnie kluczowych tematów, resztę PBIów (Product Backlog Item) dopieramy w trakcie realizacji sprintów, gdy pojawia się nam na nie przestrzeń, kierując się priorytetami.

Tak ja rozumiem ScrumBana.

Oczywiście nie bawilibyśmy się w ScrumBana jeśli nie przyniosłoby to nam konkretnych korzyści…

Mała rzecz, a cieszy.

Jak poprowadzić duże, wirtualne planowanie.

Ten wpis jest o przeprowadzeniu konkretnego rytuału SAFe’owego – dużego planowania prac dla wielu zespołów zwinnych na mniej, więcej, kwartał wprzód. Nie mniej jednak nawet jeśli totalnie nie interesuje Cię SAFe, albo wręcz gardzisz nim, to praktyczne wskazówki zawarte w artykule mogą Ci się przydać do przeprowadzenia dużego, wirtualnego planowania.

PI Planning, to kluczowy rytuał w Scaled Agile Framework. Jest ukoronowaniem okresu przygotowania wymagań biznesowych i on jest początkiem kolejnego Przyrostu Programu (Program Increment). Od tego dwudniowego wydarzenia, oraz od poziomu przygotowania do niego, zależy to jak dobrze zdefiniujemy i zaplanujemy pracę dla wszystkich zespołów składających się na Agile Release Train, a w dużej mierze też to, co dowieziemy w najbliższym PI’u.

Twórcy i praktycy SAFe, w tym ja, mocno zachęcają, aby w ramach PI Planningu wszystkie zaangażowane osoby spotkały się w jednym miejscu. Pomaga to w synchronizacji, ułatwia komunikację, wyrównuje poziom wiedzy. Bardzo często jest też dobrą okazją do spotkań integracyjnych. Są firmy, w których współpracownicy i kontrahenci realizujący wspólnie duży system widują się na żywo jedynie podczas PI Planningu, na co dzień pracując w odległych lokalizacjach. Zdarzyć się jednak może, że będziemy zmuszeni poprowadzić to spotkanie, lub podobne, częściowo lub w całości zdalnie. W moim przypadku tym powodem było oddelegowanie przez zaangażowane firmy wszystkich osób biorących udział w programie na home office z powodu epidemii koronowirusa.

Czy da się PI Planning efektywnie przeprowadzić zdalnie? Uwaga, spoiler alert – da się ;] Poniżej dzielę się moimi spostrzeżeniami i dobrymi praktykami.

8 wskazówek pomocnych przy realizacji zdalnego PI Planningu

1. Spisz wszystko, co istotne

Żeby takie wirtualne spotkanie mogło być zrealizowane efektywnie powstanie zapewne sporo reguł, procesów, wytycznych, wskazówek, zasad, porad, dokumentów, zestawień, planów, harmonogramów, agend itp., itd. Część z nich będzie dość oczywista i intuicyjna, część z nich może już dawno została wymyślona i tylko wystarczy je przypomnieć, albo się do nich odnieść, jakaś ich część będzie jednak zapewne mniejszą lub większą nowością. Tak czy siak, jeśli to wszystko nie będzie zebrane w jednym miejscu i rozpowszechnione, to nie będzie to stosowane podczas PI Planingu i cały misterny plan w … się rozjedzie. Miej plan, spisz go, udostępnij i upewnij się, że dotarło to do ludzi.

2. O wszystkim przypominaj

Spisałeś co trzeba, podlinkował gdzie należy, więc możesz spać spokojnie… nie, nie możesz. To że to zrobiłeś może mieć małe znaczenie. Ile byś nie włożył w te przygotowania atencji, to ludziska mogą to przeoczyć, nie zrozumieć, zapomnieć, olać, a może po prostu spisałeś tak wiele rzeczy, że nie szło tego zrozumieć, może wkradły się jakieś błędy, które wybuchną Ci w twarz w krytycznym momencie. Komunikuj zatem kluczowe punktu PI Planningu wielokrotnie, ustaw automatyczne powiadomienia, jeśli masz taką możliwość, wyznacz strażników w krytycznych obszarach, ale też powtarzaj się. To nic, że wszyscy wiedzą, że o 13:00 macie telco Scrum of Scrums, przypomnij o nim wszystkim zainteresowanym na 15 minut przed spotkaniem i podeślij linka do video-konferencji. Przesada mówisz? Może, ale każda wirtualna wpadka może być mega trudna do opanowania, po co ryzykować.

3. Zrób mapę wirtualnej przestrzeni

Gdzie znaleźć zespół Avengers podczas standardowego PI Planningu? To oczywiste, w ich pokoju. A gdzie ich znaleźć na zdalnym PI Planningu? No cóż, w chmurze. Jeśli pracują zdalnie od jakiegoś czasu, to mają pewnie swój chatroom zespołowy, albo eventy w kalendarzu, do których się wdzwaniają. Twoja organizacja ma już zapewne wdrożone standardy pracy zdalnej, ale czy poszczególne zespoły i osoby znają narzędzia innych zespołów. Czy są one ujednolicone? Czy darmowe wersji komunikatorów nie kończą się np. na 5 użytkownikach? Czy nadają się do pracy wielu osób? Zrób mapę, gdzie można znaleźć zespoły i ludzi, jakich czatów używają i jak się do nich najlepiej wbić. Wirtualna przestrzeń może być dużo mniej intuicyjna niż pokoje i korytarze firmowe. Bądź pomocny w tych poszukiwaniach.

4. Przetestuj wydajność narzędzi do pracy grupowej

Używacie np. Slacka do zdalnych Daily Scrumów? Super, dlaczego by go nie użyć do refinementu ważnej funkcjonalności podczas PI Planningu? A może zaprosimy wszystkich do pokoju slackowego na wystąpienia Prezesa odnośnie wpływu strategii organizacji na produkt i najbliższy Program Increment? Świetnie…, a wiesz jaki jest limit uczestników na Slacku, Hangout Meet, Workplace by Facebook, Skype, itp.? Sprawdź upewnij się, że narzędzie pociągnie planowane spotkanie, że ma odpowiednie funkcjonalności, jak np. udostępnianie pulpitu, czy automatyczna autoryzacja uczestników. Nie daj się zaskoczyć w krytycznym momencie tym, że n-ty ważny uczestnik nie może się wdzwonić do konferencji.

5. Przygotuj boardy, raporty, zestawienia i automatyzuj wszystko, co się da

W codziennej rzeczywistości biurowej ściany pokoi zespołów deweloperskich potrafia wyglądać bardzo ciekawie. Backlogi, kanbany, impact mapy, mind mapy, zestawienia, przypomnienia… raczej nie przenosimy tego wszystkiego do domu na czas pracy zdalnej. Skąd zatem wiemy, że jesteśmy gotowi do planowania, że storki spełniają DoRy, że wszystkie istotne ficzery trafiły do zespołów do zapoznania się? Jak szybko sprawdzimy, który Product Owner musi się jeszcze spiąć z ostatnimi szlifami, gdzie brakuje makiet, na którym architekcie wisi epic w analizie technicznej, który Scrum Master nie ogarnął zależności, jakie eskalowane tematy utknęły na RTE? Nie ma wspólnych śniadań, czy pizzy, nie ma wyjść na fajkę, nie ma przypomnienia sobie o czymś podczas mijanki na korytarzu. Nagle znika sporo naturalnych mechanizmów komunikacyjno-koordynacyjnych. Te wszystkie rzeczy znaleźć się w Jirze, Asanie, MS Project’cie, na Share Point’cie, na Confluence i co tam jeszcze używacie na co dzień albo od święta, a do ich tworzenia i utrzymania musi być przyłożona szczególna atencja. Im więcej da się z tego zautomatyzować, tym większa szansa, że dane będą kompletne, aktualne i spójne.

6. Moderuj kluczowe spotkania

W którym miejscu znajdziemy streaming wystąpienia będącego gwoździem programu? Czy zaczynamy punktualnie, czy jeszcze czekamy na spóźnialskich? Czy już można zadawać pytania? Kto ma teraz głos żeby się nie przekrzykiwać? Czy pytania zadajemy na głos w trakcie, czy na koniec, a może piszemy je na czacie? Jeśli mamy telco na powiedzmy 160 osób, a na PI Planningu to nic nadzwyczajnego, to porządek będzie bardzo potrzebny, żeby nam się to wszystko nie rozjechało. Przebiegnie to dużo sprawniej, jeśli ktoś będzie moderował. Upewnij się, że wszyscy wiedzą gdzie i o której będzie spotkanie, zweryfikuj czy masz już wszystkich obecnych, przynajmniej tych kluczowych, rozpocznij, prowadź, podsumuj, zakończ, przerwij jeśli trzeba, udzielaj głosu, wyciszaj jeśli trzeba, “wywołuj do tablicy”, aktywizuj uczestników.. Ty sam wyświetlaj kluczowe dokumenty, boardy, raporty, a żeby było sprawniej użyj całego arsenału swoich facylitatorskich armat. Wiele takich wirtualnych spotkań będzie realizowanych równolegle, ale Ty skup się na kluczowych, a tam gdzie nie dasz rady upewnij się, że będzie na nim jakiś inny moderator. Bądź przy tym zdecydowany i twardy jak żelki z Biedronki.

7. Nie dopilnujesz wszystkiego, wspieraj się SMami

Pamiętasz/znasz historię kapitana atomowej łodzi podwodnej? Chciałbyś mieć pewność, że wszystko jest pod kontrolę i dołożysz do tego wszelkich starań, ale czy jesteś w stanie pomyśleć o wszystkim i wszystkich? Czy jesteś w stanie wszystkiego dopilnować? Czy wiesz lepiej od zespołu, kiedy, z kim i w jaki sposób najlepiej przeprowadzić refinement backlogu? Wiesz to najlepiej z całego Agile Release Train? Wątpliwe. Nie ma potrzeby, żebyś był SPOCkiem* albo SPOFem**. Przekaż ludziom cel i intencję, daj im narzędzia, a jeśli chcesz dodatkowo się zabezpieczyć, to zaangażuj Scrum Masterów/liderów zespołów, takie krytyczne chwile są właśnie tymi momentami, w których powinna ujawnić się ich prawdziwa wartość.

8. Naprawdę zapomnij o tych przeklętych karteczkach

Na dobrą sprawę powinieneś był zapomnieć o post-it’ach i analogowych tablicach już dawno temu. Powinieneś też zapomnieć o jakimkolwiek przeklepywaniu danych z backlogów zespołów na dodatkowe boardy, arkusze, prezentacje. Niezależnie od poziomu fizyczności kontaktu uczestników PI Planningu, wszystkie zestawienia potrzebne do koordynacji prac zespołów na wyższych poziomach zarządzania powinny generować się automatycznie na podstawie tego, jak rozplanowane zostały backlogi zespołów (product backlogi i sprint backlogi). Szkoda czasu na dublowanie wpisów na przełączanie, ręczne uzupełnianie. Nonsensem też byłoby wysyłanie jakiś fotek tablic naściennych. To nie są zabawki przy produkcji dużych rozwiązań.

To pewnie nie jest pełna lista sztuczek, które powinieneś nosić ze sobą w rękawie na takie wydarzenia, ale powinny pomóc. Takie “rozproszone spotkanie” wcale nie musi być mniej efektywne od konwencjonalnego, trzeba być tylko świadomym jego specyfiki i odpowiednio się do niego przygotować. To w którym brałem udział zostało ogólnie bardzo pozytywnie ocenione przez uczestników, do tego stopnia, że część rozwiązań zostanie wdrożonych w kolejnych PI Planningach, nawet tych na których będziemy mogli spotkać się twarzą w twarz. Ta nadzwyczajna sytuacja wymusiła na nas podejście na nowo do tematu PI Planningu. Wdrożenie części mechanizmów rozważaliśmy wcześniej, ale brakowało nam jakiegoś decydującego impulsu. Intuicyjnie podejrzewaliśmy, że można sporo czasu zaoszczędzić nie ściągając wszystkich zdalnych zespołów do jednej lokalizacji na czas eventu, ale brakowało decyzji. Tą decyzję podjęło za nas życie, ale wygląda na to że dłuższej perspektywie skorzystamy na tym.

Powodzenia ;]

*SPOC – Single Point of Contact
**SPOF – Single Point of Failure

… te średnie też.

Rejestrując grupę na pierwsze w tym roku szkolenie SAFe, już w nowej wersji, SAFe 5.0, zauważyłem że z uzbierała mi się już całkiem pokaźna gromadka 119 SAFe’rów ;] Mam tutaj na myśli tylko tych, którzy zdecydowali się na akredytowane szkolenie i podejście do egzaminu. Głównie Liderzy Agile, Product Managerowie i Product Ownerzy oraz Scrum Masterzy. Myślę, że to dość sporo, biorąc pod uwagę to, jak świeży jest to temat w Polsce oraz to, że na takie szkolenia nie chodzi się samemu z ciekawości tylko jest wysyłanym przez firmy, które decydują się na spróbowanie tego podejścia.  Pierwsza 100 zatem za nami, a przed nami? Coś czuję, że to będzie rok skalowania agile i SAFe’a ;]

Jak monitorować i rozliczać projekty agile.

Wyzwanie w monitorowaniu projektów zwinnych

Zwinne podejście do realizacji projektów stawia do góry nogami klasyczny trójkąt projektowy (czas, zakres, koszt) przy okazji podważając zasadność stosowania klasycznego podejścia do monitorowania i rozliczania prac (np. Analiza Wartości Wypracowanej). Z pomocą przychodzi miernik  – Program Predictability Measure. Jest to kolejny z ciekawych mechanizmów używanych przez SAFe i propagowanych przez niego, a mogących być z powodzeniem stosowanych w oderwaniu od SAFe’a.

Monitorowanie realizacji projektów i ich końcowe rozliczanie jest w waterfallu dość łatwe. Mamy zdefiniowany oczekiwany rezultat, mamy plan który uwzględnia kluczowe zmienne: czas realizacji, zakres prac i budżet. Na bieżąco rejestrujemy odchylenia od tego planu, które akceptujemy tworząc nowy plan bazowy lub przyjmujemy do wiadomości odnotowując jak bardzo oddaliliśmy się od pierwotnego celu. Projekty oczywiście bywają bardzo złożone i wtedy dużo energii kosztuje nas liczenie tych wartości, ale ich konstrukcja jest banalnie prosta.

Z projektami zwinnymi, tudzież ogólnie ze zwinnym rozwojem produktów, jest dużo trudniej. W tym przypadku nie fixujemy się tak mocno na zakresie prac, ba, nawet sam cel może być dość płynny. Podobnie pływa nam czas i koszt realizacji. To, co stanowi podstawę naszego funkcjonowania to stały rytm prac i cykliczne dostarczanie coraz większej, sprzedawalnej wartości na bazie aktualnych priorytetów. Dokładniej opisałem ten mechanizm tutaj:

Próby stosowania klasycznego sposobu monitorowania i rozliczania projektów, w tak zmiennej konfiguracji czasu realizacji, zakresu i kosztu jest koszmarem. Przynajmniej dla mnie. Z uwagą przyjrzałem się zatem wskaźnikowi Program Predictability Measure, który daje bardzo ciekawą alternatywę, mimo iż jest dość wymagający i specyficzny.

Czym jest Program Predictability Measure?

Jak sama nazwa wskazuje Program Predictability Measure odnosi się do:

po pierwsze – programu (a konkretniej zwinnego programu, czyli zbioru prac zdecydowanie większego niż Sprint, a nawet projekt)

po drugie – jego przewidywalności

Dlaczego Program Predictability Measure a nie “Sprint Predictability Measure”? Jeśli w naszych projektach zwinnych koncentrujemy się na sprintach i to one stanowią kluczową jednostkę naszego cyklu PDCA (Plan Do Check Adapt, tak, tak, celowo napisałem Adapt zamiast Act ;]) to Sprint Goal i Increment są świetnymi wartościami, które mówią nam o relacji zamierzeń do efektów. W dużej skali chcemy jednak monitorować w dłuższym horyzoncie niż dwu-, czterotygodniowym. Dlatego interwałem do którego będziemy się odnosić jest Program Increment, który agreguje kilka sprintów i pozwala nam stawiać sobie i realizować większe cele integrujące prace wielu zespołów zwinnych. O Program Increment i PI Planningu możesz poczytać tutaj:

Stosując Program Predictability Measure porównujemy zatem plan na Program Increment z jego wykonaniem. A konkretniej będziemy porównywać cele Program Increment (PI Objectives) do poziomu ich realizacji.

Co istotne, aby nadać celom wartości liczbowych, nie posługujemy się ich pracochłonnością, tylko wartością biznesową, jaką dostarczają. W związku z tym, rozliczając cel “Obsługa płatności internetowych”, nie będziemy porównywać liczby zadań, roboczodni, czy Story Points, tylko oczekiwaną przez biznes, versus dostarczoną przez zespoły, wartość biznesową.

Wzór wygląda następująco:

Program Predictability Measure  = Delivered Business Value/Planned Business Value*100%

Oczekiwana wartość metryki PPM to od 80 do 100 procent. Jeśli PPM mieści się w tym przedziale oznacza to, że zespół realizujący program jest przewidywalny i wiarygodny. Wiarygodny nie w rozumieniu stosunku estymowanej pracochłonności do faktycznie włożonej pracy, czy zaplanowanego czasu realizacji do faktycznego czasu trwania zadań, tylko oczekiwanej wartości, jaka zostanie dostarczona interesariuszom do faktycznej wartości wytworzonego Przyrostu. Zlecając mu prace w trybie zwinnym możemy z dużym prawdopodobieństwem zakładać, że dostarczy on zadeklarowaną wartość biznesową, nawet jeśli w trakcie realizacji zmieni się zakres zadań lub pojawią się inne pomysły na sposób implementacji funkcjonalności. Czas realizacji (w rozumieniu rytmu pracy i timeboxów) mamy zadany, koszt pracy również jest znany bo wiemy ile kosztować nas będzie dana iteracja, to czym gramy, to zakres prac, a celem nie jest odbębnienie roboczogodzin, tylko wytworzenie wartościowego rozwiązania.

Wyznaczanie Program Predictability Measure

Nie wchodząc na razie w pikantne szczegóły, sposób wyznaczania PPM jest następujący:

Definiujemy cele iteracji (Program Increment)

Dodajemy cele drugorzędne, które będą stanowiły dla nas bufor, do nich jeszczę wrócę

Przypisujemy celom oczekiwaną/planowaną wartość biznesową

Na koniec iteracji oceniamy dostarczoną wartość biznesową dowiezionych (lub nie dowiezionych) celów

Sumujemy wartości i wyznaczamy metrykę Program Predictability Measure

Jak widać przy liczeniu PPM przy dostarczonej wartości biznesowej bierzemy pod uwagę cele drugorzędne, a przy oczekiwanej nie, w związku z tym wyliczenia wyglądają następująco:

Program Predictability Measure  = Delivered Business Value/Planned Business Value*100%

Program Predictability Measure  = 20/23*100% = 87%

Nie dam sobie nic za to uciąć, ale podejrzewam, że w trakcie czytania pojawiły się u Ciebie takie pytania:

1. Jak wyznaczamy Business Value?
2. Dlaczego przy dostarczonej wartości biznesowej bierzemy pod uwagę cele drugorzędne, a przy oczekiwanej nie?

Wyznaczanie Business Value

Bazowanie na Wartości Biznesowej jest tyleż ciekawym i atrakcyjnym konceptem, co kontrowersyjnym i bardzo trudnym w implementacji. Business Value nadawane jest dla obu rodzajów celów, zarówno PI Objectives jak i Stretch Objectives, przez Właścicieli Biznesowych i jest ich subiektywną oceną w skali 1 do 10. Pomysł żeby w zwinnym środowisku rozwijania produktów bazować przy ocenianiu nie na ilości włożonej pracy, poświęconego czasu, na koszcie, czy odzwierciedleniu planowanego pierwotnie zakresu, tylko na dostarczanej wartości biznesowej, jest świetny. Motywuje to do koncentrowania się na rezultacie i maksymalizacji wartości rezultatu zamiast na trzymaniu się planów, które z czasem mogą okazać się nieaktualne, źle skonstruowane, bądź bazujące na błędnych założeniach. Problem z BV polega jednak na tym, że wartość ta jest subiektywną oceną Właściciela Biznesowego, a co za tym idzie może być mało zrozumiała i trudna do wyjaśnienia interesariuszom. SAFe niestety nie pomaga zbytnio w nadawaniu tej wartości, nie instruuje jak to robić …. a przynajmniej nie wprost, ale ciekawe podejście do określania wartości biznesowej można zaczerpnąć z WSJF (Weighted Shortest Job First), które jest metoda priorytetyzacji backlogów. Samą metodę opisuję tutaj:

To co moim zdaniem można próbować z niej wyciągnąć w kontekście kwantyfikowania Business Value, to potraktowanie Cost of Delay jako Business Value. Po małej modyfikacji, możemy na przykład przyjąć, że wzór na Business Value jest następujący:

Business Value =  User Value + Time Criticality + Risk Reduction and/or Opportunity Enablement

gdzie poszczególne parametry mogą przyjmować następujące wartości:

User Value – od 0 do 4

Time Criticality – od 0 do 3

Risk Reduction and/or Opportunity Enablement od 0 do 3

Przy tych wartościach maksymalna suma może wynieść 10 czyli tyle, ile autorzy SAFe’a przewidują dla Business Value. Jak widać przyjąłem nieco większą wartość maksymalną dla parametru User Business Value (a konkretnie 4, a nie tak jak dla innych 3), żeby nadać wagę wartości użytkowej dostarczanej użytkownikowi końcowemu. Oczywiście takie podejście nie rozwiewa wątpliwości, jak nadawać wartości poszczególnym parametrom dla poszczególnych celów, ale w takiej postaci Business Value jest już trochę bardziej zrozumiałe i transparentne. Możemy wykorzystać metodę WSJF do jeszcze jednej rzeczy. Wartość biznesową poszczególnych celów możemy nadawać w sposób komparatywny, patrz akapit “Praktyczne wyliczanie wskaźnika WSJF“ w artykule o WSJF:

Stretch Objectives

Podczas liczenia Program Predictability Measure przy wartości planowanej nie uwzględniamy Wartości Biznesowej celów drugorzędnych (tzw. Stretch Objectives).

Realizacja tych celów jest planowana, a prace związane z ich dowiezieniem pojawiają się w backlogach zespołów. Przyjmujemy jednak, że nie oczekujemy od zespołu realizacji wszystkich celów, zarówno PI Objectives, jak i Stretch Objectives, wystarczą same PI Objectives, by móc uznać że jesteśmy w pełni zadowoleni z efektów pracy zespołu. Stretch Objectives stanowią więc automatycznie bufor na nasze prace. Jeśli realizacja celów głównych staje się zagrożona, to zespół poświęca na ich realizację więcej sił, kosztem Stretch Objectives.

Istnieje parę przypadków, w których rekomendowane jest potraktowanie danego celu, jako Stretch Objective, możemy wśród nich wymienić następujące:

• nie mamy wystarczających informacji do wypracowania wiarygodnych estymacji
• powiązany z celem zakres prac dotyka mało znanych technologii
• istnieje duże ryzyko zmiany wymagań biznesowych dla danych elementów rozwiązania

Takie podejście do wyznaczania celów wpływa na funkcjonowanie zespołu  na parę sposobów :

• zespół może dowieźć wszystkie PI Objectives i żadnego Strech Objective i uzyskać ocenę PPM wynoszącą 100%
• zespół może uzyskać ocenę 100% nawet jeśli nie zrealizuje w całości celów głównych ale za to dostarczy odpowiednio wysoką wartość biznesową celów drugorzędnych (tak, wiem, wydaje się do bezsensowne, co to za cele drugorzędne skoro mogą zastąpić cele główne, a zespół wciąż będzie oceniany wysoko i chwalony? zaraz to wyjaśnię
• zespół dostarczając odpowiednio dużą wartość PI Objectives i Stretch Objectives może, i jest to całkiem realne w tym modelu, dostarczyć sto ileś procent normy (historia zatacza koło? ;] )

Żeby Stretch Objectives pełniły swoją rolę, powinno się trzymać następujących zasad:

• praca związana z ich realizacją nie powinna stanowić więcej niż 10%-15% posiadanych przez zespół mocy przerobowych
• planujemy ich realizację tak samo, jak planujemy realizację celów głównych, nie zakładamy już na starcie, że zrobimy je jak nam starczy czasu, po godzinach lub w tzw. międzyczasie
• ich dowiezienie ma mniejszy priorytet niż PI Objectives

Kiedy warto używać Program Predictability Measure?

PPM jest bardzo ciekawą metryką oddającą zwinny charakter rozwoju produktów. Koncentruje się na dwóch krytycznych dla interesariuszy aspektach: przewidywalności planów i wartości biznesowej. Przewidywalność jest tutaj specyficznie rozumiana, bo odnosi się ją nie do zasobów, czy harmonogramu, tylko do dostarczanej wartości biznesowej. Ta specyfika jest wielkim atutem tego wskaźnika, ale jest też jego największą wadą. Jest on praktycznie nieużywalny w organizacjach, która na danym etapie rozwoju produktu nie są w stanie powiązać wymagań biznesowych z korzyściami, jakie przynosi ich realizacja. Jeśli natomiast posiadamy produkt, w którym dostarczanie użytkownikowi jego kolejnych wersji jest związane z monitorowaniem rezultatu, jaki przynosi, mierzonego w jakikolwiek sposób (przychód, wskaźnik zadowolenia, współczynnik pobrań itp.) to będziemy posiadali fajne narzędzie dające dużo cenniejsze informacje, niż odchylenie od harmonogramu bazowego, bądź zakładanych kosztów.

Podobieństwa i różnice między inicjatywami na poziomie portfela projektów.

Kiedy brałem udział w szkoleniu Implementing SAFe przygotowującym do roli SAFe Program Consultant nasz trener Joe Valone (takie Danny de Vito w wersji IT) nie miał ze mną łatwego życia. Bardzo chciałem poznać SAFe’a tak dobrze, jak tylko się dało podczas tych czterech dni, a dodatkowo motywował mnie fakt, że szkolenie kosztowało z grubsza 12000 PLN… no za taką kasę, to już naprawdę głupio byłoby nie wycisnąć z trenera całej wiedzy, jaką mógłby się potencjalnie podzielić. Chciał, czy nie chciał. Wierciłem mu zatem dziurę w brzuchu o różne rzeczy, między innymi o projekt, a wyglądało to mniej więcej tak:

Ja: Joe, a gdzie w SAFie są projekty?

Joe: Nie ma w SAFie projektów.

Ja: Acha… no ale jak to? Nie może nie być. Taka kobyła? Tyle poziomów zarządzania, tyle domen zaangażowanych, tyle zespołów, no wiesz, software development i w ogóle… i nie ma projektów?

Joe: No nie ma.

[po jakiś czasie]

Ja: A ten cały Agile Release Train to nie projekt przypadkiem? Wygląda mi to nieco jak projekt. Taki duży projekt.

Joe: Nie, to jest program. Agile Program.

Ja: Acha….

[jakiś czas później]

Ja: Joe, a czy …?

Joe: Nie to też nie jest projekt! W SAFie nie ma projektów!

[później na tym samym szkoleniu]

Joe: To jest Portfolio Epic [patrząc na mnie, a przynajmniej taka jest moja wersja, że mówiąc to patrzył mi prosto w oczy]. Co prawda w SAFie nie ma projektów, ale jeśli istniałyby to byłyby nimi Portfolio Epiki Można powiedzieć, że to takie SAFe’owe projekty.

Ja: ;]

O samych Epicach w rozumieniu SAFe’owym możesz przeczytać tutaj:

Epic

więc nie będę się bardzo rozpisywał szczegółowo na temat ich konstrukcji. Niestety na potrzeby zrozumienia tego artykułu będziesz musiał zapomnieć o tym czym w powszechnym rozumieniu zwinnego zarządzania wymaganiami jest Epic, bo SAFe podchodzi do niego dość specyficznie, wprowadzając przy tym niemałe zamieszanie.

Bez zbędnej beletrystyki zatem, poniżej znajdziesz wypunktowane argumenty, które według mnie świadczą o tym, że Portfolio Epic, czyli Epic zdefiniowany i zarządzany na poziomie portfela projektów i programów, to zwinny projekt i tak można go traktować w codziennej pracy z agile w skali.

Jest dużą inicjatywą powoływaną na poziomie portfela projektów.

Portfolio Epic jest zmianą, której zainicjowanie odzwierciedlone jest w Kanbanie Portela i na tym poziomie jest on definiowany, analizowany, szacowany, priorytetyzowany w sąsiedztwie innych Portfolio Epiców, aż uzyskuje zgodę na uruchomienie i czeka w Portfolio Backlogu na swoją kolej w realizacji. Specyfika SAFe’a, a konkretnie Pryncypium mówiące o decentralizacji podejmowania decyzji (Decentralize Decision Making) oraz mechanizm skalowania ról, przekłada się na to że zanim taki Portfolio Epic trafi do backlogów zespołów zostanie po drodze zdekomponowany na Capabilities, Features, Stories i Enablers, a na każdym poziomie zarządczym te wymagania nabiorą lokalnych kontekstów i będa konkurowały z innymi elementami dedykowanych danym poziomom backlogów. Nie mniej jednak rola Epic Ownera będzie czuwała nad spójnością tych działań z pierwotną intencją Epica.

Posiada coś na kształt Project Business Case

Tak jak w Project Management Body of Knowledge w wersji 6 (PMBoK 6ed.) pierwszym poważnym dokumentem określającym kontekst i potrzebę biznesową jest Project Business Case, tak jego SAFe’owym odpowiednikiem jest Epic Hypothesis Statement. O ile ten pierwszy nie jest jakoś specjalnie ściśle zdefiniowany, o tyle w przypadku tego drugiego autorzy proponują zwięzłą formatkę bardzo dokładnie określającą jakie informacje są potrzebne na tym etapie, układając ją w dość przyjemną formę. Prosty szablon Epic Hypothesis Statement wygląda następująco:

Przypomina nieco styl User Story, który prowadzi nas za rękę? Jako….., chciałbym……, żeby…. Intencja jest podobna – żeby jak najbardziej uprościć sposób definiowania podstawowych założeń biznesowych, a jednocześnie żeby nie pominąć kwestii zasadniczych. Przykładowo taki Epic Hypothesis Statement mógłby wyglądać następująco:

Dla klientów korzystających z wielu naszych produktów,

którzy są zmuszeni do tworzenia nowych kont użytkownika każdorazowo, kiedy nabywają nową aplikację webową z naszej oferty

proponowane rozwiązanie, czyli* jedno konto logowania do wszystkich produktów

jest uproszczonym mechanizmem autentykacji naszych klientów,

który pozwala użytkownikom na logowanie się do wszystkich oferowanych przez nas aplikacji za pomocą jednego konta użytkownika

W przeciwieństwie do rozwiązań, które wymagają tworzenia osobnych kont dla każdego z produktów

nasze rozwiązanie będzie wymagało od użytkownika posiadania jedynie jednego konta, za pomocą którego będzie logował się do wszystkich naszych produktów, które będą mu udostępniane na podstawie wykupionych przez niego usług. Takie rozwiązanie uprości użytkownikowi sposób logowania, zwiększy bezpieczeństwo, a przy okazji uporządkuje naszą bazę klientów i naszą wiedzę odnośnie używanych przez nich rozwiązań.

*to zamiast “the” ;]

Kolejnymi elementami, już nie tak ciekawymi w sposobie formułowania, ale nie mniej pożytecznymi w kontekście definiowania Portfolio Epica są:

• Hipotezy odnośnie spodziewanych korzyści biznesowych
• Wstępne propozycje mierników
• Wymagania niefunkcjonalne

Zdefiniowanie hipotez odnośnie potencjalnie możliwych do osiągnięcia korzyści biznesowych, z podkreśleniem tego, że na tym etapie możemy co najwyżej domniemywać ich pojawienia się w przyszłości, jest istotą podejścia zwinnego. W kontekście Portfolio Epiców objawia się ono tym, że nie będziemy definiować projektu od A do Z, tylko pokornie godzimy się z faktem, że rzeczywistość biznesowa jest czasem mało przewidywalna, a proces tworzenia oprogramowania też potrafi mocno zaskakiwać nawet bardzo mądrych i doświadczonych ludzi. Staramy się zatem zdefiniować MVP/MMP (Minimum Viable Product, czasem inaczej nazywane Minimum Marketable Product), które pochłonie minimalną konieczną ilość nakładów, a jednocześnie będzie stanowiło rozwiązanie nadające się do użycia i sprzedaży. Dopiero realny feedback z rynku, nie głos biznesu, nie wyobrażenia UXów, nie interpretacja programistów i testerów, pokaże nam na ile nasze założenia są słuszne. Wtedy będziemy podejmowali decyzje o dalszym rozwoju produktu lub jego zredefiniowaniu, bądź nawet zagrzebaniu. Ten cykl wygląda następująco, niech Cię nie zwiedzie słowo “startup”, tu nie chodzi stricte o uruchomienie nowych biznesów, tylko “startupowe” myślenie:

Jest zdefiniowany w Karcie Projektu

Mimo, że zakres Portfolio Epica nie jest tak ściśle zdefiniowany, jak w przypadku klasycznego projektu (o różnicy między podejściem sterowanym planem, a tym opartym o wartość biznesową pisałem w tym artykule https://project-management.pl/agile-czyli-waterfall-do-gory-nogami/), to nie można powiedzieć, że Portfolio Epic jest uruchamiany na łapu-capu. Dokument definiujący jego podstawowe założenia, cele i intencje – Lean Business Case (do pobrania tutaj https://www.scaledagileframework.com/epic/ ) mimo że z definicji powinien być lekki, to zawiera nie mniej informacji niż Project Charter w postaci, w jakiej funkcjonuje w większości znanych mi organizacji. Leanowość nie polega w tym przypadku na uszczupleniu dokumentacji, tylko na zdefiniowaniu MVP rozwiązania i postawieniu hipotez odnośnie oczekiwanych korzyści oraz zaproponowaniu sposobów weryfikacji ich osiągnięcia.

Lean Business Case składa się z niemałej liczby pozycji więc nie będę tu ich przepisywał, zachęcam do zapoznania się z szablonem.

Zarówno Lean Business Case, jak i Karta Projektu (czy też Project Charter) definiują intencje, cele biznesowe oraz na bardzo ogólnym poziomie główne produkty Portfolio Epica/Projektu, ale tutaj pojawia się największa różnica…

Portfolio Epic nie posiada Planu Projektu

W przypadku klasycznego projektu, zanim dostanie on zielone światło, przygotowywany jest jego plan opisany w dużo bardziej złożonej i precyzyjnej dokumentacji –  w Planie Projektu integrującym poszczególne plany subsydiarne, takie jak: plan zarządzania wymaganiami, zakresem, harmonogramem, w tym harmonogram bazowy, kosztami, w tym budżet bazowy, interesariuszami, jakością, zakupami, ryzykiem itd. W przypadku Portfolio Epica nie jest to konieczne. Zakres prac nie musi tak ściśle zdefiniowany. Częściowo będzie on odkrywany w miarę tworzenia rozwiązania i weryfikowania założeń. Dając zatem Portfolio Epicowi zielone światło nie ryzykujemy tak wiele, jak w przypadku projektu waterfallowego, dzięki skupieniu się na pracy w ramach szybkich cykli uczenia się i weryfikacji hipotez.  Ba. Zielone światło nie jest de facto równoznaczne z uruchomieniem realizacji Portfolio Epica, mówi tylko o tym że trafia on do statusu BACKLOG (oznaczającego w tym przypadku inicjatywy ocenione pozytywnie i przeznaczone do realizacji bez dodatkowej analizy opłacalności), a dopiero tam przeprowadzany jest jego scoring wykonany przy metodzie WSJF (Weighted Shortest Job First, o której piszę tutaj https://project-management.pl/wsjf-czyli-krotsze-znaczy-lepsze/), a wynik zadecyduje o tym, w której kolejności będzie on realizowany.  W SAFie nie tworzy się ścisłego planu projektu, tylko dekomponuje go na wymagania agile’owe i deleguje je do niższych poziomów zarządzania, by odpowiedni ludzie, kolejno: Solution Management, Product Management, Product Owners, zdefiniowali rozwiązanie w swoich backlogach i dostarczali kolejne przyrosty budujące MVP…. ale to już temat na niezupełnie inną historię…

I co z tego?

No dobra, niech mi będzie że Portfolio Epic, to Projekt, ale co z tego wynika, na co to się przekłada, co to znaczy w kontekście wdrażania podejścia agile w organizacjach? Otóż znaczyć może bardzo wiele. Ja widzę Portfolio Epic jak pomost łączący nie tylko strategię organizacji z dostarczanymi rozwiązaniami, ale też świat waterfallowy z agileowym. Jeśli Portolio Epicowi blisko do zwinnego projektu, to jednocześnie blisko mu do projektowego sposobu myślenia, czyli takiego który zachęca do zdefiniowania założeń przedsięwzięcia, jego celów, oczekiwanego efektu końcowego i możliwie dokładnie ścieżki dojścia. Od tego wszystkiego Portfolio Epic różni głównie tak ścieżka dojścia, gdyż zamiast skupiania się na przewidzeniu zakresu, koncentruje się na stawianiu weryfikowalnych hipotez, zdefiniowania MVP i wypracowaniu mechanizmów uczenia się i wyciągania wniosków. W założeniu zatem Portfolio Epic daje top managementowi wyraźny kontekst biznesowy, cele i korelację ze strategią oraz zgrubną roadmapę, a następnie szybką, rynkową weryfikację założeń, natomiast Product Managementowi i Zespołom Deweloperskim odpowiedni poziom autonomii w kreowaniu rozwiązania. Dzięki temu może być kluczowym elementem we wdrażaniu agile na każdym poziomie organizacji, zwłaszcza w miejscach gdzie myślenie waterfallowe jest bardzo mocne i może być przeszkodą.

Różnica między agile, a agile w skali.

Często zdarza mi się, że potrzebuję komuś szybko, w prosty sposób, zilustrować różnicę między zwinnością wdrażaną w pojedynczych zespołach lub projektach, a agile funkcjonującym w całej organizacji. Nie za bardzo potrafię. Jak tylko zaczynam rysować proste schematy, to zaraz dodaję do tego masę ról, procesów i narzędzi, aż robi się z tego niezła kobyła, która odstrasza. Na dodatek muszę zawsze okrasić rysunki taką ilością objaśnień, że ciężko mi utrzymać uwagę rozmówcy. Ale staram się. Pracuję nad tym, a poniżej efekt jednej z kolejnych prób.

Poniżej same proste schematy, tylko ikonki i parę nazw, zero objaśnień, żadnej legendy, ani słowa komentarza. Abstrahuję przy tym od konkretnych frameworków skalujących agile. Porównanie jest czytelne i zrozumiałe lub nie. To już Ty ocenisz ;]

Agile w skali zespołu

Agile w skali organizacji

Agile a Scaled Agile

Autonomia zespołów agile’owych w organizacjach.

Mam przyjemność ugościć miejsca na moim blogu na artykuł praktyka SAFe – Tomasza Czechowskiego, fana skalowania i budowania zwinności w organizacjach, który na co dzień pełni rolę dumnego ojca i skromnego Release Train Engineer’a (skromność jest chyba naturalną cechą w tym zawodzie). Tomek dzieli się swoimi spostrzeżeniami odnośnie autonomii zespołów zwinnych. Krótko i konkretnie, bez zadęcia i tonu wykładowcy, za to szczerze, od siebie i prosto z agile’owego pola walki.

Zapraszam do lektury.

„Autonomia zespołów agile’owych w organizacjach”, Tomasz Czechowski

Głównym czynnikiem, który decyduje o osiągnięciu mistrzostwa w jakiejś dziedzinie nie są wrodzone zdolności, ale zaangażowanie w rozwój. Najlepiej celowe. Tak twierdzi Robert Sternberg, wybitny psycholog, autor trójczynnikowej koncepcji inteligencji. Według niego nie zawsze Ci, którzy na początku byli najinteligentniejsi, okazują się najinteligentniejsi na końcu. Celowe zaangażowanie w rozwój jest wspierane przez nastawienie rozwojowe, według którego sprawność intelektualną osoby lub zespołu można rozwijać przez pracę i zastosowanie właściwej strategii.

Zespoły software’owe w organizacji mogą mieć różne poziomy autonomii, tworząc jeden większy produkt. Ta autonomia jest rozumiana jako zdolność do samoorganizacji i podejmowania najlepszych decyzji w drodze do osiągnięcia celu (inkrementu działającego oprogramowania, implementacji nowej funkcjonalności, czy naprawy wąskich gardeł w rozwoju produktu). Autonomią może też być zdolność do wpływania lub budowania roadmapy i definiowania feature’ów. Z drugiej strony, przykładem niskiej autonomii jest rodzaj pracy zespołu, który jest kontrolowany przez bardziej doświadczony management lub reprezentantów właściciela firmy (osoby posiadające budżet projektowy), a decyzje projektowe są narzucane z góry poprzez przełożonych bez wcześniejszej konsultacji. Obydwa podejścia mogą mieć mniejsze lub większe nasilenie i występować w różnych cyklach życia projektów i dojrzałości zespołów.

Scaled Agile Framework (SAFe) podkreśla ważność autonomii jednostek i zespołów jako jedno z podstawowych narzędzi do wspierania i motywowania pracowników organizacji opartej na wiedzy. Mówi o tym zasada nr 8 Unlock the intrinsic motivation of knowledge workers, czyli wyzwól wewnętrzną motywację wykwalifikowanych pracowników. SAFe, cytując książkę Daniela Pinka „Drive”, mówi, że pracownicy, w szczególności w organizacjach opartych o wiedzę, mają potrzebę autonomii do wyznaczania własnego kierunku i samoorganizacji. Dawanie ludziom coraz większej autonomii do działań, które powinny współgrać z wysokopoziomowym celem organizacji, oraz wyznaczanie wymagań projektowych z minimalną listą ograniczeń jest ważną odpowiedzialnością liderów organizacji.

Nie jest jednak prawdą, że zespoły w imię autonomii same wyznaczają kierunek swojej pracy, podpierając się priorytetami wyznaczonymi przez Product Ownera. Takie autonomiczne zespoły realizują funkcjonalności zgodne z Roadmapą produktu, którą z dużą starannością przygotowuje zespół produktowy (Product Management i Product Ownerzy). Za ostateczną priorytetyzację funkcjonalności w skalowalnej zwinnej organizacji powinna odpowiadać jedna osoba — Product Manager lub Product Owner. Zespoły planują swoje zadania i historyjki, natomiast Product Manager lub Product Owner specyfikuje Epiki i Ficzery. Pokazuje to poniższy wykres.

Źródło: https://docs.microsoft.com/en-us/azure/devops/learn/agile/scale-agile-large-teams

Wyznaczenie i respektowanie linii autonomii wzmacnia dojrzewanie zespołów, ich motywację oraz zacieśnia współpracę z zespołem Product Management. Jednak zmiana w drugą stronę, czyli niepewna lub zmienna linia autonomii może spowodować niższe morale i obniżoną satysfakcję zespołów oraz może prowadzić do utraty bardziej doświadczonych inżynierów.
Kontrowersyjny jest również temat planowania roadmapy — jeśli zespoły planują pracę w sprintach podczas PI Planningu (na 5 – 6 sprintów), to jak może wyglądać ustalenie roadmapy w czasie? Niestety SAFe niewiele mówi na ten temat, gdyż budowanie nowych hipotez biznesowych odbywa się na bieżąco, sprint po sprincie, natomiast ich weryfikacja jest podczas demo oraz release’ach dla klientów. Jednak co w sytuacji zamawiania kilku większych funkcjonalności — ich dokładne oszacowanie w czasie nie jest możliwe lub jest bardzo kosztowne, więc praktyka z dużych i średnich organizacji pokazuje, że dostarczanie takich funkcjonalności można określać w sposób bardzo przybliżony, np. w kwartałach, czy półroczach. Pokazuje to poniższy wykres- odpowiedzialność za zakres i zgrubny czas realizacji.

Źródło: https://docs.microsoft.com/en-us/azure/devops/learn/agile/scale-agile-large-teams

Powyższa wizualizacja planowania ma swoje odzwierciedlenie w SAFe — zespoły co sprint (2 – 3 tygodnie) robią backlog refinement,  zespoły w porozumieniu z managementem robią planowanie inkrementu (2 – 3 miesiące), Product Management buduje krótko i długoterminowe plany produktu (0.5 – 1.5 roku).

Elementem spajającym taką współpracę jest zaufanie pomiędzy zespołami, a managementem. Management wyznacza plany dla zespołów i ufa, że zespoły będą je realizować, a zespoły implementują plany zgodnie z wyznaczonymi priorytetami. Bez zaufania nie będzie funkcjonować wyznaczona granica autonomii, która służy do wzrostu organizacji, zespołów i jednostek.

Co na to Scrum… (Tomek Włodarek z #AgileRebels) tylko zespół określa, ile jest w stanie dostarczyć pracy. Nikt, oprócz zespołu, nie powinien określać, ile funkcjonalności zespół jest w stanie dostarczyć. To dopiero mocno wyznaczona linia autonomii, którą znajdziemy w Scrum Guide.

Obserwując i współpracując z kilkoma organizacjami, widziałem różne poziomy autonomii (rozumianej jako niezależność i decyzyjność) zespołów software’owych (wliczając Product Ownera) i ta autonomia nie zawsze zależała od dojrzałości zespołów, ale od całej kultury organizacji. Niektóre zespoły uznawane były za mocne i posiadały sporą autonomię, pokazaną przez zaufanie zarządu, oraz wpływ na kierunek rozwijania produktu, ale widziałem też zespoły z niską i modyfikowaną autonomią. Takie zespoły niestety nie miały wspieranej postawy rozwojowej, o której pisałem w pierwszym akapicie. Brak ustalenia linii autonomii lub brak odpowiedniej współpracy z zespołem powoduje podtrzymywanie niedojrzałości zespołu oraz potrzebę ręcznego sterowania. Takie sterowanie generuje więcej pracy po stronie managementu, który czasami ma w tym swój interes i czuje się bardziej potrzebny… a na pewno przydaje się podczas kryzysów projektowych.

Wyznaczcie linię autonomii zespołom, jeśli chcecie żeby były zmotywowane i wspierajcie ich proces dojrzewania. Dzięki temu będzie więcej wolnego czasu dla zarządu, aby się zrelaksował i skorzystał z przerwy w pracy 🙂

Tomasz Czechowski, RTE

O roli Scrum Mastera, bardzo subiektywnie.

Nie przekonuje mnie koncepcja Scrum Mastera przedstawiona w Scrum Guide. Doceniam wagę tej roli, szanuję ideę samoorganizującego się zespołu, wiem jak ważna jest osoba pomagająca w implementacji Scruma, rozumiejąca go, pomagająca stosować jego mechanizmy, ale to i pozostałe obowiązki opisane w Scrum Guide, to zawsze było dla mnie za mało. Zawsze oczekiwałem, od siebie, od Scrum Mastera, od agile, czegoś więcej. Więcej dla zespołu deweloperskiego, więcej dla współpracujących z nim zespołów, więcej dla organizacji. Na pewno można do tego podejść lepiej.

Niedopowiedzenia są groźne

Uważam, że Scrum niesie ze sobą tyleż dobrego ile zagrożeń. Przez to, że charakter roli SMa jest zwięźle opisany, pozornie łatwy do zrozumienia, a bez wątpienia trudny do opanowania, kusi do stosowania skrótów, dając przy tym spore pole do interpretacji. Scrum Guide definiuje tę rolę, przede wszystkim, jako odpowiedzialną za to, żeby Scrum był rozumiany i stosowany. W kolejnym zdaniu dodaje, że realizujemy rolę SMa dbając o to, żeby Zespół Scrumowy stosował teorię, praktyki i zasady Scruma. Podkreślając postawę lidera służebnego, używając parokrotnie zwrotów coaching, wsparcie, pomoc, buduje u wielu z nas przekonanie, że celem i misją Scrum Mastera jest nauczanie Scruma w zespole i organizacji, a warsztat narzędziowy sprowadza się głównie do coachingu. W długiej perspektywie ma to być może szansę zadziałać, a przy dojrzałych, samoorganizujących się, bardzo kompetentnych i czujących odpowiedzialność zespołach deweloperskich, wierzę że taka rola, coacha, consigliere lub czujnego mentora, wspierającego nieco z boku, jest cenna. Kiedy jednak zespoły nie wypracowały jeszcze w sobie tych cech, brak mocnego, trzymającego rękę na pulsie i potrafiącego skutecznie zareagować lidera powoduje, że projekty stają się zagrożone. Zwłaszcza duże projekty, realizowane przez wiele zespołów. Inicjatywy o charakterze projektowym funkcjonują najczęściej pod presją czasu. W związku z czym cierpliwe budowanie dojrzałości, odpowiedzialności, a przy tym pozwalanie na uczenie się zespołów na własnych błędach, to często za mało by istotnie przyczynić się do ich sukcesu.

Skąd taka dziwna nazwa w tytule?

Mając w głowie swoją prywatną wizję, nowego lepszego SMa, zacząłem nazywać go kiedyś Scrum Masterem 2.0. Świetna nazwa. Od razu wywołuje powiew świeżości, nowoczesności, kojarząc się z dążeniem do perfekcji… szkoda tylko że zajęta. Na dodatek rozumiana inaczej niż bym sobie tego życzył. Dobre nazwy są ważne. Krystalizują przekaz. Budzą oczekiwane skojarzenia. Więc może Scrum Master 2.1? 3.0? Scrum Master Pro? Scrum Master Na Sterydach? Po chwili przyszła mi do głowy nazwa Scrum Master Turbo*. Może nie do końca oddaje ideę i z pewnością nigdzie się nie przyjmie, ale za każdym razem wywołuje u mnie uśmiech na twarzy ;]

Czym zatem różni się Scrum Master Turbo od Scrum Mastera jakiego zna większość z nas?

Różnice o których piszę zgrupowałem w trzy obszary:

• odpowiedzialność
• warsztat narzędziowy
• skalowanie agile

Odpowiedzialność

Firmy sprzedające usługi programistyczne lubią przekonywać zamawiających, że warto im ufać. Coraz częściej podpisywane są tzw. zwinne umowy produkcji oprogramowania, gdzie mamy do czynienia z czymś pomiędzy umową o konkretne dzieło, a umową wynajmu pracowników. Czasem ładnie się to nazywa wynajmem zespołów. Bardzo często dochodzi do sytuacji, w której zamawiający stawiany jest w mało komfortowej sytuacji – nie może oczekiwać konkretnego efektu prac, bo projekt jest realizowany zwinnie, czyli bardziej precyzyjnie planowane są co najwyżej cele sprintów i zakresy, natomiast produkty etapowe, kamienie milowe i efekty końcowe są poza odpowiedzialnością wykonawcy. Nie może również kontrolować jakości pracy programistów, no bo przecież to wykonawca zarządza swoimi ludźmi. W skrajnie niefortunnie przygotowanych umowach zamawiający ma właściwie więcej twardo zdefiniowanych obowiązków (m.in. dostarczanie na czas wymagań, terminowe płacenie za … no właśnie, często po prostu za etaty) niż firma realizująca dla niego projekt (za produkty nie odpowiada, za poziom profesjonalizmu, rzetelność i terminowości prac również niekoniecznie, często niestety odpowiada po prostu za dostępność specjalistów). Opisane dysfunkcje są oczywiście skrajnością, ale jestem przekonany że niejeden czytelnik ma teraz twarz wykrzywioną w gorzkim uśmiechu zrozumienia.

W każdej sytuacji, w której mamy ograniczone możliwości rozliczania zespołów deweloperskich z dowożonych efektów prac nasze zaufanie do tak zwanej odpowiedzialności zbiorowej (a może raczej rozmytej) jest mocno ograniczone. Wtedy czujemy się dużo pewniej, jeśli możemy liczyć na to że w zespole jest lider, który ma duże poczucie odpowiedzialności, radar ustawiony na ryzyka i przejmuje inicjatywę jeśli widzi że zespół jest na kursie kolizyjnym, a nie widać przesłanek że sam sobie z tym poradzi. Nie czas wąchać róże, gdy płoną lasy. Przestrzeń na rozwój, naukę, możliwość popełniania błędów musi istnieć, ale priorytetem powinno być zawsze dowożenie celów projektów. W takiej sytuacji coaching to za mało, potrzebna jest trafna ocena sytuacji i działanie. Trudno oczekiwać od Scrum Mastera, że podejmie działania takie, jakie podjąłby Kierownik Projektu, bo nie ma zazwyczaj takiej siły sprawczej, ale może z kolei, i powinien, analizować, sygnalizować, przypominać, upominać, trąbić na alarm, a kiedy trzeba eskalować. Rzecz w tym, żeby w takich sytuacjach był bardziej “leader” niż “servant”, powinien działać wtedy, gdy inni udają że nie ma problemu, albo zamiatają go pod dywan.

Warsztat narzędziowy

Scrum Master Turbo musi być kimś więcej niż trenerem, coachem i konsultantem. Sukcesy realizowanych projektów będą mocno uzależnione od jego umiejętności facylitacji, zdolności komunikacyjnych, warsztatu analitycznego i znajomości narzędzi do zarządzania projektami/zadaniami. To on wspiera Product Ownera w definiowaniu wymagań i ich mapowaniu, to on pokazuje zespołowi, jak je dekomponować i jakich technikami szacować. Scrum Master jest odpowiedzialny za poprawność implementacji procesów i narzędzi, więc rzadko kiedy znajdzie się lepsza osoba, do wsparcia Product Ownera w pielęgnowaniu backlogu produktu. Prawdopodobnie nikt inny nie podniesie alarmu, kiedy w Jirze/Asanie/Redminie zrobi się bałagan. Do niego będzie też należało definiowanie i monitorowanie wskaźników. Scrum Masterzy, jakich każdy chciałby mieć w swoich zespołach muszą posiadać nie tylko wiedzę i doświadczenie, ale też sprawność w posługiwaniu się projektowym orężem. Podwijają rękaw i idą w ogień, kiedy zespoły załamują ręce przygniecione ilością danych w excelu, zawiłości map procesów, kiedy trzeba zmierzyć zjawiska pozornie niewymierne. Są mistrzami w używanych przez daną organizację narzędzi do zarządzania zadaniami – potrafią dostosować Redmine pod swój zespół, przez sen są w stanie pisać zapytania JQL, konfigurować workflow, atrybuty obiektów i konstruować dashboardy. Z nieludzką cierpliwością potrafią przedzierać się przez gąszcz zadań, historyjek, funkcjonalności, epików i zaprowadzać porządek tam, gdzie panuje chaos. Biorą markera w dłoń i podsumowują czytelnie spotkanie, podczas którego uczestnicy gubią się już w zawiłościach zależności i nie pamiętają po co przyszli.

W arsenale ma też narzędzia miękkie, działające w obszarze postaw, wartości, interakcji międzyludzkich, nimi też powinien sprawnie się posługiwać. Zarządzanie konfliktami, słuchanie ze zrozumieniem, facylitacja spotkań, o tych narzędziach Scrum Mastera nie możemy zapominać.

Skalowanie agile

Waga roli Scrum Mastera rośnie jeszcze bardziej, kiedy mamy do czynienia z agilem w skali. Gdy do poziomu zespołów dochodzi poziom programu, w którym mamy ograniczoną możliwość podejmowania działań synchronizacyjnych z bezpośrednim zaangażowaniem wszystkich zespołów w jednym czasie, kluczowej roli nabiera to, w jaki sposób zespoły reprezentowane są “na zewnątrz”. Żeby takie spotkania jak planowanie iteracji na poziomie programu, Scrum of Scrums, czy retrospektywy programu przynosiły realną wartość, Scrum Masterzy reprezentujący swoje zespoły w programie, ale też reprezentujące program na poziomie zespołów, muszą bardzo dobrze orientować się w bieżących pracach deweloperskich, ich postępach, efektach i problemach na jakie natrafiają. Muszą także sprawnie poruszać się w zagadnieniach programowych i produktowych, takich jak wizja całościowego rozwiązania, roadmapa rozwoju, harmonogram wdrożeń.

LeSS wyróżnia następujące obszary aktywności Scrum Mastera:

• zespół
• Product Owner
• organizacja
• praktyki deweloperskie

Scaled Agile Framework pokrywa te same obszary precyzując przy tym zakres obowiązków Scrum Mastera:

•wsparcie dla liderów lean-agile, pomoc we wdrażaniu podstawowych zasad zwinności i szczupłej produkcji i implementacja mechanizmów SAFe’a

• wsparcie w przestrzeganiu zasad obowiązujących zespoły, takich jak zwinne praktyki deweloperskie, np. wbudowana jakość
• facylitowanie postępów zespołu w realizacji postawionych celów, np. poprzez przedstawianie narzędzi i technik zwiększających przewidywalność, produktywność i zwinność
• wdrażanie w zespołach ciągłego doskonalenia
• facylitowanie spotkań, tych wewnętrznych zespołowych i programowych
• wsparcie dla Product Ownera w pracy z backlogiem i agilem
• usuwanie przeszkód blokujących zespół będących poza zasięgiem samego zespołu
• budowanie efektywności zespołu
• reprezentowanie zespołu w kontaktach z interesariuszami i jego ochrona przed niekontrolowanym zlecaniem prac
• koordynacja z innymi zespołami w ramach realizacji programu
• wsparcie estymowania, np. poprzez nauczanie technik i facylitowanie spotkań

To co zdecydowanie różni SAFe’a i LeSS’a w rozumieniu roli Scrum Mastera, to podejście do koordynacji – LeSS bardzo wyraźnie mówi “Nie koordynuj prac pomiędzy zespołami”, SAFe natomiast zachęca do tego. Bazując na własnych doświadczeniach i obserwacjach, bliższe mi podejście SAFe’owe, uważam że przy produkcji rozwiązań w dużej skali i występowaniu wielu zależności pomiędzy zespołami taka pomoc Scrum Mastera jest potrzebna. Zespół jest w stanie wiele ogarnąć we własnym zakresie na bazie współpracy deweloper-deweloper, ale przy złożonych rozwiązaniach lepiej jest częściowo ściągnąć im ten ciężar z barków i dać więcej przestrzeni na kodowanie. W SAFie tą koordynacją zajmuje się dodatkowo Release Train Engineer, taki Scrum Master Scrum Masterów, zwany też pieszczotliwie Uber Scrum Masterem… jest też zwany Wielkim Facylitatorem (przez nielicznych na szczęście ;] ).

Z własnego, wyskalowanego, podwórka

Najcenniejsze zachowania SMów angażujących się mocno w prace synchronizacyjne zespołu zespołów, jakie ja zaobserwowałem w mojej pracy z agilem w skali, to między innymi:

• bezpośrednia, mocna koordynacja prac paru zespołów, stanowiących część programu, ale realizujących grupę szczególnie powiązanych komponentów – mapowanie zależności, facylitacja wspólnych spotkań, wsparcie w synchronizacji backlogów, identyfikacja, monitorowanie i eskalacja kluczowych ryzyk;
• tworzenie i monitorowanie metryk programu
• tworzenie współdzielonych standardów i nadzór nad ich przestrzeganiem, nie tylko w ramach własnych zespołów

Podsumowując rolę Scrum Mastera w zwinnym zarządzaniu dużymi inicjatywami

Tak według mnie wygląda i zachowuje się Scrum Master, którego chcą mieć zespoły deweloperskie, ludzie odpowiedzialni za zarządzanie produktem, top management i cała organizacja. Taki, którego warto szukać na rynku i za którego warto płacić tyle, ile zazwyczaj słyszę w oczekiwaniach finansowych, na rozmowach rekrutacyjnych. Najfajniejsze w tym wszystkim jest z kolei to, że tacy SMowie istnieją i miałem już przyjemność pracować z takimi (i dalej mam) ;]

Oczywiście Scrum Guide nie zabrania nikomu posiadać te wszystkie kompetencje, realizować takie zadania i prezentować tego typu postawy, niemniej nie uważam, żeby tak widział tą rolę i zachęcał swoich odbiorców do działania w ten sposób. Na szczęście profesjonalni Scrum Masterzy przekraczają w swojej codziennej pracy granice poszczególnych frameworków i dobrych praktyk.

*Jeśli w kontekście nazwy tej roli słowo “Turbo” kojarzy Ci się z gumą Turbo, albo z Power Rangers Turbo, to hańba Ci. Jeśli natomiast bardziej kojarzy Ci się z wypalanymi synapsami i “Mona Lisa Turbo”… to jesteśmy w domu ;]

O szkoleniach SAFe i ich roli we wdrażaniu metodyki.

Strategię implementacji SAFe’a, zalecaną przez jego autorów, można uprościć do stwierdzenia: przeszkol liderów, zidentyfikuj strumienie wartości i Pociągi Wdrożeń (Agile Release Trains), przeszkól zespoły agile’owe i uruchom pierwszy pociąg (ART). Zachęca się, aby organizacje przeprowadzały wdrożenia własnymi siłami i zamiast bazować na konsultantach zewnętrznych opierały tą trudną zmianę na osobach, które znają specyfikę danego środowiska od podszewki. Wychodzi się z założenia, że szybsze, łatwiejsze, efektywniejsze i ogólnie korzystniejsze jest nauczenie własnych pracowników mechanizmów SAFe’a niż konsultantów uczenie organizacji. Przy takim podejściu, szkolenia SAFe nabierają szczególnej wagi. Dlatego też katalog usług i produktów Scaled Agile Inc. jest wypełniony programami szkoleniowymi i materiałami do pracy własnej, a nie usługami doradczymi.

Poniżej wszystkie szkolenia SAFe ułożone w sugerowanej kolejności wdrażania.

Opisy są krótkie i prezentują moje subiektywne opinie na ich temat, przy każdej pozycji znajduje się dodatkowo odnośnik do materiałów źródłowych.

Nazwa szkolenia: Implementing SAFe

Nazwa certyfikatu: SAFe Program Consultant

Grupa docelowa: Konsultanci SAFe

Opis z mojej perspektywy, jako SPC:

Jest to bardzo nietypowe szkolenie mocno odstające od większości szkoleń z frameworków, jakie możemy znaleźć na rynku. Implementing SAFe kształci konsultantów mających cechować się zarówno znajomością mechanizmów SAFe’a, jak i doświadczeniem w pracy z agile pozwalającym na operacyjne przeprowadzenie wdrożenia w organizacji. Jest to intensywny 4-dniowy trening, w formule train the trainers, kończący się dość wymagającym egzaminem. Po jego ukończeniu uczestnicy posiadają wiedzę, akredytację oraz narzędzia umożliwiające prowadzenie pozostałych szkoleń SAFe i wdrażanie jego mechanizmów. Żeby móc pełnić rolę wewnętrznych konsultantów oraz efektywnie wywiązywać się z tak szerokiego zakresu obowiązków uczestnicy powinni, poza znajomością SAFe’a, charakteryzować się głębokim zrozumieniem procesów wytwarzania oprogramowania, zarządzania projektami i zwinności w szczególności.

Specyfika SAFe’a polega na tym, że bez pośrednictwa SPC nie ma możliwości uczestnictwa w akredytowanym szkoleniu i przystąpienia do certyfikacji (w przeciwieństwie np. do certyfikatów sygnowanych przez Scrum.org do których dostęp nie wymaga pośrednictwa).

Scaled Agile Inc. wprowadziło rolę SAFe Program Consultant i zachęca organizacje do przeprowadzenia wdrożeń własnymi siłami, gdyż samo w  swoim modelu biznesowym nie nastawia się na usługi konsultingowe. Nie mniej jednak SPC mogą z powodzeniem pełnić również rolę zewnętrznych trenerów i konsultantów.

Jeśli organizacja, przy wdrażaniu SAFe, planuje korzystać jedynie z własnych coachów, to wykształcenie SPC jest pierwszym i niezbędnym krokiem do implementacji tego frameworka.

Szczegóły szkolenia SAFe:

Implementing SAFe®

Nazwa szkolenia: Leading SAFe

Nazwa certyfikatu: SAFe Agilist

Grupa docelowa: Liderzy agile w organizacji

Opis:

Szkolenie Leading SAFe przeznaczone jest dla osób, które są budują w swoich organizacjach kulturę lean i agile, będąc motorem wdrażania zwinnego podejścia do rozwoju produktów. Ideą tego szkolenia jest zaktywizowanie liderów, którzy przygotują podatny grunt pod implementację SAFe’a, we wszystkich domenach organizacji. Częściowo są to osoby, które będę pełniły kluczowe role SAFe’owe, częściowo te bezpośrednio wdrażające go, a częściowo po prostu, te które będą swoim aurotytetem wspierały praktyki lean i agile nawet jeśli nie będą pełniły określonej roli w modelu SAFe. Jako, że SAFe jest przeznaczony do dużo szerszego grona interesariuszy niż tylko zespoły deweloperskie i działy technologiczne, wsparcie liderów reprezentujących różne piony i poziomy organizacyjne jest kluczowe dla funkcjonowania agile w skali.

Szczegóły szkolenia:

Leading SAFe®

Nazwy szkoleń: SAFe Scrum Master i SAFe Advanced Scrum Master

Nazwa certyfikatów: SAFe Scrum Master i SAFe Advanced Scrum Master

Grupa docelowa: Scrum Masterzy

Opis bardzo subiektywny:

Są to dwa szkolenia dedykowane kolejno początkującym i doświadczonym Scrum Masterom. Jakkolwiek pierwsze kierowane jest do osób rozpoczynających dopiero swoją pracę z agilem i tą rolą, a to drugie celuje w potrzeby już nieco doświadczonych Scrum Masterów, to oba skupiają się na pełnieniu roli SMa w kontekście całej organizacji.

Moje obserwacje są takie, że najczęściej będziemy mieli do czynienia z sytuacją, kiedy za SAFe’a będą się brali już w miarę doświadczeni Scrum Masterzy, którzy śmiało mogą od razu przejść do szkolenia Advanced. Scrum Masteringu nie nauczy żadne z tych szkoleń, więc uczestnicy z założenia powinni mieć już wiedzą i pewne doświadczenie, a z takim kapitałem mogą od razu przejść do szkolenia Advanced Scrum Master i skupić się na funkcjonowaniu tej roli w skali, a w szczególności w środowisku opartym o Scaled Agile Framework.

Szczegóły szkoleń SAFe’owych dla Scrum Masterów:

SAFe® Scrum Master

SAFe® Advanced Scrum Master

Nazwa szkolenia: SAFe Product Owner/ Product Manager

Nazwa certyfikatu: SAFe PO/PM

Grupa docelowa: właściciele biznesowi, osoby zarządzające produktami, Product Ownerzy, analitycy biznesowi

Opis:

Szkolenie to przygotowuje wszystkie osoby, które będą w formule SAFe brały udział w zarządzaniu wartością rozwijanych produktów. Są to obecni i przyszli właściciele biznesowi strumieni wartości i linii produktowych, liderzy biznesowi projektów, managerowie zarządzający produktami na poziomie strategicznym (wizja, strategia rynkowa, pricing…), architekci biznesowi rozwiązań definiujący ich główne cechy, analitycy i Product Ownerzy projektujący poszczególne komponenty i funkcjonalności produktów. Każda osoba, która będzie w modelu SAFe’owym brała udział w definiowaniu produktów znajdzie w tym szkoleniu wiele cennych informacji odnośnie tego, jak zarządzać wartością dostarczaną przez zespoły deweloperskie.

Szczegóły szkolenia SAFe:

SAFe Product Owner/Product Manager

Nazwa szkolenia: SAFe for Teams

Nazwa certyfikatu: SAFe Practitioner

Grupa docelowa: Zespoły zwinne funkcjonujące w wielozespołowych projektach i przedsięwzięciach angażujących wiele domen danej organizacji.

Opis:

Szkolenie to przygotowuje zespoły zwinne (deweloperów w szerokim pojęciu, czyli oprócz programistów i adminów również analityków, UXów, testerów, itd.) niezależnie od tego, czy stosują one Kanbana, Scruma, Scrum-Bana, XP, czy inne zwinne podejście, do funkcjonowania w skali całej organizacji i w środowisku dużych rozwiązań angażujących wiele zespołów deweloperskich. Uczy jak planować i realizować prace w ramach zwinnego programu zwanego Agile Release Train.

Szczegóły szkolenia SAFe:

SAFe® for Teams

Nazwa szkolenia: SAFe Release Train Engineer

Nazwa certyfikatu: SAFe Certified Release Train Engineer

Grupa docelowa: Szkolenie skierowane jest do osób pełniących lub mających w przyszłości pełnić rolę Release Train Engineer, czyli agile’owego odpowiednika Kierownika Programu.

Opis:

Szkolenie to uczy, jak być efektywnym Scrum Masterem Scrum Masterów i koordynować w ramach Pociągu Wdrożeń działania biznesu i technologii w celu optymalizacji wartości dostarczanej w kolejnych Przyrostach Programu. Przygotowuje też RTE do koordynacji wielu programów w ramach dużych rozwiązań i strumieni wartości. Rolę Release Train Engineer’a możemy traktować jako Kierownika  

Szczegóły szkolenia:

SAFe® Release Train Engineer

Zamiast podsumowania

Wszystkie wymienione szkolenia SAFe, mniej więcej w siedemdziesięciu procentach obejmują ten sam materiał bazowy (SAFe z lotu ptaka, lean-agile mindset, pryncypia, główne komponenty, PI Panning). Przedstawiany jest on każdorazowo z perspektywy danej roli, nie mniej jednak osoba chcąca skorzystać z dwóch różnych szkoleń (np. SAFe Scrum Master i dodatkowo SAFe PO/PM) wynudzi się na tym drugim, jak diabeł na różańcu. Trenerzy posiadający akredytację nie mogą zmieniać licencjonowanych materiałów, dzięki czemu szkolenia SAFe są spójne, zgodne z intencjami frameworka i skutecznie przygotowują uczestników do certyfikacji.