Dlaczego Developerzy często nienawidzą Scruma

Ten artykuł powstał na bazie dyskusji, jakie w ciągu ostatnich trzech lat przeprowadziłem z wieloma znajomymi Developerami, o których wiem, że pracują lub pracowali w Scrumie. Są wśród nich pasjonaci podejścia zwinnego, są i zdecydowani przeciwnicy (mam wrażenie, że tych drugich jest więcej). Niektórzy celowo łagodzili przekaz, bo kojarzą mniej jako trenera Scrum.org; inni zupełnie się tym nie krępowali i widać było, że nie owijają nic w bawełnę.

Obserwacje i uwagi, oczywiście całkowicie zanonimizowane, podzieliłem na kilka grup. Pozwoliłem sobie również na wysnucie kilku generalnych wniosków, którymi dzielę się na koniec.

Zanim zaproszę do dalszej lektury, która dla wielu może być bolesna, chcę zwrócić uwagę na trzy istotne kwestie.

Po pierwsze, nie stosuję nigdzie kwantyfikatorów w rodzaju wszyscy Developerzy, każdy Scrum Master albo żaden Product Owner. Artykuł stanowi kompilacje opinii zebranych od Developerów, którzy pracują w różnych miejscach. Są organizacje i Zespoły, które nijak nie przystają do tego, co zaraz czarną farbą zacznę malować. Są też i takie, dla których ten artykuł będzie lustrzanym odbiciem.

Po drugie, Developerzy są bardzo często pomijani w dyskusjach o Agile. Choć nie, to nie tak – mówi się o nich bardzo dużo: jako o podmiocie działań Scrum Mastera i kadry kierowniczej. Moją intencją nie jest dorzucenie paliwa do grilla, na którym Developerów będzie się przypiekać za ich brak umiłowania dla Scruma. Chcę przedstawić perspektywę ludzi, którzy często są ofiarami partackiego użycia metody, bo zbyt mało jest wśród tzw. propagatorów zwinności chętnych, by z tej perspektywy na sprawy spojrzeć.

I po trzecie: w każdym z akapitów poniżej zawarty jest mniej lub bardziej szyderczy opis niedorzeczności, jakie wielu ludzi utożsamia ze Scrumem i ogólnie z pracą zwinną. W bardzo złośliwy sposób potraktowani zostali też Product Ownerzy, Scrum Masterzy, kierownicy i ogólnie wszyscy ci, którzy „uszczęśliwiają” Developerów Scrumem na siłę. Jak już pisałem, nie wszyscy są tacy, ale jeśli Developerzy zetkną się choćby z częścią postaw i poglądów, jakie przedstawiłem w artykule, nie powinno nikogo dziwić, że wywołało to scrumowstręt. Wyzwaniem dla profesjonalnych Scrum Masterów i liderów zwinności w organizacjach jest przekonanie tych ludzi, że Scrum jest świetnym narzędziem. Wierzę, że to możliwe.

Grzech pierworodny, czyli sposób wprowadzenia Scruma

Po co tłumaczyć Developerom, czemu akurat tego frameworku mają użyć? Ma być Scrum i już. Można ewentualnie coś wyjaśnić, ale koniecznie tak, by właściwie nic z tego nie wynikało. Ciężko powiedzieć, czy ten brak informacji wynika z nieumiejętności sformułowania zrozumiałego przekazu, czy z braku wiedzy o powodach, dla których organizacja ma się uzwinniać. Przyjmując oczywiście, że jakieś istnieją, bo i to budzi wątpliwości.

Scrum jest wprowadzony po to, by usprawnić rozwój produktu, a w szczególności spowodować, by development prowadził do uzyskania wartości i był efektywny. Super. Tylko czemu przylepia się do tego od razu sugestię, że sposób pracy Developerów jest marny i dlatego potrzebują Scruma? Jest w większości firm całkowicie nieusprawiedliwiona. Cóż, od lat wiadomo, że najwięcej na temat developmentu wiedzą ci, którzy przeczytali masę książek o Scrumie i Agile, są akredytowanymi coachami i mają certyfikaty…

A jeśli Developerzy znają Scruma i za diabła nie mogą dopatrzyć się sensu w jego użyciu tam, gdzie pracują? Nie rozwijają żadnego produktu, tylko wykonują na zlecenie różne prace serwisowe, a Zespół, którego są częścią, nic nigdy nie robi wspólnie i robił nie będzie. Mają pecha, bo są Developerami, a przecież wiadomo, że Development najlepiej robi się w Scrumie – książki coachów nie mogą się przecież mylić.

Najlepsza jest obietnica prawa do zarządzania swoją pracą – czyli samozarządzania przez Developerów (do 2020 nazywane to było w Scrumie samoorganizacją). Wiadomo, że najlepszą zachętą do samozarządzania będzie narzucenie metody przez kogoś z zewnątrz, kto zaczął robić Developerom Scruma. To idealne podglebie pod oczekiwanie, że samozarządzanie będzie kwitło!

Produkt jest najważniejszy, prawda?

Bardzo ważne jest dostarczanie działającego i wartościowego produktu w Scrumie. Tak, to bardzo, bardzo ważne. Jeszcze raz podkreślmy: bardzo ważne! Co prawda jeszcze nie wiadomo, czym niby jest ów mityczny produkt, jaki budujemy i chyba szybko nikt tego nie zdoła określić, no ale Scruma już używamy. Pamiętajmy więc, co jest w nim najważniejsze. Cytując króla Juliana z kreskówki: „teraz prędko, zanim dotrze do nas, że to bez sensu!”. A prędko musi być, bo przecież są Sprinty – trzeba zasuwać, jak sama nazwa wskazuje.

Czasami produkt istnieje i Developerzy wiedzą, co nim jest. Na tym dobre wiadomości się kończą, bo nawet Product Owner ma ten produkt gdzieś, nie mówiąc już o interesariuszach, których nigdy nikt nie widział, choć ponoć istnieją. Tak przynajmniej głosi legenda. Oczywiście od Developerów oczekuje się w tej sytuacji zaangażowania i żadne krytyczne uwagi nie są mile widziane. Za to wszyscy, którzy przyleźli robić im Scruma, zastanawiają się, jakby to niskie zaangażowanie podnieść. Niektórzy już odkryli, co dobrze działa: strach. No, przynajmniej przez jakiś czas działa.

Product Owner – decyzyjny value optimizer… no, prawie

Scrum, jak wiadomo, upraszcza proces podejmowania decyzji o kierunkach rozwoju produktu. Żadne tam komitety sterujące i inne brednie, tylko Product Owner. W końcu! Szkoda tylko, że na pytania Developerów odpowiada najczęściej „dowiem się i dam wam znać”. Nie wolno jednak powiedzieć, że Backlogiem Produktu zarządza figurant, który nic nie wie i nic nie może. Nie może w organizacji, bo w Zespole, to i owszem, może wiele. Gdzieś przecież musi pokazać, że jest ważny. Ach, te „odbiory” wymagań na koniec Sprintu i udowadnianie, że „nie o to chodziło”. Czyż Scrum nie jest wspaniały? No, nie jest. O ile to Scrum, bo są rozbieżne opinie na ten temat.

Na szczęście niektórzy mają bardzo decyzyjnego Product Ownera. I bardzo kompetentnego. Kiedyś był po prostu managerem projektu, ale teraz jest zwinnie i już nie można tak o nim mówić. Jak zmiany, to na całego. Trzeba jednak chłopu przyznać, że Backlog Produktu tak ułożył na najbliższe pół roku, że mucha nie kuca. Troszkę może inaczej to wygląda niż opisuje Scrum Guide, ale nie bądźmy drobiazgowi. Zresztą, nie ma czasu na ględzenie, bo velocity się nie zrobi samo, a i wykres spalania zaczyna źle wyglądać.

A skoro już mowa o kompetentnych Product Ownera, to najlepszy jest faktycznie taki, co to ma i wiedzę o produkcie i realną władzę. Więc organizacja poszukała właściwego człowieka, więc już niedługo Scrum przyniesie rewelacyjne rezultaty. Chwilowo nie przynosi, bo ten omnipotentny Product Owner nie ma przecież czasu na jakieś tam dyskusje z szeregowymi Developerami i muszą sobie radzić sami. Gdy już wyklaruje się, kto będzie dobrym proxy dla Product Ownera, wartość produktu wystrzeli. Na pewno tak będzie. Musi tak być. No, chyba że jednak nie…

Scrum Master, czyli pan i władca Scruma

Jakby Scrum Master umiał developować, to nie byłby przecież Scrum Masterem, prawda? No, więc nie umie, ale za to rewelacyjnie usuwa utrudnienia. A dokładniej usuwałby je, gdyby rozumiał, na czym polega development. Chwilowo rozwiązuje takie problemy, które w znacznej mierze sam generuje, być może po to, żeby mieć coś do roboty. W zasadzie, jakby na to dobrze spojrzeć, to największym utrudnieniem aktualnie jest Scrum Master, bo wszędzie go pełno, odrywa ludzi od roboty, a potem bełkocze coś o skupieniu, że niby to jedna z wartości Scruma.

Urocza jest też żelazna konsekwencja Scrum Mastera, który co rusz powtarza, że silosy i wąskie specjalizacje są złe, bo ograniczają Developerów, a jednocześnie sam nadal nie nauczył się nawet podstaw developmentu. Trzeba jednak chłopa zrozumieć, bo zajęty jest ważnymi sprawami. Kolejna zabawa na otwarcie Retrospekcji Sprintu sama się przecież nie przygotuje. A jakże to tak bez pajacowania Retrospekcję robić?

Skoro już o konsekwencji mowa, to zawsze przyjemnie jest obserwować w działaniu prawdziwego mistrza (Master w nazwie odpowiedzialności Scrum Mastera nie jest przypadkiem, oj nie). Uczy Developerów dbania o przejrzystość, ale diabli wiedzą, czym sam się zajmuje. Opowiada o asertywności, odwadze, otwartości, zaufaniu i innych pięknych rzeczach, ale jak się go poprosi, żeby pomógł w rozwiązaniu problemu, to wiadomo, że palcem nie kiwnie. Nie jest leniem, po prostu nie chce sobie zaszkodzić, a kierownictwo nie lubi słuchać o problemach.

Servant leadership motorem napędowym zwinności!

Agile, Scrum, wartość, Agile, Scrum, wartość… ktoś to zlicza? Zgodnym chórem kierownictwo powtarza te trzy słowa, kompletnie ich nie rozumiejąc (to ten lepszy z dwóch scenariuszy) lub mając je gdzieś. Oni zresztą widzieli już niejedną modę na taki czy inny framework. Były projekty, potem przyszedł Agile, będzie coś następnego. Na szczęście metoda metodą, a ludźmi zarządza się w nich tak samo. Trzeba tylko dołożyć właściwe słowa klucze do standardowego bełkotu i będzie dobrze. Aktualnie obowiązujące słowa to: Agile, Scrum i wartość.

Na szczęście jest zarząd. Na jego poziomie sprawy robią się poważne. Agile musi być, bo wszyscy w branży już są zwinni albo właśnie kończą się uzwinniać, czego dowodzą prezentacje na różnych konferencjach. A trzeba być zwinnym, bo Developerzy już nie chcą pracować w tradycyjnych metodach i oczekują możliwości pracy w Scrumie. Gdzie oni robili te sondaże?!

Dobrze jednak, że wsparcie dla Agile idzie z samej góry, bo to usuwa z drogi wszystkie ograniczenia. Organizacja przychyli nieba Developerom, jak trzeba będzie, a jak trzeba, to i karki poprzetrąca tym, co niechętni Scrumowi. Developerom też, bo przecież zwolniliby się z roboty, jakby w Scrumie nie mogli pracować. Poziom uzyskanego uzwinnienia, jak wiadomo, można w każdej chwili zmierzyć w ilościach Zespołów, które już korzystają ze Scruma.

Bardzo istotną zmianą w relacji z kierownictwem jest wspomniane wcześniej samozarządzanie robotą, w połączeniu ze służebnym przywództwem szefostwa (ang. servant leadership). Dzięki temu, jak nie było narzędzi developerskich, tak dalej ich nie ma i jak brakowało kasy na różne rzeczy, które przyspieszyłyby robotę, tak nadal jej brakuje. Natomiast dzięki przejściu na Scruma nikt już nie mówi ordynarnie „nie ma kasy, musicie sobie poradzić z tym, co już macie”. Teraz jest pełna kultura i kierownicy mówią „lepiej organizujcie sobie pracę, a zamiast narzekać i wynajdować problemy, szukajcie możliwości”. Szkoda tylko, że portale z ofertami pracy są w firmie poblokowane, bo łatwiej byłoby tych możliwości szukać.

Chociaż nie, problemów już przecież nie ma! To znaczy tak naprawdę są, ale teraz mówi się na nie możliwości, bo przecież ważne jest pozytywne myślenie. Ba, dzięki temu, że kazali Developerom pracować w Scrumie, nie dając niezbędnych środków, możliwości przybywa z dnia na dzień! Tylko się cieszyć, prawda?

Taki jeden napisał w książce, że dzięki Scrumowi da się zrobić dwa razy więcej w o połowę krótszym czasie. Oczywiście nikt tej książki chyba nie przeczytał, zanim kazał używać Scruma. I teraz oczekuje się od Developerów, że faktycznie będą dostarczać dużo więcej rozwiązań, niż przed wprowadzeniem tej metody. Jakiekolwiek uwagi, że niemożliwe jest tym samym składem osobowym w tym samym czasie robić dużo więcej bez obniżenia jakości, nie są mile widziane. Jakość ma być wysoka, bo jest Scrum. Wychodzi na to, że Developerzy za wolno pracują.

A jak już mowa o tempie pracy: velocity to ważna rzecz i musi być wysokie. Oczywiście najważniejsza jest wartość, czyli to, ile „dowiezione” zostało na koniec Sprintu, ale to w sumie łączy się z velocity całkiem dobrze. Co prawda trochę bezsensowne wydaje się, że nieważne co, byle „dowieźć”, ale kto by się tym przejmował? Czasu szkoda na takie rozważania, więc do roboty, bo velocity spadnie.

Gdy teoria (nie) staje się praktyką

Po wprowadzeniu Scruma bardzo dużo się zmieniło. Stanowiska nazywają się inaczej, decyzje podejmowane są przez inne osoby, inaczej poukładane są Zespoły, powydzielane zostały na nowo produkty. Wszyscy mówią, że jest lepiej, ale co mają mówić – że zmiana nie była na lepsze? Co się tyczy produktu, jego realnej wartości i jakości, to diabli wiedzą. Wiadomo – przejrzystość, jak to w Scrumie, więc ciągle słychać o jakimś Elmo. Jakby pracował u nas, dawno by się zwolnił.

Spotkania w Scrumie mają bardzo dużą zaletę: wiadomo, kiedy się odbywają, więc można sobie tak poukładać robotę, żeby za bardzo nie musieć się od niej odrywać. Złe jest to, że sporo tych spotkań jest, ale Scrum Master nie odpuszcza. Może kiedyś nam wyjaśni, po co są. Choć może lepiej powiedzieć tak: tłumaczył, ale do naszej rzeczywistości pasuje to, jak pięść do nosa. Ważne, że teraz mówimy o spotkaniach, że to zdarzenia. Jak zmiany, to zmiany.

Zanim zastosowany został Scrum, wielkie stado Developerów pracowało w ramach projektu nad jednym produktem, często wchodząc sobie w paradę. A teraz? Jak ręką odjął. Każdy Zespół ma odpowiedzialność za swój kawałek i w końcu można spokojnie pracować. Lub żeby być uczciwym, jeszcze nie można, bo na razie „wykuwają się” granice produktów i firma „uczy się skalowania”. Za to, jak już się „wykuje”, co ma się „wykuć”, i jak się firma „nauczy” owego skalowania, to będzie naprawdę dobrze. Chwilowo jest chaos. Od dwóch lat.

Scrum to ponoć metoda dla pojedynczego Zespołu. Pozostaje zagadką, dlaczego kazano jej używać Developerom, którzy w sile 200 osób budują jeden produkt. Cały czas podkreśla się wagę tego, by wszystko było ukończone co Sprint i jest nawet Definicja Ukończenia, w sumie sensowna rzecz. Tylko że produkt dalej wydawany jest raz na kwartał, jeśli dobrze pójdzie, a żaden Zespół nie może samodzielnie zrobić niczego, co by nadawało się do użycia. Scrum Master nie bardzo wie, jak wyjaśnić te sprzeczności ani co z nimi zrobić. Chwilowo zresztą jest zbyt zajęty tłumaczeniem, że to źle, jeśli na Daily Scrumie pojawiają się Developerzy z innych Zespołów. Zdaje się, że trzeba będzie robić jakieś dodatkowe spotkania. Znaczy się zdarzenia, najlepiej tak, żeby się Scrum Master o tym nie dowiedział, bo jeszcze piekielnik zabroni.

Wygląda zresztą na to, że cały Agile (i Scrum też) to taka wymówka, by bałagan, jaki już był wcześniej, zachować bez zmian, ale nazwać jakoś ładniej. Szkoda tylko, że przy okazji pojawiły się nowe problemy. To znaczy możliwości. Przykład? Kiedyś interesariusze nie gadali z Zespołami, przez co nie bardzo było wiadomo, czego potrzebują i zdarzały się przykre niespodzianki. Teraz gadają z Zespołami, ale przestali gadać ze sobą, przez co… nawet oni nie bardzo wiedzą, co powinno być robione. Tak po prawdzie, to przed Scrumem było lepiej – bo spokojniej, a chaos mniej więcej taki sam.

Scrum wymaga technicznej doskonałości!

Dlatego istnieje Definicja Ukończenia, żeby było wiadomo, jak ma być budowany produkt. Bardzo zmyślna rzecz, tylko że okazało się, że albo nigdy nie będzie spełniona, albo trzeba będzie z niej właściwie wszystko wywalić. Na to zgody nie było, bo jakby to wyglądało? No, więc Definicja chwilowo nie jest stosowana w całości. Może kiedyś będzie, ale perspektywy są negatywne.

Inną świetną rzeczą, jaką przyniósł Scrum, jest takie planowanie Sprintów, żeby na koniec coś było faktycznie ukończone. Co prawda dla wielu Zespołów oznacza to mniej więcej tyle, że ich rozwiązania są gotowe do zintegrowania w większą całość, ale sam pomysł naprawdę jest przedni. Tam, gdzie realnie udaje się go wcielić w życie, musi być fajnie. Ponoć ktoś widział takie Zespoły, ale może to kolejna miejska legenda.

Równie fajny jest iteracyjny i przyrostowy sposób budowania produktu. Trzeba tylko jakoś znaleźć sposób, by coś, co wymaga pół roku pracy, zbudować w jeden Sprint, ale wtedy będzie naprawdę super. Na razie możliwości się mnożą (czyli dawniej: problemy). Czemu tak? Bo przecież każda nowa wersja produktu musi nadawać się do użycia, co w naszej firmie oznacza, że ma być w pełni działająca i kompletna funkcjonalnie. A to wymaga miesięcy pracy, nie tygodni. Jak jeden ze Scrum Masterów zaczął coś opowiadać o dzieleniu roboty na plasterki (ang. vertical slicing), to mu nie przedłużyli kontraktu. Nasz Scrum Master wyjaśnił nam potem, że takie podejście z tymi plasterkami to bzdura, bo przecież nie da się używać kawałka funkcjonalności.

Agile i Scrum służy budowaniu wartościowych produktów, ale wychodzi na to, że tak naprawdę jest to promowanie bylejakości. Już wiadomo, o co chodziło z tym Elmo – to skrót od „zróbmy to byle jak, bo czas leci, a trzeba jeszcze zrobić kolejne badziewie” (nie wiadomo, w jakim języku trzeba to zapisać, żeby wyszło „Elmo”, może po klingońsku). Developerzy mają poczucie, że zaczynają się cofać kompetencyjnie, bo na „przesadny perfekcjonizm” nie ma czasu. Wychodzi na to, że Agile to przede wszystkim sztuka szybkiego naprawiania błędów.

Co do wartości, a dokładniej sposobu jej definiowania, to wydaje się, że tylko dla Developerów techniczna jakość jest również częścią składową wartości. Najwyraźniej nie opłaca się robić rzeczy dobrych, bo potrzebne są wystarczające (czyli znów: Elmo). Wystarczą średnie umiejętności developerskie, za to musi być świetny Product Owner i jeszcze światlejsi interesariusze, a wtedy sukces produktu murowany. To nie zachęca ani do rozwoju zawodowego, ani do starania się przesadnie. Ot, trzeba zrobić tyle, by produkt jakoś tam działał i nikt się nie przyczepił. Na fajny development jest czas po pracy, w prywatnych projektach.

Developerzy bez trudu zresztą dowiedzą się, że najważniejsze w pracy Zespołu są relacje, dobra komunikacja, atmosfera i mnóstwo innych tego typu rzeczy. Dlatego potrzebują świetnego Scrum Mastera, który nauczy ich komunikacji bez przemocy, technik facylitacyjnych, zorganizuje świetną Retrospekcję Sprintu – taką pełną ciekawych ćwiczeń, karteczek, no po prostu niemal zabawę. A kompetencje developerskie? Wiadomo, że Developerzy muszą mieć, więc skupmy się na tym, co ważne.

Sprawiedliwa ocena w duchu wartości Scrum

Choć nie, czasami jednak trzeba porozmawiać o kompetencjach developerskich. Najlepiej, by robił to ktoś, kto nigdy Developerem nie był, bo dzięki temu może obiektywnie ocenić, czy development jest realizowany efektywnie. A już najlepiej, żeby podstawą do ocen Developerów były jakieś konkretne obiektywne miary, bo wtedy da się wyznaczyć cele do osiągnięcia i w ogóle zobaczyć, czy następuje jakiś rozwój. Doskonałym źródłem takich miar są książki, jakie przeczytał Agile coach, lub ewentualnie jakiś doświadczony Scrum Master.

Po namyśle: Developerzy nie powinni jednak narzekać na to, że nie przykłada się wagi do ich pracy. Przykłada się, i to jaką! Całe rzesze ludzi – Agile coachów, Scrum Masterów, ekspertów, ewangelistów zwinności, doradców itd. – zajmują się kwestiami developerskimi. Poszukują odpowiedzi na pytanie, czemu brakuje Developerom zaangażowania lub kompetencji, czemu źle organizują swoją pracę, nie rozwijają się, nie potrafią nic „dowieźć” na koniec Sprintu. Czyż to nie budujące, że tak wiele osób uczyniło z „rozwiązywania problemu Developerów” swe źródło utrzymania? Zabawne, że w tej sytuacji mówi się o problemach a nie o możliwościach…

A jest jeden taki problem, który pojawia się wyjątkowo często i poświęca mu się mnóstwo czasu na konferencjach, w artykułach, książkach, na szkoleniach itd.: leniwym Developerom nie chce się robić i mają wszystko gdzieś. Więc biedni Scrum Masterzy poszukiwać muszą sposobu na to, by jakoś przekonać ich do pracy. Nie jest to łatwe, bo przecież każdy taki Developer może być leniem z innego powodu. Gdy przypadkiem zdarzy się Scrum Master, który zacznie dopatrywać się braku motywacji w otoczeniu Zespołu, szybko delikwenta się ustawi do pionu, albo i zwolni, jeśli za bardzo „psuje relacje w firmie”.

Komedia absurdu, czyli jest „zabawnie”

Pielęgnacja Backlogu Produktu to ubaw po pachy. Trzeba wyszacować wymagania, bo ktoś tam (Product Owner być może?) potrzebuje zrobić prognozy dat dostarczenia różnych funkcjonalności produktu. Oczywiście potem robi się z tego deadline, ale cicho sza, bo przecież w Agile nie ma czegoś takiego jak deadline. Szacować trzeba dokładnie, a najlepiej z zapasem, żeby potem dało się dotrzymać terminów. Niestety to Scrum, więc absolutnie nie wolno Developerom gadać o sposobach realizacji wymagań w ramach pielęgnacji Backlogu Produktu, bo od tego mają Planowanie Sprintu. Prawdziwa beczka śmiechu z tego się robi, taka zalana wodą…

Technicznych dyskusji zresztą nie wolno prowadzić w ramach żadnych spotkań scrumowych z wyjątkiem Planowania Sprintu. To znaczy się zdarzeń! Jest tych spot… zdarzeń cała masa, ale Developerzy i tak muszą organizować sobie dodatkowe, jeśli chcą pogadać bez ograniczeń o tym, co dla nich ważne. I w ten sposób dzięki Scrumowi mają okazję popisać się umiejętnościami samozarządzania.

One są zresztą krytyczne, bo w przeciwieństwie do tych podłych czasów przed Scrumem, teraz budują produkt naprawdę używalny. Co prawda dostęp do narzędzi, środków, ekspertów itd. nadal jest taki, jak był wcześniej, ale to tylko stwarza szansę do rozwoju. Tak powiada Scrum Master, tak też mówią kierownicy. Po raz kolejny można przy tej okazji dowiedzieć się, że to nie problemy, tylko możliwości.

Wraz ze Scrumem pojawiła się przestrzeń do tego, by Developerzy proponowali rozwiązania, a nie tylko bezmyślnie realizować szczegółowe wymagania. Super jest! Zamiast tych wrażych wymagań zaczęli dostawać zdawkowe hasła, z których nie wynika ani kto, ani czego, ani po co potrzebuje i mają na tej podstawie zbudować produkt. A dokładniej dwa razy więcej funkcjonalności w o połowę krótszym czasie. Z racji zwinnego podejścia i pozostawienia swobody Developerom do podejmowania decyzji, możliwości skomunikowania się z interesariuszami i wyjaśnienia czegokolwiek spadły. Poza tym teraz nie do końca wiadomo, kto czym się zajmuje, więc ciężko stwierdzić, komu zadawać pytania. Na szczęście jest Product Owner. Gdy już się zorientuje, co się dzieje, będzie super. Chwilowo jest fatalnie.

Pamiętać trzeba jednak, że podejmowanie decyzji wiąże się z odpowiedzialnością. Produkt musi być wartościowy dla interesariuszy. Dlatego wiele organizacji jednak wyciąga rękę ku Developerom i podobnie, jak w smutnych czasach minionych, daje im bardzo precyzyjne wymagania. Oczywiście to już jest Agile, więc teraz nazywają się one historyjkami użytkownika. Rozpoznaje się je po tym, że zapisywane są tak: „jako użytkownik…”, a potem to już leci prawie normalnie.

Jeszcze tylko trzeba wyszacować wymagania w story pointach. Dziwne, że sprawia to komukolwiek aż taką trudność, skoro trzeba po prostu przeliczyć dni na punkty i gotowe. Oczywiście zabronione jest mówienie, że szacuje się w dniach i coś przelicza, bo story pointy są bezwymiarowe! Jest też taki problem, że w sumie nikt nie wie, jaki powinien być przelicznik – opinie rozjeżdżają się między różnymi Scrum Masterami. Czemu zamiast dni stosowane są story pointy? Cóż, jak to w Agile, musi być zmiana i przejrzystość, więc posługiwanie się dniami przeliczonymi na punkty wedle niejawnego i nieustalonego współczynnika jest koniecznością.

Interesującą kwestią jest też ten wymóg gotowości na zmianę. Większość Developerów zrozumiała, że chodzi o gotowość zmiany planów nawet co Sprint. Nic bardziej mylnego. Okazuje się, że chodzi o zmianę wszystkiego w dowolnym momencie. Widać jeszcze nie jesteśmy dość zwinni, bo sprawia nam to kłopot. Jest oczywiście jedna stabilna rzecz, czyli Cel Sprintu – odkąd w ogóle go ustalamy. Wcześniej nie ustalaliśmy, bo był zbyt ograniczający. Teraz już umiemy go zdefiniować tak, że wszystko w Sprincie można wybebeszyć, a Cel jest niezmienny. Więc może jednak mamy już tę niezbędną gotowość na zmianę?

Na szkoleniu ze Scruma coś tam mówiono, że Sprint to umowa między interesariuszami a Zespołem: interesariusze dają Zespołowi możliwość skupienia na pracy, za co Zespół odwdzięczać się ma elastycznością, jeśli chodzi o dalszy rozwój produktu. Chyba trener, co o tym opowiadał, nie doczytał Manifestu Agile i nie wie o wymogu gotowości na zmianę. W każdym razie u nas obowiązuje bardziej pragmatyczna umowa: interesariusze płacą, to wymagają, a jak coś jest pilne, to żadne pitolenie o Sprincie nie ma przecież znaczenia. Zresztą, w tym Manifeście wyraźnie stoi przecież, że ludzie i ich interakcje są ważniejsze niż procesy, prawda?

Wróćmy na moment do silosów kompetencyjnych. Wiadomo, że są złe, bo Zespół ma być wszechstronny i najlepiej, żeby wszystko robił wspólnie. Oczywiście pod warunkiem, że każdy będzie robił to, za co mu płacą i będzie cały czas zajęty. Na wszelki wypadek trzeba raportować godziny, żeby wykazać, na co poświęca czas każdy Developer. Dzięki temu ci, co „pomagają” Developerom wiedzą, jaka „pomoc” jest potrzebna.

Taka praca zespołowa faktycznie bywa przydatna. Dzięki niej można połączyć kompetencje i rozwiązać jakiś złożony problem. Wszyscy bowiem wiedzą, że ze złożenia braku kompetencji powstają nowe możliwości (niegdyś nazywane problemami, ale to było przed Scrumem). A ponieważ można pracować Zespołowo, czasu na rozwój dla Developerów już nie potrzeba, dzięki czemu faktycznie udaje się zrobić czasami więcej, niż wcześniej. Oczywiście wciąż nie dwa razy więcej w o połowę krótszym czasie, bo jednak Zespół wciąż uczy się, jak być zwinnym.

Na koniec

Starałem się oddać choć trochę ironiczny lub wręcz złośliwy ton, w jakim o „zbawiennym wpływie Scruma” opowiadali mi Developerzy. Mam przy tym nadzieję, że nie istnieje firma, w której występują wszystkie opisane tu przeze mnie problemy na raz.

Od siebie dołożę dwie obserwacje, dla których nie mam jakiegoś mocnego potwierdzenia, ale mimo to uznałem za zasadne o nich wspomnieć.

Pierwsza jest taka, że Scrum powstał jako odpowiedź na potrzeby między innymi również Developerów w środowisku IT. Z jakiegoś powodu oderwał się od korzeni i to w dwójnasób: wielu ludzi stara się, by przestano Scruma kojarzyć z IT, a metoda dawno już przestała być dla Developerów ich narzędziem. Przez lata cała rzesza propagatorów Scruma wyrywała go z rąk developerskich i efekty widać. Dziś zdecydowana większość literatury, szkoleń, konferencji itd. skupia się na Scrum Masterach i Product Ownerach, a zapomina się o Developerach. Lub – co gorsza – traktuje się Developerów jako jakiś „problem do rozwiązania”.

Jet całe mnóstwo marnych przyczyn, dla których tak się stało, oraz jeden powód sensowny: pierwsi Scrum Masterzy byli zawsze jednocześnie Developerami, podobnie jak pierwsi Product Ownerzy byli zarazem kierownikami projektów lub managerami produktów działającymi tradycyjnie. Oni potrzebowali nauczyć się wielu rzeczy, które pozwoliłyby im działać lepiej: facylitacji, budowania relacji, dobrego komunikowania się itd. Niestety przez lata wszystko się zmieniło, więc to skupienie na potrzebach Product Ownerów i Scrum Masterów dziś już jest chybione.

Natomiast potrzebne jest skupienie na Product Ownerach i Scrum Masterach. Dziś jednym z wydajniejszych generatorów nienawiści do Scruma wśród Developerów są właśnie Scrum Masterzy i Product Ownerzy. Podobnie jak dziś to nie Waterfall jest problemem dla firm, które nie radzą sobie z nadążaniem za potrzebami rynku, ale źle stosowany Agile (a w tym i Scrum).

Druga obserwacja jest związana z samymi Developerami: wciąż pokutuje stereotyp introwertyka, który nie chce z nikim rozmawiać, niepotrzebnie poleruje rozwiązania, które już dawno są wystarczająco dobre, jest leniem robiącym tylko to, co musi itd. Do tego obowiązkowo nie rozumie potrzeb interesariuszy i komplikuje to, co proste, szukając dziury w całym. A czasami, złośliwiec jeden, na siłę wpycha niepotrzebnie jakąś technologię do produktu tylko po to, by się nią pobawić.

Cóż, to ostatnie faktycznie się zdarza, bo jest reakcją obronną przed całkowitym zniechęceniem. Jeśli kwestie techniczne są jedynym ciekawym aspektem pracy Developera, traktowanego jako problem, to trudno się dziwić takiemu postępowaniu. Wyjątkowo w tym momencie całkiem na serio napiszę: Developerzy to możliwości, a nie problemy i dobrze byłoby nauczyć się z nich korzystać.

Zachęcam do refleksji nad tym tekstem i sugeruję, by dyskretnie sprawdzić swoje otoczenie. Niekoniecznie warto wprost pytać Developerów, co myślą o Scrumie, bo jeśli nie pałają do niego sympatią, najpewniej nie uznają za rozsądne przyznawać się do tego. Nie ma też sensu dorzucać kolejnego powodu niechęci do Scruma, jakim mogłaby się stać presja na to, by tę metodę lubić. Zamiast tego trzeba doprowadzić do tego, by Scrum był używany jako narzędzie rozwiązywania problemów przez Developerów, a nie jako narzędzie opresji przez organizację, Scrum Masterów i innych ludzi, którzy w dobrych intencjach potrafią wdeptać development w błoto.

Skąd ten cytat?

Kto jest autorem zacytowanej na początku szyderczej definicji Scruma, wedle której to „metoda, po jaką sięgają firmy, gdy nie mają lepszego sposobu, by zrobić sobie krzywdę”? Tak odpowiedzieli uczestnicy jednego ze szkoleń, które prowadziłem, gdy poprosiłem ich o wyjaśnienie jednym zdaniem, czym jest Scrum. Łatwo odgadnąć, że byli to Developerzy, którzy pojawili się na szkoleniu z bagażem nienajlepszych opinii o Scrumie.

Na szczęście ta niechęć nie jest nigdy wrodzona ani przesadnie trwała i da się jej wyzbyć, zmieniając środowisko na takie choć trochę mniej szkodliwe. Dlatego dobrzy Scrum Masterzy, zdolni wykreować przestrzeń do sensownego użycia Scruma nawet w podłym miejscu, zawsze byli, są i będą w cenie.