Kryzys ten polega, ogólnie rzecz ujmując, na rozwodnieniu znaczenia agile, oderwaniu go od koncentracji na tworzeniu dobrze 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ę z nimi porozmawia czy poczyta fora programistyczne, coraz częściej widać niechęć, a nawet wyśmiewanie się z agile coachów i scrum masterów.

Kiedyś było inaczej: dziesięć, a nawet jeszcze sześć lat temu o scrumie i agile chętnie mówiło się na konferencjach dla programistów, a oni sami stanowili dużą część uczestników szkoleń dla scrum masterów. Teraz trafiają się tam 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. Moim zdaniem z tego, że coraz częściej scrum jest czymś, co inni robią developerom, a nie czymś, co developerzy stosują, żeby lepiej działać.

Dzieje się zatem fatalna rzecz – scrum w szczególności, a agile w ogólności, odrywają się od swoich korzeni. Bo przecież obie 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 w byle jakich zespołach, ale wysoce zmotywowanych, niewielkich i zgranych, złożonych z ludzi, którym zależało zarówno na powodzeniu produktu, jak i na dobrym rzemiośle. Agile – w znaczeniu zwinnych sposobów 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 ujęte 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 tzw. manifeście agile.

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 swoją nazwę.

Wyimaginowane problemy, narzucana metodyka

Dziś niestety coraz częściej scrum jest narzucaną odgórnie metodyką, wciskaną często bez sensu, w sposób nieprzemyślany. Począwszy od braku podziału na produkty (za czym powinna iść odpowiednia struktura zespołów), poprzez próby pogodzenia scruma i zwinności z silosową organizacją, stosowanie go jako best practice (co wiąże się z przymusowym sposobem pracy nawet tam, gdzie akurat nie ma on sensu), a skończywszy na kompletnym ignorowaniu faktu, że żadnego scruma nie da się zrobić, jeśli zespoły nie mają podstawowych narzędzi do pracy (sprawnych i szybkich komputerów, repozytoriów kodu, systemów testowych 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 otrzymali dodatkowe zadanie dbania o jego rozwój i usprawniania 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 czy branch, nie tylko nie rozumie wyzwań jakie stoją przed zespołem, ale 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ści w zespole).

Niski poziom zaangażowania w pracę

Warto tu 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, odkąd niemający pojęcia o programowaniu Scrum Masterzy stali się nie wyjątkiem a regułą, zaczęliśmy mieć problem. Właśnie ten problem, że scrum staje się czymś, co inni robią developerom… W dodatku ci inni 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 przemyślenia 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 w dodatku przez „szamanów” niemających pojęcia o tym, co taki programista czy tester robią. Nic dziwnego, że im się to nie podoba. I nic dziwnego, że nie daje to obiecywanych efektów (a więc często wydawanego, działającego i wartościowego oprogramowania).

Róbmy swoje

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 mamy 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, biorąc pod uwagę fakt, ż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ż podczas pracy z nim. Jeśli nie mają nawet podstaw, będzie to dla 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.

Andy Brandt  

Założyciel i senior consultant firmy doradczo-szkoleniowej Code Sprinters. Wcześniej był między innymi Country Managerem Swisscom CEE (w Polsce pod marką Air Bites), a także menedżerem i konsultantem w 4pi, Unisys i T-Mobile Polska, jak też pierwszym redaktorem naczelnym „Linux+”.