Blog

Z faktu, że Developerzy pracujący w Scrumie spotykają się codziennie o tej samej porze na maksymalnie piętnaście minut przy jakiejś tablicy bynajmniej, nie wynika, że Daily Scrum się rzeczywiście odbywa. Możliwe, że tak, ale równie dobrze może to być ceremonia wymuszona przez proces, niedająca żadnych wartościowych efektów. Jak Scrum Master może stwierdzić, czy to, co robią Developerzy w jego Zespole, 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 Developerom. 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 trakcie Planowania Sprintu. Raz na dobę Developerzy sprawdzają stan spraw oraz adekwatność planu działań na pozostałą część Sprintu, po czym na podstawie pozyskanej w ten sposób wiedzy dokonują adaptacji planu (o ile to konieczne).

Oczywiście dostosowanie planu działania odbywa się na bieżąco, gdy tylko Developerzy odkryją taką potrzebę i nie należy odkładać tego do najbliższego Daily Scruma. To zdarzenie służy zapewnieniu, że takie podejmowane na bieżąco decyzje wiodą we właściwą stronę i są wystarczająco skoordynowane, by nie doszło do rozejścia się Developerów w rozbieżnych kierunkach. 24-godzinny interwał, z jakim Daily Scrum się odbywa, jest na tyle krótki, że ryzyko całkowitego wymknięcia się spraw spod kontroli jest ograniczone.

Przy czym w Daily Scrumach nie chodzi po prostu o wymianę informacji pomiędzy Developerami, którzy komunikują się ze sobą na bieżąco i nie potrzebują do tego dedykowanego zdarzenia. Można przyjąć, że w wielu przypadkach Developerzy w trakcie Daily Scruma nie dowiadują się niczego, czego nie wiedzieliby przed nim. Daily Scrumy są po to, by uwspólnić wnioski z posiadanej wiedzy i skoordynować działania podejmowane na ich podstawie.

Jest bowiem możliwe, że wszyscy Developerzy wiedzą, że np. praca nad jakąś zmianą w produkcie jest na półmetku, ale:

• jeden z nich uzna, że praca idzie świetnie i powinna być kontynuowana zgodnie z planem,
• inny będzie przekonany, że implementacja się przeciąga, co zagraża możliwości osiągnięcia Celu Sprintu, dlatego konieczna jest zmiana planów i przegrupowanie sił,
• kolejny uważa, że robota idzie lepiej, niż oczekiwano, więc pojawia się przestrzeń na wykonanie dodatkowej, nieplanowanej wcześniej pracy,
• jeszcze następny będzie przekonany, że zamiast pracować nad tą konkretną zmianą, należy skupić się nad czymś zupełnie innym, o wiele bardziej pilnym, a dopiero – jeśli czas pozwoli – dokończyć rozpoczętą implementację.

Jeśli ze sobą nie porozmawiają i nie uzgodnią, co faktycznie każdy z nich powinien teraz robić, może się okazać, że podejmować będą kompletnie rozbieżne decyzje. A nie dokonując częstej synchronizacji, zbyt późno zorientują się, że sprawy wymknęły im się z rąk.

Inny przykład: w Sprincie wystąpił problem, którego nikt nie przewidział. Jest możliwe, że każdy z Developerów o tym wie, ale nie ma gwarancji, że wszyscy tak samo ocenią, co należy w tej sytuacji zrobić. Ktoś może być przekonany, że problem nie jest pilny, ktoś inny, że krytyczny. Wszyscy mogą uznać, że problemem ktoś się zaraz zajmie, w konsekwencji czego nie zajmie się nim nikt do momentu, aż development zostanie całkiem zablokowany.

Gdyby ze sobą porozmawiali, szybko ustaliliby, co i kto ma zrobić albo – jeśli wymaga to dłuższej dyskusji – zaplanowaliby w trakcie Daily Scruma, kiedy ona nastąpi i kto weźmie w niej udział.

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 (fizycznym lub wirtualnym) i każdego dnia 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 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. Pozwoli też szybko wykryć rozbieżności w rozumieniu stanu spraw i uniknąć podejmowania sprzecznych decyzji.

Gdyby spotkania synchronizacyjne odbywały się dopiero wtedy, gdy wszyscy uznają, że „mają czas na rozmowę i mają co pokazać” – mogłoby się okazać, że 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 Developerzy organizują Daily Scrumy. W oczywisty sposób nie wystarczy sprawdzić, czy spotkanie się odbywa i nie trwa dłużej niż kwadrans. Jeśli codzienne spotkania są, ale nijak mają się do tego, czemu Daily Scrum ma służyć, wtedy obowiązkiem Scrum Mastera jest nauczyć Developerów, jak efektywnie używać tego zdarzenia do efektywnego radzenia sobie z niestabilną złożonością w Sprincie.

Jak sprawdzić, czy Daily Scrum jest skuteczny?

Czy jest jakiś prosty i jednoznaczny wskaźnik albo miara, których można użyć do zmierzenia efektywności Daily Scrumów. Zapytany o to 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 metawskaźniki tego, że Daily Scrum jest skuteczny na przestrzeni wielu Sprintów.

Pierwszy: Developerzy potrafią na bieżąco dostosowywać Backlog Sprintu w reakcji na nieplanowane zdarzenia w Sprincie i nie musi tego pilnować Scrum Master, Product Owner ani nikt inny z otoczenia Zespołu.

Drugi metawskaź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, ile 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 (toczą się w nim konflikty) lub gdy funkcjonuje w niezdrowej organizacji (brak celów, opresyjne kierownictwo, brak przyzwolenia na eksperymentowanie i poszukiwanie lepszych sposobów działania), szansa na dobrze działający Daily Scrum jest nieduża. To jednak temat na osobny artykuł.

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 Developerów, że nie zdołają 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łania (czyli: udało się, ale cudem, a nie na skutek świadomych działań).

Innym sygnałem, że Daily Scrum jest skuteczny, jest brak (lub sporadyczność) 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ę Developerów na to, co w danym momencie jest najważniejsze.

Gdy Daily Scrum działa dobrze, prace w Sprincie co do zasady podejmowane są wedle ich ważności – wynikającej z Celu Sprintu. Rzadko zdarzy się więc sytuacja, w której Developerzy najpierw zrealizują „swoje” tematy (na przykład przydzielone do poszczególnych osób w czasie Planowania Sprintu), zanim podejmą cokolwiek innego. Można powiedzieć, że tam, gdzie Daily Scrum naprawdę działa, Backlog Sprintu jest narzędziem używanym przez wspólnie przez Developerów 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ęść Developerów nie wie o istotnym czynniku wpływającym na przebieg prac – to również objaw skuteczności Daily Scruma. 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 niemal cały Sprint 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 i po prostu przestaną się pojawiać na spotkaniu. 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 złoś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 zowąd dobrze idący Sprint zamienia się w totalny chaos i sprawy wymykają się spod kontroli (najczęściej pod koniec iteracji). 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 Developerzy znajdą się wcześniej czy później na cenzurowanym u kierownictwa. 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 umiejący zapewnić mu czas niezbędny na pozbieranie się, jest na wagę złota.

„Z pamiętnika Scrum Mastera”

Na koniec parę opowieści o Daily Scrumach, 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 raz na dobę to za mało. Robili więc Daily Scrumy dwa razy dziennie. Wspominam o tym, bo to idealny przykład dojrzałych Developerów, który używają zdarzenia w metodzie jako narzędzia do radzenia sobie z odkrytym problemem. Odkryli, że książkowy sposób realizacji Daily Scruma to za mało, więc dostosowali je do swoich potrzeb, zachowując przy tym zgodność ze wszystkimi zasadami metody.

Oczywiście nie sugeruję tu, żeby poprzez analogię rozważać scenariusze odwrotne i iść w stronę jakichś co-dwa-dni Scrumów. 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 wydarzyło się coś, co wymaga świadomej reakcji Developerów. Jeśli rzeczywiście synchronizacja co parę dni zamiast 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 liczące sporo Developerów (na przykład piętnastu i więcej), które wpadają 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. W jego trakcie Developerzy mogą zidentyfikować potrzebę odbycia takiej dyskusji i zaplanować, kiedy się ona odbędzie.

Jeśli 15 minut nie wystarcza, coś robimy nie tak. Być może Daily Scrum zaczyna pełnić jeszcze jakąś inną funkcję – pytanie, czy aby nie kosztem funkcji podstawowej.

A może problem tkwi w samym 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 Zespół 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ć.

Niewykluczone zresztą, że przeciągające się Daily Scrumy wcale nie są pochodną wielkości Zespołu, ale tego, jak organizuje on sobie pracę. Jeśli każdy Developer zajmuje się czym innym, nawet pobieżne przejście przez listę realizowanych równocześnie zmian w produkcie będzie czasochłonne. Gdyby praca odbywała się zespołowo, nie byłoby takiego problemu…

Historia trzecia o limitowaniu WIP

Ano, właśnie. Wiele Zespołów podchodzi do prac w Sprincie w ten sposób, że Developerzy 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 liczby wymagań realizowanych jednocześnie do dwóch (na limit WIP równy 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 codziennie ustanawiać cel dnia po to, by skupić się na tym, co ważne.

Czym jest wspomniany WIP? To ilość pracy w toku (ang. work in progress). W przypadku Zespołu, o którym piszę, WIP ten liczony był jako liczba elementów Backlogu Produktu realizowanych równocześnie.

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 jeśli 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, o tyle nadal istniała szansa na powstanie nieporozumień i podejmowanie sprzecznych decyzji.

Poza tym regularne sprawdzenia, czy plany są adekwatne, wymuszały na obu Developerach taki sposób dzielenia pracy na etapy, by w momencie odbywania się Daily Scruma mieć już coś zrobione (lub wiedzieć, że podczas pracy nad tym czymś pojawiły się problemy). Dzięki temu development nie ciągnął się nigdy bez wyraźnych efektów przez kilka dni. Efektem była wysoka skuteczność w działaniu, mimo że przecież Zespół był naprawdę niewielki.

A jak Daily Scrum działa w twoim Zespole?

Pomyśl, jak to sprawdzić.