1

Is it Agile is it SAFe?

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.

Z punktu widzenia Scrum Mastera, wypróbowywanie nowych sposobów zarządzania procesem wytwarzania oprogramowania jest zawsze ekscytujące. Tym bardziej, kiedy przypomnę sobie początek Agile Manifesto:

We are uncovering better ways of developing
software by doing it and helping others do it.

SAFe jako framework nie jest nowy. Powstawał w pierwszej dekadzie XXI wieku jako propozycja skalowania zwinnego/przyrostowego wytwarzania produktu i pogodzenia tego z długo i średnio- terminowymi planami biznesowymi (cele strategiczne, roadmapa produktu, portfolio). W założeniu pozwala on (przy zastosowaniu wartości i metod związanych z Lean, Agile, Scrum, XP) na dostarczanie rozwiązań, które wymagają zaangażowania większej ilości zespołów, dostawców i innych interesariuszy i jednoczesne zwiększenie przewidywalności dla biznesu.

Podstawowym mechanizmem zapewniającym synchronizację, współbieżność celów i średnioterminowe plany na poziomie programu w SAFe jest ART - czyli Agile Release Train.

Pociąg pędzi przed siebie po niekończących się torach (póki wartość jest dostarczana 🙂 i zatrzymuje się punktualnie na z góry określonych stacjach - Program Increment’ach. W pociągu znajdują się wszyscy, którzy potrzebni są do dostarczenia wartości:

  • zespoły scrumowe (i kanbanowe),
  • przedstawiciele biznesu, marketingu, sprzedaży, wsparcia
  • reprezentanci klienta
  • inni dostawcy,
  • architekci,
  • wszelkiej maści servant-leaderzy i właściciele produktu.

Całość kierowana jest przez zawiadowcę, czyli RTE (Release Train Engineer - pieszczotliwie zwany Chief Scrum Master).

Moje pierwsze zetknięcie z SAFe odbyło się w grudniu 2016, w trakcie szkolenia na SAFe Program Consultant. Podczas tego 4- dniowego maratonu przeszliśmy przez, jak się zdaje, większość zakamarków tego frameworka. Pierwsze wrażenie: jest tego ogrom! O ile w przypadku innych metod czy podejść, ilość ‘przepisów’ jest ograniczana do minimum, to w przypadku SAFe wydaje się królować podejście: “dajmy na start wszystko, aby ludzie mogli bezpiecznie zacząć, nawet od zera”. Mamy tutaj bardzo szczegółowe opisy wartości, praktyk, metod, spotkań (agendy podane już nawet co do godziny!), ról, backlogów i wszystkiego innego, co potrzebne jest aby zacząć - czyli uruchomić swój pierwszy pociąg.

SAFe mocno stawia nie tylko na opis ‘krok po kroku’, ale także podkreśla, że bez nastawienia zwinnego, (Agile Manifesto, Lean House) nie uda się poprawnie wdrożyć tego framework’a w organizacji. Jestem bardzo ciekawy jak to nam się sprawdzi w dalszej pracy (patrząc na realizację celów, dostarczonej wartości i innych metrykach typu cycle time, lead time). Z tyłu głowy mam gdzieś oczywiście emocjonalny wpis Kena Schwabera o SAFe, jednak jestem daleki od ferowania wyroków bez spróbowania implementacji tego i ocenienia rezultatów.

Duża część szkolenia jest też poświęcona propagowaniu postawy servant-leader’a. Czyli w sumie wszystko się zgadza (zwinność) i do tego jest podane na tacy (implementacja, ramy i przewidywalność dla biznesu :).

A jak jest w praktyce? Dopiero zaczynamy, ale pierwszymi ciekawymi obserwacjami mogę się już z Wami podzielić.

Pierwszy Program Increment Planning odbył się w dniach 16-17 stycznia. Zaledwie miesiąc po naszym szkoleniu SPC4. Całe szczęście na szkoleniu mieliśmy przedstawicieli zarówno części ‘technicznej’ jak i ‘biznesowej’. Dzięki temu mogliśmy stworzyć odpowiednio umocowaną grupę implementującą SAFe już na samym starcie. Mówiliśmy tym samym językiem i mogliśmy uzyskać ‘buy-in’ całej organizacji. Uniknęliśmy w ten sposób pułapki wprowadzania zmian ‘top-down’ (gdzie zwykle jest opór, niezrozumienie, rozmycie celów) czy ‘bottom-up’ (partyzantka, brak widocznych korzyści dla biznesu, sub-optymalizacja lokalna).

Przygotowanie pierwszego PI Planningu wymagało kilkunastu dni intensywnej pracy. Od dostarczenia backlogu programu (duże feature’y, wstępnie rozbite na User Stories), poprzez szkolenia dla leaderów i zespołów (w okrojonej formie niestety) do przygotowania samej lokalizacji (miejsca dla kilkunastu zespołów). Nie wszystko udało się idealnie, ale efekt i tak był niezapomniany 🙂

Fascynujące było brać udział (jako SM zespołu i jako SPC dla całej organizacji) w takim wydarzeniu i zaangażować się w wytworzenie wspólnego planu na następne 5 sprintów (Program Increment). Mimo rozgardiaszu, lekkiego chaosu i hałasu dało się wyczuć niesamowitą pozytywną energię, zaangażowanie i… samoorganizację. Wykrywaliśmy błyskawicznie zależności, mogliśmy je przegadać technicznie z innymi zespołami, negocjować zakres i priorytety z biznesem oraz względy architektoniczne (interfejsy, api, dane wejściowe/wyjściowe, bazy danych). Nie na wszystko byliśmy gotowi i nie wszystko dało się przygotować przed planowaniem - wiele rzeczy musieliśmy dogrywać ‘ad-hoc’. Było to w ogóle możliwe tylko dzięki temu, że mieliśmy WSZYSTKICH w jednym miejscu.

Planowanie zakończyliśmy wspólnie wypracowanym planem na Program Increment, który powstał poprzez zagregowanie planów zespołowych (i “przefiltrowanie” ich przez kluczowych interesariuszy).

Z jednej strony biznes wie, czego może się spodziewać w średniej perspektywie czasu (kwartał), z drugiej strony zespoły wiedzą, że nie pracują w izolacji i rozumieją jak ich mniejsze funkcjonalności łączą się w całość - przyrost produktu (w skali programu).

Wnioski, usprawnienia na przyszłość:

  • Wcześniejsze przepracowanie backlogów zespołowych (refinement) tak, aby zespoły mogły się 'oswoić' z proponowanymi funkcjonalnościami
  • Lepsza wizualizacja postępów planowania i ‘dużego obrazka’ (program board) w jednym miejscu dla wszystkich na planowaniu
  • Estymacje zgrubne już przegadanych backlogów za pomocą metody affinity estimation
  • Większy nacisk na przygotowanie środowisk lokalnych, do integracji i typu staging PRZED rozpoczęciem prac
  • Stworzenie System Team na starcie - tak, aby wspomóc tematy integracji softu (różni dostawcy, środowiska, sposoby pracy)
  • Zaadaptowanie tworzenia celów programowych (PI Objectives) zamiast ograniczać się do zaplanowanej zawartości backloga, aby jeszcze mocniej zaznaczyć wspólny kierunek pociągu
  • Pizza, jeszcze więcej pizzy 🙂

Wiemy, że to początek naszej drogi - nasz pierwszy Program Increment nie będzie idealny, ale wykorzystamy go maksymalnie do nauki i ulepszenia się na przyszłość.

A jakie są wasze doświadczenia z SAFe lub innymi frameworkami do skalowania zwinnego podejścia?

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

ROIWiele napisano o tym, jak Scrum Master pracuje nad samoorganizacją zespołów, efektywnością pracy i usprawnia całą organizację. Jako Scrum Masterzy propagujemy także zwinne praktyki i narzędzia (oraz, tam gdzie ma to sens - także Scrum :). Jesteśmy świetni w facylitacji, usuwaniu blokad i wspieraniu samoorganizacji.

Jest jednak jeden obszar, który przynajmniej ja - przez długi - czas traktowałem ‘po macoszemu’. Jest to właśnie wspieranie Product Ownerów w rozwoju pod kątem zarządzania produktem i maksymalizacji wartości. Można powiedzieć, że pracując z zespołami i organizacją, byłem Scrum Masterem poziom 2 (może 2,5 😉 na 3. Jak wskoczyć w pełni na trzeci poziom? Zapraszam do lektury.

Jeśli tak jak ja nigdy nie byliście wcześniej Product Ownerami, odnalezienie się w zagadnieniach zarządzania produktem (i maksymalizacją wartości) może być dla Was (jak i mnie) pewnym wyzwaniem. Jeszcze większym może być pokazanie Product Ownerowi, że faktycznie jesteśmy mu, jako Scrum Masterzy w stanie pomóc w zdobyciu nowych narzędzi i kompetencji w tej dziedzinie (oraz sami od niego lub niej się uczyć). Jak w ogóle podejść do współpracy z PO, który często jest ekspertem biznesowym z wieloletnim doświadczeniem w zarządzaniu produktami?

A przecież, jak oznajmia Pismo Scrum Guide:

“Scrum Master wspiera Właściciela Produktu w wielu aspektach, na przykład:

  • w znajdowaniu technik efektywnego zarządzania Backlogiem Produktu,
  • (...)
  • zapewniając, że Właściciel Produktu wie, jak porządkować Backlog Produktu, aby maksymalizować wartość,
  • (...)”

No i klops. Jak wspomóc Product Ownera w zarządzania Product Backlogiem czy w sposobach maksymalizowania wartości nie będąc nigdy wcześniej w jego butach? Jak przekonać go (lub ją) do wypróbowania nowych sposobów pracy, o których przeczytaliśmy, usłyszeliśmy na konferencji, widzieliśmy w innych firmach lub poznaliśmy od innych PO na Agile Wrocław (pozdrawiam Michale :)?

Podstawowym warunkiem rozpoczęcia wspólnej pracy nad obszarem maksymalizowania wartości jest… zdobycie wiedzy 🙂

  • Czytamy artykuły, książki, blogi
  • Dyskutujemy z innymi Scrum Masterami i Product Ownerami
  • Uczestniczymy w społecznościach (np. Agile Wrocław, PO Wro)
  • Eksperymentujemy z narzędziami, technikami - najpierw na mniejszą skalę
  • Poznajemy domenę produktu, w którym przyszło nam pracować

Kolejnym krokiem jest zbudowanie odpowiedniej relacji z Product Ownerem. Co z tego, jeśli pokażemy naszemu PO jak wiele rzeczy wyczytaliśmy, poznaliśmy (czy nawet wypróbowaliśmy w innych firmach), jeśli nie będzie on (lub ona) widział(a) bezpośredniego przełożenia na jego (lub jej) pracę?

Tak jak w przypadku budowania relacji z zespołem, tak i tutaj ja nastawiam się na słuchanie i zrozumienie potrzeb, a następnie zaoferowanie swojej pomocy i dostarczenie faktycznej wartości. Przykłady:

  • Zaoferuj PO pomoc przy porządkowaniu Product Backlogu. Przygotuj się do tego, przeglądnij Backlog, zrozum historię produktu, domenę, użytkowników. Zapytaj zespół jak się pracuje z Backlogiem, czego oczekują. Następnie siądź z Product Ownerem i poświęć tyle czasu, ile trzeba aby uzyskać najlepszy efekt (dopasowanie narzędzi, grupowanie, usuwanie, szeregowanie, estymacje z zespołem, etc.).
  • Pomóż PO zebrać empiryczne dane na temat produktu i zespołu (zdrowie Product Backlogu, time to market, release burndown chart, ilość błędów, czas życia błędów, prędkość zespołu, stopień dostarczenia MVP czy MMF, dostarczona ilość wartości, etc.) aby mógł podejmować decyzje produktowe bazując na faktach.
  • Przeprowadź zespół przez ciężkie fazy formowania się i konfliktu aby ustabilizować prędkość.
  • Zorganizuj warsztaty wizji produktu aby pomóc PO zaangażować zespół w wizję i strategię produktu.
  • Udzielaj regularnej informacji zwrotnej i sam(a) o nią proś; Doceniaj!
  • i inne…

W ten sposób zbudujemy naturalną relację, w której my jako Scrum Masterzy wspomagamy nie tylko zespół developerski (z którym często siedzimy, z którym się kontaktujemy codziennie), ale także Product Ownera, który dostrzeże w takiej relacji wartość także dla siebie.

W takiej sytuacji dużo łatwiej nam jest współpracować z Product Ownerem i eksperymentować z nowymi narzędziami także w obszarze związanym z zarządzaniem produktem i wartością. Dzięki temu będziemy biec nie tylko szybko (efektywność, produktywność zespołu i organizacji), ale także w dobrym kierunku 🙂

Ostatnim, kluczowym elementem próbowania nowych narzędzi i metod z Product Ownerem jest prezentowanie ich na faktycznych przykładach z Waszej codziennej pracy. Szkolenia otwarte, bazujące na przykładach ‘uniwersalnych’ (i nierealnych, choć niewątpliwie ciekawych) są dobre aby przedstawić początkującym osobom podstawowe pojęcia. Dla zaawansowanych osób (jak większość PO, z którymi współpracowałem), takie szkolenia nigdy nie będą tak skuteczne, jak przećwiczenie danego narzędzia na ‘żywym organizmie’.

BVJeśli więc masz zamiar przećwiczyć np. Opportunity Canvas - weź faktyczne problemy/pomysły z Product Backlogu (np. epiki do zrobienia) i przejdź z PO przez całe ćwiczenie bazując na tym przykładzie. Jeśli wypracowujesz sposób wyznaczania Business Value na podstawie obszarów wpływu (o tym jeszcze kiedyś będę pisał), to ‘rozpracujcie’ to na przykładzie obszarów produktu lub grupy produktów w waszej firmie. Moim zdaniem, taka nauka przez doświadczanie i eksperymentowanie jest najbardziej jednym z najbardziej efektywnych sposobów przekazywania nowej wiedzy i wdrażania nowych kompetencji.

Po czym poznać, że ‘zaskoczyło’ i jest szansa na to, że ludzie będą kontynuować pracę z nowymi narzędziami?

  • W trakcie ćwiczenia następuje gorąca dyskusja (lub nawet spory co do wyniku) -> wyzwalają się emocje.
  • Eksperymentowanie z kształtem samego narzędzia -> “Co by szatan zrobił z twoim feature’em” (o tym też może kiedyś 😉 jako dodatkowe pole w Opportunity Canvas.
  • Po zakończeniu ćwiczenia/warsztatu, ludzie robią zdjęcia wyników lub wręcz zabierają je ze sobą.
  • Powstają (spisane) akcje opisujące ‘co dalej’.

Pomagając Product Ownerom w efektywnym zarządzaniu produktem możemy mieć niejako uczucie ‘wchodzenia na cudze podwórko’. Z mojego doświadczenia mogę powiedzieć, że czasem chyba niepotrzebnie się tego obawiamy jako Scrum Masterzy 🙂 Jeśli pokażemy naszym Product Ownerom, że mogą mieć bezpośrednią korzyść z nowych sposobów pracy, że nam, jako Scrum Masterom, także zależy nam na efektywnym dostarczaniu wartości, to wspólny rozwój, eksperymentowanie i uczenie się będą tylko naturalną konsekwencją.

1

sm relacjeW pracy każdego Scrum Mastera przychodzi ten moment, kiedy wchodzimy do nowego dla siebie zespołu czy nawet firmy lub organizacji. U mnie zwykle wiąże się to z lekkim stresem i jednocześnie ekscytacją - jak to będzie? Co to za ludzie? Co jest dla nich ważne? Czy mnie zaakceptują oraz - jak będę im mógł pomóc? Chciałbym podzielić się z wami moim doświadczeniami związanymi z wejściem w nowe środowisko. Pokażę wam, jak nauczyłem się (często na błędach), że budowanie relacji (oraz ich podtrzymywanie) jest moim zdaniem kluczowe do osiągnięcia do osiągnięcia dobrych wyników - czy wręcz aby przeżyć te pierwsze tygodnie 🙂

"Wjeżdżam na białym koniu i robię im Scrum'a"

Można czasem zaobserwować takie o to zjawisko:

Wchodzi [Scrum Master/Agile Coach/Konsultant/Agile Expert/Mistrz Yoda] do (pokoju) obcego zespołu. Obwieszcza:
- myślę, że coś tracicie stosując taką tablicę kalendarzową. Dobre praktyki i doświadczenie podpowiadają mi inne rozwiązanie. Moim zdaniem powinniście mieć tablicę z przepływem, dzięki temu zwiększycie swoją transparencję.
Po czym osobnik wychodzi i więcej się nie pojawia (lub pojawia się po paru tygodniach) - zrobił przecież swoją robotę. Był lustrem, zaproponował alternatywę, a resztę zrobi 'samoorganizacja'.

Sam niestety złapałem się parę razy na podobnym działaniu. Dostawałem 'zlecenie' od sponsora/interesariusza: "zajmij się tym zespołem, zwróć uwagę na to i na to". Następnie szedłem do zespołu, mówiłem z jakiego umocowania tu jestem i co jest moim celem. Jaki był efekt? To zależy 🙂 Niektórzy nic nie mówili, inni reagowali defensywnie (lub wręcz agresywnie) na propozycje zmian, jeszcze inni zadawali pytania. Czasem coś się zmieniało, ale raczej zmiany nie były trwałe.

Problem, moim zdaniem, nie polega na tym, że ten osobnik z przykładu był lustrem, że zaproponował swoje rozwiązanie, różne od tego wypracowanego przez zespół. Przyjrzyjmy się jednak stwierdzeniu: "Wchodzi (...)  do (pokoju) obcego zespołu".

Jeśli przypomnę sobie te sytuacje, kiedy jednak udało się zbudować wysoko-wydajny zespół, zainicjować trwałe zmiany, zarówno w samym zespole jak i w organizacji, to wszystkie mają wspólny mianownik: były poprzedzone moją inwestycją w zbudowanie relacji. Wszędzie tam, gdzie najpierw dokonałem (świadomego lub nie) wysiłku w celu poznania ludzi, tego, co ich 'nakręca' (także poza pracą), z jakimi problemami się mierzą oraz czego potrzebują - tam znacznie częściej udawało mi się znaleźć 'podatny grunt' do inicjowania zmian.

Bardzo dobrze ten mechanizm opisuje M. Brzeziński w "Głaskologii". Budowanie dobrych relacji, docenianie i pomaganie innym buduje nasz 'kapitał' u innych ludzi, który później możemy wykorzystać w momentach, kiedy chcemy zaadresować trudny temat (usprawnić praktyki, proces, omówić konflikt w zespole, etc.). R. Cialdini w swojej książce "Wywieranie wpływu na ludzi" nazywa takie moment 'Moments of Power'. Każdy temat taki trudny temat, który wymaga ZMIANY zachowania, przyzwyczajeń, procesów w naturalny sposób wywoła u ludzi OPÓR. Im większy nasz uzbierany kapitał u ludzi, z którymi pracujemy, tym mniejszy opór w takich sytuacjach. A właśnie takie 'Momenty Mocy' to coś, co bardzo często chcemy wykorzystać w naszej pracy Scrum Masterskiej - do zainicjowania zmian, do poruszenia trudnego tematu, do uświadomienia konsekwencji czy pokazania kierunku.

Jak budować dobre relacje? - Wersja dla introwertyka

Temat jest obszerny i skupię się tutaj na kilku moich metodach, które dla mnie działają. Przydały mi się w szczególności w tych kluczowych początkowych tygodniach współpracy z nowymi ludźmi (zespołem, firmą). Dla mnie każdy z tych sposobów w jakimś stopniu wyciąga mnie ze strefy komfortu i jest dla mnie świadomym wysiłkiem - jako introwertyk (dodatkowo długo borykający się z nieśmiałością), na dłuższą metę męczę się przebywając wśród ludzi. Dla kogoś innego może być to dużo łatwiejsze (wręcz naturalne), dla kogoś z kolei - dużo trudniejsze i/lub sztuczne.

1. "Cześć" + uśmiech

Proste i sprawdzone. Nie zawsze wychodzi mi uśmiech 🙂
Tym sposobem inicjujemy ten najprostszy kontakt. Może on ułatwić dalsze 'zapoznanie się'. Ludzie oswajają się z naszą osobą.
Ważne: staram się przywitać z każdym, kogo mijam. Nie ważne, czy pracuje ze mną w zespole czy nie. Jeśli utrzymuję bliższą relację z jakimiś współpracownikami - staram się zawsze znaleźć czas na przywitanie się i krótką rozmowę, bez względu na to gdzie akurat siedzą i czy na siebie trafimy w trakcie dnia czy nie. Słowem - chodzę po ludziach 🙂
Ćwiczenie dla ciebie: przez następny tydzień mów 'cześć' ludziom siedzącym w pokojach, obok których przechodzisz w drodze do własnego w trakcie dnia (lub na początku).

2. Przedstaw się!

Kolejna oczywistość, ale dla mnie jako introwertyka nie do końca łatwa. Dużo łatwiej jest mi czekać, aż ktoś nas sobie łaskawie przedstawi. Walczę z tym - im szybciej przecież poznam imię drugiej osoby, tym szybciej zacznie budować się relacja. Samo imię ma dużą moc w rozmowie - zwróćcie czasem uwagę, co się dzieje z drugą osobą kiedy zwrócimy się do niej po imieniu (np. "Tomku, widzę, że robisz to User Story"). Ja wtedy np. zamieniam się w słuch.
Ćwiczenie dla ciebie: na następne spotkanie w szerszym gronie przyjdź parę minut wcześniej. Przedstaw się osobiście każdej osobie, której nie znasz.

3. Spędzaj czas z ludźmi i słuchaj ich.

Kolejna rzecz, którą z czasem sobie wypracowałem: przezwyciężenie wrodzonej chęci do zamknięcia się ze swoim zadaniem w swojej własnej przestrzeni gdzie jest cisza i spokój 🙂 Aby poznać ludzi, trzeba z nim przebywać. Słuchać tego, co mówią, jak się zachowują - szczególnie w 'luźnych' sytuacjach typu lunch, wspólne wyjście, etc. Zwróć uwagę na momenty, w których się 'nakręcają' - o czym wtedy mówią? To będą właśnie rzeczy, które są dla nich ważne, którymi się interesują.
Ćwiczenie dla ciebie: zbierz zespół któregoś dnia w pracy i idźcie razem na śniadanie/lunch. Zaobserwuj co jest tematem rozmowy i włącz się do dyskusji.

4. Pytaj o zainteresowania. Szukaj podobieństw.

Dowiedz się, co 'nakręca' ludzi, z którymi współpracujesz. To, co robimy w pracy to tylko wycinek (znaczny, ale jednak) tego, kim jesteśmy i co robimy. Pytaj, interesuj się tymi 'pobocznymi' tematami. Tutaj warunek jest jeden: szczere zainteresowanie. Kiedy nasz rozmówca zobaczy, że udajemy zainteresowanie (np. z grzeczności), może to wyhamować budującą się relację. Jeszcze lepiej, jeśli znajdziemy wspólne tematy do rozmowy - mamy skłonność do szukania ludzi, którzy mają podobne zainteresowania czy wartości co my. Być może utwierdza nas to w przekonaniu, że nasze wartości są 'dobre'.
Ponieważ jedną z moich mocnych stron (StrengthsFinder Gallupa) jest 'Individualization', nie muszę się zmuszać do słuchania - mnie naprawdę fascynuje to, jak każdy może być inny 🙂 Inną sprawą jest to, że zawsze mi bliżej do ludzi, których polubię na bazie ich zainteresowań, wartości. Nie umiem wszystkich traktować 'po równo'.
Ćwiczenie dla ciebie: u każdej osoby, z którą ściśle współpracujesz, znajdź przynajmniej jedną rzecz, która 'napędza' (interesuje, angażuje) tę osobę.

5. Otwieraj się. Mów także o swoich problemach, wątpliwościach, słabościach. Proś o pomoc.

Mam wrażenie, że nie jest to łatwe w środowisku 'profesjonalnym' - przyznać się do niewiedzy, do błędu. Zobaczyłem, że właśnie taka otwartość, poproszenie o pomoc czy o naukę działa bardzo pozytywnie na budowanie relacji. Szczególnie kiedy np. wchodzimy jako 'Ekspert' z zewnątrz do zespołu. Poprzez otwieranie się i mówienie jasno o swoich problemach, proszenie o pomoc, angażowanie w swoje sprawy - skracamy dystans, stawiamy na partnerstwo zamiast na stosunek 'rodzic-dziecko'.
Nie wiem jak wy, ale ja strasznie nie lubię jak ktoś przychodzi do mnie z pozycji wszystko-wiedzącego, niepopełniającego błędów eksperta, który chce mi udowodnić jak wiele jeszcze nie wiem 🙂
Ćwiczenie dla ciebie: przy następnej 'aktywności scrum'owej' (facylitacja spotkania, wyliczanie metryk, wdrażanie nowej praktyki inżynierskiej) poproś osobę z zespołu o poradę.

6. "Jak mogę ci pomóc?" + faktyczna pomoc

Jedna z kluczowych pozycji. Nie ważne, czy pracuję jako SM czy trener czy mentor - podstawowym elementem jest dla mnie pomoc (np. w rozwoju) drugiej osobie czy grupie osób. Przez 'pomoc' rozumiem tutaj nie wrzucanie na siłę zespołowi jakichś praktyk (niestety, zdarzało mi się tak robić) "bo przecież to dla ich dobra", tylko zdiagnozowanie potrzeby i zaadresowanie jej. Nic tak nie zacieśnia relacji jak wzajemna pomoc (więcej na ten temat przeczytacie w "Głaskologii").
Ważne: nie zostawiajmy ludzi z samym "Jak mogę ci pomóc?" i jednocześnie licząc na to, że jednak nic nie będziemy musieli robić ("Może wystarczy pokazać, że w razie czego coś mogę pomóc, ale przecież o nic mnie nie zapyta, bo się na tym nie znam?"). Ludzie będą chcieli zobaczyć efekty. Dodatkowo: moim zdaniem nie jest możliwe zebranie prawdziwych potrzeb od współpracowników, zanim faktycznie nie nawiążemy z nimi relacji (patrz punkty 1-5). Wydaje mi się, że dopiero wtedy otworzą się oni na tyle, żeby ujawnić swoje faktyczne problemy.
Ćwiczenie dla ciebie: pójdź do osoby, z którą współpracujesz i z którą masz zbudowaną już dobrą relację. Wybierz taką osobę, która według ciebie z czymś się boryka (np. zauważyłeś ostatnio niższy poziom energii u tej osoby). Zaproponuj swoją pomoc.

7. Docenienie, podziękowanie - tajna broń

Jednym z najlepszych, moim zdaniem, sposobów na 'dokładanie' środków do naszego kapitału zgromadzonego u innych osób jest docenienie i wzmocnienie. Tak się dobrze składa, że jest to też jedna z podstawowych technik wsparcia rozwoju. Doceniając pozytywne zachowania, wzmacniając osobę w wysiłkach nie dość, że budujemy wzajemną relację, to jeszcze wskazujemy dobry kierunek - wpływamy na kształtowanie pozytywnych postaw. Mając w ręku taki 'oręż', po prostu trzeba z niego korzystać. Nie dajcie się porwać (wygodnemu) podejściu w stylu: "przecież jak nic nie mówię, to wiadomo, że jest dobrze".
Ważne: docenienie, wzmocnienie i podziękowanie - wszystkie te rzeczy powinny być moim zdaniem niezwłoczne, szczere oraz proporcjonalne do poziomu zachowania (czyli nie dziękujemy z różami i czekoladką za ciepłe słowo przy ekspresie do kawy 2 miesiące temu - no chyba, że słowa te odmieniły nasze życie 🙂 ).
Ćwiczenie dla ciebie: każdego dnia przez następny tydzień znajdź czas aby docenić lub podziękować za coś komuś w pracy. Jeśli nie widzisz takich rzeczy - patrz ćwiczenie z punktu 5.

W skrócie: Bądź mądry - zbuduj relacje. Nie bądź jak ten bohater.

 

Drugi w tym miesiącu wywiad poruszający temat początków ścieżki Scrum Mastera. Tym razem swoimi doświadczeniami podzielił się Łukasz Olczyk - współorganizator wrocławskiej społeczności Agile Addicted 🙂

2

Lubię słuchać opowieści, w których pojawia się takie zdanie:

"Scrum nie zadziałał, więc przeszliśmy na kanbana".

Uśmiecham się wtedy szeroko (w duchu 🙂 ) i dopytuję jak to faktycznie wyglądało z tym "Scrum nie zadziałał".

Po wysłuchaniu kilku takich historii, dochodzę do wniosku, że kanban nadal jest w niektórych miejscach traktowany jako 'scrum bez commitmentu na sprint'. Pal licho nawet fakt, że od kilku lat nie ma już słowa 'commitment' w scrum guide! Nie udaje się 'dowozić', zespół jest pod presją (biedny zespół...) bo klient (o zgrozo!) oczekuje regularnie dostarczanych paczek z wartością? Zrezygnujmy ze spotkań, celów i tych niedobrych 'commitment'ów' i przejdźmy na 'kanbana' - pójdzie nam szybciej 😀

Są jednak sytuacje, kiedy kanban może być przydatny - czy to jako suplement scrum'a (o tym napiszę kiedy indziej) czy to jako "samodzielna" implementacja. Dzisiaj zajmiemy się tym drugim przypadkiem - opiszę pewną historię z życia i pokażę w jaki sposób podejście przepływowe (i filozofia 'pull' zamiast 'push') pomogła ograniczyć znacznie lead time w pewnym projekcie. I jednocześnie - dlaczego nie zrobiło to żadnego wrażenia na managemencie 🙂

Trzy lata temu pracowałem w pewnej międzynarodowej firmie telekomunikacyjnej we Wrocławiu. Zmieniłem dopiero co dział i rozpocząłem pracę w dwóch rolach - Scrum Master jednego z zespołów i 'Agile Coach' tegoż działu (gdzie tej drugiej roli raczej wtedy nie rozumiałem :). Zespoły w tym dziale pracowały w "scrumie" i dostarczały część produktu, która co rok (później pół roku) była składana w jeden release. Od czasu do czasu niektóre zespoły wchodziły (na okres do 3 miesięcy) w tak zwany tryb 'maintenance', gdzie ich głównym zadaniem było ograniczenie liczby błędów w systemie przed końcem danego release'u.

Kiedy przyszedłem do swojego zespołu, właśnie rozpoczynał się taki 'tryb' maintenance, który jak się później okazało - trwał właśnie ok. 3 miesiące. Pomyślałem sobie wtedy - super, jest okazja do przetestowania kanbana i pokazania wszystkim (ha!), że jest to świetne narzędzie i w ogóle. Zaczęliśmy stopniowo - od sprawdzenia jak wygląda nasz proces przepływu błędów przez zespół, jak możemy zaadaptować naszą tablicę (czyli podobnie do tego, o czym już pisałem). Kolejnym krokiem było przekonanie managementu (a także 'koordynatorów od błędów' - tak, były takie pozycje w dziale 🙂 do tego, że ograniczenie WIP jest dobre i nie prowadzi to do tego, że ludzie 'się obijają'. Ustaliliśmy, że możemy zacząć eksperyment.

Zespół ustalił sobie limity WIP na naszej tablicy. Szybko odkryliśmy, że ustawienie limitu na 6 (ilość członków zespołu) w KAŻDEJ kolumnie sprawia, że możemy mieć 18 błędów na raz otwartych w zespole - a to trochę mija się z celem :). Koniec końców zdecydowaliśmy się zmniejszyć limity i zobaczyć jak to wpłynie na pracę zespołu - a konkretnie na lead time (od przyjęcia błędu do zespołu do wypuszczenia poprawki 'dalej') i cycle time (od rozpoczęcia pracy nad błędem do 'wypchnięcia' poprawki).

kanban_board

Warunkiem sprzyjającym do przeprowadzenia eksperymentu było też to, że w poprzednim roku zespół także był w trybie 'maintenance' przez 3 miesiące i mogłem także dotrzeć do danych typu lead time i cycle time w tamtym okresie. Co nam się udało osiągnąć dzięki wprowadzeniu kanbanowych zasad i filozofii (oraz budowaniu zespołu, kompetencji i wdrażaniu praktyk inżynierskich 🙂 )? Skrócenie średniego lead time i cycle time dla poprawy błędów:

limit_wip_rezultaty

Jak zmieniła się ilość błędów naprawionych w danym okresie? Nie zmieniła się - być może nawet spadła o kilka procent. Nie zawsze 'system' był w stanie zapewnić stały (równomierny) przypływ nowych błędów do poprawy, a 'przepustowość' zespołu się nie zmieniła.

Czy w takim razie udało mi się przekonać management do tego, że kanban jest świetny i powinniśmy we wszystkich zespołach tak pracować? W skrócie - nie. Nadal słyszałem wypowiedzi w stylu:

"2 błędy na osobę w tym samym czasie jest optymalną ilością - przecież jak jeden jest zablokowany lub czeka się na odpowiedź od testera, to developer może w tym czasie poprawiać drugi, a nie siedzieć bezczynnie".

Moją reakcją było wtedy oczywiście obruszenie i stwierdzenie - nie znacie się 🙂 Nie mogłem zrozumieć dlaczego, mimo przedstawienia twardych dowodów na 'skuteczność' tego podejścia nie zyskałem wsparcia od sponsorów. Teraz jak na to patrzę z perspektywy czasu i dodatkowego doświadczenia to zaczynam rozumieć.
Próbowałem sub-optymalizować jakąś cząstkę całego przepływu wartości - bardzo małą cząstkę. Dla organizacji nie było kluczowe ograniczanie 'lead time' - nie w sytuacji, kiedy wdrożenie poprawek odbywa się raz na pół roku (częściej, jeśli są faktycznie 'krytyczne' problemy). W takiej sytuacji ustawiane były cele ilościowe - np. ile max. błędów może być otwartych na koniec danego release'u. Nie miało znaczenia to, czy poprawki będą dostarczane regularnie w trakcie pracy, czy wszystkie na koniec ostatniego dnia - byleby by były zrobione i był czas na ich 'odpowiednie' (DoD się kłania) przetestowanie. Tak naprawdę to, że skróciliśmy średni lead time poprawy błędów w zespole z 90 dni do 10 nie miało znaczenia, jeśli Time to Market cały czas wynosił min. pół roku. Co więcej - management był właśnie odpowiedzialny za to, aby te cele ilościowe były spełnione - więc optymalizacja lead time i cycle time, którą zaproponowałem, nie adresowała ich najważniejszych potrzeb.

Nie pracuję już w tak dużej organizacji, ale wiem też teraz ciut więcej i rozumiem jak ważne w przypadku przepływu jest spojrzenie na 'cały obrazek' i szukanie wąskich gardeł w całym systemie. Warto też moim zdaniem zwrócić uwagę na to, co mierzymy jako organizacja - jakie wyznaczamy sobie cele. Nieodpowiednie ustawienie tych rzeczy może prowadzić do konfliktu interesów 'niżej' w strukturze organizacji. Jako Scrum Master powinniśmy starać się zrozumieć potrzeby różnych interesariuszy - także managementu. Zaadresowanie tych potrzeb może w znacznym stopniu ułatwić wprowadzanie 'dobrych zmian' później 🙂

Praca z zespołami jest bardzo ważna i jednocześnie nie może być jedynym obszarem zainteresowania Scrum Mastera. Możemy stworzyć najbardziej efektywny zespół na świecie - jednak jeśli nie jest on jedynym elementem 'układanki' - wtedy niekoniecznie przyśpieszymy dostarczanie wartości naszym klientom 🙂

Witajcie!

Dzisiaj mam dla was filmik - wywiad z Izabelą Kowalik o jej początkach Scrum Masterstwa i co z tego wyniosła. Zapraszam do oglądania i komentowania 🙂

W pracy spotkałem się z różnymi formami wizualizacji sprint backlogu czy przepływu wartości przez system. Od najprostszych fizycznych tablic typu 'to do, ongoing, done' do bardzo rozbudowanych elektronicznych wersji (Jira, TFS, Redmine, Target Process). W większości przypadków to zespół miał możliwość dostosować sobie swoją scrumową (lub kanbanową) tablicę do swoich potrzeb. Czasem wymagało to prowadzenia (niestety) dwóch tablic - gdyż np. elektroniczna wersja wymagana była do zapewnienia transparencji do klienta lub PO, który znajdował się w innej lokacji. Spotkałem się też z ciekawymi i zakręconymi tablicami - szalonymi eksperymentami 🙂 Łączyło je wszystko jedno - były tworem eksperymentów. I takim eksperymentem zajmiemy się dzisiaj.

Zacznijmy od tego po co nam właściwie tablica?

  • Pokazujemy w jaki sposób (jakimi zadaniami) zrealizujemy cel sprintu
  • Wiemy ile jeszcze pracy nam zostało, a co już jest zrobione - czyli gdzie jesteśmy obecnie
  • Diagnozujemy gdzie są potencjalne ryzyka (np. wąskie gardła)
  • W jaki sposób najbardziej optymalnie podzielić się pracą w zespole - codzienne planowanie
  • Zapewniamy transparencję naszej pracy do interesariuszy (co buduje zaufanie)
  • Wizualizujemy stan akcji usprawniających
  • Oraz aby spełnić inne potrzeby, o których w tej chwili nie pomyślałem 🙂

Chciałbym wam przedstawić ewolucję pewnej tablicy pewnego zespołu (od momentu, w którym do nich dołączyłem).
Przy okazji bardzo dziękuję chłopakom, że pozwolili mi się tą historią z Wami podzielić. Sam proces zmiany i techniki były wspierane co prawda przeze mnie, ale cały wkład (kształt procesu, tablicy) to już całkowicie zasługa samego zespołu.

Wersja początkowa

Tablica wyglądała tak:

stara tablica - pulic

Moją pierwszą reakcją było: o co chodzi w tej tablicy? Sam kiedyś eksperymentowałem z łańcuchem krytycznym przy planowaniu sprintu, ale nigdy rezygnując jednocześnie z tablicy przepływowej. Na szczęście nie zacząłem od rewolucji i 'narzucenia' jedynego słusznego kształtu tablicy. Postanowiłem poobserwować, zadawać pytania i odzwierciedlać (w skrócie - marudzić 😉 ).
Po pytaniach o kształt tablicy, zespół wymienił następujące korzyści, które chcieli uzyskać:

  • możliwość planowania daty ukończenia zadania
  • co za tym idzie - uzyskać większą przewidywalność ukończenia zadań
  • dodatkowo: możliwość rozplanowania sobie pracy i zobaczenia zależności (kto gdzie jest zajęty) -> w skrócie, wstęp do łańcucha krytycznego

To co ja zauważyłem to:

  • duże zadania (po kilka dni)
  • rozpoczynanie wielu rzeczy na raz
  • karteczki nie odzwierciedlały faktycznych stanów zadań
  • nie wiadomo kiedy mamy coś 'DONE'
  • zadania często nie kończyły się w dniach zaplanowanych przez zespół
  • (po jakimś czasie) członkowie zespołu nie wiedzieli co się dzieje z zadaniami, kiedy brakuje w danym dniu kogoś, kto się tym zadaniem zajmował

Co było dalej

Krok pierwszy - obserwacja, odzwierciedlenie, potrzeba zmiany.

  • odzwierciedlałem do zespołu każdy przykład niejasności, braku spójności tablicy ze stanem faktycznym
  • zadawałem pytania ("czy to już jest DONE, czy jeszcze nie?"; "to w jaki sposób te zadania przybliżą nas do celu sprintu?" i inne takie 🙂

Po jakimś czasie część osób w zespole zaczęło otwarcie mówić, że tablica jest dla nich nieczytelna i nie pomaga w planowaniu zadań. Porozmawiałem w między czasie z doświadczonym członkiem zespołu - przedstawiłem pomysł wizualizacji procesu dostarczania funkcjonalności w produkcie (produktach) rozwijanych przez zespół. Zasugerowałem też, że są inne opcje wizualizacji - np. tablica stanów. Jednym słowem - wzmocniłem potrzebę zmiany i zebrałem koalicję 🙂

Krok drugi - wizualizacja strumienia wartości.

Zrobiliśmy sobie ćwiczenie, gdzie rozrysowaliśmy cykl życia naszych wymagań. Celem było uświadomienie sobie nawzajem jaką ścieżkę musi przebyć potrzeba klienta od 'poczęcia' do dostarczenia. Skupiliśmy się na stanie rzeczywistym, nie na 'idealnym'. Taki był wynik:

mapowanie strumienia wartosci - public

Krok trzeci - draft nowej tablicy.

W ostatni dzień sprintu, już po spotkaniach zrobiliśmy z zespołem draft tablicy. Skupiliśmy się na tym, aby zwizualizować potencjalne 'wąskie gardła' - czyli stany oczekiwania zadań. Okazało się, że możemy rozbić przepływ na dwie części - dla zadań oraz wizualizacja przepływu funkcjonalności na poziomie Product Backlogu.
Co ciekawe - pojawił się też pomysł aktualizacji samego procesu release'u softu tak, aby składał się on z mniejszej liczby kroków. Postanowiliśmy skorzystać z okazji i zrobić to.

nowa_tablica_22_04_draft - public

Krok czwarty - tablica v0.1

Pierwszy dzień sprintu - stworzyliśmy pierwszą wersję tablicy.

nowa_tablica_27_04 - public

Dalsze kroki:

Pierwsze obserwacje:

  • Wow, ale mamy dużo tych stanów
  • Dolna część tablicy (ścieżka US) jest nieużywana za bardzo (jeszcze)
  • Po 2 dniach sprintu udało się zamknąć 9 zadań (w tym 90% akcji z retrospekcji) -> wcześniej w pierwszym tygodniu sprintu (z trzech) udawało się zamknąć 2-3 zadania.

Dalsza obserwacja i wyciągnięcie wniosków z zespołem (po iteracji), w szczególności:

  • jak tablica wpłynęła na transparencję zadań
  • co się stało z cycle time dla historyjek w sprincie
  • jak wpłynęło to na naszą przewidywalność
  • jak oceniają tablicę pozostali interesariusze (np. PO)
  • czy ilość stanów spełnia swoją rolę? Czy dolna część tablicy będzie wartościowa?
  • w jaki sposób praca z tablicą może nam wskazać drogę skracania procesu delivery?

Podsumowując: tablica scrum'owa (czy kanbanowa) jest moim zdaniem jednym z podstawowych narzędzi pracy zespołu, a co za tym idzie - także jednym z obszarów zainteresowań Scrum Mastera. Warto moim zdaniem zachęcać zespół do eksperymentowania z tym narzędziem - jednocześnie przedstawiając dobre praktyki czy to z branży czy z własnego doświadczenia 🙂
Jednocześnie warto pamiętać, że to co zadziałało w jednym miejscu, niekoniecznie sprawdzi się w innym.

A jak jest u Ciebie? Czy ośmielisz się wrzucić zdjęcie swojej tablicy?

good job

Feedback czyli po polsku informacja zwrotna. Co to właściwie znaczy w naszej kulturze? Mam wrażenie, że mamy z tym duży problem jako społeczeństwo. Zarówno z udzielaniem jak i proszeniem o nią. Kiedy spotkałeś ostatnio kogoś, kto poprosił Cię o informację zwrotną na temat Twojej współpracy z tą osobą i jeszcze na koniec powiedział "dziękuję"?
Żyjemy w środowisku, w którym nadal panuje presja sukcesu. Rzadko widzę zespół czy projekt, w którym panuje na tyle bezpieczna atmosfera, która pozwala popełnienie błędu bez 'straszliwych' konsekwencji. A przecież jest to podstawa eksperymentowania, które prowadzi do innowacyjnych produktów (zamiast do po prostu 'wyrobnictwa'). W związku z tym gdzieś tam z tyłu głowy czai się strach przed byciem ocenianym. Bo przecież ocena naszych działań wiąże się z ryzykiem tego, że usłyszymy, że robimy jednak coś 'nie tak'. A jeszcze jakby usłyszeli to inni w naszej organizacji... nie do pomyślenia! Lepiej siedzieć cicho i się nie narażać. W drugą stronę podobnie - wszelkie pochwały i docenienie traktujemy podejrzliwie. No bo przecież najczęściej jest to wstęp do jakiegoś "...ale", prawda?

Miałem kiedyś pewnego przełożonego. Pracowaliśmy w firmie, w której nie było kultury udzielania regularnej informacji zwrotnej. Najczęściej kontakt z przełożonym odbywał się podczas corocznej ewaluacji jakości pracy danego pracownika. Kiedy w końcu spotkaliśmy się w trakcie tego procesu, podzieliłem się z nim moją potrzebą - poprosiłem bo o częstsze rozmowy. Chciałem wiedzieć, czy moja praca przynosi dobre efekty według niego, co robię dobrze, a nad czym muszę jeszcze popracować. Usłyszałem od niego: "ale przecież wiadomo, że jak cię nie wołam do siebie, to jest wszystko ok". Dla mnie to nie było 'ok'.

Wszystko to składa się na moją obserwację, że bardzo rzadko prosimy o feedback. Boimy się, że dostaniemy tyle rzeczy negatywnych, że nie będziemy wiedzieć co z nimi zrobić. Wychodzimy z przeświadczenia, że jak ktoś ma z nami 'problem' to w końcu coś nam powie. A jeśli już odważymy prosić o informację zwrotną, jest to najczęściej w formie "powiedz mi, co zrobiłem/am źle". Wiele osób mówi mi, że to właśnie ten negatywny feedback jest dla nich najważniejszy. A to przecież tylko "jedna strona mocy" jak mawia mój znajomy. Pełna informacja zwrotna powinna zawierać obie rzeczy - zarówno te rzeczy, które dostrzegamy jako pozytywne (postępy) jak i te, które według nas powinno się poprawić (dalszy rozwój).

Nie mamy doświadczenia z dobrej jakości informacją zwrotną, w związku z tym sami też jej nie udzielamy. W wielu zespołach czy grupach spotkałem się z opinią, że "ogólnie to jest fajnie, ale ten facet to mi już gra na nerwach. I to nie jest tylko moja opinia".  Na pytanie "czy już mówiłeś to temu człowiekowi" pada najczęściej odpowiedź "to jest tylko praca, trzeba nauczyć się żyć z tymi ludźmi". Czyli jednym słowem - nie wypada nic mówić, bo "jeszcze narobimy sobie wrogów". Nie warto o nic pytać, bo jeszcze otworzymy niepotrzebnie drzwi do "niechcianej" oceny naszej pracy.

Jak przełamać ten zaklęty krąg kiedy jesteś liderem lub Scrum Masterem w zespole? Moim zdaniem warto najpierw sprawdzić jakie są obawy grupy/zespołu przed udzielaniem i otrzymywaniem informacji zwrotnej. Możesz to zrobić np. krótkim ćwiczeniem:

  • Podziel członków grupy/zespołu na 3 mniejsze grupy
  • 1sza grupa pisze o obawach związanych z UDZIELANIEM feedbacku
  • 2ga grupa pisze o obawach związanych z PROSZENIEM o feedback
  • 3cia grupa pisze o tym dlaczego warto udzielać i przyjmować feedback
  • Omówienie - wspólnie omawiacie obawy oraz mapujecie te obawy z pozytywnymi aspektami z grupy trzeciej

Kiedy już przepracujecie obawy, które mają członkowie grupy/zespołu, możesz przedstawić zasady udzielania dobrej informacji zwrotnej (jak te dobre zasady zaadresują obawy?) oraz przećwiczyć z grupą jakąś konkretną strukturę (polecam SPINKĘ).

Najczęstsze obawy (z mojego doświadczenia) i jak je zaadresować:

Obawa Jak zaadresować?
Urażę kogoś informacją zwrotną Przygotuj się dobrze - powiedz osobie, której chcesz udzielić informacji zwrotnej po co to robisz, do jakiej sytuacji się odnosisz. Zapewnij o dobrowolności odbioru informacji zwrotnej - ile z tego weźmie dla siebie, to jej. Zapewnij ją, że nie chcesz jej zmienić, a tylko pokazać jej potencjalny 'ślepy punkt' i twoje obeserwacje/odczucia z tym związane.
Słyszałem, że zawsze musi być jakiś pozytyw w feedbacku. Czasem po prostu jednak nie widzę niczego pozytywnego w danym zachowaniu i strasznie mnie to gryzie. Może lepiej w związku z tym nic nie mówić? Czasem lepiej powiedzieć niż zostawić to 'na później' kiedy negatywne emocje mogą narastać i przeszkadzać w normalnej pracy. Zastanów też się co chcesz osiągnąć mówiąc akurat to tej osobie. Jeśli chcesz powiedzieć o swoich emocjach i potrzebach w związku z zachowaniem danej osoby, możesz skorzystać z komunikatu asertywnego (np. komunikat "Ja" lub FUKO).
Boję się, że ktoś może odebrać informację zwrotną jako atak na swoją osobę. Ponownie kluczowe jest przygotowanie. Przeanalizuj dokładnie co chcesz powiedzieć i dlaczego. Zastanów się w jaki sposób dzięki Twojemu feedbackowi pomożesz tej drugiej osobie. Zastanów się czy ta osoba będzie coś w stanie zrobić z tą informacją? Czy to coś, nad czym może faktycznie popracować? W trakcie rozmowy odpowiadaj na pytania, podawaj konkretne przykłady zachowań - oceniaj zdarzanie, nie osobę. Zapewniaj, że jest to twój (i tylko twój) punkt widzenia.
Feedback i tak niczego nie zmieni. Warto na koniec rozmowy zapytać się drugiej osoby co bierze dla siebie z Twojego feedbacku. Zaoferuj pomoc w pracy nad obszarami rozwojowymi (przez chociażby zaproponowanie kolejnej sesji feedbackowej z informacją o postępach). No i warto zaakceptować, że jedynymi osobami, które możemy zmieniać to my sami. Innym możemy tylko odsłaniać 'ślepe punkty' i pokazywać konsekwencje (i alternatywy) ich działań.
Nie wiem kiedy mam dawać informację zwrotną. Jak najszybciej (z rozwagą oczywiście 😉 ). Wtedy moim zdaniem efekt jest najbardziej intensywny. Ważne: doceniać osoby możemy w szerszym gronie. Feedback pozytywny i negatywny (lub komunikat asertywny) lepiej dawać w cztery oczy

A jak u was wygląda kultura udzielania informacji zwrotnej? Jakie macie doświadczenia? Zapraszam do komentowania.