SAFe – trzy miesiące później

Pierwszy Program Increment za nami. Wkroczyliśmy w drugi PI z marszu, bogatsi o doświadczenia, metryki i wnioski. 5ciu dostawców, 16cie zespołów, setki elementów w backlogu. Czego się nauczyłem,  jakie wyciągnąłem wnioski? Zapraszam do lektury.

Kiedy idę na szkolenie lub prezentacje i ktoś sprzedaje mi wspaniałe narzędzie, które powinno rozwiązać większość moich problemów, zwykle jestem podejrzliwy. Szukam gwiazdek i dodatkowych warunków zapisanych drobnym drukiem.

Podobnie miałem w przypadku SAFe. Wydaje mi się, że mogę już (po paru miesiącach) zidentyfikować ten ‘drobny druk’. Są to dwa ważne obszary: wartości z obszarów Lean oraz Product Ownership.
Dzięki zaangażowaniu biznesu i chęci do eksperymentowania z procesem (i dobremu RTE) rzuciliśmy się na głęboką wodę i uczymy się szybko co u nas działa, a co nie. Jednak bez zadbania o te ważne obszary nadal działamy, moim zdaniem, mniej efektywnie niż moglibyśmy.

Uwaga! W artykule używam wiele zwrotów, które mają zastosowanie głównie w SAFe - co więcej, nie wyjaśniam ich (o zgrozo! ;). Więcej o terminologii SAFe znajdziesz drogi czytelniku tutaj.

Sprawdźmy jak nam poszedł pierwszy Program Increment:

• W PI-2017.1 zrealizowaliśmy ~50% item’ów w Backlogach (miara obiektywna).
  • Jednak zamknęliśmy tylko 1 feature - 31 było nadal otwartych na koniec PI (miara obiektywna).
• Przewidywalność pociągu pod względem PI Objectives w PI-2017.1: 81% (miara subiektywna - ocena ProductMgmt).
• Współczynnik realizacji celów sprintu całego pociągu: średnia 76% (miara subiektywna - ocena Product Ownera).
• Velocity vs. Forecast: średnia 69% (miara obiektywna).
• Cycle Time dla historii: 8 dni (trend rosnący w porównaniu z Q3 2016; miara obiektywna).
• Nie jesteśmy w stanie oszacować wytworzonej faktycznej wartości dla użytkownika - rozwiązania nie zostały jeszcze wdrożone tak, aby użytkownicy mogli się z nimi zapoznać i dać nam informację zwrotną

Nadal uczymy się przewidywalności - pierwszy PI nie zakończył się ‘pełnym sukcesem’. Jednocześnie dużo się nauczyliśmy (także bardziej realistycznie planować, lepiej wyszukiwać i częściowo ograniczać zależności). W PI-2, także dzięki fizycznej tablicy (Program Board), udało się przynajmniej zwizualizować i przedyskutować większą ilość zależności.

Jeśli chodzi o metryki - zaskakujące jest to, że biznes ocenił dostarczenie Business Value na poziomie 81% w PI-2017.1, a zamknięty (zintegrowanych, gotowych do release’u) mamy tylko 1 (słownie: jeden) feature. Może to wynikać pośrednio z faktu, że cele (PI Objectives) dla pierwszego PI były wyznaczone dopiero w trakcie trwania Program Incrementu (i były przez to bardziej realistyczne niż na planowaniu). Dodatkowym czynnikiem może być tu postrzeganie wartości - nie wszystkie elementy feature’ów muszą być zrealizowane, aby dostać MVP).

Wnioski z pierwszego PI Planningu i co udało się nam faktycznie usprawnić

• • Wcześniejsze przepracowanie backlogów zespołowych (refinement) tak, aby zespoły mogły się 'oswoić' z proponowanymi funkcjonalnościami  
    • To nam się udało częściowo. Wiele zespołów mogło się zapoznać ze swoimi ‘Feature’ami’ przed PI Planningiem. Nadal jednak kuleje u nas podejście przepływowe do zawartości backloga programowego. Kanban board na poziomie programu dopiero raczkuje (z kolumnami typu Pomysły, Analiza, Gotowe do Implementacji). Istnieje tu pewne ryzyko wprowadzenia procesu typu ‘phase-gate’. Zespoły nie chcą commitować się na planowaniu do czegoś, czego nie widziały wcześniej na oczy. Więc ustalane są terminy do kiedy najpóźniej muszą być ‘dostarczone’ wymagania i ‘top 10 features’ przed PI Planning... Gdzieś już to widziałem niestety.
  • Lepsza wizualizacja postępów planowania i ‘dużego obrazka’ (program board) w jednym miejscu dla wszystkich na planowaniu
    • Fizyczna tablica zadziałała bardzo dobrze. Udało się zidentyfikować i omówić dużo więcej zależności na starcie Program Incrementu. Zabrakło niestety ostatniego kroku: Identyfikacja - Omówienie - Próba likwidacji zależności. Nadal nie zmniejszyliśmy WIP na przykład.
  • Estymacje zgrubne już omówionych backlogów zespołowych za pomocą metody affinity estimation
    • Refinement feature’ów w backlogach zespołowych i estymacje były w wielu przypadkach przeprowadzane już przed drugim PI Planningiem, więc tym razem nie zajęło to tyle czasu co ostatnio.
  • Większy nacisk na przygotowanie środowisk lokalnych, do integracji i typu staging PRZED rozpoczęciem prac
    • Wiele nauczyliśmy w trakcie pierwszego PI na pierwszych (bolesnych) System Demach (problemy z integracją wielu dostawców: braki w środowiskach, problemy z integracją sieciową środowisk; błędy). Nauka na przyszłość: System Demo jest (czasem bolesną), ale koniecznym elementem, jeśli chcemy faktycznie pokazywać ‘working software’ jako miarę postępu w wytwarzaniu produktu.
  • Stworzenie System Team na starcie - tak, aby wspomóc tematy integracji softu (różni dostawcy, środowiska, sposoby pracy)
    • Pomoc System Team okazała się nieodzowna w przypadku, kiedy mamy tak wielu dostawców, którzy próbują min. raz na 2 tygodnie zaprezentować kolejny zintegrowany Inkrement. Baliśmy się trochę, że taki System Team zabierze odpowiedzialność za integrację softu z zespołów - jednak w większości przypadków to się nie sprawdziło. Zespołom nadal mocno zależy na integracji softu oraz tworzeniu narzędzi, które ten proces usprawniają (CI/CD).

• • Zaadaptowanie tworzenia celów programowych (PI Objectives) zamiast ograniczać się do zaplanowanej zawartości backloga, aby jeszcze mocniej zaznaczyć wspólny kierunek pociągu
    • Tutaj też udało się to wprowadzić. Pokazuje to jasno jakie są cele na Program Increment o wysokiej (potencjalnej) wartości dla Business Ownerów i na czym się skupić w pierwszej kolejności. Jest to szczególnie ważne w sytuacjach, kiedy zespoły muszą sobie pomagać i/lub odblokowywać pracę innych zespołów (zależności, duży WIP w programie). Dzięki PI Objectives możemy zbudować poczucie dążenia całym pociągiem do wspólnego celu. Każdy zespół ma własne PI Objectives, ale jest w stanie je ‘poświęcić’ (przy konsultacji z PO/ProductMgmt) aby wspomóc zespoły z celami o wyższym Business Value (większy focus, mniejszy WIP).

Z czym nadal się borykamy i co chcemy dalej usprawniać?

1. Architektura, współdzielone komponenty, proces Continuous Integration oraz Continuous Deployment

Tworząc nową wersję produktu (i rozpoczynając tyle obszarów na raz) okazuje się, że ważna jest wspólna wizja technologiczna takiego rozwiązania (oraz sposób w jaki pracujemy nad nią):

• ogólny kształt architektury (np. mikrousługi)
• interfejsy, api, komunikacja między usługami, model danych
• “reużywalność” komponentów (aby zespoły nie odkrywały koła na nowo i np. każdy nie tworzył sobie własnego wyglądu listy, pola wyszukiwania, formularzy, etc.)
• w jaki sposób robimy deploy na kolejne środowiska (deploy, integracja) - szczególnie kiedy nad rozwiązaniem pracuje 5ciu różnych dostawców (i w sumie 16cie zespołów)

Po kilku porażkach (np. z System Demo) doszliśmy do wniosku, że rozwiązaniem jest stworzenie, po pierwsze:

• System Team do wspomagania integracji i pracy ze środowiskami - o tym już pisałem

oraz po drugie:

• rozszerzenie grupy architektów systemowych - do regularnego spotkania tzw. Solution Team. Szczególnie ten drugi byt, w skład którego wchodzą architekci oraz przedstawiciele wszystkich dostawców (liderzy techniczni, chapter leaderzy) spotyka się regularnie i ustala wspólny kierunek dla rozwiązań technologicznych.

Dodatkowo wprowadziliśmy tzw. ‘Decision Log’ gdzie wpisujemy decyzje techniczne, biznesowe, które mogą wpłynąć na dalszy rozwój oprogramowania (wraz z przyczyną, dla której dana decyzja została podjęta i jakie niesie ze sobą konsekwencje).

Dzięki tym dwóm usprawnieniom, chcemy połączyć ‘emergent design’ z ‘intentional architecture’ - dać pewne (nie za wąskie) ramy zespołom developerskim, aby mogły zarówno eksperymentować z własnymi rozwiązaniami, jak i zwiększyć szansę na to, że będą one mogły być (re)używane przez innych w pociągu (lub kiedyś przyszłości). Nadal wyzwaniem pozostaje utrzymywanie tych komponentów oraz dbanie o to, aby wszystkie były podobnej (wysokiej) jakości wśród wszystkich dostawców.

To, z czym nadal się zmagamy, to w pełni zautomatyzowany proces CI/CD. Tutaj jest jeszcze trochę pracy do wykonania. Na szczęście mamy zalążek community DevOps, które przy wsparciu System Team pracuje intensywnie nad usprawnieniem tego obszaru jeszcze w tym Product Incremencie.

2. Work in Progress

Nadal nie wychodzi nam ograniczenie WIP i skupienie się na najważniejszych rzeczach, chociaż jest już z tym lepiej niż w pierwszym PI - przynajmniej przyjęliśmy historyczną prędkość na planowaniu, wyznaczyliśmy najważniejsze PI Objectives (pod względem Business Value) oraz mamy dodatkowy punkt skupienia w postaci demonstrowalnej wersji produktu na zbliżające się targi w Monachium.

W pierwszym Program Incremencie mocno tego zabrakło, co doprowadziło do długiego Cycle Time dla funkcjonalności. Duży WIP powoduje też, siłą rzeczy, powstanie wielu zależności między zespołami. Szczególnie, jeśli pojawiają się zespoły komponentowe, jak u nas. Wtedy faktyczna wartość dla użytkownika (np. zwizualizowana przez User Journey) jest mocno ‘poszatkowana’. Mamy dostarczone i zintegrowane małe porcje funkcjonalności (User Stories), ale cały produkt nie jest używalny w ‘podstawowym’ zakresie, end-to-end. Nie pomogły też tutaj częste zmiany priorytetów - czasami wręcz całej wizji podstawowych funkcjonalności czy wyglądu produktu. Bardzo uczulam tutaj na stwierdzenia od kluczowych interesariuszy w stylu: “wiemy czego chcemy - trzeba przepisać (lub portować) cały produkt i wszystko jest ważne”. Warto jednak dopytać wtedy o szczegóły.

I tutaj właśnie przychodzą mi do głowy wartości, które powinny być u podstaw SAFe - czyli podejście przepływowe, szczupłe, oraz ogólnie rozumiany ‘Product Ownership’. Jednymi z głównych zasad SAFe są ograniczenie WIP, zmniejszanie paczek pracy, myślenie systemowe czy bazowanie decyzji w oparciu o (zmodyfikowany) Cost of Delay. Bez świadomego podejścia przez interesariuszy do tych zagadnień niewiele niestety się zmieni. W zrozumieniu, co jest najważniejsze w produkcie mogłyby pomóc takie rzeczy jak:

• Stworzenie wizji produktu czy portfolio produktów -> tutaj mogłyby pomóc warsztaty z kluczowymi interesariuszami (np. CEO klienta) przy użyciu takich narzędzi, jak wszelkiej maści Canvasy (Value Proposition, Value Statement, Product Vision Board, etc.)
• Uruchomienie warstwy Porfolio i Value Stream w SAFe -> aby zrozumieć jak wizja, cele strategiczne kaskadują sie na poziom Programu (i umożliwiają np. wybranie faktycznie ‘top 10’ features zamiast ‘top 30’).
• Zmapowanie strumienia wartości dla produktów - szczególnie w kontekście współpracy z innymi ‘działami’ u klienta i jasne określenie, które działania bardziej przyczyniają się do realizowania wizji, strategii, a które mniej (i gdzie są zależności, które trzeba skoordynować).
• Częsta weryfikacja hipotez produktowych (czy to poprzez badania rynku, testy A/B, ankiety Kano czy poprzez np. beta-testy minimalnych ścieżek funkcjonalności z faktycznymi użytkownikami)

3. Co to znaczy ‘good enough’

Tworzymy nową wersję produktu i chcemy szybko doprowadzić ją do stanu używalności na poziomie minimum wersji poprzedniej. Niestety ‘szybko’ jest tu pojęciem względnym. Co więcej, póki nie będziemy mieli takiej ‘minimalnej’ wersji (czy faktycznie jest to MVP?), biznes nie chce niczego udostępniać użytkownikom na środowisko produkcyjne (gdzieś już to widziałem…).

Z drugiej strony, biznes chce zachęcać potencjalnych klientów do nowego produktu, np. poprzez zaprezentowanie go na targach (wersja nie musi być doskonała). W związku z tym zadajemy sobie często pytanie - co to znaczy ‘good enough’ w przypadku naszego oprogramowania. Jak obszerne musi być Definition of Done produktu w obecnej fazie rozwoju. Czy funkcjonalności muszą już być w każdym stopniu doszlifowane (wszystkie piksele w UI na swoim miejscu) i czekające na wdrożenie (w SAFe mamy : ‘integrate often, release any time’), czy może jednak powinny być mniej dopieszczone, a szybciej wypuszczone do klienta w celu weryfikacji (z długiem technicznym?). I na jakim poziomie jest to ‘dopieszczanie’ - czy chodzi tylko o refactoring i ulepszenie UI, czy może także testy automatyczne (na różnych poziomach). Czy mamy tworzyć od razu reużywalne komponenty (dłuższa praca teraz, ale z perspektywą skrócenia czasu developmentu w przyszłości) czy może (szybko) stworzyć coś, co można pokazać i skomunikować z innymi częściami systemu? Czy wszystkie błędy są krytyczne i w jakim momencie cyklu rozwoju produktu?

Te zagadnienia są szczególnie ważne w przypadku pracy z 5cioma dostawcami, gdzie każdy z nich może mieć inne zrozumienie tego, co oznacza pojęcie ‘jakość’ (lub ‘jakoś’ ;).

Nie widzę tutaj jakiejś uniwersalnej odpowiedzi. Z jednej strony chcemy mieć szybką pętlę informacji zwrotnej, z drugiej chcemy, aby użytkownicy faktycznie mieli ‘co’ testować - czyli móc użyć aplikacji do rozwiązania jakiegoś swojego problemu zamiast po prostu poklikania w przyciski i zakładki ("o, ładne!"). Mamy obszar jakości produktu pod względem funkcjonalnym (i rozwiązań technicznych kryjących się pod spodem) oraz czy produkt faktycznie spełnia potrzeby użytkowników. To, co możemy zrobić na wstępie to mierzyć to jak sobie radzimy w poszczególnych obszarach.

Moim zdaniem tutaj znowu przechodzimy do punktu numer 2 - ograniczenia WIP i skupieniu się na dostarczeniu jakiegoś ‘przepływu’ dla użytkownika, z którego może on skorzystać. Wtedy szybko można przetestować takie rozwiązanie z grupą beta-testerów i uzyskać feedback do dalszego rozwoju (może nie wszystkie funkcjonalności starego produktu są warte do przeniesienia do nowej wersji?)

Moje najważniejsze wnioski po 3 miesiącach pracy z frameworkiem SAFe

• Framework ten (ani żaden inny) nie zmieni nawyków ani kultury organizacji. Nie wprowadzi, ale też nie zabije zwinności - wszystko zależy od wartości i sposobu użycia.
• PI Planning jest jednym z lepszych pomysłów jakie widziałem na planowanie średnioterminowe w przypadku organizacji, gdzie współpracuje więcej niż 2-3 zespoły nad jednym produktem. Program Board jest niezłym narzędziem do wizualizacji stopnia skomplikowania planu.
• Kluczem do efektywnego wytwarzania produktu jest, moim zdaniem, nadal: Product Ownership oraz myślenie systemowe, przepływowe (Lean, Systems Thinking)
• Podejście DevOps jest bardzo ważne w tak złożonym środowisku - bez tego cofamy się do czasów ‘code freeze’ i manualnej integracji produktu pod koniec sprintu
• Istnieje niestety duża pokusa traktowania Program Increment jako 10-tygodniowego sprintu (‘mamy jeszcze czas, najwyżej nie wdroży się na RC w tym sprincie i nie będzie na System Demo’).
  • Wielka ‘paczka’ wymagań tworzona jest przez dział Product Managementu, następnie ‘wrzucona’ do zespołów przed PI Planningiem (najczęściej sprint Innovation and Planning), następują refinementy, wielkie 2-dniowe planowanie i commitment na 4-5 sprintów do przodu. PI Objectives to takie cele tego ‘dużego sprintu’. Cała nadzieja w częstym integrowaniu całego produktu (minimum na System Demo, co 2 tygodnie) - tego nie da się oszukać i faktycznie biznes widzi, czy mamy działający soft co sprint czy nie.
• Użycie ‘Commitmentu’ na planowaniach PI czy sprintów wprowadza ten sam mechanizm, od którego uciekł kiedyś Scrum. Zaczynamy ponownie grać w tzw. ‘Commitment Game’ -> co może prowadzić do braku przestrzeni na porażkę, eksperymenty oraz bardzo bezpieczne planowanie (z wieloma buforami).
• Sposób ‘szacowania’ startowej prędkości nowych zespołów, które proponuje SAFe (a który łączy Story Pointy z pojemnością zespołu w Man Days) jest niepraktyczny (szkodliwy wręcz) i nie polecam go (u nas w ogóle się nie sprawdził, doprowadził do bardzo nierealistycznych predykcji)
• Bez jasnej wizji, strategii, bez rygorystycznego i agresywnego priorytetyzowania działań na poziomie biznesowym (Portfolio, Value Stream) framework traci dużo jeśli chodzi o przewidywalność (co przecież ma być główną kartą przetargową aby zainteresować nim biznes właśnie). Jeśli mówimy sobie, że chcemy release’ować dopiero wystarczająco ‘bogaty’ produkt (który rozwiąże jakiś problem użytkownika), to warto mieć jasno określone co to dla nas znaczy. Inaczej nigdy nie wiemy jak blisko celu jesteśmy.
• Gdybym miał okazję wdrażać SAFe ponownie w jakiejś organizacji, ciut więcej czasu spędziłbym na:
  • Doprecyzowaniu ról - szczególnie wytypowanie silnie umocowanego Product Managera.
  • Pomoc w zebraniu i zwizualizowaniu wizji oraz strategii związanej z biznesową stroną organizacji.
  • Value Stream Mapping - aby zobaczyć przepływ wartości przez organizację i jakie produkty faktycznie tworzymy/utrzymujemy (i dla kogo).
  • Wsparcie Product Managementu w bardzo agresywnym priorytetyzowaniu (wycinaniu) backlogu na podstawie wizji, strategii oraz WSJF (czy ogólnie Cost of Delay).

Artykuł po raz pierwszy opublikowany został na blogu RST Software Masters.