Dziś (prawie) wszystko o DSM (ang. Daily Scrum Meeting), jednym z pięciu wydarzeń opisanych w Scrum Guide. Czy bez Daily Scrum Meeting damy radę skutecznie i wydajnie pracować w Scrumie? Czym się różni od „Daily Stand Upu”?
Czym jest Daily Scrum?
Daily Scrum to jedno z pięciu wydarzeń w Scrumie, które ma na celu przygotowanie planu dla Deweloperów na kolejny dzień pracy. Oznacza to, że rezultatem Daily jest to, że wszyscy uczestnicy wiedzą co będą robić do kolejnego spotkania.
Pracując zespołowo nie mamy świadomości odnośnie tego, co wszyscy robią w każdym momencie, z jakimi problemami się mierzą, czy potrzebują pomocy i czy może już skończyli coś, na czym nam bardzo zależało. Daily jest po to, żebyśmy przynajmniej raz dziennie wszyscy spotkali się w jednym miejscu i ustalili jak będziemy pracować przez kolejne 24 godziny (czyli do kolejnego Daily).
Ci, którzy pomyśleli sobie, że przecież wszyscy wiedzą co mają robić, będą zdziwieni jak słabo informacje przepływają w zespołach. Tym bardziej jest to widoczne w erze pracy zdalnej. Takie szybkie, codzienne spotkanie, które nigdy nie powinno trwać dłużej niż 15 minut, jest ekstremalnie pożyteczne.
Tu warto podkreślić, że Daily Scrum to nie jest status ani spowiadanie się, ani nawet nie „mówienie co zrobiliśmy”. Daily to przede wszystkim wydarzenie, na którym wszyscy wspólnie omawiamy to, co będziemy robić.
Po co ten standup?
Daily Standup jest pojęciem z okolic eXtreme Programming (XP). Tam faktycznie istniała sugestia, że w trakcie Daily wszyscy powinni stać, ponieważ niewygoda zmusza wszystkich do tego, żeby szybko i sprawnie uwinęli się z tematem. W Scrumie nie ma takich wymagań odnośnie Daily, ale czasami możemy usłyszeć tę nazwę (standup) zamiennie stosowaną z Daily. Tu trzeba dodać, że faktycznie niektóre rzeczy lepiej się robi na stojąco – prowadzi szkolenia, warsztaty, przemówienia. Jeśli jesteśmy w biurze, to lepiej także stać w trakcie Daily Scrum Meeting, najlepiej bezpośrednio pod naszą Tablicą Scrum.
Odpowiedź na pytanie „Po co?”, powinna być już wam dobrze znana. Wyrwani do odpowiedzi w nocy o północy powinniście powiedzieć, że Daily jest po to, żeby Deweloperzy zaplanowali kolejny dzień pracy. Chodzi o to, żebyśmy ustalili co zostało jeszcze do zrobienia, co już zostało zrobione i jaki jest najlepszy sposób na to, żeby osiągnąć Cel Sprintu.
To też mocno sugeruje, że w swoim założeniu w Scrumie nie przydzielamy wszystkich zadań do osób w zespole. Pracujemy zespołowo! Każdy z nas zabiera się za jakieś rzeczy do wykonania, ale nad następnymi będziemy się rozglądać dopiero po tym, jak skończymy bieżące zadania. Niektórzy mówią, że Sprint Backlog to powinien być worek, z którego pobieramy kolejne rzeczy do realizacji. Oczywiście, jak już skończymy to, co rozgrzebaliśmy.
Procedura Daily Scrum
Scrum jest frameworkiem, to znaczy, że nie zawiera szczegółowych instrukcji przepisów i porad. Określone są „jedynie” pewne ramy. Podobnie jest w przypadku Daily Scrum, gdzie nie mamy ustalonego sposobu działania. Mamy za to określony cel i maksymalny czas na jego osiągnięcie. Ten czas to 15 minut (niezależnie od długości Sprintu). Sprawne i zgrane zespoły ubijają się w 7-8 minut.
Najczęstszą formuła prowadzenia Daily Scrum jest przechodzenie po każdej osobie po kolei i szybkie szybkie streszczenie tego, czym się ona zajmuje. Warto się też pochwalić tym, co zostało skończone, szczególnie, jeśli ma to wpływ na resztę zespołu. Tutaj zawsze też jest miejsce na to, żeby zgłosić jakiekolwiek przeszkody, które powstrzymują nas przed osiągnięciem Celu Sprintu lub zrealizowaniem jakichś wymagań. Pamiętajmy jednak, że nie trzeba czekać na Daily ze zgłaszaniem blokerów. Róbmy to od ręki.
Równie popularne jest przejście przez tablicę scrumową, czyli skomentowanie każdego wymagania, które znajduje się w trakcie realizacji. W ten sposób jesteśmy też w stanie zaktualizować ich status na jednym krótkim spotkaniu. Niektórzy wolą to robić przed Daily, ale jest pewna w magia w przesunięciu czegoś do kolumny „Done„.
Trzecia najpopularniejsza metoda, to wyznaczanie kolejnej osoby, która będzie mówiła. Każdy na koniec swojej wypowiedzi, wyznacza następnego/następną. Dzięki temu, każdy „musi uważać”, bo zaraz może być jego/jej kolej. Na fizycznych spotkaniach w biurze używaliśmy do tego celu piłeczki, którą po prostu rzucaliśmy do siebie, tak żeby wyznaczyć jakąś kolejność. Na spotkaniach zdalnych najczęściej odbywa się ta na zasadzie nominowania na koniec wypowiedzi.
Warto tutaj po raz kolejny podkreślić, że Daily to nie spotkanie statusowe. Nie chodzi o to, żeby każdy „wyspowiadał się” z tego co robił i co będzie robił. My liczymy na dyskusję, które będzie skutkować stworzeniem lepszego planu na najbliższy dzień pracy.
To chyba jest też moment na to, żeby odczarować pewne mity i jasne i wyraźnie stwierdzić: na Daily znajdują się tylko i wyłącznie Deweloperzy. Nie ma tam Product Ownera i nie ma tam Scrum Mastera, o ile nie są oni także Deweloperami realizującymi rzeczy ze Sprint Backlogu.
Słynne trzy pytania…
Do 2017 roku w Scrum Guide istniał zapis, mówiący o tym, że na Daily każda jedna osoba powinna odpowiedzieć na trzy pytania. Te pytania znamy na pamięć, śnią się nam po nocach i przytaczamy je poniżej aby Wam też się śniły:
- Co zrobiłem wczoraj, co pomogło Zespołowi Deweloperskiemu przybliżyć się do osiągnięcia Celu Sprintu?
- Co zrobię dzisiaj, co pomoże Zespołowi Deweloperskiemu przybliżyć się do osiągnięcia Celu Sprintu?
- Czy widzę jakiekolwiek przeszkody mogące uniemożliwić mi lub Zespołowi Deweloperskiemu osiągnięcie Celu Sprintu? – Scrum Guide
Słyszałem o sytuacjach, w których ktoś „tresował” ludzi, żeby odpowiadali po kolei na te trzy pytania. Trzeba jednak przyznać, że Daily przeprowadzone w ten sposób jest głupią ceremonią, a nie czymś co faktycznie pomaga nam zaplanować kolejny dzień pracy. Osobiście nigdy w ten sposób nie działałem. Jeśli czasami zdarzyło mi się opowiedzenie o takich czy innych rzeczach, to nigdy nie powinien to być obowiązek.
Na szczęście od 2017 roku te pytania to tylko i wyłącznie sugestia. Nie jest to już twardy wymóg i w końcu możemy odetchnąć i ze spokojem być w pełni zgodni z metodyką.
Zapis ten nie był zupełnie pozbawiony sensu. Jasno pokazuje nam, że celem Daily Scrum jest dogadanie się w kwestii tego, jak mamy zamiar osiągnąć Cel Sprintu. Celem nigdy nie jest zrealizowanie wszystkich rzeczy, które wrzuciliśmy do Sprint Backlogu. Czasami więc możemy znaleźć sugestie, że nie powinniśmy mówić o rzeczach, które poza tym cel wykraczają. Nie zgadzam się z tym i zaproponuję prostsze rozwiązanie. Przede wszystkim rozmawiajmy o Celu Sprintu, a o innych rzeczach – w drugiej kolejności. 15 minut to naprawdę dużo czasu, żeby być w stanie omówić kolejne 8 godzin pracy.
Idealna pora na Daily Scrum Meeting
Jakoś tak się złożyło, że większość zespołów robi Daily rano. „Rano” to znaczy w pierwszych dwóch godzinach pracy. Ma to całkiem dużo sensu, ponieważ skoro mamy zaplanować sobie czas do kolejnego Daily, to robienie tego na początku dnia pracy jest po prostu naturalne.
Nie spotkałem się z zespołem który robiłby Daily na koniec dnia pracy – po to, żeby ustalić co będzie robić jutro. Nie ma to sensu, chociażby z tego powodu że niektóre osoby zostają po godzinach i coś jeszcze sobie dłubią. Może się zdarzyć, że kolejnego dnia usiądziemy do pracy z już nieaktualnymi informacjami.
Zdarzają się jednak sytuacje, w których Daily odbywa się o jakiejś określonej godzinie z powodów organizacyjnych bądź technicznych. Jeżeli mamy do czynienia z zespołami rozproszonymi działającymi w różnych strefach czasowych, to musimy znaleźć taką godzinę która odpowiada wszystkim. A jeśli wszystkie nasze środowiska są codziennie odtwarzane o jakieś określonej godzinie i skutecznie blokuje nam to jakąkolwiek pracę, to to też jest całkiem niezły termin na Daily.
Niezależnie od tego, Scrum Guide mówi wyraźnie, że czas i miejsce prowadzenia Daily powinny być stałe. Ma to na celu ograniczenie złożoności. Nie pytamy, czy mamy dzisiaj daily, bo mamy je codziennie. Nie pytam gdzie i kiedy, bo zawsze w tym samym miejscu i o tej samej porze.
Zdalny Daily Scrum
Już na wstępie zasugerowałem, że Daily potrzebujemy jeszcze bardziej pracując zdalnie, niż gdy siedzimy w biurze. W pracy biurowej często chodzimy na wspólne lunche, kawę czy po prostu na taras jeżeli takowy jest w naszym biurze. Informacje przypływały same z siebie. Jeżeli ktoś poczuł sie bezsilny i walnął pięścią w klawiaturę – wszyscy to widzieli. Jeśli ta sama osoba zrobi to w domowym zaciszu, nie dowie się o tym nikt.
W przypadku pracy zdalnej wiele osób mówi, że „ciągle rozmawiają ze sobą na Teamsach”. Zwykle jednak robi to tylko część zespołu i to na pewno nie odnośnie wszystkich tematów, które przydałoby się omówić w pełnym gronie. Dlatego w przypadku pracy zdalnej sugeruję, żeby jeszcze większy nacisk położyć na sensowne i skuteczne Daily. Nie ma tutaj miejsca na spowiadanie się i zdawanie raportów. Potrzebne są konkrety.
Daily jest spotkaniem robionym przez Deweloperów dla Deweloperów. Nie ma w nim miejsca ani na tematy które ich nie interesują, ani tym bardziej na Product Ownera, Project Managera czy jakiegokolwiek innego przełożonego, który „chciałby przyjść zebrać status”. Jeżeli ktoś ma taką potrzebę, to zaadresujmy ją innym spotkaniem, przy innej okazji, a daily zostawmy Deweloperom. Po to, żeby mogli omówić rzeczy, które są mi potrzebne do codziennej pracy.
A jeżeli niesutannie słyszymy, że „oni nie mają o czym rozmawiać” i „nic ich nie interesuje”, to odsyłam do tekstu mówiącego o tym że zespół profesjonalistów to nie zespół. Bowiem faktycznie, może zdarzyć się taka sytuacja, że nasza grupa osób nie ma ze sobą o czym rozmawiać. Bo nie mają wspólnych tematów, bo nie realizują wspólnych wymagań i tak naprawdę nie rozwijają jednego produktu. To jednak temat na zupełnie inny tekst, bo taki zespół, to nie Scrum Team.
Jeszcze więcej o Daily, w tym zalecane przez nas „najlepsze praktyki”, możecie znaleźć w tekście https://bialko.eu/agile/3-sposoby-na-daily/