Blog

Jakiś czas temu dzieląc się przemyśleniami na temat Daily Scruma, wspomniałem – celowo nie rozwijając tej myśli – że Zespoły obarczone wewnętrznymi problemami lub takie, którym przyszło funkcjonować w toksycznej organizacji, mogą mieć problem z organizacją tego zdarzenia. Uznałem, że temat zasługuje na osobny artykuł i zgodnie z zapowiedzią, wracam do niego.

Przebieg poszczególnych zdarzeń scrumowych, a co za tym idzie ich rezultat, zależy od relacji pomiędzy uczestnikami oraz – w mniejszym stopniu – od otoczenia. Konflikty w Zespole lub niesprzyjająca Scrumowi kultura organizacji utrudnia, a czasami wręcz uniemożliwia realizację zdarzeń tak, by służyły one celowi, dla którego zostały zdefiniowane. Dotyczy to również Daily Scruma, którego brak prowadzi do upośledzenia możliwości Developerów, pozbawiając ich codziennej dawki empiryzmu niezbędnej do radzenia sobie ze złożonością.

Jakie czynniki i w jaki sposób mogą uczynić Daily Scrum nieskutecznym, a nawet doprowadzić do całkowitego zaniku tego zdarzenia? Uważny czytelnik, zwłaszcza po lekturze jednego z poprzednich artykułów, zapewne bez trudu odpowie sobie na pytanie. Mimo to pokuśmy się o opisanie paru mrocznych przypadków.

1. Scrum pozbawiony kontekstu

Wyobraźmy sobie Zespół, który wdrożył bezkontekstowy „książkowy Scrum”, zgodny z zapisami zawartymi w Scrum Guide, ale pozbawiony jakiejkolwiek głębi. Są w nim oczywiście wszystkie odpowiedzialności, powstają artefakty, jakie Schwaber z Sutherlandem kazali wytwarzać, odbywają się wymagane zdarzenia. Gdy jednak poskrobiemy ten piękny obrazek paznokciem, okaże się, że to mechanistyczny Scrum, Scrum-zombie czy Scrum-wydmuszka.

Żadne zdarzenie w takim „Scrumie” nie służy empirycznej kontroli procesu, odpowiedzialności utożsamiane są z nazwami stanowisk w firmie, nie dąży do uzyskania wartości dla interesariuszy, a żaden artefakt nie służy zapewnieniu przejrzystości i możliwości działania empirycznego. W takim Zespole Daily Scrum jest ceremonią. Jest więc mistrz ceremonii (osobliwie jest to najczęściej Scrum Master), jest protokół postępowania (lub obrządek, jak kto woli). Nie ma za to zaangażowania uczestników ani wartości wynikającej z odbycia ceremonii.

2. Brak wartości Scrum

Teraz wyobraźmy sobie dla odmiany Scrum w Zespole, któremu całkowicie brak jednej z wartości (odwagi, zaangażowania, otwartości, skupienia lub szacunku). W praktyce brak jednej z nich przekłada się na powolny zanik pozostałych, bo – na przykład – ciężko wyobrazić sobie otwartość tam, gdzie brak odwagi, by mówić o rzeczach trudnych.

Jeśli niektórym ludziom zależy na produkcie a innym nie, zacznie iskrzyć i pojawią się konflikty. Gdy dodamy do tego brak szacunku i obrzucanie się mniej lub bardziej zawoalowanymi inwektywami (bo „seniorzy” wiedzą lepiej co i jak powinno być robione niż „juniorzy”, bo „testerzy” nie ogarniają technologii, a „programiści” to tylko bezmyślni klepacze kodu…), Daily Scrum będzie po prostu kolejnym polem bitwy. Często krwawej, po której lista wzajemnych urazów i pretensji narasta.

Ten brak wartości może również spowodować, że dla niektórych Developerów każdy dzień w pracy będzie formą walki o przetrwanie do kolejnego weekendu. Celem jest wtedy utrzymanie się w pracy i zapewnienie sobie źródła dochodu (nie wszędzie przecież jest tak różowo, jak w branży IT w czasach prosperity). Brak odwagi skojarzony z brakiem wzajemnego szacunku doprowadzi do całkowitej zapaści empiryzmu. Nikt nie będzie dążył do ustalenia prawdziwego stanu spraw, bo dla jednych mówienie o problemach stanie się prostą drogą do wystawienia głowy na strzał, a dla innych będzie to idealna okazja do dowalenia przeciwnikom.

Bywa, że konflikt toczy się tylko między dwoma osobami w Zespole, ale podlany sosem braku zaangażowania, otwartości i szacunku, rozwija się w najlepsze na tyle długo, że już nikt nie wie, od czego się rozpoczął. Wszyscy wiedzą o problemie, ale wolą tematu nie poruszać, bo zrobi się z tego prawdziwa jatka… Dlatego o pewnych rzeczach się nie mówi, żeby przypadkiem nie zejść na kwestię konfliktu. Im bardziej pogrążamy się w przemilczeniach, zakłamaniu i hipokryzji (celowo używam ciężkich słów), tym trudniej zapewnić, że Daily Scrum służył będzie skutecznej inspekcji stanu spraw i prowadził do adekwatnej adaptacji planów działania.

3. Brak wizji i celów

Co się stanie przypadku Zespołu, który organizacja powołała do istnienia, nie kłopocząc się w ogóle wyjaśnieniem, po co to zrobiła? Rozwój przypadków może być skrajnie różny, ale niewykluczone, że Zespół stoczy się w marazm i zasklepi w jakiejś miernej wersji mechanistycznego „Scruma”, przychodząc do pracy jedynie dla pieniędzy.

Podobnie jak w opisanych wcześniej przypadkach, Developerom w taki Zespole Daily Scrum bardziej przeszkadza, niż w czymkolwiek pomaga, bo przymusza ich do udawania, że robią cokolwiek sensownego. Zaangażowanie szoruje po dnie, ale „na szczęście do weekendu już niedaleko”…

Inny scenariusz braku wizji i celów prowadzi do skupienia organizacji nie na osiąganiu wartości (bo nazwanie tejże wymagałoby posiadania wizji i wynikających z niej celów), ale na źle rozumianej produktywności. Nieważne co jest wytwarzane, skoro ludziom trzeba dużo zapłacić za każdy dzień, muszą zasuwać. Czyli robić dużo, dostarczać szybko i zawsze w terminie. Bo jak nie dostarczają, to znaczy, że marnują się środki zainwestowane w Zespół. Na taką stratę organizacja nie może sobie pozwolić! A czy to, co jest wytwarzane, jest rzeczywiście potrzebne…? „Nie zadawaj zbędnych pytań, tylko weź się do roboty!”.

Zespół pozbawiony źródła motywacji i drogowskazu dającego skupienie nie będzie sobie świetnie radził. Ludzie naciskani, rozliczani z pracy co do godziny, krytykowani za „brak efektywności”, zaczną chować się do skorupy i powstanie coś, co jedynie udaje Scruma. Możliwe też, że ludzie schronią się przed opresyjnym otoczeniem za pięknym, acz fałszywym obrazem rzeczywistości. A wtedy Daily Scrum będzie wyłącznie temu służyć – by podtrzymywać kolorową fasadę, za którą kryje się paskudna prawda.

4. W oparach organizacyjnych absurdów

Teraz wyobraźmy sobie Zespół, który ma potencjał i sensowny cel działania, ale powstał w organizacji o toksycznej kulturze. Takiej, w której za każdy błąd ludzie są karani. Takiej, gdzie ludzi podejrzewa się o niekompetencje i lenistwo. Gdzie „zaufanie jest dobre, ale kontrola jeszcze lepsza”. Gdzie wszyscy mają być innowacyjni, ale jeśli cokolwiek w ramach innowacji nie wyjdzie, stanie się automatycznie dowodem na prawdziwość zarzutów braku kompetencji, lenistwa etc.

Zespół w takim miejscu dzień po dniu jest na wojnie z otoczeniem, a otwarte mówienie o problemach może doprowadzić do jego zniszczenia. Zrobienie prawdziwego Daily Scruma w tej sytuacji może wymagać heroizmu. Bardziej prawdopodobne, że zdarzenie używane będzie do mówienia kierownictwu tego, co ten chce usłyszeć (pal licho przejrzystość!) i zamieni się w spotkanie statusowe. A jeśli Developerzy będą mogli o tym zdecydować, to Daily Scrum przestanie się odbywać w ogóle (bez większej straty, bo i tak niczemu nie służył, a podnosił ryzyko, że ktoś się przyczepi, jeśli mowa będzie o problemach).

Zdarza się, że osoby funkcjonujące w warunkach permanentnej kontroli i rozliczania realizują Daily Scrum w dwóch odsłonach: oficjalnej – na potrzeby otoczenia, i nieformalnej – pozwalającej empiryzmowi działać wewnątrz Zespołu. Rozwiązanie takie powoduje rozdźwięk między rzeczywistością a tym, co widać na pierwszy rzut oka (jak się to ma do otwartości i szacunku, o przejrzystości już nie wspominając?). Z drugiej strony takie desperackie dążenie do poradzenia sobie z wrogim otoczeniem wymaga odwagi i zaangażowania. Jednoznaczna ocena tego podejścia jest trudna i niech każdy dokona jej samodzielnie.

5. Scrum, w którym nic nie wolno

A jeśli Developerzy obwiązani zostaną ciasno sznurami zasad, nakazów i zakazów, albo pozbawiony niezbędnych środków do wykonywania swojej pracy? W tak mocno zaciśniętej pętli ograniczeń samozarządzanie nie może działać, bo potrzebna jest do tego choćby minimalna decyzyjność Developerów.

Brak możliwości samozarządzania prowadzi do zaniku potrzeby stosowania narzędzia, jakim jest Daily Scrum, którego zasadniczym celem jest dostarczenie Developerom dawki empiryzmu niezbędnej do naoliwienia samozarządzania właśnie. I nawet, jeśli zdarzenie w takich okolicznościach wciąż się odbywa, najczęściej zamienia się w spotkanie statusowe służące nie Developerom lub choćby całemu Zespołowi Scrum, ale otoczeniu, które nad Developerami sprawuje ścisłą kontrolę.

Uszy do góry!

Nie chciałbym budować wrażenia, że wszędzie jest tak źle – opisywałem skrajności, które czasami się zdarzają. Rzeczywistość prawie nigdy nie jest całkiem czarna, choć w wielu miejscach dostrzegamy symptomy powolnego osuwania się ku tej czerni. Jeśli je widzimy, możemy i powinniśmy przeciwdziałać degradacji Zespołu.

Czasami wystarczy wyedukować otoczenie. Bo, jakkolwiek naiwnie to brzmi, wielu ludzi działa irracjonalnie i w sposób szkodliwy nie ze złej woli, ale na skutek braku wiedzy lub zrozumienia co pomaga, a co szkodzi Zespołom. Gdzie indziej trzeba pokazać otoczeniu praktycznymi działaniami, że warto zaufać Zespołowi, że Developerzy potrafią dużo zrobić, jeśli mają wystarczająco przestrzeni, by wykorzystać swe umiejętności…

Poszukajmy sojuszników. Jeśli przyjdzie nam pracować z ludźmi, którzy nie ogarniają Scruma i są impregnowani na argumenty lub wiedzę, którą staramy się im przekazać, znajdźmy kogoś, kto potrafi do tych osób dotrzeć. A może gdzieś uda się znaleźć przykład dobrze używanego Scruma, który zmieni ich nastawienie?

Bohaterowie

Pisałem wcześniej o heroizmie, jakiego wymagałoby dobre użycie Scruma w niektórych organizacjach i Zespołach. Pragnę donieść, że są tacy ludzie, którzy potrafią wykazać się odwagą, bo im zależy. Bo wierzą w cel, do którego dążą. Bo są cierpliwi, a może nawet uparci i nie chcą odpuścić za szybko. Czasem są w tym naiwni i czekają na cud, który nie nastąpi. Bywa jednak, że cud ten ma miejsce i dochodzi do przełomu, po którym w końcu jest lepiej.

Nie jest moją intencją namawianie do walki z wiatrakami lub heroizmu. Chcę skłonić osoby tkwiące w trudnym środowisku do aktywnego działania i ustalenia – empirycznie, a jakżeby inaczej! – co jest możliwe. Łatwo ulec defetyzmowi i skupić się na negatywach, dużo trudniej znaleźć ten wąski przesmyk prowadzący do poprawy stanu spraw.

Zamiast przyjmować z góry, że mamy do czynienia ze skrajnymi patologiami, spróbujmy coś zmienić, choćby nawet miała to być bardzo mała rzecz. Reakcja na nasze działania – zwłaszcza dobrze przemyślane – często wskaże kierunek dalszych starań i usprawnień. Obrazowo mówiąc, znajdziemy w murze miejsce, gdzie kilka słabszych uderzeń młotkiem pozwoli wykuć dziurę. Lub potwierdzimy (zamiast domniemywać), że mur jest wszędzie tak samo gruby, a beton, z którego go stworzono, cały czas tężeje. Wtedy z czystym sumieniem możemy iść gdzieś indziej.

Nie tylko Daily Scrum

Niesprzyjające środowisko i problemy w samym Zespole, które utrudniają przeprowadzanie Daily Scrumów, wpływają negatywnie na wszystkie elementy Scruma. Moje doświadczenie (ale też opowieści znanych mi Scrum Masterów) podpowiadają, że zanim jeszcze umrze Daily Scrum, nieboszczką stanie się Retrospekcja Sprintu, bo w niej niczym soczewce skupią się wszystkie problemy. Z drugiej strony, dopóki Retrospekcja wciąż działa, dopóty mamy w zasięgu ręki narzędzie, by z trudnościami sobie poradzić.