-
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.
-
Szczepionka 737MAX
Jest taki wpływowy artykuł zatytułowany „Software is eating the world”. Chodziło w nim o to, że software jest podstawą działalności właściwie wszystkich odnoszących sukcesy firm. I, że w związku z tym software i budowanie go staje się kluczowe i zarazem powszechne.
Niestety, wraz z tym powszechne stały się także złe nawyki i praktyki IT, na przykład takie jak wydawanie niegotowych produktów, ukrywanie długu technologicznego czy wręcz testowanie produktów przez użytkowników. To nie było takie groźne, póki chodziło o edytory tekstu, gry czy sieci społecznościowe, ale staje się śmiertelnie niebezpieczne, kiedy przenosi się na inne branże.
Pierwszym znanym przykładem był Boeing 737MAX wypchnięty „na chybcika”, z wieloma dysfunkcjami organizacyjnymi jakże znajomymi każdemu, kto kiedykolwiek „wypychał za bramę”, na „deadline” kolejną, poprawioną „na szybko” wersję starego systemu. W tym przypadku oznaczało to śmierć około 300 osób i prawie dwuletnie uziemienie samolotów skutkujące poważnymi kłopotami dla Boeinga. A także utratę zaufania do FAA – niegdyś „złotego standardu” wśród regulatorów lotniczych – kiedy okazało się, że FAA właściwie tylko przybijała pieczątki na tym, co Boeing sam „sprawdził”.
Teraz widzimy podobne podejście – wypchnąć „za bramę”, zrobić testy „na chybcika”, sprawdzić to na milionach użytkowników – na szczepionkach. Z tym, że w przypadku Boeinga 737MAX chodziło o próbę ponownego reużycia starego projektu przez „doklejenie” do niego paru nowych, komputerowych dynksów. Tu zaś mamy wzorzec „nowe eksperymentalne, pospieszne testy na ścieżkach pozytywnych a resztę niech nam ludzie sprawdzą i wykryją błędy”. Coś, co znaliśmy kiedyś z wczesnych wersji Windowsów i co sprawdza się dziś w przypadku Microsoft Flight Simulator 2020 (piękny, nowa jakość w branży ale roi się od błędów), tu się oczywiście nie sprawdzi. W MFSF2020 katastrofy nie są prawdziwe, a sfrustrowani gracze bugi zaraportują po czym co najwyżej poczekają na kolejny „patch” grając w X-Plane. W przypadku szczepionek – zwłaszcza Pfizera i Moderny, opartych na nowej, nigdy wcześniej nie stosowanej technologii – nie będzie tak łatwo, bo żaden „patch” nie przywróci później zrujnowanego zdrowia ani nie wskrzesi tych uczestników eksperymentu, na których wyjdą „bugi”.
W tej chwili mało kto się tym przejmuje, ale za kilka lat będziemy patrzeć na to, że FDA i inni „regulatorzy” na to pozwolili tak, jak dziś patrzymy na dopuszczenie przez FAA 737MAX do lotów. Z tą różnicą, że – miejmy nadzieję – tym razem odpowiedzialni poniosą jakieś realne konsekwencje.
-
„Feedback”
Coraz większą popularność uzyskuje słowo „feedback”. Odbywają się całe sesje poświęcone temu jak „dawać feedback” – jak już pisałem urządza się z tego nawet konkursy. Ten „feedback” to widać jakieś bardzo trudne i skomplikowane, a zarazem bardzo ważne zagadnienie, prawda? Dziwna rzecz jakim cudem ludzkość dała sobie radę przez całe wieki, ba!, tysiąclecia, nie roztrząsając tak ważnego zagadnienia.
Spróbujmy więc „rozpakować” to dziwne słowo i ustalić co się za nim kryje.
Tak naprawdę chodzi po prostu o to, jak Brajankowi powiedzieć, że coś spieprzył tak, żeby Brajanek nie poszedł z płaczem skoczyć z okna. To jasne, kiedy tylko się chwilę nad tym zastanowimy, bo jakoś nie słyszałem, żeby ktoś miał jakiś problem z chwaleniem (słyszeliście o jakiejś sesji klasy „jak chwalić ludzi, żeby nie urazić ich skromności”? o kursach chwalenia zręcznie?). Problem zawsze jest z krytyką, powiedzeniem komuś, że coś zrobił nie tak, że nie jest wspaniały i cudowny. Innymi słowy „feedback” to eufemizm na krytykę.
Kłopot polega przy tym nie na samym komunikacie (który najczęściej jest po prostu faktem), tylko na tym, że mamy do czynienia z całymi tabunami niedojrzałych psychicznie ludzi, którzy nie są w stanie go po prostu normalnie przyjąć bez popadania w jakieś okropne stany psychiczne. Innymi słowy, ponieważ mamy do czynienia z ludźmi, którzy fizycznie są dorośli, ale psychicznie są dziećmi, to mamy ich traktować tak, jak pięciolatków. Pięciolatkowi nie można powiedzieć wprost, że jego rysunek samochodu to bohomaz, który nic nie przypomina, bo mogłoby to naruszyć jego delikatną, rozwijającą się psychikę. Dzwudziestopięciolatek powinien jednak być w stanie przeżyć komunikat „twój kod to badziwie, jest nieczytelny, weź się ogarnij i napisz to porządnie jeśli umiesz” bez spazmów i napadu depresji. Powinien, ale niestety coraz częściej nie umie, nie jest w stanie. Brajanka głaskano bowiem i „pozytywnie motywowano” pochwałami za byle co przez całe życie, więc nie jest przyzwyczajony do tego, że jego dzieła mogą budzić inną reakcję niż choćby umiarkowany zachwyt.
Zresztą, Brajankowi nic nie brakowało całe życie, o nic nie musiał walczyć ani starać się dając z siebie wszystko. Nie wymaga więc wiele od siebie samego. A przy tym Brajanek wie, że jest ogromny popyt na każdego, co umie sklecić jakiś w miarę działający kod, więc nie obawia się utraty pracy – uważa, że znajdzie łatwo następną. I niestety ma rację. W związku z tym nie można Brajanka „naprostować”, oswoić z normalną, prostą komunikacją dorosłych ludzi – trzeba się z nim cackać. Problem w tym, że jednak czasem trzeba Brajankowi przekazać informację, że to co stworzył to badziwie nie używając tego straszliwego słowa. I stąd są wszystkie „kursy feedbacku”, to po prostu kombinowanie jak by ten prosty komunikat olukrować i ozdobić, żeby Brajanek nie doznał straszliwej zapaści psychicznej, a jednocześnie jednak coś poprawił. To kapitulacja wobec smutnej rzeczywitości podobnie jak przypominające przedszkola dla dorosłych biura wiodących firm.
Popularność kursów i książek „feedbacku” to wszystko objaw problemów społecznych, które toczą naszą schyłkową cywilizację. Wiele jest aspektów tego zjawiska. Na przykład ogólny kult dziecięctwa i młodości, dotyczący nie tylko cielesności (ten wieczny wyścig by wyglądać młodo), ale także umysłowości, który zastąpił typowy dla tradycyjnych społeczeństw szacunek wobec doświadczenia i mądrości nabywanej z wiekiem.
Ja myślę, że lepiej jednak zamiast komibinować, po prostu mówić wprost i jasno, bez lukrowania o co chodzi. Jeśli ludzie nie zostali przygotowani do bycia dorosłymi przez wychowanie i system edukacyjny, to niestety będą musieli tą lekcję odrobić boleśnie w życiu dorosłym. Traktując pracowników jak dzieci i bawiąc się w „feedback” wcale im nie pomagamy – przeciwnie, utrwalamy niedojrzałość i oderwanie od rzeczywistości hamując w zasadzie ich prawdziwy rozwój.