W lutym 2021 Agile ukończy oficjalnie 20 lat – wtedy miną dwie dekady od spotkania, którego efektem był Manifest Agile. Niestety, w swoje dwudziestolecie Agile przeżywa kryzys, którego – co gorsza – większość zaangażowanych „agilistów” jeszcze nie zauważyła. Kryzys ten polega, ogólnie rzecz ujmując, na „rozwodnieniu” Agile, oderwaniu go od koncentracji na tworzeniu działającego, wartościowego oprogramowania i przesunięciu punktu ciężkości na dbałość o dobre samopoczucie, miłą atmosferę, a czasem także elementy politycznej poprawności w zespołach. 

Istotnym objawem tego kryzysu jest to, że programiści i testerzy coraz częściej odrzucają Agile, a w szczególności Scrum. Kiedy się porozmawia z nimi, poczyta fora programistyczne itp., coraz częściej widać niechęć i wyśmiewanie się z Agile Coachów i Scrum Masterów. Kiedyś było inaczej: dziesięć a nawet jeszcze sześć lat temu o Scrum i Agile mówiło się na konferencjach dla programistów, stanowili oni też dużą część uczestników szkoleń dla Scrum Masterów. Teraz trafiają się pojedynczo, a na blogach i konferencjach developerskich już się o Agile pozytywnie nie mówi. Coś się ewidentnie zmieniło w tym jak programiści i testerzy postrzegają Agile i Scrum – i z czegoś ta zmiana wynika.

Ja uważam, że powodem tej zmiany postrzegania jest to, że coraz częściej Scrum jest czymś, co inni robią developerom, a nie czymś, co developerzy robią, żeby lepiej działać.

Dzieje się zatem fatalna rzecz – Scrum w szczególności, a Agile w ogólności, odrywa się od swoich korzeni. Bo przecież te metody – które w swoich zrębach tworzono pod koniec ostatniej dekady ubiegłego wieku – powstały w zespołach budujących oprogramowanie, zmagających się z trudnymi projektami. I to nie byle jakich zespołach, ale wysoce zmotywowanych, niewielkich i zgranych, złożonych z ludzi, którym zależało i na powodzeniu produktu i na dobrym rzemiośle. Agile – „zwinne sposoby pracy” – to zatem efekt organicznych wysiłków tych ludzi: programistów, testerów i pracujących z nimi bezpośrednio menedżerów. To tacy ludzie – zaangażowani i rozumiejący istotę pracy nad rozwojem oprogramowania – wypracowywali „w boju” praktyki i schematy, które później zostały „skodyfikowane” w metodach takich jak Scrum. Podobnie, to dyskusja nad tymi podejściami doprowadziła uczestników pamiętnego spotkania w lutym 2001 roku do zapisania pewnych wspólnych ich cech w „Agile Manifesto”.

Wiem to nie tylko z ich relacji, ale i z własnego doświadczenia. Wraz z moim zespołem dokładnie w taki właśnie sposób odkryłem Agile – to znaczy najpierw pracowaliśmy w krótkich sprintach i tak dalej, bo to było rozsądne rozwiązanie w naszych warunkach, a dopiero potem dowiedzieliśmy się z książek, że to ma już nawet nazwę (tutaj o tym opowiadam a tu piszę).

Dziś niestety coraz częściej Scrum jest narzucaną odgórnie metodyką, „wciskaną” często bez sensu i pomyślunku. „Bez sensu” z poprzedniego zdania jest bardzo szerokie – od braku przemyślenia podziału na produkty i co za tym idzie odpowiedniej struktury zespołów, poprzez próby pogodzenia Scruma i zwinności z silosową organizacją, stosowanie go jako „best practice” (przymusowego sposobu pracy nawet tam, gdzie akurat nie ma on sensu) , po kompletne ignorowanie faktu, że żadnego Scruma nie da się zrobić, jeśli zespoły nie mają podstawowych narzędzi do pracy (sprawne i szybkie komputery, repozytoria kodu, systemy testowe itp. itd.) oraz – co najważniejsze – jakiejkolwiek motywacji do tego, by faktycznie pracować lepiej.

Co gorsza, Scrum Master i Agile Coach stały się osobnymi zawodami. To już nie są członkowie zespołu, którzy mają dodatkową rolę dbania o jego rozwój i usprawnianie jego pracy. Obecnie to są już osobni specjaliści, których umiejętności to facylitacja, otwarte pytania, „uwalniające struktury”, flipowanie, dawanie feedbacku (dowiedziałem się ostatnio, że istnieją konkursy w dawaniu feedbacku!) – i którzy najczęściej nigdy w życiu nie programowali, w związku z czym kompletnie nie rozumieją co tak naprawdę robią ludzie, z którymi pracują.

Ta sytuacja ma zresztą inne wymiary. Scrum Master, który nie umie czytać kodu, nie wie czym różni się funkcja od metody, nie wie co to repozytorium, branche itp., nie tylko nie rozumie wyzwań jakie stoją przed zespołem – nie jest także w stanie efektywnie pomóc we wdrożeniu dobrych praktyk technicznych, bo najpewniej nie wie o ich istnieniu. Często także nie rozumie, jak istotne jest częste integrowanie i testowanie działającego oprogramowania, w efekcie zamiast na tym, żeby produkt działał a kod był dobry, koncentruje się na „dobrej atmosferze”, albo na zwalczaniu wyimaginowanych problemów (np. „nierówność w zespole”).

Tu warto podkreślić, że nie chodzi o to by „skreślić” każdą osobę, która nie mając żadnej wiedzy technicznej ani doświadczenia, została Scrum Masterem. Zdarzają się i tacy, którzy pomimo to dobrze pracują ze swoimi zespołami (choć najczęściej, kiedy się przyjrzeć tym przypadkom, to wykonali jednak jakiś wysiłek, by lepiej zrozumieć, co zespół robi). Niestety, kiedy stało się powszechne, odkąd nie mający pojęcia o programowaniu Scrum Masterzy nie są wyjątkowymi przypadkami tylko regułą, to zaczynamy mieć problem. Właśnie ten problem, że Scrum staje się czymś, co inni robią developerom; w dodatku inni, którzy nie mają pojęcia o tym, na czym w istocie polega praca developerów.

Połączenie tych dwóch elementów – „wciskania” na siłę, bez pomyślunku Scruma oraz Scrum Masterów czy Agile Coachów, którzy nie rozumieją meritum pracy zespołów – to główne przyczyny, dla których tenże Scrum w wielu miejscach nie działa. Inną ważną przyczyną jest ogólnie niski poziom zaangażowania ludzi w ich pracę. Jak już pisałem, Scrum (i Agile w ogóle) powstał wśród ludzi zaangażowanych w to co robili – zarówno na poziomie rzemiosła jak i zaangażowania w los produktu, który tworzyli. Przełożenie ich doświadczeń i wypracowanych przez nich metod na ludzi, których z produktem wiąże wyłącznie wypłata, a którzy rzemiosło (czyli jakość kodu i architektury) mają w głębokim poważaniu, okazuje się trudne (delikatnie rzecz nazywając). 

Zatem zamiast zaangażowanych (a więc chcących!) programistów i testerów, którzy empirycznie wypracowują lepsze sposoby pracy nad produktem, na którym im zależy, mamy teraz coraz częściej zdemotywowanych programistów i testerów, którzy są zmuszani do udziału w „ceremoniach” – i to do tego przez „szamanów” nie mających pojęcia o tym, co taki programista czy tester robią. Nie dziwota, że im się to nie podoba, i że nie daje obiecywanych efektów (a więc często wydawanego, działającego i wartościowego oprogramowania).

Duch czasów – obowiązkowy optymizm – nakazuje zakończyć ten tekst jakimiś pozytywnymi wskazówkami lub propozycją wyjścia z problemu. Na tę chwilę jednak nie widzę tu żadnego „rozwiązania”, a więc czegoś co mogłoby szybko i radykalnie poprawić sytuację.

Pozostaje zatem robić swoje, a więc przede wszystkim szerzyć dobrą, solidną widzę o Scrumie i Agile wśród tych, z którymi mam okazję pracować – dbać o to, by Scrum Masterzy dobrze rozumieli swoją rolę i dbali o to, by Scrum był tym, co robi ich zespół, a nie czymś co oni robią temu zespołowi. Ważne by mieli też zdrowy, a więc pragmatyczny stosunek do samej metody.

Trzeba także zmienić sposób kształcenia Scrum Masterów, dostosowując go do faktu, że coraz więcej z nich nie ma pojęcia o programowaniu. Trzeba im zatem dostarczyć namiastki tego doświadczenia oraz przekazać wiedzę niezbędną, by mogli dobrze rozumieć zespoły i nawiązać z nimi merytoryczną komunikację. Innymi słowy Scrum Masterzy powinni poznać podstawy programowania – i to najlepiej nie ucząc się ich od swojego zespołu, już w pracy. Jeśli nie mają nawet podstaw to będzie to dla tego zespołu frustrujące i spowalniające, o ile w ogóle zespół zechce podjąć się tłumaczenia tychże podstaw swojemu Scrum Masterowi. Lepiej zrobią to profesjonaliści mający doświadczenie w nauczaniu.

Dlatego w Code Sprinters – korzystając z naszych programistycznych „korzeni” – zamierzamy przygotować specjalny program edukacyjny umożliwiający Scrum Masterom, którzy nie mają żadnej wiedzy o programowaniu uzyskanie niezbędnych podstaw w bezpiecznym, wspierającym środowisku.