Blog

Z faktu, że zespół pracujący w Scrumie spotyka się codziennie o tej samej porze na maksymalnie piętnaście minut przy tablicy bynajmniej nie wynika, że w zespole tym zdarzenie Daily Scrum się rzeczywiście odbywa. Możliwe, że tak, ale równie dobrze może to być ceremonia wymuszona przez proces, nie dająca żadnych wartościowych efektów. Jak Scrum Master może stwierdzić, czy to, co jego zespół robi, jest Daily Scrumem, czy jedynie stratą czasu?

Po co jest Daily Scrum?

Przed przeczytaniem dalszego ciągu zastanów się, jaka byłaby twoja odpowiedź na takie pytanie. Czy potrafisz wyjaśnić cel tego zdarzenia? I to w sposób, który nie będzie instrukcją jak przeprowadzać Daily Scrum, ale odpowiedzią na pytanie po co zdarzenie to się odbywa? I dlaczego ten cel, który Daily Scrum ma pomóc osiągnąć, jest tak istotny?

Odpowiadając najogólniej: Daily Scrum dostarcza codziennej minimalnej dawki empiryzmu zespołowi developerskiemu. Empiryzm ten jest niezbędny, by radzić sobie ze wszystkim, co wydarzyło się w czasie trwania sprintu, co ma istotny wpływ na przebieg prac i możliwość osiągnięcia ustalonego celu sprintu, a o czym nie wiadomo było w momencie planowania. Co 24 godziny zespół sprawdza stan spraw oraz adekwatność planu działań na pozostałą część sprintu, po czym w oparciu o pozyskaną w ten sposób wiedzę dokonuje adaptacji planu (o ile to konieczne).

Oczywiście nie jest tak, że dostosowanie planu działania odbywa się tylko w czasie Daily Scruma. Decyzje o tym podejmowane są na bieżąco przez zespół, bo przecież interakcje między developerami nie ograniczają się wyłącznie do Daily Scruma. Natomiast raz na dobę spotykają się oni by synchronizować swoją wiedzę i uzgodnić plan działania. To zapewnia (a przynajmniej powinno zapewnić), że wszyscy tak samo rozumieją sytuację i pozwala zespołowi szybko reagować na pojawiające się nieprzewidziane problemy (ale też wykorzystać niespodziewane możliwości, odkryte już w trakcie sprintu). 24 godziny to interwał na tyle krótki, że ryzyko całkowitego wymknięcia się spraw spod kontroli jest ograniczone.

Celem Daily Scruma jest więc sprawdzenie postępu prac, a następnie po zsynchronizowaniu wiedzy o tym i o odkrytych problemach / możliwościach, dostosowanie planów. Powodem jest konieczność skutecznego i szybkiego reagowania na wszystko, co czyni nieadekwatnymi poczynione wcześniej plany.

Co jest Daily Scrumem, a co nim nie jest

Jest oczywistością, że wymóg organizowania Daily Scruma nie sprowadza się do stwierdzenia „ma odbywać się spotkanie”. Chodzi o osiąganie celu tego zdarzenia. Dlatego nie ma znaczenia, czy odbywać się będzie ono rano, czy pod koniec dnia, czy będzie na stojąco czy na leżąco. Ważne jest natomiast, by spotkanie odbywało się w tym samym miejscu i o tej samej porze z co najmniej dwóch powodów.

Pierwszy: stałe miejsce i pora ułatwiają organizację Daily Scruma (nikt nie musi się zastanawiać, gdzie i o której tym razem będzie spotkanie), a także umożliwia developerom zorganizowanie sobie działań tak, że udział w zdarzeniu nie odrywa ich od niedokończonej pracy. Brak stałego miejsca i czasu zwiększałby złożoność, a tej przecież i tak już mamy zazwyczaj w nadmiarze…

Drugi powód: stały interwał zmusza do twardego sprawdzenia jak jest teraz, co zabezpiecza przed wpadnięciem w pułapkę myślenia, że „jeszcze momencik i na pewno skończymy”. Regularne sprawdzenie ujawni niepokojące trendy, jeśli praca idzie wolniej niż się developerzy spodziewali. Gdyby spotkania synchronizacyjne odbywały się dopiero jak wszyscy uznają, że „mają co pokazać” – mogłoby się okazać, że pierwsze zorganizowane zostanie zbyt późno, by możliwa była skuteczna adaptacja planów na pozostałą część sprintu.

Scrum Guide nakłada na Scrum Mastera obowiązek zapewnienia, że zespół odbywa Daily Scrumy i potrafi je przeprowadzić w maksymalnie kwadrans. Jeśli codzienne spotkania są, ale nijak mają się do tego, czemu Daily Scrum ma służyć – to obowiązkiem Scrum Mastera jest wyedukować zespół i pomóc mu dojrzeć do tego, by zdarzenie to wykorzystywać efektywnie do radzenia sobie ze złożonością.

Jak sprawdzić, czy Daily Scrum „działa” w zespole?

Czy jest jakaś metryka (albo ogólniej mówiąc wskaźnik), którego można użyć do jednoznacznego stwierdzenia, czy Daily Scrum jest robiony dobrze? Zapytany o to zastanawiałem się przez chwilę, i doszedłem do wniosku, że w zasadzie nie (a przynajmniej ja takiej jednej klarownej miary nie potrafię określić).

Zbyt wiele zależy od indywidualnego kontekstu każdego zespołu, poza tym często zmiana na lepsze lub gorsze jest widoczna dopiero w dłuższej perspektywie (a nie jako jedna, punktowo mierzona wartość). Dlatego należy poszukiwać wzorców i monitorować trendy. A wtedy da się określić trzy meta-wskaźniki tego, że Daily Scrum „działa” na przestrzeni wielu sprintów.

Pierwszy: organizacja pracy w zespole jest taka, że to on sam wyłapuje problemy wynikające z nieadekwatnych planów i złej koordynacji swoich działań zanim zrobi to Scrum Master lub otoczenie (inny team, interesariusze, management).

Drugi meta-wskaźnik dobrego Daily Scruma: nieprzewidziane problemy skali mniejszej niż totalna katastrofa nie powodują, że zespołowi nie uda się niczego dostarczyć, „odporność” na problemy jest duża a czas reakcji na niespodziewaną zmianę krótki.

Trzeci wskaźnik związany jest nie tyle z efektywnością zdarzenia, co z samym nastawieniem developerów do niego. O skuteczności Daily Scruma świadczy chęć developerów do uczestnictwa w nim. Jeśli zdarzenie pomaga w organizacji pracy i nie jest stratą czasu, będzie się odbywać bez konieczności „zaganiania trzódki” na spotkanie przez Scrum Mastera, bez spóźnień i nieobecności etc.

Tu uwaga: jeśli zespół jest obarczony jakimiś ciężkimi problemami wewnętrznymi (konflikty), lub gdy funkcjonuje w niezdrowej organizacji (brak celów, opresyjny management, brak przyzwolenia na innowację i sprawdzanie nowych rozwiązań), szansa na „działający” Daily Scrum jest nieduża. Ale to temat na osobny artykuł (już wkrótce).

Symptomy dobrze działającego Daily Scruma

Jeśli Daily Scrum działa, to niski jest odsetek sprintów, w których zespół całkowicie traci kontrolę nad przebiegiem prac. Mówiąc inaczej rzadko zdarzają się iteracje, w których rozwój sytuacji do tego stopnia zaskoczy zespół, że ten nie zdoła w ogóle zareagować, albo zrobi to za późno. Skutkiem niekoniecznie musi być nieosiągnięcie celu sprintu; może nim być również nieuporządkowany sposób działań (czyli: udało się, ale cudem, a nie na skutek świadomych działań).

Innym dobrym sygnałem, że Daily Scrum jest skuteczny, jest brak (lub mała ilość) sytuacji, gdy robione jest przez developerów coś mało istotnego, podczas gdy pilniejsze rzeczy, ujawnione już w czasie sprintu, leżą odłogiem. Inaczej mówiąc dobrze robione Daily Scrumy szybko doprowadzają do przeorientowania się zespołu na to, co w danym momencie jest najważniejsze w kontekście bieżącego sprintu.

Gdy Daily Scrum „działa”, prace w sprincie co do zasady podejmowane są wedle ważności. Rzadko zdarzy się więc sytuacja, w której członkowie zespołu najpierw zrealizują „swoje” tematy (na przykład przydzielone do poszczególnych osób w czasie planowania), zanim podejmą cokolwiek innego. Można powiedzieć, że tam, gdzie Daily Scrum naprawdę działa, backlog sprintu jest narzędziem używanym przez cały zespół wspólnie do empirycznego planowania działań (w kontrze do traktowania tego backlogu jako quasi-statycznej listy sumującej rzeczy do zrobienia przez poszczególnych developerów).

Jeśli rzadkością jest sytuacja, w której przez kilka dni część zespołu nie wie o istotnym czynniku wpływającym na przebieg prac – to również objaw skuteczności Daily Scruma. W takim zespole prawdopodobnie nie zdarzy się (lub wystąpi incydentalnie) sytuacja, w której developerzy zdecydowanie za  późno zajmą się problemem uniemożliwiającym osiągnięcie celu sprintu.

Przy dobrze robionym Daily Scrumie nie będzie też można zaobserwować sytuacji znanej (niestety) z wielu firm, w których przez półtorej tygodnia codziennie wszyscy mówią „idzie nam dobrze”, a dwa dni przed końcem iteracji okazuje się, że niczego nie da się ukończyć ze względu na kaskadę problemów, które pojawiały się w kolejnych dniach, a z którymi nic nie zrobiono (ani nawet o nich nie porozmawiano).

Na koniec zastrzeżenie: piszę o symptomach, a nie twardych wskaźnikach, że „jest dobrze”. Tak jak brak tych symptomów nie oznacza automatycznie, że Daily Scrum kompletnie nie działa, tak ich występowanie nie jest gwarantem, że sytuacja jest idealna.

Gdy Daily Scrum jest nieskuteczny…

…to ludzie zagłosują „nogami”. Ich nastawienie do zdarzenia będzie wrogie lub lekceważące. Nikt nie chce brać udziału w spotkaniu, z którego nic nie wynika, i które wydaje się (lub co gorsza rzeczywiście jest) stratą czasu. Pierwszym wyraźnym sygnałem, że Daily Scrum może być robiony źle jest brak zaangażowania developerów w jego organizację, spóźnienia, a czasami obraźliwe uwagi o „bezsensownych wymogach Scruma”.

Innym sygnałem, że coś z Daily Scrumem jest nie tak jest powtarzanie się sytuacji, w których ni stąd ni z owąd dobrze idący sprint zamienia się w totalny chaos i sprawy wymykają się spod kontroli (najczęściej pod koniec sprintu). Przyczyny mogą być przynajmniej dwie i występować rozłącznie, lub razem. Pierwsza to za mała przejrzystość spraw, przez co za późno dostrzegany jest problem. A druga, bardziej związana właśnie ze zrozumieniem procesu empirycznego – skupienie developerów na „swoich” zadaniach, bez intencji rzeczywistej pracy zespołowej i wspólnego rozwiązywania problemów.

Nieskuteczne Daily Scrumy prowadzą do narastających problemów z kontrolowanym tworzeniem działających produktów (przyrostów) na koniec sprintu. To spowoduje, że zespół znajdzie się wcześniej czy później na cenzurowanym przynajmniej u Product Ownera. A to często uruchamia lawinę nowych problemów i ustawia developerów na równi pochyłej, bo trudno dokonywać usprawnień pod presją. W takiej sytuacji dobry Scrum Master pracujący z zespołem i potrafiący zapewnić mu dość czasu na „pozbieranie się” jest na wagę złota.

„Z pamiętnika Scrum Mastera”

Na koniec parę ciekawostek dotyczących Daily Scruma, które mogą stanowić dodatkową inspirację.

Historia pierwsza o ekstremalnej nieprzewidywalności

Spotkałem kiedyś zespół, który pracował w tak niestabilnym środowisku, że po kilku sprintach stało się jasne, iż synchronizacja co 24 godziny to za mało. Robili więc Daily Scrumy dwa razy dziennie. Wspominam o tym, bo to idealny przykład świadomego zespołu, który używa zdarzenia w metodzie jako narzędzia – gdy odkrył, że „książkowy” sposób jego realizacji to za mało, dostosował je do swoich potrzeb.

Oczywiście nie sugeruję tu, żeby poprzez analogię rozważać scenariusze odwrotne i iść w stronę jakichś „bi-daily scrumów” (specjalnie pisze to w cudzysłowie i z małych liter). Scruma jako metody używa się do radzenia sobie ze złożonością i nieprzewidywalnością – 24 godziny to naprawdę dużo czasu na to, by podziało się coś, co wymaga świadomej reakcji zespołu. Jeśli rzeczywiście synchronizacja co parę dni zamiast codziennie byłaby wystarczająca… warto zastanowić się, czy Scrum jest właściwie dobraną metodą do charakteru rozwiązywanych nim problemów.

Historia druga o tym, że kwadrans zawsze wystarczy

Zdarzają się zespoły większe niż zalecane 3-9 developerów i wpadają one często na „genialny” pomysł, że proporcjonalnie wydłużą sobie Daily Scrumy tak, by było dość czasu na… no właśnie, na co? Gdyby czas trwania zdarzenia miał zależeć od wielkości zespołu, twórcy metody zapewne daliby nam to jasno do zrozumienia w Scrum Guide. W istocie kwadrans dla każdego zespołu wystarczy do synchronizacji i podjęcia kluczowych decyzji. Daily Scrum nie służy przecież dyskusjom technicznym ani rozwiązywaniem problemów – a jedynie zaplanowaniu takich dyskusji (jeśli są potrzebne) i innych działań.

Jeśli 15 minut nie wystarcza, coś robimy nie tak. Albo Daily Scrum zaczyna pełnić jeszcze jakąś inną funkcję (pytanie, czy nie kosztem funkcji podstawowej?), albo problem tkwi w zespole. Im mniejsza spoistość grupy, im mniej zgrani ze sobą są developerzy, tym oporniej im Daily Scrum idzie. Doświadczenie (obserwacje pracy wielu zespołów) pokazuje, że sprawny i zgrany team rzadko potrzebuje więcej niż 5-7 minut na przeprowadzenie Daily Scruma i to nawet w sytuacji, gdy co drugi developer ujawnia w jego trakcie niespodziewany problem, z którym coś trzeba zrobić.

Historia trzecia o limitowaniu WiP

Wiele zespołów podchodzi do prac w sprincie w ten sposób, że dzielą między siebie elementy backlogu produktu i próbują realizować maksymalną ich liczbę równolegle. Poza generowaniem masy problemów technicznych, powoduje to nieuchronnie jeden skutek: trudność z rzetelną oceną sytuacji. Ponieważ każdy zajęty jest czym innym, w zasadzie nie ma też pracy zespołowej (nie ma więc skupienia zespołu, jednej z wartości Scrum…). Daily Scrum w takiej sytuacji sprowadza się do spotkania ludzi, którzy nie mają właściwie wspólnych tematów. Skutki bywają opłakane.

Jeden z moich zespołów tak pracował do czasu, gdy przygniotło go „dziedzictwo” niedokończonych tematów rozpoczętych w poprzednich sprintach. W desperacji developerzy podjęli decyzję o ograniczeniu ilości wymagań realizowanych jednocześnie do dwóch (na WiP limit = 1 nie zdołałem ich namówić). Po kilku sprintach nie dość, że wygrzebali się z zaległości, to odkryli, że Daily Scrum pomaga w organizacji pracy i radzeniu sobie w Sprincie. I to do tego stopnia, że obok celu sprintu zaczęli ustanawiać każdego dnia „cel dnia” po to, by skupić się na tym, co ważne.

Historia czwarta o tym, jak Daily Scrum pomaga developerom

I ostatnia opowiastka o zespole, w którym było tylko trzech developerów. Gdy jeden z nich poszedł na dłuższy urlop, wydawać by się mogło, że dwaj pozostali nie będą robić Daily Scrumów. Dwie osoby to już nie zespół, ale para, nie istnieje też ryzyko, że jak o czymś porozmawiają, to jeden z nich nie będzie wiedział, co ustalili. Okazało się jednak, że Daily Scrumy odbywały się nadal, ponieważ – jak powiedzieli mi obaj panowie – „pomaga porządkować pracę”. O ile bowiem nie istniał problem synchronizacji wiedzy, regularne sprawdzenia czy plany są adekwatne wymuszały taki sposób działania, by w momencie odbywania się Daily Scruma mieć już coś zrobione (lub wiedzieć, że podczas pracy nad tym czymś pojawiły się problemy). Dlatego, choć pracowali w parze, Daily Scrum dalej robili.

A jak Daily Scrum działa w twoim zespole?

Pomyśl, jak to sprawdzić.