Wydarzenia Scrumowe: Daily Scrum (3)

Daily Scrum jest jednym z 5 wydarzeń Scruma. Jest kluczowym wydarzeniem, które każdego dnia umożliwia Developerom inspekcję wykonanej pracy i adaptację dalszego planu w kierunku osiągnięcia Celu Sprintu.

O Daily Scrum Słów parę

Daily Scrum jest jednym z 5 wydarzeń zdefiniowanych w Scrumie (Sprint, Planowanie, Daily, Review i Retrospektywa) [1].

Daily Scrum to wydarzenie trwające 15-minut, niezależnie od ustalonej długości Sprintu. Odbywa się każdego dnia roboczego w Sprincie o tej samej godzinie i w tym samym miejscu. Jest to spotkanie dla Developerów (obecność innych członków Zespołu np. Scrum Mastera nie jest konieczna). W trakcie tego spotkania dokonuje się inspekcji postępów prac w dążeniu do uzyskania Ukończonego Przyrostu, który pozwoli osiągnąć Cel Sprintu [2].

Celem Daily Scrum jest ustalenie planu działania na najbliższe 24 godziny, czyli do kolejnego Daily (adaptacja). Developerzy rozmawiają o tym co będą robić by zwiększyć szansę osiągnięcia Celu Sprintu. Wynikiem tego krótkoterminowego planowania są najczęściej zmiany w Sprint Backlogu, które przejrzyście ukazują nad czym obecnie pracuje Zespół.

Wykonywane poprawnie Daily Scrum wspiera skupienie, poprawia umiejętność samozarządzania oraz komunikację w Zespole.

Czy mamy jakieś problemy?

W trakcie Daily Developerzy identyfikują napotkane przeszkody. Mogą podjąć próbę szybkiego rozwiązania problemu. Jeżeli uda się sprawnie omówić kwestię i znaleźć rozwiązanie, to unikamy konieczności organizowania dodatkowych spotkań.

Jeżeli natomiast problem jest bardziej złożony, to zasługuje na dodatkowe spotkanie. Warto od razu ustalić kto i kiedy się spotka w celu wypracowania rozwiązania problemu. Staramy się unikać rozwiązywania skomplikowanych kwestii podczas Daily [2], by skupić się na tym co najważniejsze, czyli ustaleniu planu działania na najbliższe 24h.

Dzięki codziennym spotkaniom wszelkie problemy są wyłapywane na wczesnym etapie [4], co powoduje wzrost efektywności pracy Zespołu (np. nikt nie trudzi się w samotności nad czymś przez tydzień).

3 rezultaty zamiast 3 pytań

Scrum Guide nie wskazuje sposobu przeprowadzania Daily Scruma. Można go organizować w dowolny sposób, o ile w wyniku uzyskujemy:

Developerów, którzy mają ustalony plan działania na najbliższy czas,

zidentyfikowane problemy oraz plan ich rozwiązania (np. ustalone kto i kiedy się spotka, żeby wypracować rozwiązanie)

przejrzysty Sprint Backlog odwzorowujący plan działania.

Pewien dość często powielany błąd związany z przeprowadzaniem Daily polega na tym, że każdy odpowiada na 3 pytania [4, 6]: co robiłem wczoraj, co będę robić dziś i czy coś blokuje wykonywaną przeze mnie pracę. Odpowiadanie mechanicznie na tak postawione pytania i zakończenie Daily tuż po odpowiedziach nie wspomaga procesu inspekcji i adaptacji [4]. Tak przeprowadzone Daily zmienia spotkanie w status meeting zabijający samoorganizacje (spowiadanie się z wykonanej pracy i przypisanie nowych tasków).

Odpowiedzi na te pytania mogą dostarczyć istotnych informacji, które pomogą opracować plan działania Developerów. Zbyt łatwo jest jednak wpaść w opisaną powyżej pułapkę „spowiadania się” i utracić możliwości, które daje Daily Scrum.

Można natomiast postawić inne pytania, które naprowadzą Zespół na dobre wykorzystanie Daily Scruma: [3]

CO? – Które zadania są najistotniejsze do wykonania w najbliższym czasie, by przybliżyć Zespół do osiągnięcia Celu Sprintu? Jakie zadania będą kolejne?

KTO? – Kto będzie się nimi zajmował?

KIEDY? – Jaka powinna być kolejność wykonywania poszczególnych elementów planu?

Zwróćcie uwagę, że pytania te wspierają samoorganizację Zespołu! Daily powinno być dyskusją Developerów, współpracą ukierunkowaną na grupowe podejmowanie decyzji [4, 7]

Co robi Product Owner na Daily Scrum?

Ten rozdział nie będzie tym razem długi, ponieważ z założenia Product Owner nie powinien być obecny na Daily. Wydarzenie to jest przeznaczone dla Developerów. Wyjątkiem może być sytuacja, w której PO wciela się również w rolę Developera (pracuje nad PBI ze Sprint Backlogu).

Ewentualnie Product Owner może uczestniczyć w Daily jako cichy słuchacz. Natomiast w takiej sytuacji czyhają na Zespół pułapki, które mogą zaburzyć dobre funkcjonowanie Daily. Jeżeli Zespół wpadnie w którąś z tych pułapek to traci możliwość inspekcji i adaptacji w kierunku Celu Sprintu.

Pułapka #1 – Spotkanie statusowe zamiast Daily Scrum

Obecność osoby pełniącej inną rolę niż Developer może powodować, że Daily może zamienić się w spotkanie statusowe. Członkowie Zespołu mogą mieć uczucie, że muszą się tłumaczyć z wykonywanej pracy i informować o zaplanowanych czynnościach.

Pułapka #2 – Dyskusje niezwiązane z planem na najbliższy dzień

Mogą rozwinąć się dyskusje niezwiązane z głównym celem Daily, jakim jest ustaleniem planu na najbliższy czas. Może to działać w dwie strony – z jednej strony Product Owner może mieć trudność z pozostaniem cichym słuchaczem [8] (PO to osoby, które z natury lubią i dużo mówią), z drugiej strony Developerzy mogą chcieć korzystać z obecności Product Ownera i zadając mu pytania, rozpoczynać dyskusje niezwiązane z Daily.

Pułapka #3 – Zaburzenie transparentności

Obecność Product Ownera może peszyć lub budzić obawy wśród członków Zespołu, blokując pełną transparentność procesu.

Jeżeli mimo tych pułapek Product Owner decyduje się uczestniczyć w Daily Scrum, to Scrum Master powinien pilnować by nie wpływało to negatywnie na rezultaty spotkania [4].

Czy ja bywam na Daily Scrum?

Przyznaje się bez bicia, że na Daily chodzę.

Jestem w pełni świadoma zagrożeń, które czyhają na Zespół, gdy pojawiam się na Daily. Decyduje się na to z paru powodów.

Pracuję z dojrzałym Zespołem, który rozumie proces Scrumowy. Od wielu lat współpracuje z tymi samymi ludźmi i bardzo dobrze się znamy. Dodatkowo zawsze miałam w Zespole dobrych Scrum Masterów, którzy wyłapaliby problemy i umieli je naprawić.

Nie zawsze uczestniczyłam w Daily. Sytuację zmieniła pandemia i praca zdalna. Ograniczony bezpośredni kontakt na co dzień bywa trudny. Dzięki obecności na Daily jestem na bieżąco z tym co się dzieje w Sprincie; staram się milczeć, ale w razie potrzeby jestem dostępna na szybkie pytania ułatwiające ułożenie planu przez Developerów; mogę szybko rozwiać pojawiające się wątpliwości.

Pod koniec Sprintu wcielam się również poniekąd w rolę Developera. Nasza definicja Ukończenia nakłada na Przyrost pewne formalności, którymi zajmuje się jako Product Owner. Są to: zapewnienie spełnienia przez Przyrost wymagań formalno-prawnych, konsultacje dotyczące wprowadzanych zmian z działem certyfikującym Produkt, czy aktualizacja wymaganych przez normy dokumentów dla Produktu.

W Zespole nie mamy niestety osoby, która zajmuje się projektowaniem UX / UI. Jako, że ten temat jest bliski memu sercu, to chętnie podejmuje się prób zaprojektowania koniecznych interfejsów do realizowanych zmian. Wtedy działam w Zespole jako Developer.

Czy poleciłabym obecność na Daily każdemu Product Ownerowi? Zdecydowanie nie, ponieważ może to przynieść więcej szkody niż korzyści. Jeżeli jednak się na to decydujesz, to bądź świadomy zagrożeń i porozmawiaj z swoim Scrum Masterem by był czujny na czyhające pułapki.

Podsumowanie

Daily Scrum jest istotną częścią procesu Scrumowego. Jest wydarzeniem przeznaczonym dla Developerów, a jego celem jest ustalenie planu działania na najbliższe 24 godziny, który będzie maksymalizować szansę Zespołu na osiągnięcie Celu Sprintu. Najlepiej jak Product Owner trzyma się z dala od tego wydarzenia, gdyż pułapki czyhające na Zespół w takiej sytuacji mogą znacząco zaburzyć możliwość Zespołu na praktykowanie empiryzmu w oparciu o filary Scruma, jakimi są przejrzystość, inspekcja i adaptacja.