-
„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.
-
Szkolenia online z perspektywy
Dwa tygodnie temu poprowadziłem pierwsze szkolenie stacjonarne od początku marca 2020, a więc od pół roku (było to szkolenie PSPO Advanced). Przez ten czas zdążyłem jednak poprowadzić wiele szkoleń online. Bycie na sali było więc poniekąd zapomnianym doświadczeniem, powrót do którego przyniósł nieuchronne porównywanie tego ze szkoleniem online. Poniżej dzielę się tymi moimi osobistymi spostrzeżeniami i wrażeniami.
Już przygotowując salę i materiały do szkolenia (wieczorem przed pierwszym dniem) – rzecz, którą przez ostatnią dekadę robiłem dziesiątki razy – miałem poczucie bezsensu i cofnięcia się. Bite dwie godziny przygotowywania różnych papierów: wieszania na ścianach plakatów, zasłaniania części z nich (by móc je potem w odpowiednim momencie ćwiczenia odkryć), następnie sortowania i układania materiałów opisujących studium przypadku (które potem uczestnicy otrzymywali stopniowo w trakcie), by upewnić się, że są wszystkie i we właściwej kolejności. Następnie sprawdzenie kart do gier (podczas szkolenia uczestnicy układają różne pojęcia lub otrzymują „karty inspiracji” – i tak dalej) i również odpowiednie ich przygotowanie. A na koniec rozłożenie na stołach materiałów indywidualnych – wydruk slajdów + miejsce na notatki w naszych eleganckich segregatorach – oraz oczywiście karteczek post-it, pisaków itp. itd. Całe sterty papieru. Papieru, który jest tam tylko dlatego, że nie ma jak inaczej przekazać tego wszystkiego uczestnikom; co gorsza papieru, którego większość skończyła w koszu dwa dni później.
Poczucie bezsensu miałem, bo w głowie miałem świeże doświadczenie jak rzecz wygląda na szkoleniu online. Również trzeba przygotować materiały – a więc współdzielone dokumenty, czasem tablice wirtualne i jakieś wspomagające narzędzia. Wszystko to jednak jest od razu gotowe, nie trzeba rozkładać, sortować, kleić na ścianach i tak dalej. Nie może się też nic pogubić ani ułożyć w złej kolejności. Można więc ten czas przed szkoleniem poświęcić na to by, na przykład, zastanowić się co poprawić, co tym razem zrobić inaczej, lepiej. Mój czas jako trenera jest dużo lepiej wykorzystany – a dodatkowo nie powstają żadne odpady.
Przez pierwszy dzień szkolenia zastanawiałem się, czy ten cały wysiłek ma w ogóle jakiś sens, ale nie odkryłem ani jednej korzyści z tego, że materiały miały fizyczną, papierową postać.
Wręcz przeciwnie: pojawił się ponownie problem „brakujących slajdów”. Szykując materiały szkoleniowe do wydruku, zawsze pomija się pewne slajdy – na przykład takie, które zdradzają rozwiązania zagadek albo sugerują dalszy rozwój ćwiczeń – lub po prostu po to, żeby móc w ogóle uczestników czymś zaskoczyć. Oczywiście potem mają oni poczucie, że coś stracili, jeśli tych slajdów nie mają w leżącymi przed nimi wydruku – rodzi się zupełnie niepotrzebna frustracja. W szkoleniu online, gdzie nie ma żadnych papierowych artefaktów, problem w ogóle z natury rzeczy nie występuje, szkolenie toczy się naturalnie i wszyscy widzą to, co widzą, i co widzieć powinni wtedy, kiedy powinni. Jeśli potem proszą o PDF ze slajdami to nie z frustracji, ale po to pewnie, by móc coś, co ich zaciekawiło pokazać innym – albo z nawyku.
Przy okazji zawsze zastanawiałem się jaka jest w ogóle wartość drukowania materiałów szkoleniowych. To taka tradycja, że na przyzwoitym szkoleniu stacjonarnym trzeba dostać coś drukowanego. Każdy z nas, kto pracuje dłużej niż dekadę, ma pewnie gdzieś – w domu albo w biurze – małą stertę takich materiałów, zbindowanych albo w segregatorkach, okraszonych naszymi notatkami i rysuneczkami. Ciekaw jestem jak często zdarza się Wam do nich wrócić – a jeśli już w ogóle się zdarzyło, to do jakiej części z nich? Bo mi się to prawie nie zdarza. A najważniejszym tego powodem jest fakt, że nie mogę ich przeszukać szybko i sprawnie. Dlatego już od kilku lat, kiedy jestem na szkoleniu jako uczestnik notuję na komputerze (parę lat temu nawet kupiłem specjalnie tableto-notebook by móc to robić efektywnie) – i te notatki niejednokrotnie zdarzyło mi się czytać, korzystać z nich. Czemu? Bo są w OneNote – a więc zawsze pod ręką – i łatwo mogę je znaleźć (wpisuję o co mi chodzi w pole „Search” – i voila, mam moje notatki).
Ale na tym nie koniec. Na szkoleniu stacjonarnym część notatek powstaje jako wspólna praca zespołów, której efekty umieszczane są oczywiście na flipach albo na karteczkach lepionych po całej sali. Do tego dochodzą rysuneczki tworzone przez trenera przy okazji tłumaczenia tego czy owego zagadnienia. Żadnej z tych rzeczy uczestnicy nie mogą zabrać z sobą (i potem kończą one w śmietniku), więc wszyscy robią zdjęcia telefonami. Nie wiem czy później z tych zdjęć się korzysta czy też trafiają one na wirtualną stertę podobnie jak fizyczne segregatorki ze szkoleń? Bo problemem może być odgadnięcie czego dotyczy kolekcja kolorowych karteczek zabazgranych różnymi charakterami pisma, którym zdjęcie cyknąłeś rok temu.
A jak to wygląda na szkoleniu online (przynajmniej u nas)? Każda grupa współpracuje na współdzielonym dokumencie, do którego wszyscy mają dostęp. Niemal wszystko, co normalnie ląduje na ścianie w formie flipów i post-itów, trafia tam. Tyle, że jest tam w kontekście konkretnego ćwiczenia czy zagadnienia, który jest w tymże dokumencie opisany, więc wiadomo o co chodzi. I jest w formie tekstu. Jest więc to zrozumiałe, łatwo wyszukiwalne i dostępne. Jeśli poza dokumentem używamy jakichś wirtualnych tablic, to na nich też po kartkach pisze się tekstem. Jeśli jako trener rysuję (czasem to robię, choć żaden ze mnie artysta), robię to oczywiście na wirtualnej tablicy. Później do wszystkiego tego uczestnicy zachowują dostęp „na zawsze” (w każdym razie u nas), czyli mogą sobie to skopiować albo wracać do tego, kiedy tylko zechcą.
Inna obserwacja: na szkoleniach typową formą pracy jest dyskusja lub ćwiczenie w podgrupach (zespołach), a potem omówienie wyników cała grupą. Koncept jest ogólnie dobry, ale na szkoleniu stacjonarnym jest mały problem. Gdy grupy wkręcą się w dyskusję (co jest ogólnie dobre) samo doprowadzenie do tego, żeby wszyscy się uciszyli i można było kontynuować wymaga kilku minut sygnalizowania na różne sposoby, że czas minął. Tylko potem te „kilka minut” się sumuje i zjada czas, w efekcie czego jest ryzyko, że z agendy wypada jakaś część przewidzianego materiału. Można oczywiście uciszać i sygnalizować bardziej „agresywnie”. Wtedy jest szybciej, ale uczestnikom jest nieprzyjemnie o czym od razu mówią (mają poczucie, że prowadzący traktuje ich „z buta”).
Kiedyś przyjmowałem to jako swego rodzaju zło konieczne, coś, co trzeba po prostu zaakceptować. Teraz patrzę już na to inaczej, bo wiem już jak się to robi online. Używamy do tego tzw. breakout-rooms, które na platformie Zoom mają niezwykle cenną cechę: same się zamykają po upłynięciu wcześniej ustawionego czasu (tzw. timebox). Problemu z przeciągającą się pracą w grupach po prostu nie ma. Zasadniczo ułatwia to trzymanie się czasu na szkoleniu, a co za tym idzie, sprawne przerobienie materiału. Mocno za tym zatęskniłem na sali.
Co więcej, na szkoleniu online nie ma w ogóle „pobocznych dyskusji” – czyli sytuacji, kiedy dwie-trzy osoby gdzieś o czymś zawzięcie debatując przeszkadzają grupie – i trenerowi – w pójściu dalej z zajęciami. Na sali to norma. I zwykle dyskutujący są tak zaangażowani, że trzeba po prostu poczekać w ciszy aż skończą, albo zapytać o czym rozmawiają, żeby przerwali. To nie jest ich zła wola ani znudzenie zajęciami – przeciwnie, to najczęściej wyraz zaangażowania. Ale to kolejny „poślizg”, czas dla pozostałych zmarnowany.
Szkoleń online od początku nie prowadziliśmy w Code Sprinters w blokach 8 godzinnych. Od razu wiedzieliśmy, że byłoby to zbyt męczące dla uczestników, obniżając ich zdolność do przyswojenia naszych szkoleń, których program jest mocno „napakowany”. Dlatego nasze szkolenia online od początku trwały 3-4 dni po 3.5-4.5h dziennie. Uczestnicy chwalą sobie, że dzięki temu nie mają typowego dla szkoleń popołudniowego „doła energetycznego”. Mogą także lepiej wykorzystać swój dzień – o tych zaletach już pisałem.
Szkoląc stacjonarnie przez dwa pełne dni mogłem zaobserwować, że znużenie i zmęczenie, pojawiające się najpóźniej około 14-ej nie jest wyłącznie domeną szkoleń online. Przeciwnie, na sali jest ono nawet silniejsze, bo zwykle jest to czas po obiedzie – a więc dodatkowo organizm wielu osób krzyczy wręcz o typową poobiednią drzemkę. A tu nie ma mowy o tym (choć niektórzy przysypiają), bo jeszcze kolejne 3-4 godziny szkolenia przed nami. Więc wypija się kawę litrami (porada: lepiej pić wodę niż kawę) i je szkoleniowe ciastka, żeby podnieść sobie poziom cukru – co pomaga, ale tylko na chwilę. W sumie więc wszyscy się męczą – druga połowa dnia jest zawsze trudniejsza, mniej efektywna, o czym mówią też uczestnicy.
Sęk w tym, że na szkoleniu stacjonarnym nie da się tego problemu rozwiązać. Nikt nie przyjedzie na cztery „połówki dni” – raz, że musiałoby go nie być 4 dni w pracy, dwa: to zwiększone koszty dla przyjeżdżających z innych miejscowości o kolejne noclegi, a dla trenera o dni wynajmu sali. Pozostaje się przemęczyć.
I jeszcze jeden delikatny problem. Czasem widać, że ktoś z uczestników ma jakiś kłopot. Nie zgadza się z czymś albo nie rozumie albo jest mocno zamyślony. Jako dla prowadzącego jest to dla mnie sygnał, że z tym kimś trzeba porozmawiać, ustalić co się dzieje. Na szkoleniu stacjonarnym problem jest jak to zrobić dyskretnie, tak, żeby mieć szansę porozmawiać jeden na jeden. Jedyną metodą jest próba „wyłowienia” delikwenta na przerwie, w chwili, kiedy jest sam nad kawą – co nie zawsze się udaje.
Co ciekawe, ten problem, ale w drugą stronę zgłaszali mi też uczestnicy: czasem z różnych powodów krępują się zadać prowadzącemu pytanie kiedy inni uczestnicy są w pobliżu. I również wtedy „łowią” prowadzącego na przerwach albo po szkoleniu.
W formacie online oczywiście problem nie występuje. Rzecz można zrobić natychmiast korzystając z czatu „jeden na jeden”, w razie potrzeby umówić się na dodatkowe e-spotkanie (korzystając z tego, że dzień szkoleniowy jest krótszy).
Czy przez te dwa dni nie było ani jednego momentu, który byłby lepszy niż na szkoleniu online? Owszem, były. Dwa.
Pierwszy, to spontanicznie zorganizowane przez uczestników piwo pierwszego dnia po szkoleniu. Było to fajne i ciekawe towarzysko, zwłaszcza, że w grupie były dwie osoby, które już znałem z wcześniejszej współpracy a dawno nie miałem okazji ich spotkać. Problem w tym czy można to faktycznie podciągnąć pod szkolenie per se?
Drugi, to kiedy na koniec drugiego dnia uczestnicy w ramach scenki praktykowali rozmowę z różnymi typami osobowości (w ramach tematu pracy z interesariuszami) – na tą chwilę wydaje mi się, że zorganizowanie tego na szkoleniu online byłoby mniej skuteczne. Ale niedługo spróbuję i może się okazać, że jednak i tu online pozytywnie mnie zaskoczy. Niemniej, wartość tego jednego ćwiczenia nie uzasadnia w mojej ocenie wysiłku, jakim jest podróż do innego miasta na szkolenie.
Podsumowując, po tych dwóch dniach znów spędzonych na sali poczułem się jako trener jak ktoś, komu kazano się z samochodu przesiąść do furmanki – cofnięcie w czasie do starych, gorszych rozwiązań. Z perspektywy pół roku prowadzenia szkoleń online szkolenie stacjonarne to dla mnie po prostu szkolenie mniej efektywne.
Główne punkty:
- Trudność w przygotowaniu materiałów i ich niższa jakość (papier).
- Trudniejsze „zabranie” notatek i materiałów ze sobą przez uczestników.
- Mniejsza dyscyplina na szkoleniu, w efekcie większe ryzyko poślizgu i „wypadania” materiału do przerobienia z braku czasu.
- Większe zmęczenie w formacie całodniowym a co za tym idzie mniej efektywne uczenie się.
- Dodatkowe niepotrzebne wyjazdy do innego miasta, noclegi itp. itd.
- Ogromne marnotrawstwo papieru.
Dlatego postanowiłem, że szkolenie PSM-II, które poprowadziłem w zeszłym tygodniu było ostatnim szkoleniem stacjonarnym, które osobiście prowadzę; na pewno ostatnim w 2020, a może i w ogóle ostatnim.
-
Kryzys Agile
W lutym 2021 Agile ukończy oficjalnie 20 lat – wtedy miną dwie dekady od spotkania, którego efektem był Manifest Agile. Niestety, w swoje dwudziestolecie Agile przeżywa kryzys, którego – co gorsza – większość zaangażowanych „agilistów” jeszcze nie zauważyła. Kryzys ten polega, ogólnie rzecz ujmując, na „rozwodnieniu” Agile, oderwaniu go od koncentracji na tworzeniu działającego, wartościowego oprogramowania i przesunięciu punktu ciężkości na dbałość o dobre samopoczucie, miłą atmosferę, a czasem także elementy politycznej poprawności w zespołach.
Istotnym objawem tego kryzysu jest to, że programiści i testerzy coraz częściej odrzucają Agile, a w szczególności Scrum. Kiedy się porozmawia z nimi, poczyta fora programistyczne itp., coraz częściej widać niechęć i wyśmiewanie się z Agile Coachów i Scrum Masterów. Kiedyś było inaczej: dziesięć a nawet jeszcze sześć lat temu o Scrum i Agile mówiło się na konferencjach dla programistów, stanowili oni też dużą część uczestników szkoleń dla Scrum Masterów. Teraz trafiają się pojedynczo, a na blogach i konferencjach developerskich już się o Agile pozytywnie nie mówi. Coś się ewidentnie zmieniło w tym jak programiści i testerzy postrzegają Agile i Scrum – i z czegoś ta zmiana wynika.
Ja uważam, że powodem tej zmiany postrzegania jest to, że coraz częściej Scrum jest czymś, co inni robią developerom, a nie czymś, co developerzy robią, żeby lepiej działać.
Dzieje się zatem fatalna rzecz – Scrum w szczególności, a Agile w ogólności, odrywa się od swoich korzeni. Bo przecież te metody – które w swoich zrębach tworzono pod koniec ostatniej dekady ubiegłego wieku – powstały w zespołach budujących oprogramowanie, zmagających się z trudnymi projektami. I to nie byle jakich zespołach, ale wysoce zmotywowanych, niewielkich i zgranych, złożonych z ludzi, którym zależało i na powodzeniu produktu i na dobrym rzemiośle. Agile – „zwinne sposoby pracy” – to zatem efekt organicznych wysiłków tych ludzi: programistów, testerów i pracujących z nimi bezpośrednio menedżerów. To tacy ludzie – zaangażowani i rozumiejący istotę pracy nad rozwojem oprogramowania – wypracowywali „w boju” praktyki i schematy, które później zostały „skodyfikowane” w metodach takich jak Scrum. Podobnie, to dyskusja nad tymi podejściami doprowadziła uczestników pamiętnego spotkania w lutym 2001 roku do zapisania pewnych wspólnych ich cech w „Agile Manifesto”.
Wiem to nie tylko z ich relacji, ale i z własnego doświadczenia. Wraz z moim zespołem dokładnie w taki właśnie sposób odkryłem Agile – to znaczy najpierw pracowaliśmy w krótkich sprintach i tak dalej, bo to było rozsądne rozwiązanie w naszych warunkach, a dopiero potem dowiedzieliśmy się z książek, że to ma już nawet nazwę (tutaj o tym opowiadam a tu piszę).
Dziś niestety coraz częściej Scrum jest narzucaną odgórnie metodyką, „wciskaną” często bez sensu i pomyślunku. „Bez sensu” z poprzedniego zdania jest bardzo szerokie – od braku przemyślenia podziału na produkty i co za tym idzie odpowiedniej struktury zespołów, poprzez próby pogodzenia Scruma i zwinności z silosową organizacją, stosowanie go jako „best practice” (przymusowego sposobu pracy nawet tam, gdzie akurat nie ma on sensu) , po kompletne ignorowanie faktu, że żadnego Scruma nie da się zrobić, jeśli zespoły nie mają podstawowych narzędzi do pracy (sprawne i szybkie komputery, repozytoria kodu, systemy testowe itp. itd.) oraz – co najważniejsze – jakiejkolwiek motywacji do tego, by faktycznie pracować lepiej.
Co gorsza, Scrum Master i Agile Coach stały się osobnymi zawodami. To już nie są członkowie zespołu, którzy mają dodatkową rolę dbania o jego rozwój i usprawnianie jego pracy. Obecnie to są już osobni specjaliści, których umiejętności to facylitacja, otwarte pytania, „uwalniające struktury”, flipowanie, dawanie feedbacku (dowiedziałem się ostatnio, że istnieją konkursy w dawaniu feedbacku!) – i którzy najczęściej nigdy w życiu nie programowali, w związku z czym kompletnie nie rozumieją co tak naprawdę robią ludzie, z którymi pracują.
Ta sytuacja ma zresztą inne wymiary. Scrum Master, który nie umie czytać kodu, nie wie czym różni się funkcja od metody, nie wie co to repozytorium, branche itp., nie tylko nie rozumie wyzwań jakie stoją przed zespołem – nie jest także w stanie efektywnie pomóc we wdrożeniu dobrych praktyk technicznych, bo najpewniej nie wie o ich istnieniu. Często także nie rozumie, jak istotne jest częste integrowanie i testowanie działającego oprogramowania, w efekcie zamiast na tym, żeby produkt działał a kod był dobry, koncentruje się na „dobrej atmosferze”, albo na zwalczaniu wyimaginowanych problemów (np. „nierówność w zespole”).
Tu warto podkreślić, że nie chodzi o to by „skreślić” każdą osobę, która nie mając żadnej wiedzy technicznej ani doświadczenia, została Scrum Masterem. Zdarzają się i tacy, którzy pomimo to dobrze pracują ze swoimi zespołami (choć najczęściej, kiedy się przyjrzeć tym przypadkom, to wykonali jednak jakiś wysiłek, by lepiej zrozumieć, co zespół robi). Niestety, kiedy stało się powszechne, odkąd nie mający pojęcia o programowaniu Scrum Masterzy nie są wyjątkowymi przypadkami tylko regułą, to zaczynamy mieć problem. Właśnie ten problem, że Scrum staje się czymś, co inni robią developerom; w dodatku inni, którzy nie mają pojęcia o tym, na czym w istocie polega praca developerów.
Połączenie tych dwóch elementów – „wciskania” na siłę, bez pomyślunku Scruma oraz Scrum Masterów czy Agile Coachów, którzy nie rozumieją meritum pracy zespołów – to główne przyczyny, dla których tenże Scrum w wielu miejscach nie działa. Inną ważną przyczyną jest ogólnie niski poziom zaangażowania ludzi w ich pracę. Jak już pisałem, Scrum (i Agile w ogóle) powstał wśród ludzi zaangażowanych w to co robili – zarówno na poziomie rzemiosła jak i zaangażowania w los produktu, który tworzyli. Przełożenie ich doświadczeń i wypracowanych przez nich metod na ludzi, których z produktem wiąże wyłącznie wypłata, a którzy rzemiosło (czyli jakość kodu i architektury) mają w głębokim poważaniu, okazuje się trudne (delikatnie rzecz nazywając).
Zatem zamiast zaangażowanych (a więc chcących!) programistów i testerów, którzy empirycznie wypracowują lepsze sposoby pracy nad produktem, na którym im zależy, mamy teraz coraz częściej zdemotywowanych programistów i testerów, którzy są zmuszani do udziału w „ceremoniach” – i to do tego przez „szamanów” nie mających pojęcia o tym, co taki programista czy tester robią. Nie dziwota, że im się to nie podoba, i że nie daje obiecywanych efektów (a więc często wydawanego, działającego i wartościowego oprogramowania).
Duch czasów – obowiązkowy optymizm – nakazuje zakończyć ten tekst jakimiś pozytywnymi wskazówkami lub propozycją wyjścia z problemu. Na tę chwilę jednak nie widzę tu żadnego „rozwiązania”, a więc czegoś co mogłoby szybko i radykalnie poprawić sytuację.
Pozostaje zatem robić swoje, a więc przede wszystkim szerzyć dobrą, solidną widzę o Scrumie i Agile wśród tych, z którymi mam okazję pracować – dbać o to, by Scrum Masterzy dobrze rozumieli swoją rolę i dbali o to, by Scrum był tym, co robi ich zespół, a nie czymś co oni robią temu zespołowi. Ważne by mieli też zdrowy, a więc pragmatyczny stosunek do samej metody.
Trzeba także zmienić sposób kształcenia Scrum Masterów, dostosowując go do faktu, że coraz więcej z nich nie ma pojęcia o programowaniu. Trzeba im zatem dostarczyć namiastki tego doświadczenia oraz przekazać wiedzę niezbędną, by mogli dobrze rozumieć zespoły i nawiązać z nimi merytoryczną komunikację. Innymi słowy Scrum Masterzy powinni poznać podstawy programowania – i to najlepiej nie ucząc się ich od swojego zespołu, już w pracy. Jeśli nie mają nawet podstaw to będzie to dla tego zespołu frustrujące i spowalniające, o ile w ogóle zespół zechce podjąć się tłumaczenia tychże podstaw swojemu Scrum Masterowi. Lepiej zrobią to profesjonaliści mający doświadczenie w nauczaniu.
Dlatego w Code Sprinters – korzystając z naszych programistycznych „korzeni” – zamierzamy przygotować specjalny program edukacyjny umożliwiający Scrum Masterom, którzy nie mają żadnej wiedzy o programowaniu uzyskanie niezbędnych podstaw w bezpiecznym, wspierającym środowisku.