TL;DR: nie da się wskazać wartości Scruma i benefitów z obecności Scrum Masterów w dev teamach. Fenomen tego zjawiska należy raczej rozpatrywać w kontekście wiary i myślenia życzeniowego.
To jest mój pierwszy post z serii anty-Scrumowej. Jest nieco tendencyjny i pełen generalizacji, ale zależało mi na wskazaniu sekciarskiego charakteru Scruma i nieprzekładalności tej metodyki na wymierne rezultaty.
Kim jest Scrum Master?
Ostatnio byłam świadkiem kosmicznej metamorfozy. Laska z księgowości, miła osoba, ale bez żadnego doświadczenia z zakresu zarządzania projektami IT i bez absolutnie żadnej znajomości technologii została Scrum Masterką w mocno technicznym teamie. Czy sobie poradziła? Jeszcze jak! Do tej pory siłą inercji utrzymuje się na stanowisku, uczestnicząc jako cichy słuchacz w spotkaniach cross-teamowych oraz figurując w DW maili dotyczących projektów. Czasem zagada, czasem zupdejtuje status taska w Jirze.
Może jest wybitna, a mnie boli z tego powodu dupa. A może – tylko się tak zastanówmy – a może Scrum Master nie ma żadnych konkretnych umiejętności? Może jest to – przepraszam za mocne słowo – profesja, która nie wymaga za bardzo niczego poza względną komunikatywnością i znajomością Scrum Guide’a?
Nauczyć się katechizmu potrafi nawet przedszkolak, podobnie jak używać słów, które powinno się wypowiadać w określonych sytuacjach. “Retro, refi, sprint, planning, dependencje, daily, artefakty, blokery, capacity, velocity” etc. Ach, jeszcze “empiryzm“, odarty ze swoich filozoficznych konotacji.
Wątpliwa wartość Scruma
Scrum Masterzy w najlepsze wrośli w strukturę dev teamów. Zapuścili korzenie na tyle głęboko, że właściwie nikt już nie zastanawia się, czy gość, który codziennie pyta, co dzisiaj będziesz robić, ma jakkolwiek pozytywny wpływ na twoją pracę. Po prostu jest, jak paprotka na babcinej meblościance, jak reprezentant komisji partyjnej na zebraniu zespołu roboczego w fabryce.
Trochę mnie to dziwi, bo jednak biznes płaci za apostołów Scruma niemały hajs (często za pensję SM można przecież zatrudnić dodatkowego programistę), a efekty ich pracy są właściwie niemierzalne. Jak bowiem ocenić pracę Scrum mastera? Ilością partyjek planning pokera? Stopniem uporządkowania backlogu? Liczbą ceremonii (notabene – słowo z terminologii religijnej) na tydzień? Znajomością 10 wyrazów ciągu Fibonacciego?
Chyba nie tylko ja odnoszę wrażenie , że organizacje uprawiają ze Scrumem jakiś kult cargo. Chcą zaklinać rzeczywistość i wierzą, że sama obecność nadzorców scruma wystraczy, żeby software rósł w siłę, a korporacje żyły dostaniej. Bo Netflix tak robi, bo Amazon, bo Google, etc…
Tylko prawdziwy Scrum
“Hola!” – powie twardogłowy Scrum master, a przyklaśnie mu scrumowy neofita. “To nie tak, w Scrumie chodzi o podejście, o mindset (Scrum ocieka wszak anglicyzmami), a poza tym na pewno wasz scrum został źle zaimplementowany”. Antidotum? Wiecej Scruma, dev team wytrzyma. Może jeszcze jedna partyjka planning pokera, może jeszcze jedno retro w kozetkowym klimacie, może kolejny Miro board ze sticky notes. I niech się nie śmieje ten, kto nigdy nie przyklejał truskawek na interaktywną tablicę podczas “refi”.
No dobra, oddając cesarzowi co cesarskie. Założenia Scruma są spoko. Napisali je programiści dla innych programistów, by ustandaryzować ich pracę i nadać jej jakieś ramy.
Cel szczytny, ale konsekwencją wdrożenia Scruma w organizacjach było to, że szybko do gry weszła horda samozwańczych SM po bootcampach, nie mających zielonego pojęcia o pracy nad softwarem i z głośnym poparciem managementu rozpanoszyła się jako pełnoprawni członkowie dev teamów. Zrobił się z tego biznes, który obejmuje nie tylko zjawisko Scruma w organizacjach, ale też branżę szkoleniową, konferencje, consulting etc. Organizacje psim swędem podążyły na nową modą. Obecnie trudno sobie wyobrazić dział IT bez sfory SM-ów, z zerowym rozumieniem technologii i bolączek software developmentu.
Prozelici Scruma zaraz zaprotestują, że SM przecież nie musi być techniczny, on przecież ustawia procesy wg swojej czerwonej książeczki Mao (Scruma) i pielęgnuje, żeby principia Scruma trzymały się w teamie mocno. Nie mnie oceniać, czy to dobre podejście. Moim zdaniem, w zespole powinna być osoba techniczna wspomagająca managerów czy Product Ownerów w podejmowaniu decyzji oraz – mówiąc wprost – sprawdzająca, czy dev team nie robi ich w konia. Myślę, że wrócę do tego tematu w innym poście.
Co zamiast Scruma?
Zżyliśmy się z tym Scrumem. Fajnie jest się spotkać na 15 minut, pogadać o planowanej pracy, nawet jeśli nie ma to nic wspólnego z rzeczywistymi planami, szczególnie w teamach pracujących zdalnie. Retrospektywy? OK. Praca w sprintach? Nie mam nic przeciwko.
Ale czy naprawdę trzymanie się tego wymaga obecności dedykowanej osoby? Czy nie może tego robić po prostu Project Manager/Product Owner/Kierownik Projektu/Team Lead/[wstaw tutaj ekwiwalentne stanowisko z twojej firmy]. Spróbujmy sobie odpowiedzieć na to pytanie, zdaje się, że jednak retoryczne.
Dodaj komentarz