Epitafium Scrum Mastera. Status quo.

Wszyscy znamy start-upowe korzenie metodologii Agile oraz wiemy, jak bardzo specyficzną kulturę pracy ten rodzaj mikro przedsiębiorstw sobą reprezentuje w odniesieniu do ogólnego i uśrednionego schematu organizacyjno-operacyjnego firm z branży IT. Przyczyn takiego stanu rzeczy jest oczywiście wiele, od otwartości na najnowsze technologie napędzanej brakiem długu technologicznego, poprzez zazwyczaj niewielką ilość zaangażowanych stron czy osób, połączonej z płaską strukturą hierarchiczną oraz minimalnym narzutem zarządzania, aż po sam cel ich założenia, który najczęściej sprowadza się do kilku rund pozyskiwania inwestorów zakończonych bardzo intratną sprzedażą. Gdy zatem lata temu, w blasku reflektorów napędzanych brakiem jakichkolwiek przeciwstawnych argumentów ruszyła lawina ogólno-sektorowej transformacji Agile’owej przez certyfikowanych Scrum Masterow, była ona napędzana ewangelickim wręcz poziomem wiary w jej uniwersalną aplikowalność, a tym samym w niechybny i odczuwalny wzrost wydajności pracy. Było tak nie tylko ze względu na brak jakiejkolwiek merytorycznej analizy czy braku danych statystycznych, ale też z powodu nieistnienia wiarygodnych metryk mających na celu potwierdzić lub zaprzeczyć pozytywnemu wpływowi wdrażanej metodologii na wyżej wspomnianą produktywność. Od tego czasu zdążyło już upłynąć dużo wody w rzece, a rynek zweryfikował założenia manifestu Agile’owego i w mojej opinii odbiły się one od ściany, zwłaszcza tej korporacyjnej. Mowa tutaj oczywiście o faktycznej efektywności wdrożenia tej metodologii, a nie tej anegdotycznej, którą chwalą się wszelkiej maści konsultanci na LinkedIn-ie. Efektem czego był, już też omawiany we wcześniejszych tekstach mojego autorstwa, krok wstecz ku waterfallowi, ochrzczony mianem SAFe’a, co w mojej opinii było po prosty racjonalnym zaniżeniem oczekiwań wobec wdrażanych zmian w kontekście dużych multi-dyscyplinarnych organizacji z wielopoziomowymi strukturami hierarchicznymi. Skutki oczywiście są debatowalne, a ja o ile mogę jedynie odnieść się tylko do mojego i anegdotalnego doświadczenia znajomych w branży, o tyle chciałbym nakreślić i omówić obecną ewolucje Agile’a, którą można zaobserwować głównie w większych korporacjach.

Mityczny bohater

Omawiając metodologie Agile nie sposób jest nie skupić się na roli Scrum Mastera, który niczym prometejski bohater niosący ze sobą oświecenie mądrością świętego manifestu miał, poprzez szereg precyzyjnych spotkań, uratować nas z chaosu i poprowadzić ku nowej, lepszej, rzeczywistości. W praktyce oraz mniej doniosłych słowach miał on usprawnić komunikację interdyscyplinarną i poprzez swoistą, oraz wieloetapową psychoanalizę doprowadzić do rozwiązania konfliktów spowodowanych techniczno-laickim dysonansem poznawczym wszystkich stron zaangażowanych w proces wytwarzania produktów cyfrowych. Nie umniejszając szczytności takiego przedsięwzięcia chciałbym zwrócić uwagę na same jego podwaliny, czyli postrzegalny ogólno-hierarchiczny kryzys komunikacyjny spowodowany archaicznymi strukturami organizacyjnymi datującymi na czasy sprzed nowożytnej rewolucji cyfrowej wraz z adekwatnie przestarzałymi procesami wewnętrznymi oraz produkcyjnymi w kontekście bardzo dynamicznie ewoluującej rzeczywistości technologicznej w erze internetu. Sytuację oczywiście pogarszał często niestety prawdziwy stereotyp programisty.

Piwniczak

Tym oto pejoratywnym określeniem zwykło się nazywać programistów na początku obecnego wieku. Typowy niechlujny oraz asocjalny przedstawiciel flanelowej gwardii, którą sam kiedyś z dumą reprezentowałem, nie był w oczach wysublimowanej elity wszelkiej maści menadżerów i dyrektorów, posługujących się równie elokwentnym co pustym korpo-żargonem, partnerem w dyskusji. Z tego też powodu powstała nisza dla pewnego rodzaju programistyczno-biznesowego tłumacza, którą szybko i skutecznie wypełnił świeżo ochrzczony Scrum Master, poprzez mówienie w imieniu ludzi, którzy nie chcieli lub nie umieli mówić za siebie w sposób zrozumiały dla przeciętnego laika technologicznego i jednocześnie tłumacząc odpowiedzi zwrotne na język przyswajalny przez specjalistów z branży IT.

Z piwnicy na salony

Jak nietrudno się domyślić, wraz z rozwojem sektora IT i nieustającym przyrostem demograficznym populacji technologicznej w połączeniu z latami nabytego doświadczenia zaczęło pojawiać się w nim coraz więcej jednostek reprezentujących wykraczający poza stereotyp poziom tzw. umiejętności miękkich. Było to po części skutkiem nabycia ich w procesie długotrwałego docierania się w kontaktach laicko-technologicznych, a także swojego rodzaju dojrzewania społecznego rzeszy programistów, którzy wychodząc ze swoich przysłowiowych piwnic powoli, dostosowali się, oczywiście w różnym stopniu, do nowej interdyscyplinarnej rzeczywistości pracy. Tym samym nisza, którą wypełniał Scrum Master powoli zaczęła się wypełniać, niemniej jednak jest jeszcze jeden krytyczny powód, dla którego rola ta odchodzi do lamusa, mianowicie upłynęło już wystarczająco dużo czasu, aby móc dokonać wstępnej, o ironio, retrospekcji w kontekście faktycznej skuteczności dogmatycznego wdrażania metodologii Agile.

Paradoks

Jakże absurdalnym dowodem na daremność wspomnianego przedsięwzięcia ma przeciętna odpowiedź na pytanie, czy dana organizacja pracuje w metodologii Agile. Już tak proste pytanie skutkuje zachwianiem wiary w jej dogmaty, gdyż zazwyczaj w odpowiedzi usłyszymy coś w stylu „po swojemu”, „w pewnym stopniu”, czy też „staramy się”. W praktyce oznacza to obecność kilku spotkań w kalendarzu oraz pracy w sprintach, oczywiście mniej więcej, ponieważ jak wszyscy wiemy, świętość kontraktu wcale nie jest taka niepodważalna, jak wskazuje na to jego nazwa. Tym samym zarysowuje nam się bardziej realny obraz Scrum Mastera oraz jego obowiązków i wkładu w proces dostarczania oprogramowania.

Bolesna prawda

O ile na samym początku rola Scrum Mastera miała zazwyczaj bezpośrednio przełożenie na stanowisko pracy, tzn. rola była tożsama z nazwą stanowiska i zakresem jego obowiązków w stosunku jeden do jednego. O tyle z biegiem czasu okazało się, że w kontekście wyżej opisanej ewolucji branży IT albo nie spełnia ona oczekiwań wewnątrz organizacyjnych sama z siebie lub że nie uzasadnia ona pełno etatowego wymiaru pracy. Tym samym szybko zaczęli pojawiać się Agile Lead-owie, Agile Project Managerowie, Agile Delivery Managerowie i cała rzesza innych ról z doklejonymi przedimkiem Agile jako swoistego rodzaju reliktem minionej ery, tak aby bazową definicję roli uzupełnić o faktyczne wymagania okołoprojektowe, organizacyjne czy też strukturalne. Powstała zatem rzesza ról hybrydowych oparta o metodologię Agile’a, ale jednocześnie będąca jej bezpośrednią antytezą i cichą kapitulacją, bo skoro nawet tak podstawowy dogmat nie znajduje potwierdzenia w rzeczywistości to, co dopiero można powiedzieć o całej reszcie jej ewangelii? Otóż przyjrzyjmy się kolejnemu, ale również podstawowemu paradoksowi roli Scrum Mastera oraz obowiązków do niej przypisanych w kontekście dużo prostszych i ogólniejszych złotych prawd branży IT i nie tylko. W tym celu wystarczy jedno dobrze znane zdanie.

Kolejne spotkanie, które mogło być emailem

Jeżeli wszyscy zgodnie uważamy, że niepotrzebne spotkania są rakiem kulturowym nowożytnego środowiska pracy, co potwierdza mnogość memów sarkastycznie ilustrujących powyższe powiedzenie, to jest to w mojej opinii dość jednoznaczny sygnał, że rola, która sprowadza się w głównej mierze do ich umawiania, prowadzenia czy moderowania jest reliktem kończącej się ery. W celu udowodnienia skali absurdu tego dogmatu przyjrzyjmy się kilku faktom z pogranicza rewolucji technologicznej. Tradycyjne struktury organizacyjne bazują na łańcuchu dowodzenia, który w uproszczeniu i oparciu o archaiczne definicje przebiega następująco: pracownik – kierownik – dyrektor. Tym samym w erze merytokracji doprowadza to do konfliktu hierarchicznego, gdyż często osoba na stanowisku decyzyjnym nie jest osobą, która powinna, z braku specjalistycznych kompetencji, owe decyzje podejmować. Tym samym dochodzi do sytuacji, w którym wiele z tradycyjnie kierowniczych ról traci w pewnym sensie na swoim prestiżu czy poważaniu przy jednoczesnym uszczupleniu ich kompetencji, czy też zakresu odpowiedzialności. Jak zatem kierownik czy dyrektor może próbować to kompensować? Wdrażając w życie kolejny frazeologizm.

Nie ważne jak o nas mówią, ważne żeby mówili

Z tego też powodu istnieje cała kasta różnej maści korpo-kierowników o przepełnionych kalendarzach, którzy ciągle o czymś rozmawiają, jednocześnie nie mówiąc nic. Czemu zatem nowa i postępowa metodologia bazuje na replikowaniu schematów, z którymi teoretycznie stara się walczyć? Na to pytanie nie mam dobrej odpowiedzi poza obserwacją, że w kontekście powyższego stanu rzeczy Scrum Master jest tak naprawdę wilkiem w owczej skórze i kolejnym stadium ewolucji nisko wyspecjalizowanej roli pseudo – kierowniczej bazującej na dogmatycznych i jak już wspomniałem nie weryfikowalnych wynikach swojej pracy. Niemniej doprowadza nas to do bardzo ważnego pytania leżącego u samych podnóży problemów, które nas tu doprowadziły.

Wieża babel

Czy skoro źródła problemów powodujących nieoptymalną pracę w naszej organizacji doszukujemy się w szeroko zakrojonych problemach komunikacyjnych, które właśnie wjeżdżający na białym koniu Scrum Master miałby naprawić to czy tak naprawdę, z jednej strony nie odsuwamy od siebie odpowiedzialności za zaistniałe patologie, a z drugiej strony z kolei nie przyznajemy się do ich ogólno-organizacyjnej skali? Odpowiadając na to pytanie odrobinę redukcjonistycznie w celu zwięzłości, czy skoro stwierdzamy, że nie da się ich naprawić bez interwencji z zewnątrz to czy faktycznie sposób komunikacji wewnątrz naszej firmy, czy też projektu lub interdyscyplinarnego zespołu jest tak nieefektywny, że nie umiemy go rozwiązać bez odnajdywania nowej „religii”, którą będziemy mogli wspólnie wyznawać? Czy rzeczywistym problemem nie jest tak naprawdę nasza niechęć do przyznania się do bezsilności w obliczu przerastającego nas konfliktu komunikacyjnego, a co za tym idzie do jawnej akceptacji odpowiedzialności za stan rzeczy, w którym cała kultura pracy w naszej organizacji, wraz z archaiczną hierarchii, jest kontrproduktywna? Tutaj niestety często zamyka się błędne koło, gdyż osoby mogące podjąć decyzje o zmianie powyższego statusu quo są jednocześnie osobami, których role nie mają miejsca w nowej rzeczywistości.

Agile kontra DevOps

Na koniec chciałbym jeszcze omówić dogmatyczny konflikt pomiędzy metodologią Agile’a, a jej bliskim transformacyjnym kuzynem, czyli metodyką DevOps. Pomimo często synchronicznych prób wdrożenia obydwu wspomnianych adaptacji organizacyjno-procesowych warto zauważyć, iż sama obecność Scrum Mastera w zespole cross-funkcyjnym i DevOps-owym jest paradoksem, ponieważ ich definicja zakłada ze byt ten jest samoorganizujący się i w pewnym sensie samowystarczalny. Czy naprawdę potrzeba wysoko opłacanego certyfikowanego specjalisty, żeby wrzucić spotkania do kalendarza i odpytać z listy obecności? Żeby zrobić notatki z retrospektywy albo usprawnić komunikację ze stakeholderami czy też z zespołami, z którymi łączą nas zależności technologiczne lub projektowe? Czy sam ten fakt nie świadczy o wspomnianej wcześniej patologii komunikacyjnej wewnątrz danej organizacji? No bo przecież jeśli zatrudniamy kompetentnych dorosłych ludzi, z pominięciem wyjątków potwierdzających regułę, to przecież powinni oni umieć się ze sobą porozumieć, czyż nie? Na dowód tego zadam kolejne pytanie. Dlaczego w żadnej innej branży produkcyjnej nie ma odpowiednika takiego stanowiska? Z drugiej strony z kolei może prościej będzie spojrzeć, gdzie ono jest, zazwyczaj kryjąc się pod nazwą mediatora, na przykład w policji, przy sprawach rozwodowych, w polityce i ogólnie szeroko pojętych sytuacjach ekstremalnie konfliktowych. Podążając dalej tym tokiem myślenia, nie pozostaje nic innego stwierdzić, że większość procesów dostarczania produktów cyfrowych to metaforyczna strefa wojny pomiędzy zaangażowanymi stronami. Czy zatem nie warto by było zdobyć się na szczerość i nazwać rzeczy po imieniu? Przyznać się do winy i obiecać poprawę, po czym ją faktycznie wdrożyć? Według mnie tak byłoby prościej, taniej, lepiej, a nawet szybciej. Wszak pierwszym krokiem do uzdrowienia jest przyznanie się do problemu. Zatem powtarzajcie za mną „Tak, moja organizacja jest toksyczna, ale chcę to zmienić!”.

Zawieszenie broni i początek nowej ery

Sam fakt zaistnienia takiej roli wynikał z przedawnionej i stereotypowej percepcji osób technicznych jako aspołecznych odludków, którzy przecież nie potrafią się wysłowić i porozumieć z osobą spoza ich wysoko wyspecjalizowanego i prawie że subkulturowego zamkniętego kręgu. Tak samo krzywdzące obecnie można uznać stwierdzenie, że osoby nie stricte techniczne są technologicznymi analfabetami, którzy nie rozumieją zasad działania złożonych systemów. Co gorsza, obydwie strony zakładają brak empatii po drugiej stronie i z góry zakładają porażkę, nie podejmując nawet dialogu, lub podchodząc do niego z uprzedzeniami uwłaczającymi wszystkim z zaangażowanych osób. Na szczęście te krzywdzące stereotypy powoli odchodzą do lamusa i wkraczamy na kolejny poziom dojrzałości sektora IT, w którym mam nadzieję królować będzie domenowa merytoryka zamiast archaicznych hierarchii organizacyjnych podpartych na politycznej walce o władzę. Tym samym coraz częściej można zaobserwować powstawanie technicznych stanowisk kierowniczych odzwierciedlających ich faktyczną odpowiedzialność i decyzyjność w organizacji, czyli piony technologiczne zaczynają dochodzić do samego czubka drzewa strukturalnego bezpośredniego przejścia w pion biznesowy. Innymi słowy, coraz wyżej i dalej od samego procesu rozwoju oprogramowania odsuwane jest ognisko zapalne laicko-technologicznego konfliktu komunikacyjnego, a tym samym ubywa gruntu pod nogami roli Scrum Mastera.

Czy zatem wylać dziecko z kąpielą?

Otóż paradoksalnie odpowiedziałbym, że nie. O ile sama rola Scrum Mastera w świetle powyższej racjonalizacji jest niepotrzebna, o tyle konkretne elementy samej metodologii jak najbardziej mają potencjał niesienia wartości dodanej. Nakreślają one bowiem krytyczne elementy komunikacji wewnątrzorganizacyjnej, które trzeba mieć na szczególnej uwadze i zarazem określają nam wyjściowy framework do ich autoanalizy i usprawnienia. Niczym nowym bowiem jest iteratywny rozwój oprogramowania, który był opisywany już w latach sześćdziesiątych minionego wieku, a zatem około czterdziestu lat przed publikacją manifestu Agile’owego. Tak samo pojęcie retrospekcji nie jest żadnym błyskotliwym odkryciem w ogólnym znaczeniu tego słowa. Bez umiejętności spojrzenia w przeszłość i uczenia się na błędach nie bylibyśmy w ogóle w pozycji, w której omawiane przez nas problemy miałyby w ogóle miejsce, gdyż cały nasz postęp cywilizacyjno-technologiczny oparty jest na metodzie prób i błędów. Tak też chciałbym podsumować rolę Scrum Mastera i niejako całą metodologię Agilę. Spróbowaliśmy, były pozytywne rezultaty, ale nie do końca działało, tak jakbyśmy chcieli, wyciągnijmy wnioski na przyszłości i idźmy dalej.