Ramzes umarł, Kryzys żyje


Nasz proces deploymentu


Apokaliptycznych wizji ciąg dalszy. Jak wspomniałem we wstępniaku, proces deploymentu nowych funkcjonalności jest dość skomplikowany. SCRUM’em objeliśmy jedynie fazę developmentu i testów na środowiskach developerskich. Reszta procesu wygląda (w pewnym uproszczeniu) mniej więcej tak:


Dla tych którym nie chce się zagłębiać w powyższy diagram lista co ciekawszych właściwości procesu:
  1. Proces skomplikowany i przejście go trwa bardzo długo (średnio około miesiąca),
  2. Przez proces przepływają nowe wersje komponentów, a nie funkcjonalności (jedna funkcjonalność może wymagać zmiany w kilku komponentach),
  3. Spora część procesu znajduje się poza bezpośrednią kontrolą zespołu,
  4. Po stronie organizacji klienta istnieje trylion różnych zespołów IT, nad którymi nasz klient (sponsor, PO, zespół biznesowy) nie ma bezpośredniej kontroli (znajdują się w innym pionie organizacji).

Problem


Teraz najwyższa pora opisać jak to wyglądało w praktyce. Otóż przez proces przepływała olbrzymia ilość zgłoszeń o deploy komponentów. Część z nich utykała w różnych miejscach procesu, część  w ogóle ginęła w niewyjaśnionych okolicznościach, części nie udało się zainstalować z powodu braku innych komponentów, od których były zależne, wreszcie część jakimś cudem udawało się „przepchnąć” na środowisko produkcyjne. W tym ogólnym galimatiasie co jakiś czas zespół biznesowy ni stąd, ni zowąd rzucał jakąś datą: np. funkcjonalność XYZ ma być gotowa za tydzień bo umówiliśmy się z klientem na testy. Oczywiście funkcjonalność, mimo że gotowa od strony developerskiej, znajdowała się w bliżej nieokreślonym stanie w procesie deploymentu. Jednym słowem KRYZYS. W takich przypadkach zbieraliśmy sztab kryzysowy, zakasaliśmy rękawy i do roboty!! A robota polegała na szaleńczym „przepychaniu” zgłoszeń wszelkimi możliwymi sposobami… co oczywiście przynosiło skutek odwrotny od oczekiwanego i funkcjonalność „przechodziła” przez proces deploymentu jeszcze dłużej. Ramzes umarł, kryzys żyje!!!

Rozwiązanie


Ktoś mógłby powiedzieć, że fundamentalnym problemem jest tutaj „zasięg” SCRUM’a, który nie obejmuje procesu deploymentu. Niestety, mimo że takie podejście pozwoliło by nam rozwiązać większość wymienionych powyżej problemów, w naszym przypadku nie jest możliwe do zastosowania. Przeszkodami są tutaj:
  1. Zespół developerski nie ma kontroli nad sporą częścią procesu, 
  2. Proces trwa bardzo długo, a z powodu opisanego w punkcie 1. zespół developerski nie ma możliwości skrócenia go,
  3. Wydłużenie sprintów tak, aby mogły objąć development + deployment nie wchodzi w grę z powodu dużej dynamiki biznesu klienta (cały czas coś się zmienia, a długie, miesięczne sprinty spowodowałyby nieakceptowalną dla zespołu biznesowego „bezwładność” funkcjonalności).

Debatując nad problemem doszliśmy do wniosku, że w naszej sytuacji najistotniejszą rzeczą, jaką musimy zrobić, jest opanowanie chaosu. Wszyscy muszą mieć wyraźny wgląd w aktualną sytuację, jaka panuje w procesie deploymentu. W świecie Lean Managementu istnieje oczywiście rozwiązanie naszego problemu i nazywa się Visual Management. Dodatkowo aby ułatwić wdrożenie nowego rozwiązania oraz uczynić go atrakcyjniejszym dla zespołu postanowiłem „ubrać go w szaty” zabawy. I tak powstała gra planszowa „Kryzys”. 


Czym jest gra planszowa „Kryzys” ?


Jest to pewna wariacja tablicy Kanbanowej (nie mylić z tablicami często wykorzystywanymi w SCRUM’ie do realizacji Sprint Backlogu), która reprezentuje nasz proces deploymentu. Przez pola przedstawiające poszczególne kroki procesu, wędrują żetony funkcjonalności (a nie tak jak do tej pory komponenty). Jednak w porównaniu do typowej tablicy Kanbanowej posiada ona kilka innych elementów. Są to:

  • Żetony „Kryzysu” (reprezentowane przez bombę atomową) – jeśli widzimy zagrożenie, że dana funkcjonalność może nie „przejść” procesu deploymentu na czas przypinamy do niej żeton „Kryzysu”,
  • Pole z Datami – które reprezentują daty dostarczone przez klienta,
  • Punktację dla graczy biorących udział w grze.

Nasza tablica wygląda mniej więcej tak:


Tura gry „Kryzys” odbywa się codziennie o stałej porze (za wyjątkiem dni planningów) i bierze w niej udział delegacja z zespołów: developerskiego, testerów i IT.

Gorąco zachęcam też do zapoznania się z instrukcją do gry, którą znajdziecie w pliku poniżej:

Instrukcja do gry "Kryzys"

Problemy Wyzwania


Visual Management pomógł nam opanować chaos, a przedstawienie pomysłu jako gry planszowej uczyniło to rozwiązanie atrakcyjnym dla zespołu. Należy jednak pamiętać, że dla developerów zarządzanie procesem deploymentu to zło konieczne, którym najchętniej w ogóle by się nie zajmowali. Dlatego z czasem entuzjazm w zespole osłabł, jako ScrumMaster musiałem (!?) pilnować, aby spotkania kryzysowe odbywały się regularnie, frekwencja również bardzo zmalała. Problemem również okazało się  wyciąganie (a właściwie to wydzieranie) dat i terminów od zespołu biznesowego. Niemniej jednak przedsięwzięcie uważam za bardzo udane… wprowadziliśmy je półtora roku temu i wciąż działa. Pomogło nam też zapobiec wielu poważnym  kryzysom.

Przyszłość

Dlaczego nie zastosowaliśmy Kanbana? Odpowiedź jest prosta: tak jak SCRUM, Kanban jest koncepcją prostą do zrozumienia, lecz trudną do stosowania, szczególnie dla zespołu biznesowego osadzonego w rzeczywistości korpo(racji). Gra „Kryzys” pozwoli na łagodne „wejście” w świat Kanbana… świat w stronę którego zmierzamy (przynajmniej w kwestii deploymentów, ponieważ oczywiście ze SCRUMa nie rezygnujemy). W tym momencie, gdy zaczniemy wprowadzać np. WiP limity, każdy zrozumie dlaczego to robimy. W końcu wielokrotnie podczas gdy w „Kryzys” widział jak ten czy tamten krok procesu korkuje się powodując znaczne utrudnienia dla wszystkich deploymentów.

Wyciągnięte lekcje


  1.  W firmie/projekcie zmiany wprowadza się trudno i mozolnie. Dotyczy to szczególnie projektów, które mają styczność z rzeczywistością korpo(racyjną)
  2. Nie oznacza to, że nie warto próbować. Jeśli nie możesz przeskoczyć problemu to spróbuj go obejść
  3. Zmiany wprowadzaj małymi kroczkami (nie wszystko naraz)
  4.  Zespół zaadaptuje zmiany szybciej, jeśli spróbujesz ją uczynić dla nich … po prostu fajną (fun factor !!!)
  5. „Krzywa nauki” będzie mniej stroma, jeśli upewnisz się, że:
    1. Wszyscy wiedzą, dlaczego wprowadzamy zmianę / nowy element procesu
    2. Zasady są jasne i przejrzyste
  6. Przygotuj się na to, że w wypadku zmian typu „zło konieczne” zapał z czasem osłabnie.
  7. W świecie Agile poza SCRUM’em istnieją też inne frameworki. Większość z nich ma tą ciekawą właściwość, że nie wykluczają się nawzajem, lecz raczej uzupełniają (najczęściej stosowany mix to SCRUM + XP, ale nie jest to jedyna możliwość)



Categories: , ,

Leave a Reply