Coraz częściej otrzymuję zapytania dotyczące problemów związanych z wdrożeniami metodyki Scrum na szerszą skalę. Przez "szerszą" mam na myśli transformację organizacji (firm, departamentów) 50-250 osobowych, często rozproszonych, czy to pomiędzy piętrami, budynkami, miastami, czy po świecie. Zwykle zespoły te zajmują się zarówno rozwijaniem oprogramowania (wytwarzaniem nowych funkcjonalności) jak i utrzymaniem tego co już opracowano i wydano klientowi (klientom) wcześniej (w ekstremalnych przypadkach kilkanaście lat temu). Można zatem założyć, że mamy do czynienia z organizacjami o ustabilizowanych metodach działania (nawet jeśli to "ustabilizowanie" oznacza chaos), ustalonej strukturze organizacyjnej, nazewnictwie stanowisk służbowych oraz wypracowanych na przestrzeni lat procesach wytwórczych, technologii, relacjach, polityce wewnętrznej itd.
Przede wszystkim bardzo mnie cieszy ten stan rzeczy, gdyż oznacza, że w Polsce, podobnie jak na świecie, nurt agile rozwija się dynamicznie i z partyzanckiego, "piwnicznego" ruchu, przeradza się w dostrzegany przez kadry zarządcze pełnoprawny model realizacji projektów. Martwi mnie jednak fakt, iż w starciu z twardym biznesem, istniejącymi strukturami i wypracowanymi przez lata sposobami działania (polityką), idee ruchu agile są nader często marginalizowane. Wyławiane i wykorzystywane są pojedyncze elementy konkretnych metodyk (Scruma, XP, DSDM-a), natomiast pomijane są wartości stojące u podstaw tego ruchu - jednym słowem skupiamy się na "jak?", a nie na "dlaczego? po co?". Ken Schwaber nazywa taki sposób działania "Scrum, but", Martin Fowler "flaccid Scrum", ja nazywam tak powstałe procesy produkcyjne "protezami", "pseudoagile'm" albo "prawiescrumem".
Na marginesie dodam, że nie tak dawno poznałem określenie "wagile" (waterfall agile), opisujące proces w swojej istocie bardzo kaskadowy - ustalenie zakresu na początku cyklu, testowanie i wdrożenie na jego końcu, a jednak podzielony na iteracje, z całą ceremonią z nimi związaną.
Planowanie iteracji, w rozumieniu osób stosujących pseudoagile'a to odkrojenie z kompleksowego harmonogramu kolejnych kilku tygodni, realizacja kolejnych faz produkcyjnych następuje bowiem (po staremu) stopniowo. Przygotowanie wymagań w kilku krokach, kodowanie w kilku kolejnych i testowanie w kolejnych. Codzienne spotkania i sesje demo to narzędzie precyzyjnego, chirurgicznego wręcz, zarządzania zasobami - co, kto, kiedy i na kiedy. I wszechobecne "mendejsy" jako jedyna miara wartości wytwarzanego oprogramowania - "mendejsy" wypracowane muszą równać się "mendejsom" zaplanowanym. Jednym tchem można tu jeszcze dorzucić doskonalenie multitaskingu jako sztuki zawalania kilku projektów na raz i właściwie grunt pod klęskę mamy przygotowany. Jak bardzo wykrzywiony jest to model okazuje się zwykle końcu takiego procesu, kiedy klient (znowu) nie dostaje czego oczekiwał (czasem nie dostaje zupełnie nic), zespół (znowu) jest zdemotywowany, a kierownicy - liniowi i projektów - (znowu) dostają po łbach za to, że (kolejny) projekt zaliczył klapę, albo ciągnie się w nieskończoność. Miało być pięknie (bo teraz będziemy edżajl), a wyszło jak zwykle. A coach jest be, bo pokazuje nam to wszystko palcem. Gdzieś zapomniano, że siłą napędową modelu ewolucyjnego jest zmiana. Przenosimy się z domeny planowania czynności (zadań) na planowanie funkcjonalności (cech) produktu, bez motoru napędowego w postaci zmian ani rusz. Tam zmiana była naszym wrogiem, tu jest sprzymierzeńcem. Ta zupełnie podstawowa zasada ruchu agile znika przykryta przygotowanym na początku projektu harmonogramem, pociągając za sobą zawalenie się kolejnego filara zwinności - samoorganizacji zespołu.
Przy każdej możliwej okazji - szkoleń, wykładów, konsultacji - uczulam moich słuchaczy na fakt, iż "myślenie kaskadowe" jest silniejsze niż nam się wydaje. Może się ono przejawiać w fazowości procesu (zauważenie tego aspektu jest akurat trywialne, chyba, że proces został odświeżony farbą marki "wagile" i trzeba trochę zdrapać żeby się przekonać), może również być ukryte w strukturze organizacyjnej (piony funkcjonalne, struktura macierzowa ze spinającymi komunikację kierownikami projektów), procedurach kontraktowania i budżetowania projektów oraz, co chyba najtrudniejsze do wychwycenia, w mentalności osób biorących udział w przedsięwzięciu. Niechęć do współpracy i konfrontacji rezultatów pracy z klientem i jego oczekiwaniami, niechęć do podnoszenia poprzeczki inżynierskiej, niechęć do doskonalenia procesu produkcyjnego i wyciągania nauki z popełnionych błędów, ba... niechęć do przyznania głośno, że niektóre procedury po prostu nie działają i miliony wymówek z tym wszystkim związanych. "Jesteśmy agile, bo refaktorujemy już drugi sprint", "Świetnie, a jakie jest pokrycie tego kodu testami? Ile automatycznych testów w czasie tych dwóch sprintów powstało?", "...Mmmm... żadnego. A pokrycie na razie wynosi zero, bo testy PM zaplanował na 8. sprint." - brzmi (dumna) odpowiedź. Uff... Tego typu anegdoty mógłbym przytaczać (niestety) w nieskończoność.
Ale po co o tym wszystkim piszę? Ano dlatego, że czas już chyba pójść o krok dalej - nie tylko agile dla zespołów, ale też agile dla organizacji, departamentów, pionów i całych firm. Nie wystarczy poszatkować harmonogram na "sprinty" i zagonić programistów do planning pokera (w "mendejsach", a w najlepszym razie w punktach przeliczanych przez PM-a na "mendejsy"). Agile warto wdrażać na serio, agile może stanowić podstawę działania. Owszem, potrzebna będzie szeroka i głęboka zmiana, sięgająca fundamentu, na którym opiera się organizacja. Taką zmianę można zainicjować i można z sukcesem przeprowadzić. Warto jednak najpierw przemyśleć zbiór swoich wartości i przekonań, odpowiadając na pytanie po co nam agile. Odpowiedź będzie stanowić fundament, na którym tranzycja, często długa i żmudna, zostanie oparta.
Design Patterns: Elements of Reusable Object-Oriented Software
