Daily Scrum — po co i jak go przeprowadzić?

Po co nam to Daily?

Daily Scrum to krótkie, maksymalnie 15 minutowe spotkanie, dla Zespołu Deweloperskiego, podczas którego jego członkowie planują swoją pracę na kolejny dzień, po to żeby zmaksymalizować szanse osiągnięcia Celu Sprintu. W tym jednym zdaniu zawiera się cała istota tego kluczowego Scrumowego wydarzenia, ale jak to zwykle bywa diabeł tkwi w szczegółach. W tym wpisie omówię absolutne podstawy Daily Scruma, opowiem, jak przeprowadzać go w prawidłowy sposób, a także podam kilka negatywnych scenariuszy wraz z informacją, jak można sobie z nimi poradzić.

Na początku warto zwrócić uwagę, że spotkanie nazywa się Scrum (tak jak framework), a ponieważ odbywa się codziennie, to Daily Scrum. Nazwa została pożyczona z Rugby, gdzie jest to element wykorzystywany do restartu gry. Potocznie używana jako zamiennik nazwa stand-up też nie jest prawidłowa, bo nie ma takiego wymagania, żeby spotkanie odbywało się na stojąco. Każde spotkanie może odbywać się na stojąco, bo taka praktyka powoduje większe zaangażowanie uczestników i skraca potrzebny do osiągnięcia rezultatu czas.

“…tak jak w Rugby, piłka jest podawana w zespole w miarę jak porusza się on po boisku jako jednostka.”

- Takeuchi-Nonaka – The New New Product Development Game (1986)

Scrum Guide wskazuje, że Daily Scrum jest kluczowym spotkaniem w procesie inspekcji i adaptacji. Stanowi fundament empiryzmu, na którym oparty jest Scrum. Daily Scrum jest codzienną pętlą Inspect & Adapt. Pozwala optymalizować to, jak członkowie Zespołu Deweloperskiego ze sobą współpracują dzień po dniu.

Prawidłowo przeprowadzone Daily pozwala Zespołowi reagować na wszelkiej maści trudności i problemy, które pojawiają się w Sprincie, wprowadzając niezbędne zmiany, tak żeby utrzymywać kurs na Cel Sprintu. To właśnie Cel Sprintu jest kompasem Zespołu na Daily Scrum i wyznacza kierunek działania. To przez jego pryzmat dokonujemy inspekcji postępów prac oraz dostosowujemy plan na pozostałą część Sprintu. Bez dobrego Celu Sprintu Daily Scrum traci swój sens. Pod co Zespół może się zoptymalizować jeśli, nie ma celu?

Zmiany planu powinny być uwidocznione w Backlogu Sprintu, który powinien być zawsze aktualny. Jeśli Zespół korzysta z praktyki wykresu Burndown, to spogląda na jego aktualny stan i patrzy, czy linia dotknie punktu zero na koniec Sprintu.

Wychodząc z Daily Scruma Zespół Deweloperski powinien mieć jasny obraz tego, gdzie jest w Sprincie, ile mu brakuje do osiągnięcia jego celu oraz, jakimi potencjalnymi ryzykami i zmaterializowanymi problemami powinien się zająć w najbliższej dobie. Jeśli jest to potrzebne, Zespół albo jego część powinien od razu przedyskutować możliwości i zdecydować, jakie akcje trzeba podjąć. Jeśli jako Scrum Master obserwujesz Zespół, który takich wniosków na Daily Scrum nie wypracowuje, jako strażnik framework będziesz musiał interweniować, żeby pomóc Zespołowi wrócić na dobry tor.

Poczucie jakie Zespół Developerski powinien mieć po Daily Scrum bardzo dobrze pokazuje ten krótki film.
Warto zwrócić uwagę na synchronizację całego zespołu i skupienie na grze.

Jak prawidłowo przeprowadzić Daily Scrum?

Zacznijmy od podstaw — Daily Scrum odbywa się zawsze o tej samej porze i w tym samym miejscu, po to, żeby nie komplikować zbędnie procesu. Dzięki temu unikamy komplikacji już na samym starcie — wszyscy członkowie Zespołu Deweloperskiego wiedzą, gdzie i o której mają się stawić.

Po drugie — Daily Scrum to spotkanie dla Zespołu Deweloperskiego i tylko jego członkowie biorą w nim udział. Osoby spoza zespołu mogą się na nim pojawić (w myśl zasady mówiącej o pełnej przejrzystości tego, gdzie jesteśmy w Sprincie), ale Scrum Master upewnia się, że osoby te nie włączają się do dyskusji bez potrzeby. Z resztą sam Scrum Master nie musi pojawiać się na Scrumie, ale o tym za chwilę.

Po trzecie ma wyznaczony maksymalny timebox- 15 minut. Co oznacza, że powinno trwać nie dłużej niż ten wyznaczony czas, natomiast może skończyć się wcześniej, pod warunkiem, że został osiągnięty cel spotkania.

Za poprawne przeprowadzenie Daily Scrum, zgodnie z tym, jak wydarzenie to zostało zdefiniowane w Scrum Guide odpowiada Zespół Deweloperski. Nikt inny nie wykonuje tego zadania za Zespół, bo może to prowadzić do zjawiska raportowania lub spowiedzi. Na przykład może się przerodzić w status przed Scrum Masterem lub Product Ownerem, jeśli osoby te nieopatrznie włączą się w dyskusję w trakcie Codziennego Scruma. Scrum Guide idzie o krok dalej i wspomina, że dopóki Daily Scrum skupia się na Celu Sprintu sposób jego przeprowadzenia oraz struktura mogą się różnić w zależności od potrzeb Zespołu Deweloperskiego. A zatem nie zmuszajmy Zespołów Deweloperskich do odpowiadania na trzy pytania czy stania przez 15 minut w imię nieistniejącej zasady. Scrum Guide nie wymaga też rzucania w siebie maskotkami w celu wskazania następnej osoby do podzielenia się informacjami.

Rolą Scrum Mastera jest upewnić się, że spotkanie się odbywa, że nie trwa dłużej niż 15 minut i że uczestnicy rozumieją jego cel. Jeśli Scrum Master widzi, że Scrum nie daje oczekiwanego rezultatu, dzieli się tym z Zespołem Deweloperskim, ale robi to raczej po Daily Scrumie, chyba, że mamy do czynienia z bardzo mocną dewiacją w stosunku do frameworka i interwencja wymagana jest od razu.

Czwartym kluczowym aspektem Daily Scruma są tzw. inputs i outputs, czyli to, co stanowi materiał wejściowy i wyjściowy ze spotkania. To na podstawie tego materiału Scrum Master jest w stanie ocenić, czy Scrum przynosi zespołowi korzyści.

Wchodząc na Daily Scrum Zespół Deweloperski powinien mieć pod ręką Sprint Backlog, ponieważ to tam znajduje się w pełni przejrzysta i czytelna dla wszystkich zainteresowanych osób informacja o tym, jak nam idą prace w Sprincie. Sprint Backlog to nie tylko lista Product Backlog Items, które Zespół Deweloperski chce dostarczyć w Sprincie, ale również plan ich dostarczenia. Scrum Guide nie definiuje formy, w jakiej Sprint Backlog ma być utrzymywany, ale jasno wskazuje, że musi to być forma umożliwiająca monitorowania zmian w postępach prac z dnia na dzień. Sam Sprint Backlog to materiał na osobny wpis, ale musimy pamiętać, że należy pilnować jego pełnej przejrzystości i aktualności.

W trakcie Daily Scruma, po przeanalizowaniu dotychczas wykonanych prac, Zespół modyfikuje plan na najbliższy dzień, po to, żeby zmaksymalizować swoje szanse na dostarczenie ukończonego Przyrostu i osiągnięcie celu Sprintu. A zatem kluczowym materiałem wyjściowym z tego spotkania jest ten sam, zaktualizowany, Sprint Backlog.

Jeden z cytatów Dwighta Eisenhowera, 34 Prezydenta Stanów Zjednoczonych oraz generała amerykańskiej armii, który dobrze oddaje istotę Daily Scruma to:

„In preparing for battle, I have always found that plans are useless but planning is indispensable.”

Cytat ten bardzo mocno podkreśla znaczenie procesu przeplanowywania prac, na bazie zbieranych na bieżąco doświadczeń i informacji. Dzięki Codziennemu Scrumowi minimalna częstotliwość tego zabiegu wynosi raz na dzień, co pozwala Zespołowi Deweloperskiemu optymalizować szanse na osiągnięcie Celu Sprintu.

Dlaczego tak istotne jest codzienne sprawdzanie planu? Ponieważ pracujemy nad złożonym produktem albo rozwiązujemy złożony problem. To implikuje, że wiele rzeczy nie jesteśmy w stanie przewidzieć i w ramach wykonywania pracy odkryjemy nowe aspekty tej pracy. W ten sposób Zespół aktualizuje prognozę stworzoną na Planowaniu Sprintu, czyniąc ją coraz bardziej prawdopodobną.

Kluczowym materiałem wyjściowym z Daily Scruma jest również lista Impediments, czyli przeszkód, które uniemożliwiają Zespołowi Deweloperskiemu dostarczenie Przyrostu i z którymi Zespół Deweloperski nie jest w stanie poradzić sobie sam. Te trudności powinny zostać zakomunikowane Scrum Masterowi.

Przykład dobrego Daily Scruma

Jako przykład dobrze przeprowadzonego Daily Scruma pokażę na przykładzie jednego z zespołów z branży mediowej, z którymi pracowałem kilka lat temu. Był to na tyle udany Scrum, że zapadł mi w pamięci i do tej pory posługuję się nim jako punktem referencyjnym.

Daily Scrum zaczyna się punktualnie o 9 rano. Wszyscy członkowie Zespołu Deweloperskiego są na miejscu. Na spotkaniu nie ma nikogo spoza tego zespołu.

Deweloperzy zbierają się przy tablicy ze Sprint Backlogiem przyklejonej na ścianie i jeden z nich rozpoczyna Daily przypominając wszystkim zebranym Cel Sprintu, który próbują osiągnąć jako zespół.

Dyskusja o postępach prac zaczyna się od konkretnego Story znajdującego się na samej górze tablicy. Zespół przyjął sobie umownie, że w ten sposób porządkuje tematy wciągnięte na Sprint od najistotniejszego do najmniej ważnego. Deweloperzy, jeden po drugim, dzielą się informacjami o tym, co udało im się w ramach tej historyjki wypracować w ciągu ostatniej doby oraz jak to wpływa na Cel Sprintu. Kolejne osoby włączają się do dyskusji wtedy, kiedy widzą, że ma to sens. Nie ma żadnej wymuszonej praktyki wskazywania się palcem.  Zespół omawia historyjkę po historyjce. W trakcie tej wymiany zdań aktualizowane są statusy zadań na tablicy, Deweloperzy wymieniają się informacjami o potencjalnych problemach i zależnościach oraz identyfikują nowe zadania do wykonania.

Po tej pierwszej rundzie następuje runda druga, podczas której Zespół Deweloperski wspólnie zastanawia się, za co zabierze się w ciągu bieżącego dnia, tak żeby wykonać kolejny krok w stronę osiągnięcia Celu Sprintu. Na tym etapie ponownie aktualizowany jest Sprint Backlog, tak żeby było na nim widać aktualny stan prac wraz z informacją o planie na bieżący dzień.

Na koniec Daily Scrum kilka osób umawia się na krótką sesję w podgrupach, żeby zbadać jeden z tematów nieco dokładniej, zanim zabiorą się za jego kodowanie. Reszta Zespołu rusza do pracy nad świeżo zdefiniowanymi zadaniami.

Zespół wychodzi ze spotkania po niecałych 15 minutach, pozytywnie nastawiony do nadchodzącego dnia pracy. Dwóch Deweloperów od razu kieruje się do Scrum Mastera z przeszkodą, którą zespół zidentyfikował podczas Daily Scrum, żeby ten wsparł ich w jej wyeliminowaniu.

Dobre wzorce, które możesz zaczerpnąć z tego przykładu:

1. Mówienie o ukończonych elementach i wyeliminowanych przeszkodach, a następnie zaplanowanie pracy.
2. Ustalenie planu,biorąc pod uwagę punkt pierwszy.
3. Zebranie przeszkód, których Zespół sam nie może usunąć i przekazanie ich Scrum Masterowi.
4. Dobry Daily Scrum powinien wzbudzić entuzjazm do kolejnego dnia pracy.

Negatywne przykłady Daily Scruma — Antywzorce

Niestety zdecydowanie częściej niż z pozytywnymi przykładami Daily Scruma spotykam się z wypaczeniem tego wydarzenia. Poniżej opiszę kilka typowych scenariuszy i wskażę potencjalne powody, nad których analizą warto się pochylić w celu wyeliminowania danej dysfunkcji.

1. Daily Scrum jako okazja do zebrania statusu od Deweloperów

Jedna z najczęstszych błędnych interpretacji Daily Scrum wskazuje na fundamentalny problem braku zrozumienia Scruma i koncepcji samoorganizacji Zespołu Deweloperskiego. Interpretacja ta mówi o tym, że Daily Scrum to szansa na zebranie statusu prac od członków Zespołu Deweloperskiego przez Scrum Mastera, Product Ownera, architekta, Project Managera, czy dowolną inną postać spoza tego zespołu. Czasem dochodzi do tego też przypisywanie zadań do Deweloperów w trakcie wydarzenia.

Żeby rozbroić ten antywzorzec należy odpowiedzieć sobie na pytanie, czym jest spotkanie statusowe. Stephanie Ockermann zauważa, że nie ma jednej definicji, której można by się złapać, ale co do zasady celem takiego spotkania jest zebranie przez osobę odpowiedzialną za plan projektu bieżącego statusu prac od osób je wykonujących. Samo to zdanie wskazuje, że wyszliśmy poza framework Scrumowy, ponieważ w Scrumie za plan prac w Sprincie odpowiada Zespół Deweloperski i to jego członkowie muszą ze sobą rozmawiać, żeby ten plan aktualizować. W Scrumie, w trakcie Sprintu, to Zespół Deweloperski odpowiada za monitorowanie postępów prac. Nie ma więc potrzeby, żeby w tym celu na Daily pojawił się ktokolwiek inny. Sprint Backlog jest dostępny dla każdego, więc status prac można sprawdzić sobie we własnym zakresie w dowolnym momencie.

Jeśli mamy do czynienia ze zjawiskiem raportowania przez członków Zespołu Deweloperskiego podczas Daily statusu prac do kogoś spoza tego zespołu, trzeba zastanowić się, z czego wynika ta sytuacja. Rolą Scrum Mastera jest w takim wypadku wskazanie tej dewiacji Zespołowi Scrumowemu, podzielenie się informacją o negatywnych skutkach takiego zachowania oraz wsparciu Zespołu w procesie „wychodzenia” z tego antywzorca. Może to oznaczać konieczność edukacji osób, które o ten status zabiegają, tak żeby one również zrozumiały, jak mocno taka działalność uderza w samoorganizację Zespołu Deweloperskiego. 

2. Daily Scrum jako element tzw. Zombie Scruma

Ten problem występuje równie często jak problem „spowiedzi” i odznacza się tym, że członkowie Zespołu Deweloperskiego pojawiają się na Daily, jeden po drugim informują, co się u nich dzieje, ale bez odniesienia się do Celu Sprintu i opuszczają spotkanie bez żadnego konkretnego planu na następny dzień. W rezultacie Daily Scrum nie spełnia swojej kluczowej roli — nie wspiera zespołu w dążeniu do osiągnięcia Celu Sprintu. Jest martwym spotkaniem, które co prawda odbywa się o stałej porze i w stałym miejscu, nie trwa dłużej niż 15 minut, ale też nie przynosi ze sobą żadnych korzyści.

Upraszczając — często Daily Scrum wygląda tak, że w ramach rundy każdy Deweloper mówi “wczoraj grabiłem liście, dzisiaj będę grabił liście i nie widzę problemów” i Zespół się rozchodzi.

Nie da się jednoznacznie wskazać powodu dla takiego przebiegu Daily Scruma. Może ich być bardzo wiele, ale jako punkt startowy warto przypomnieć Zespołowi Deweloperskiemu o meritum Daily Scrum — inspekcji postępów prac i adaptacji planu, który umożliwi im dostarczenie ukończonego Przyrostu i realizację Celu Sprintu. W trakcie takiej dyskusji często okazuje się, że Cel Sprintu jest niejasny (warto pochylić się nad procesem jego formułowania w trakcie Planowania Sprintu), albo, co gorsza, nieznany Zespołowi Deweloperskiemu. Może też być tak, że Zespół tak naprawdę pracuje nad różnymi, niezależnymi od siebie elementami, a nie jednym Produktem. Wtedy członków zespołu nie interesuje co robią inni.

Jeśli problemem nie jest Cel Sprintu, można spróbować coachować zespół pytaniami na zakończenie Daily Scrum:

• Czy udało Wam się wypracować plan działania na kolejną dobę?
• Czy jest dla Was jasne, kto i nad czym będzie pracował, żeby zbliżyć Was jako Zespół Deweloperski do osiągnięcia Celu Sprintu?
• Co zamierzacie zrobić ze zidentyfikowanymi problemami?
• Jakie działania podejmujecie w kontekście zidentyfikowanych ryzyk?

3. Brak śledzenia postępu prac

Tak jak pisałem to Zespół Deweloperski decyduje o tym jaką formę i strukturę ma Daily Scrum, ponieważ jest to spotkanie dla Deweloperów i przez nich przeprowadzane. Powyższe jest często interpretowane przez Deweloperów jako „róbta co chceta”. W rezultacie podczas Codziennego Scruma zespół często dyskutuje w oderwaniu od rzeczywistości. Nie ma analogowej tablicy ze Sprint Backlogiem, nikt nie zabiera ze sobą komputera i rzutnika, żeby wyświetlić wersję cyfrową. Zamiast inspekcji i adaptacji Backlogu Sprintu mamy po prostu 15 minutową pogadankę, często z dygresjami w kierunkach zupełnie nie związanych z Celem Sprintu.

Jeśli macie do czynienia z takim zjawiskiem, Waszym obowiązkiem jako Scrum Masterów jest uzmysłowić Zespołowi Deweloperskiemu, że monitorowanie postępów prac w Sprincie to ich obowiązek. Co więcej, na poziomie opisu Sprint Backlogu, Scrum Guide jasno wskazuje, że Zespół Deweloperski musi zapewnić przejrzysty obraz tego, gdzie jest w ramach prac w Sprincie oraz, ile jeszcze zostało mu pracy w kontekście celu, który chce osiągnąć. Dobrą praktyką jest przeprowadzać to spotkanie przy tablicy lub z rzutnikiem, na którym jest wyświetlony Sprint Backlog.

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. […] Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

Adresując ten problem, warto zadać kilka pytań, które pokierują Zespół Deweloperski na właściwe tory:

• Gdzie jesteście w ramach swojego planu na ten Sprint?
• Ile pracy Wam zostało do osiągnięcia Celu Sprintu?
• Czy Cel Sprintu jest zagrożony? Jeśli tak, to od kiedy o tym wiecie i jakie kroki wykonaliście w porozumieniu z Product Ownerem, żeby dostosować plan prac?
• Czy powyższe ustalenia są widoczne w Backlogu Sprintu?

Podsumowanie

Daily Scrum to kluczowy element Scruma. Prawidłowo przeprowadzone pozwala każdego dnia weryfikować to, jak bardzo Zespół Deweloperski zbliża się lub oddala od Celu Sprintu i odpowiednio wcześnie zareagować. Stanowi fundament poprawnej implementacji frameworka. Daily Scrum to spotkanie dla Zespołu Deweloperskiego przeprowadzane przez ten zespół. Takie podejście wzmacnia samoorganizację i poczucie odpowiedzialności za dostarczenie ukończonego Przyrostu Produktu wśród Deweloperów. Jeśli Zespół nie wykorzystuje Daily zgodnie z jego przeznaczeniem lub, co gorsza, zupełnie z niego rezygnuje, sabotuje własne szanse na sukces w Sprincie.

Źródła

1. Scrum Guide
2. Daily Scrum is NOT a status meeting