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 zespołu developerskiego, pozbawiając go 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 poprzedniego artykułu, zapewne bez trudu odpowie sobie na pytanie. Ale 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”. Taki co do litery zgodny ze Scrum Guide, w którym brak jakiejkolwiek głębi. Są oczywiście wszystkie role (bo metoda ich wymaga), powstają artefakty (bo Schwaber z Sutherlandem kazali), odbywają się wymagane zdarzenia. Ale jak poskrobiemy ten piękny obrazek paznokciem, okaże się, że to tak zwany „mechanistyczny Scrum”, „zombie-Scrum” czy „Scrum-wydmuszka”.

Żadne zdarzenie w takim „Scrumie” nie służy empirycznej kontroli procesu, żadna z ról nie dąży do uzyskania wartości, żaden artefakt nie jest używany tak, by zapewniać przejrzystość. W takim zespole Daily Scrum jest ceremonią. Jest więc mistrz ceremonii (osobliwie jest to najczęściej Scrum Master), jest protokół (lub obrządek, jak kto woli). Nie ma za to zaangażowania uczestników ani wartości wynikającej z odbycia ceremonii.

2. Gdy brak wartości

Teraz wyobraźmy sobie Scruma w zespole, któremu całkowicie brak jednej z wartości (odwagi, zaangażowania, otwartości, skupienia lub szacunku). W praktyce zanik 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 „trącać”, 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. Gdy nikt nie wie, dokąd zmierzamy

Co się stanie przypadku organizacji, która powołała do istnienia zespół, ale nie dała mu sensownej odpowiedzi na pytanie „po co”? 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, takiemu teamowi Daily Scrum bardziej przeszkadza, niż w czymkolwiek pomaga, bo przymusza do udawania, że robi cokolwiek na serio. Tylko że tak naprawdę nie robi, bo uczestników procesu nie obchodzi to, co się dzieje. „Na szczęście już czwartek i do weekendu niedaleko” – myślą sobie…

Inny scenariusz braku wizji i celów działania 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 „produktywności”. Nieważne co robimy, skoro ludziom dużo płacimy za każdy dzień, muszą zasuwać. Czyli robić dużo, „dostarczać” szybko i zawsze w terminie. Bo jak nie „dostarczają”, to znaczy, że marnujemy inwestycję 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 podobnie jak wcześniej, powstanie mechanistyczne „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 managementowi to, co ten chce usłyszeć (pal licho przejrzystość!) i zamieni się w spotkanie statusowe. A jeśli zespół będzie mógł 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ć „oficjalnie” (jak się to ma do otwartości i szacunku?). 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 zespół obwiązany zostanie 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ń samoorganizacja nie może zadziałać, bo implikuje ona choćby minimalną decyzyjność developerów.

Brak możliwości samoorganizacji prowadzi do zaniku potrzeby stosowania narzędzia jakim jest Daily Scrum, którego zasadniczym celem jest dostarczenie zespołowi dawki empiryzmu niezbędnej do naoliwienia samoorganizacji 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 zespołowi, ale otoczeniu by „sprawować 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. A jeśli je widzimy, możemy przeciwdziałać.

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ć praktycznymi działaniami, że warto, że potrafimy, że można inaczej… – po to, by zbudować relacje, zyskać zaufanie.

Poszukajmy sojuszników. Nawet jeśli przyjdzie nam pracować z ludźmi, którzy „nie ogarniają” Scruma i są impregnowani na argumenty i wiedzę, którą staramy się im przekazać – warto rozejrzeć się dokoła. Może ktoś potrafi do takich oponentów dotrzeć? Może gdzieś da się wykreować działający przykład, który otworzy im oczy?

Bohaterowie

Pisałem wcześniej o heroizmie, jakiego wymagałoby dobre użycie Scruma w niektórych kontekstach (zwłaszcza organizacyjnych). Pragnę donieść, że są tacy ludzie, którzy potrafią wykazać się odwagą, bo im zależy. Bo wierzą w cel, na rzecz którego pracują. 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. Ale bywa, że następuje, dochodzi do przełomu i 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ć. 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 to 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

Pisząc o efektywnych Daily Scrumach nie chciałem pogłębiać wątku „trudnych organizacji” i zespołów z problemami głównie dlatego, że nie chodzi tu wyłącznie o to jedno zdarzenie. Wszystko, co wpływa negatywnie na działanie Daily Scruma, będzie równie silnie uderzać we pozostałe elementy Scruma.

Z moich doświadczeń (ale też opowieści znanych mi Scrum Masterów), zanim „umrze” Daily Scrum, wcześniej nieboszczką stanie się retrospekcja, bo w niej niczym soczewce skupią się problemy z brakiem wartości i niesprzyjającym otoczeniem. Z drugiej strony tak długo, jak retrospekcja wciąż działa, to mamy w zasięgu ręki narzędzie, by z trudnościami zacząć sobie radzić.