• Agile,  Zarządzanie

    Nie stawiajcie Scruma na głowie!

    Kryzys Agile, o którym pisałem pół roku temu stał się już tak widoczny, że właściwie nikt nie polemizuje już z samą tezą o jego istnieniu. Niektórzy jednak zaczęli się pocieszać, że to w sumie nic złego.

    Rozumowanie, które do tego prowadzi jest takie: deweloperzy nie muszą wcale się interesować procesem, Scrumem, organizacją pracy. To my, Scrum Masterzy i Agile Coache jesteśmy od tego! My im to zorganizujemy, poukładamy, a oni będą się mogli skupić na tym, w czym są dobrzy, na wykonywaniu pracy (czyli kodowaniu).

    Postawa taka jest dla mnie antytezą tego, czym Agile jest – a może raczej miał być.

    Uważam tak, bo istotnym elementem idei Agile w ogólności a Scrum w szczególności to jest to, że to ludzie wykonujący pracę sami ją sobie organizowali. W Scrum organizacja narzuca być może strukturę, w tym właśnie Scrum, narzuca podział na zespoły (choć lepiej jeśli pozwoli ludziom się samym do nich przypisać lub choćby o tym współdecydować), ale o całej reszcie ma decydować zespół. Ba! Cała następna fala nowatorskich metod zarządzania klasy Holakracji idzie jeszcze dalej: ludzie (pracownicy) sami ustalają także struktury oraz podział odpowiedzialności i obowiązków, który jest przez nich dynamicznie dostosowywany zależnie od potrzeb.

    Skąd ta idea się wzięła? Choćby z obserwacji, że to ludzie bezpośrednio wykonujący pracę mają najwięcej wiedzy na temat tego jak ona jest wykonywana, a zatem są w najlepszej pozycji do tego, żeby ją usprawnić, poprawić. A także z obserwacji, że jeśli ludzie mają wpływ na to jak pracują, to są bardziej zaangażowani w pracę – co powoduje, że jeszcze bardziej im zależy, żeby to dobrze działało. I tak mamy w organizacji – a przynajmniej w zespole – pozytywne sprzężenie zwrotne, które podnosi i jakość pracy i zaangażowanie. To właśnie do tego służą w Scrumie retrospekcje – robiliśmy pracę cały sprint, teraz pomyślmy jak tą pracę robiliśmy, żebyśmy robili ją jeszcze lepiej – bo nam zależy na tym, żeby robić ją lepiej.

    Zresztą, Scrum wziął się stąd że zaangażowani deweloperzy i współpracujący z nimi produktowcy, menedżerowie kombinowali jak pracować lepiej. W skrócie, Scrum to jest coś co zespół robi, żeby lepiej działać (o czym już pisałem szerzej w przywołanym już artykule).

    Mentalność „my wam to poustawiamy, nie musicie tego robić, wy macie kopać” jest z tym sprzeczna, wręcz szkodliwa. Obniża zaangażowanie, promuje postawę klasy „ja tu robię X od-do, a resztę mam w… głębokim poważaniu” albo „niech menedżer … ee.. Scrum Master się tym zajmie, to nie moja sprawa”. To jest po prostu stawianie Scruma na głowie, powrót do biernych deweloperów zarządzanych przez menedżerów którzy – jako ci starsi i mądrzejsi – poustawiają im świat. Czyli powrót dokładnie do tego w opozycji do czego cały ruch Agile w ogóle powstał. Innymi słowy, takie myślenie to prosta droga do tego, żeby Scrum nie był czymś co robią deweloperzy, żeby lepiej działać ale stał się czymś, co inni robią deweloperom. A to, jak już wiemy, nie działa.

    Właśnie między innymi dlatego, żeby walczyć z takimi pomysłami w najnowszym Scrum Guide nie ma już ról. Są odpowiedzialności w zespole (Scrum Team). Cały zespół odpowiada za to, czy praca jest dobrze zorganizowana. Cały zespół odpowiada za to, czy jest wartościowa.

    Jeśli to czytasz a masz odpowiedzialność Scrum Master apeluję: nie stawiaj Scruma na głowie! Nie próbuj we wszystkim zespołu wyręczyć, wszystkiego im poukładać. Pewnie, jak zespół jest mało doświadczony, w ogóle świeży (w sensie nie pracowali razem wcześniej) to tego układania potrzebuje więcej. Ale z czasem ma być go coraz mniej. Nigdy nie stawiaj się ponad zespołem, nigdy nie myśl, że TY im poukładasz a oni nie muszą o tym myśleć. Właśnie przeciwnie – powinni o tym myśleć. Jako SM masz dążyć do tego, żeby każdy członek zespołu czuł się odpowiedzialny nie tylko za swoje „od-do”, ale za całość: całość tego jaki produkt jest, ale także całość tego jak wygląda nasz zespół, jak wygląda organizacja, co można poprawić albo zmienić – i tak dalej.

    Jeśli będzie inaczej twój zespół po prostu odrzuci Scruma, potraktuje go jako kolejny wymysł menedżerów wciskany im na siłę. A nie o to przecież chodzi.

  • Uncategorized

    Kryzys Agile

    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.