W swojej karierze miałem okazję pracować lub przyglądać się wielu różnym projektom o bardzo różnej skali trudności i wielkości. Od jedno lub dwuosobywych poprez małe zgrane kilkuosobowe zespoły aż do wielkich przedsięwzięć realizowanych przez dziesiątki programistów.  Ale tak naprawdę do napisania tego cyklu artykułów sprowokowała mnie publikacja na którymś portalu społecznościowym (bodajże linkedin) w której autor opisywał, że jest zmęczony Agile. W treści było jeszcze, że woli zorganizowany chaos jak nazwał sposób developmentu w małej grupie programistów bez ceremonii Agilowych

Miałem do czynienia z różnymi rodzajami zarządzania projektem począwszy od wrzasku prezesa poprzez zorganizowany i niezorganizowany chaos, niejawne zarządzanie aż po wielkie zorganizowane projekty. Wiele się nauczyłem obserwując ludzkie interakcje i wielokrotnie mając okazję kontaktować się z różnymi uczestnikami przedsięwzięć i obserwując ich różne perspektywy na te same problemy. Sam będąc zarówno developerem z wieloletnim doświadczeniem jak i Scrum Masterem i konsultantem miałem okazję obserwować projekt zarówno od strony bezpośrednio wykonawczej jak i od strony organizacyjnej.

Zacznijmy od początku – większość firm wytwarzających oprogramowanie deklaruje się, że jest Agile. W większości przypadków oznacza to tyle, że robi się dzienne spotkania zwane przez uczestników w różny mniej lub bardziej wyszukany sposób i inne spotkania znane ze Scrum-a lub np. SAFe. Czy to wystarczy, aby być naprawdę Agile albo czy powinniśmy w ogóle starać się być Agile?

Są różne implementacje i rozumienia Agile. Wszyscy zajmujący się Agile na poważnie niby o tym wiedzą i wszyscy obserwujemy to, co się dzieje na co dzień a jednak jest pewien problem. Godzimy się mianowicie na to, żeby nazywać coś, co Agile nie jest tą nazwą i później jesteśmy zdziwieni, kiedy pojawiają się głosu mówiące Agile jest do kitu. Boli nas, kiedy ludzie wyszydzają „daily stan du.y” ale tak naprawdę nie potrafiliśmy głośno powiedzieć, że to co się dzieje, niewiele ma z Agile wspólnego.

Przynajmniej jedna różnica powinna być jednak oczywista – poza projektami naprawdę będącymi Agile lub takimi, którym nikt się nie stara przypinać etykiety Agile, w toku mojej kariery zaobserwowałem, że istnieją dwa różne nazwijmy to stany. Pierwszym z nich to stan, który mógłbym nazwać „rozpocząłem moją drogę do bycia Agile”. Jeszcze nie rozumiem wszystkiego, nie potrafię robić wszystkiego tak, jak pewnie by należało, ale znam kierunek i chciałbym w nim podążać. Czyli nie robię wszystkiego jak powinienem, ale mam świadomość braków lub staram się je zlokalizować i co ważniejsze pewną konsekwencję w zmienianiu procesu na lepszy. I wizję tego, co oznacza zwinne wytwarzanie oprogramowania.  Tak naprawdę nie ma istotnego znaczenia czy wszystko jest robione zgodnie ze Scrum Guide albo jakimś innym wyznacznikiem naszego celu, ważniejsze jest, czy robimy to kierując się duchem twórców Agile. Co to oznacza? Wystarczy zajrzeć do Agile manifesto.

Drugi stan można by nazwać „nie chcę być Agile, ale nie wypada się przyznać”. Dlaczego? Bo Agile to najpopularniejszy sposób wytwarzania oprogramowania, bo wszyscy są Agile, bo Zarząd tego oczekuje, bo nie ma innej sensownej alternatywy, bo…. Powodów może być milion, ale my jako organizacja nie bardzo chcemy. Przy czym może to być wola jawna lub niejawna, powody mogą być zakorzenione w dotychczasowych praktykach lub niewierze, że może być inaczej. Albo ukrytych politycznych pobudkach. A więc bierzemy tradycyjny produkt management lub też niezorganizowany chaos, który mieliśmy do tej pory i zaczynamy przy pomocy młotka, srebrnej taśmy i paru innych trików udawać, że jesteśmy Agile. Wprowadźmy daily, estymaty (o tym napiszę następnym razem) i już będziemy Agile.

Co jednak istotne to stan ten bardzo zniechęca ludzi do edżajla. Bo pełno już w tej chwili opinii, że Agile to w sumie zło wcielone, praca w Scrum-ie niszczy zespoły i ich motywację, że Agile to dramat i tragedia. Tutaj chciałbym dorzucić taką osobistą refleksję, że nigdy nie widziałem, żeby ktoś próbował przemycać metody zwinne jako tradycyjny project management natomiast całą masę odwrotnych przypadków. Ciekawe, prawda? Podobnie jak częste wypowiedzi, że tradycyjny project management lepiej działa. To jest możliwe w pewnych przypadkach, tylko trudno jest znaleźć kogokolwiek, kto prowadziłby w ten sposób projekt nie nazywając tego Agile przy okazji.

To tyle tytułem czy Agile jest do bani. Tak naprawdę pytanie brzmi co oceniamy – czy naprawdę Agile, czy też coś, co ktoś nazwał Agile bo tak po prostu wypadało. Bo prawda jest taka, że zorganizowany chaos przywołany przeze mnie na początku tego wpisu jest często bardziej Agile niż niektóre odmiany Agile w których nawet nikt się nie stara, żeby było zwinnie.