"Napatrzeć się na Jadźkę", czyli o zaletach nielubienia

Dawno nie było mnie na łamach Bloggera. Początkowo miałem zamiar „wyskoczyć tylko na chwilę”, a okazało się, że trwało to kilka lat. Mam jednak nieodparte wrażenie, że "postowałem" nie dalej jak „chwilę" temu. Tylko dlaczego klawiatura pokryta jest grubym kożuchem kurzu, ekran oblepia pajęczyna? O! Nawet mój Windows 7 nadal działa. 

(No tak. Przyjdzie zmienić "zdjęcie" profilowe.) 

Okazuje się, że bywają “chwile”, które trwają sekundy, godziny, lata, wieczność… Dziadek Albert (ten od E=mc2) miał rację. Upływ tak specyficznej jednostki czasu jak „chwila” jest bardzo względny i subiektywny. 

A propos specyfiki i względności „chwili”. Bywa bardzo użyteczna w trudnych sytuacjach towarzyskich: 

„Pożycz mi stówę na chwilę” – prosi gościu będący w pilnej potrzebie finansowej. 

„Za chwilę” – odpowiada pechowy acz sprytny posiadacz owej stówy. 

Tak czy inaczej, jestem z powrotem i mam ku temu kilka powodów. 

Po pierwsze, znowu mam "coś" do powiedzenia. Nie. Nie żebym miał władzę i nie wahał się jej użyć. Wręcz przeciwnie. Nie mam żadnej władzy (co za ulga), ale mam za to „coś”, czym chciałbym się podzielić na rzeczonych łamach, a nad czym myślałem wtedy, kiedy mnie na nich nie było. Sytuacja może jednak okazać się dla mnie trochę ryzykowna. Wspomniany efekt relatywistyczny odnośnie "chwili" mógł spowodować przejaw paradoksu bliźniaków: to, co mam dzisiaj „do powiedzenia” mnie wydaje się nadal doniosłe, a możliwe, że „tu i teraz” dla wielu jest już odległą, nieaktualną i mało istotną historią. 

No cóż... Zaryzykuję w myśl przysłowia

„Czego nie zrobiłeś wczoraj, zrób dzisiaj. Przecież to i tak nie ma już znaczenia.” 

Po drugie, jakiś czas temu - dzięki szczodrości mego pracodawcy (oby żył wiecznie), a także odrobinie mojej cierpliwości - miałem okazję i przyjemność uczestniczyć w szkoleniu "Professional Scrum Master", które skłoniło mnie do kilku przemyśleń na temat tej jakże popularnej „konfesji” organizacji pracy, a które to przemyślenia zaowocowały kolejnymi przemyśleniami na temat wieloaspektowych skutków fascynacji Scrumem, który jest już standardem de facto, a w wielu organizacjach nawet de jure. Postanowiłem zatem poświęcić mu trochę czasu i energii, tym bardziej, że przeszedł ciekawą formalną metamorfozę w ostatnich latach, z której nie zdawałem sobie dotąd sprawy. 

Ale do rzeczy. 

Scrum “uprawiam” od lat, choć nie od zawsze świadomie. Szczerze mówiąc, przez dłuższy czas należałem do grona tych "praktykujących niewierzących". Niby wszystko się zgadzało z literą Guida - Scrum jest (miał być) łatwy w zrozumieniu i trudny w implementacji – ale z duchem już był problem. Im bardziej praktykowałem, tym bardziej wiara więdła i tym bardziej dochodziłem do wniosku, że ... coś mi tu nie grało. I nadal nie gra. Nadal usiłuję pojąć, jak to się dzieje, a przecież dzieje się, że z interakcji kilku osób w emergentny sposób czasami "wyłania" się produkt, a czasami nie. Dlaczego w jednych przypadkach Scrum działa, w innych nie? Od czego to zależy? 

Scrum okazuje się bardzo trudny w zrozumieniu (jak bardzo, to zależy od woli zrozumienia - im mniejsza, tym wydaje się łatwiejszy) i równie trudny w implementacji. Może właśnie dlatego, że wciąż wielu przekonanych jest o jego prostocie i "łatwości". Niezrozumienie istoty Scruma stoi za większością porażek (również moich) w jego wdrożeniach i praktycznym stosowaniu. Lektura raportów Standish Group nie pozostawia złudzeń. 

Spróbujmy zrozumieć, jak bardzo nie rozumiemy. Dowiedzmy się, czego nie wiemy. 

Zacznijmy zatem „od pieca”, czyli od samej definicji Scrum zaczerpniętej z polskiego tłumaczenia Scrum Guida. 

"[...] Scrum to ramy postępowania, które są wykorzystywane w zarządzaniu wytwarzaniem złożonych produktów [...] " 

- Scrum Guide 2017 

Skoro tylko i aż ramy, to mam kilka pytań:

• Jeśli ramy to metoda osiągania celu, to co jest celem? 
• Czy i co można w ramach ram rozszerzać i do jakiego stopnia, a co jest niewzruszalne i dlaczego? 
• Czy Scrum możliwy jest tylko w postaci "vanilla Scrum", literalnie zgodnej ze Scrum Guidem, czy też dozwolone jest tworzenie "exotic Scrum" - jakiejś jego "mutacji"? 
• Jeśli tak, kiedy Scrum przestaje być Scrumem, a staje się "zmutowanym potworkiem"? 
• Czy i jaki ma to wpływ na efektywność zarządzania procesem wytwórczym? 

"[...] Scrum nie jest procesem czy techniką wytwórczą, czy też wyczerpującym opisem sposobu działania. Definiuje jedynie ogólne reguły postępowania, w obrębie których możliwe jest stosowanie różnego rodzaju procesów i technik. [...]" 

  - Scrum Guide 2017  

• Jakie są te reguły? 
• Co będzie, gdy złamiemy jakąś regułę?
• Czy wolno dodawać nowe reguły? 
• Jakie są te procesy i techniki? 
• Czy można stosować dowolne procesy i techniki? 
• Jeśli nie, skąd wiadomo, jakie powinny być te procesy i techniki, a jakie nie? 

"[...] Scrum został osadzony w teorii empirycznej kontroli procesu lub — krócej — w teorii empiryzmu. Empiryzm reprezentuje pogląd, iż wiedza wynika z doświadczania i podejmowania decyzji w oparciu o to, co zostało poznane. [...] " 

                                                                                             - Scrum Guide 2017  

Co to, u licha, jest “teoria empiryzmu”? Przecież empiryzm to doktryna lub dogmat, a nie teoria. Czyżby chodziło o teorię doktryny (sic!)? 

O “empirycznej kontroli procesu” (Empiryczna? Czy "na szkiełko i oko" czy tylko "na oko"?) nikt oprócz autorów Guida i “ludu scrumowego” nie słyszał. Może to błąd tłumaczenia? Może chodziło o "control" w sensie "sterowanie"?

A teraz crème de la crème. Scrum ma jeszcze 5 wartości: 

• Zaangażowanie, 
• Odwaga, 
• Skupienie, 
• Otwartość, 
• Poszanowanie, 

oraz 3 filary: 

• Przejrzystość, 
• Inspekcja, 
• Adaptacja. 

Ktoś zapyta: „Wartości? Filary? A co to? A po co to? Okej. To taki modny ostatnio „miękki blabling. Od wartości i filarów nie przybywa kodu ani zrobionych stories”. No właśnie przybywa. I tu jest pies pogrzebany. Bez zrozumienia roli systemu wartości i zasad wszystko nie trzyma się kupy i nie działa. Wartości Scrum bowiem, to nic innego jak określony model tzw. kultury korporacyjnej występowanie której twórcy Scrum implicite zakładają, a u podłoża której też stoją „mocne” teorie socjologiczne, psychologiczne i kognitywistyczne. W zależności od stanu tejże kultury framework może funkcjonować lub nie. Na przykład, Scrum może się nie sprawdzać w kręgach kulturowych/cywilizacyjnych o niskim kapitale społecznym i/lub przy niewłaściwej konstelacji profili psychologicznych członków zespołów. Ma to fundamentalne znaczenie dla wewnętrznej (w zespole) i zewnętrznej komunikacji (z interesariuszami), zatem stanowi krytyczny czynnik sukcesu przedsięwzięć opartych o to podejście.

Wiele innych "miękkich" aspektów organizacji pracy zespołów scrumowych trzeba brać pod uwagę decydując się na wybaw tego podejścia.

Są ośrodki, które to badają i, niestety, są też pesymistycznie nastrajające wyniki ich badań. 

Mnie szczególnie zainteresowały filary. Dlaczego „Filary”?

„Filary” odczytuję jako zawoalowaną filozofię procesu Scrum.

Nie chodzi o workflow, o kolejność poszczególnych czynności, ceremonie, ich time-boxy, artefakty czy inne duperele.

Chodzi o istotę Scruma - o metodę "empiryczną", cokolwiek to znaczy.

Jaka jest ta metoda? Jak zatem ta metoda ma się do metody "naukowej", "dialektycznej" lub innych metod?

A tak właściwie o metodę czego chodzi? Poznania? Decydowania (sterowania)? Wytwarzania? Może o "metodę wszystkiego"? 

Próbując rzetelnie odpowiedzieć na powyższe pytania można by obronić kilka magisterek, a i na doktorat starczy materiału. Niestety, większość adeptów Scruma ogranicza się do powierzchownego “zrozumienia”, czyli przeczytania i zapamiętania owych kilku lakonicznych definicji i wskazówek ze Scrum Guida. Przy takim podejściu Scrum rzeczywiście jawi się jako zbiór kilku prostych zasad. Do tego kilka artefaktów, kilka ceremonii, kilka ról. Zasada 3-5-3. Proste? Proste. Nie mamy (na ogół) z tym problemów. No to jedziemy… tylko dlaczego, kurza twarz, tak trudno “toto” praktycznie zastosować? 

Coś mi tu nie gra. 

W Przyrodzie nie może tak być. Albo łatwe jest proste, a trudne jest skomplikowane, albo... tylko wydaje się "łatwe" (albo "trudne"). 

I właśnie o to chodzi. To tak, jak z jazdą samochodem. Kierownica plus kilka pedałów, alleluja i do przodu. Okej. To dlaczego istnieje tak wiele szkół jazdy (i wypadków)? Podobnie jest z jazdą na nartach. Dwie narty, dwa kijki. Tu góra, tam dół. Okej. To dlaczego jest tyle szkółek jazdy (i połamańców)? Z jazdą na rowerze jest podobnie, tylko dlaczego nie ma szkół jazdy? 

Tak jak kręcenie kierownicą i włączanie kierunkowskazów wystarczy na placu manewrowym lub w prostych sytuacjach drogowych, jazda pługiem sprawdzi się na ”oślej łączce”, a kręcenie pedałami na ścieżce rowerowej, tak lektura „ze zrozumieniem” Scrum Guida wystarczy w przypadku projektu budowy apki na telefon. Okej. Przesadziłem. Niech będzie, że na duży telefon. 

W sytuacjach skomplikowanych, w projektach, gdzie chodzi o “prawdziwe pieniądze”, należy rozumieć zagadnienie “do cna”. 

Jak mawiał mój drugi dyrektor w mojej pierwszej pracy ( który nie był "profesjonalnym" informatykiem): 

“Panie Marku, to nie informatyka. Na tym trzeba się znać.” 

W przeciwnym wypadku to brak profesjonalizmu i hochsztaplerka. Tak zwane „spojrzenie nieskażone znajomością rzeczy” sprawdza się na krótko i na ogół kończy tragicznie. 

Przypomina mi się scena z filmu „Sami Swoi” (zakładam, że wszyscy wiedzą o jaki film chodzi). 

Pawlak i Witia młócą zboże cepami (wyjaśniam młodszym czytelnikom: cep to taka agilowo skonstruowana maszyna rolnicza). Witia tęskno wodzi wzrokiem za Jadźką Kargulanką. 

- Witia! Coś ty taki nienapasiony, a? Sto razy mówił, że masz nienawidzić to Kargulowe plemię. No i nieuchronnie idzie do pełnoletności. Toż ona nie dla ciebie!” – zrzędzi Pawlak 

- Ale tato, jak ja się napatrzę, tak dobrze, i w nocy się przyśni, to jej tak nienawidzę, że strach. 

Ze Scrumem jest dokładnie tak samo. Do Scruma można mieć dwa podejścia. Albo się go lubi, albo nie. Gdy się go lubi, nie trzeba nic rozumieć - wystarczy wiara w jego cudowną moc sprawczą - ale gdy się go nie lubi, należy go zgłębiać, aby przynajmniej rozumieć, za co i dlaczego. 

Jak mawiał mój pierwszy Product Owner w mojej drugiej robocie (który był dyplomowanym informatykiem): 

"Marek, skończyłeś studia, więc najwyższa pora zacząć się uczyć." 

No to zacząłem i trwa to do dzisiaj. Weszło w krew. 

Wtedy, w mej "drugiej robocie", a było to kilka dekad temu, już "pracowaliśmy Scrumem" (lub czymś scrumopodobnym): iteracyjnie, przyrostowo i zawsze "na wczoraj". Oczywiście nikt tego "frameworka" (kto to wiedział, że takie zagraniczne słowo w ogóle istniało) tak nie nazywał. Daily to była "dzienna narada produkcyjna", na PO wołano "Panie Kierowniku działu", a na SMa "Panie Naczelniku do spraw badań i rozwoju". Byliśmy przy tym "agile" jak cholera (spróbowalibyśmy nie być). Presja dyrekcji, permanentny brak czasu, zero dokumentacji, praca 12/24 ... a tu same (znowu) sukcesy. Pół Polski gminno-wojewódzkiej (powiatów jeszcze nie było) udało się skutecznie skomputeryzować. I to bez pomocy Unii. Nawet w "Bajtku" o tym pisali. To były czasy! Ech! Łza się w oku kręci... 

Okej. Wiem. Do brzegu... 

Scrum Guide jest bardzo lakoniczny, co niektórzy poczytują za jego zaletę. Choć dość precyzyjnie tłumaczy co i jak "trzeba" robić, nie wyjaśnia, dlaczego tak właśnie. Czyni to pozory prostoty Scruma. W rzeczywistości, Scrum jako framework jest złożony, gdyż bazuje na kompilacji kilku zaawansowanych konceptów z obszaru cybernetyki technicznej i społecznej, socjologii, psychologii, filozofii, kognitywistyki, semiologii i kilku innych dziedzin, o czym autorzy Guida - przez roztargnienie zapewne - zapomnieli wspomnieć, prawdopodobnie, aby nie zniechęcić potencjalnych adeptów. Jak na coś "łatwego w zrozumieniu" i bardzo "empirycznego" trochę jednak dużo tych "teorii". 

Dlatego postanowiłem, jako ten „nielubiący” Scruma, pochylić się nad nim i dociec w końcu, dlaczego ja go tak "nie lubię". 

W kolejnych kilku postach (mam nadzieję nie "wyskakiwać" z bloga znowu „na chwilę” by powracać co kilka lat) postaram się podzielić z Wami moimi refleksjami z perspektywy „ofiary” (czytaj „użytkownika”) Scruma, i bezlitośnie wysmagać biczem konstruktywnej krytyki nie tyle same ramy (ostatecznie każdy zarabia jak może, gdy musi), co mit o ich prostocie. Na pierwszy ogień wezmę nieszczęsny „empiryzm” i „empiryczną kontrolę”. Potem zajmiemy się wartościami i filarami. 

Ale najpierw, niczym Witia Pawlak, muszę się "napatrzeć na Jadźkę", za co z góry przepraszam wszystkie panie i panny Jadwigi, które poczuły się urażone. 

Zatem do zobaczenia ... za chwilę (jakkolwiek będzie ona krótka).

Wasz,

M.