Codzienny Scrum – zorientowany na zadania, czy ludzi?

W Teorii

W teorii, Codzienny Scrum (ang. Daily Scrum) jest spotkaniem przeznaczonym dla Zespołu Deweloperskiego, mającym wyznaczone stałe miejsce, godzinę rozpoczęcia oraz czas trwania. Podczas Codziennego Scruma zespół dokonuje inspekcji prac, które zostały wykonane od ostatniego spotkania, bieżące działania podejmowane przez członków zespołu są ze sobą synchronizowane, następuje prognozowanie prac, które mogą zostać wykonane przed kolejnym spotkaniem, co w konsekwencji prowadzi do powstania planu działań na najbliższe dwadzieścia cztery godziny.

Podczas tego spotkania każdy członek Zespołu Deweloperskiego udziela informacji:

• 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?

W Praktyce

Obserwując codzienną pracę zespołów, wyłonił się niespodziewanie odrobinę inny model a w zasadzie dwa modele przeprowadzania przez różne Zespoły Scrumowe swoich Codziennych Scrumów. Osobiście nazwałbym model pierwszy: zorientowanym na ludzi, a drugi: modelem zorientowanym na zadania. Poniżej postaram się przybliżyć jak w praktyce wyglądają takie spotkania, jakie potencjalne korzyści lub zagrożenia za sobą niosą.

Codzienny Scrum – zorientowany na ludzi

W zespołach preferujący ten model spotkań, każdy z członków Zespołu Developerskiego kolejno odpowiada na trzy wskazywane przez Scrum Guide pytania: co zrobiłem wczoraj, co planuję zrobić dzisiaj, czy mam jakieś przeszkody w realizacji zadań?

Zaobserwowaliśmy, iż samo udzielenie odpowiedzi na trzy powyższe pytania przez każdego z członków Zespołu Developerskiego, nieważne, czy bardzo ogólnej, czy szczegółowej, niekoniecznie prowadzi do pożądanej synchronizacji informacji wewnątrz Zespołu oraz przygotowania planu pracy na najbliższe 24h. Jeżeli padną wyłącznie suche odpowiedzi, bez zastanowienia się, jak informacje te wpływają na trwający Sprint, czy faktycznie przybliżają do osiągnięcia wyznaczonego Celu Sprintu, Scrum Codzienny stanie się wyłącznie spotkaniem statusowym. Często taka formuła spotkania odciąga uwagę od zadań i celu, skupiając uwagę uczestników na poszczególnych członkach Zespołu Deweloperskiego, wywiera presję w stylu: „nie ważne co, byle mówić” , a nie to jest celem tego spotkania.

Codzienny Scrum – zorientowany na zadania

Spotkania Zespołów preferujących ten model współpracy przebiegają w sposób odmienny od opisanego powyżej przykładu. Technika ta koncentruje uwagę bardzo mocno na zadaniach realizowanych w sprincie, a nie poszczególnych członkach wchodzących w skład Zespołu Developerskiego. Polega ona na omawianiu każdego zadania po kolei, przez co każdy, kto brał czynny udział w realizacji konkretnego zadania, przekazuje informacje synchronizacyjne wyłącznie w kontekście omawianego tematu. Kiedy konkretne zadanie jest już omówione i wiemy, co będzie się z nim działo w ciągu najbliższych 24h, przechodzimy do omawiana kolejnego zadania. Czynność ta jest powtarzana do momentu, w którym wszystkie zadania wymagane do osiągnięcia wyznaczonego Celu Sprintu zostaną omówione. Takie podejście daje dużo większe prawdopodobieństwo wyłapania ewentualnych problemów i podjęcia odpowiednio szybko kroków mających na celu zniwelowanie zagrożeń, mających wpływ na realizację Celu Sprintu.

A jak wygląda Codzienny Scrum w Twoim Zespole? Jakich technik używacie, aby spotkania te spełniały swoje najważniejsze zadanie, czyli pomagały Zespołowi Developerskiemu przybliżyć się do osiągnięcia Celu Sprintu?