Na początek trzeba zastanowić się, czym jest wspomniany „kulawy Scrum”. Jest wybrakowany lub niekompletny? Jeśli tak, czego w nim brak i jakie są tego skutki? A może reguły obowiązujące w organizacji uniemożliwiają poprawne użycie Scruma? Jeśli tak, co jest niemożliwe i jak wpływa to na efektywność działania zespołów scrumowych?

Pierwszy scenariusz jest taki: dziś faktycznie nie da się użyć Scruma poprawnie, bo organizacja przez lata ułożyła się pod zupełnie inny sposób działania, niemożliwy do zmiany z dnia na dzień. A ponieważ nie możemy lub nie chcemy robić rewolucji (której organizacja mogłaby nie przetrwać), potrzebujemy czasu. Inaczej mówiąc: wiemy, co robimy nieefektywnie i szukamy sposobu, by to zmienić – co być może wymaga gruntownej przebudowy kultury całej organizacji.

Jeśli ten proces (dążenia do zmiany i jej wprowadzania) nie jest pozorny, i jeśli faktycznie dążymy świadomie do tego, by działać lepiej (i liczymy na to, że im bliżej „poprawnego Scruma” się znajdziemy, tym większe odniesiemy korzyści), to wcale nie jest „kulawy Scrum”. Jest marny, może bardzo marny, ale to właśnie jest Scrum: iteracyjne i inkrementalne rozwijanie produktów i zespołów (szerzej: organizacji), by lepiej przekuwać możliwości ludzi i zasoby firmy na coś, co daje wymierne korzyści.

To, że uwiera nas robienie czegoś „niezgodnie z definicją”, to dobrze – powinno uwierać, bo wtedy dążyć będziemy do zmiany status quo. Natomiast to nie jest powód, by samobiczować się stwierdzeniami o „kulawym Scrumie”.

Zróbmy listę tych rzeczy, które wymagają zmian i usprawnień najpilniej, a następnie zajmijmy się nimi po kolei – poczynając od tego, co najważniejsze, albo co da najlepsze efekty, eksperymentując, dzieląc duże problemy na małe kawałki tak, by łatwiej było sobie z nimi radzić… Brzmi znajomo? Tak, dokładnie tak buduje się produkty z użyciem Scruma. Nie ma powodu, by tego samego podejścia nie użyć do budowania zwinnej organizacji.

Po co nam ten Scrum…

Możemy niestety odkryć coś mniej budującego: ktoś nakazał użycie Scruma, ale nikt nie ma rzeczywistych intencji z niego korzystać ani wysilać się, by zrobić to dobrze. Zanim przejdę dalej, krótka dygresja: ten scenariusz nie jest tożsamy z sytuacją, w której jakaś firma podjęła decyzję o użyciu Scruma na zasadzie kultu cargo – z nadzieją, że mechanistyczne „wdrożenie” procesu z automatu przyniesie korzyści. Taki scrumowy kult cargo zazwyczaj wygląda z zewnątrz bardzo poprawnie i trzeba zdrapać kilka warstw z fasady, by zobaczyć, że to wszystko pozory (brak empiryzmu, brak przejrzystości itd.). Tym samym scrumowy kult cargo rzadko bywa oskarżany o bycie „kulawym Scrumem”. Za to dużo częściej bywa „dowodem na to, że Scrum nie działa”.

Jeśli nie uda się wykrzesać chęci użycia Scruma, niewiele z tym można zrobić. Sytuacja nie jest beznadziejna, ale prawie zawsze problem trzeba rozwiązywać poza zespołem Scrum. Żadne szamańskie tańce dookoła Developerów, pohukiwanie na nich i szkolenia nie zmienią faktu, że ludzie nie chcą robić czegoś, czego się od nich oczekuje. Nie chcą, bo być może nie ma to sensu (wtedy poszukajmy innej metody), albo też nie rozumieją powodów, dla których Scrum w ich kontekście jednak sens ma (wtedy dajmy im ten powód).

Co zatem robić?

Co zrobić, będąc Product Ownerem w takiej sytuacji? Zadbać o dobrą definicję swojego produktu – tak, żeby wiedzieć, po co jest robiony, jaki sens jest w jego efektywnym budowaniu, jakie korzyści to daje, jakie są koszty i skutki braku tej efektywności. Kto wie, może uda się uzyskać źródło zaangażowania dla ludzi i przesuniemy się do tego pierwszego scenariusza. Wciąż będzie trudno, bo zderzymy się z różnymi ograniczeniami organizacji, ale przynajmniej będziemy realnie dążyć do zniesienia tych ograniczeń.

Ale może też się okazać, że nasz produkt… nie ma w ogóle sensu. Albo że nikt w organizacji nie ma realnych intencji czegokolwiek zmieniać, a samo wprowadzenie metod zwinnych jest tylko grą pozorów – bo „wypada być Agile”. Wtedy sytuacja może być beznadziejna, o ile nie uda nam się przebić „w górę” i uzyskać choćby minimalnego wpływu na sposób działania organizacji. Czasami jedynym sposobem, by zacząć robić coś sensownego, jest przejście do innej firmy. Bo, wbrew tym, którzy oferują „przeprowadzenie transformacji zwinnych w każdej organizacji”, nie wszędzie da się uzyskać choćby podstawową zwinność.

Artykuł Problem „kulawego Scruma” pochodzi z serwisu CRN.

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+”.

  

Artykuł Kryzys Agile pochodzi z serwisu CRN.