Dzisiaj będzie o Codziennym Scrumie albo, jak ktoś woli, Daily, Daily Scrumie czy Stand’upie. Przeanalizujemy zdanie po zdaniu, akapit po akapicie, jak to wydarzenie opisują ojcowie frameworka Scrum – Ken Schwaber i Jeff Sutherland – w swoim „Przewodniku po Scrumie”.
Poniżej, w formie cytatów, przytoczę Wam pełną treść rozdziału „Codzienny Scrum”. Pod poszczególnymi zdaniami lub akapitami wstawię swoje komentarze. Zapraszam do lektury!
Codzienny Scrum jest wydarzeniem dla Zespołu Deweloperskiego, ograniczonym czasowo do piętnastu minut.
Ken i Jeff wyraźnie piszą, że jest to wydarzenie dla zespołu deweloperskiego. Nie dla Product Ownera, nie dla Scrum Mastera, nie dla szefa, kierownika, prezesa, czy dyrektora. Czy to oznacza że osoby inne niż deweloperzy nie mogą brać w nim udziału? Nic z tych rzeczy – oczywiście, że mogą, ale pod jednym warunkiem: aktywnie uczestniczą tylko deweloperzy. Pozostali goście mogą być jedynie OBSERWATORAMI tego spektaklu i nie mogą przeszkadzać. Jeżeli organizacja chce zbudować odpowiedzialne i samoorganizujące się zespoły, to nie ma rady – trzeba zaufać deweloperom i pogodzić się z tym, że znają się na swoim rzemiośle.
Jeśli jesteś Product Ownerem i poczułeś się urażony, że Daily nie jest dla Ciebie i może nawet przez głowę przemknęła Ci myśl, żeby przestać na nie chodzić, to nie rób tego, proszę. Jesteś częścią Zespołu Scrumowego, skarbnicą wiedzy produktowej, z której być może deweloperzy będą chcieli skorzystać. Nikt nie zabroni Ci odpowiedzieć na pytania, które mogą się pojawić podczas wydarzenia. Ponadto, wsłuchując się w dyskusję, możesz być na bieżąco z tym, co się dzieje w sprincie, zawczasu wychwytywać ryzyka i zagrożenia.
Jeśli jesteś Scrum Masterem i, podobnie jak Product Owner, czujesz się z tym źle, że Daily nie dla Ciebie, to spokojna głowa, przyjdzie czas, abyś mógł pokazać, co potrafisz. Czytaj dalej.
Jeśli jesteś osobą spoza zespołu i do tej pory przychodziłeś na Daily, dyskutowałeś, rozdzielałeś pracę, odpytywałeś o „status”, to zapraszam na Podsumowanie Sprintu – tam będzie czas na takie dyskusje. Na tym wydarzeniu oddaj przestrzeń Zespołowi Deweloperskiemu.
W analizowanym zdaniu jest jeszcze jedna bardzo ważna informacja – „Codzienny Scrum nie może być dłuższy niż piętnaście minut”. Scrum Masterze – wyzwanie dla Ciebie. Obserwuj, jak Deweloperzy rozmawiają ze sobą i pomóż im wypracować taką formułę, aby zmieścili się w czasie, a spotkanie kończyło planem na kolejny dzień. Na Daily nie ma czasu na rozwiązywanie konkretnych problemów z dziedziny technologii, za to jest czas na zgłaszanie tego typu problemów, aby omówić je w odpowiednim gronie w późniejszym czasie.
Codzienny Scrum organizowany jest każdego dnia Sprintu.
Zdarza się, że zespół w dniu, kiedy ma podsumowanie Sprintu, nie chce spotykać się na Daily. Tłumaczą to zwykle, że szkoda czasu, że i tak będzie okazja do porozmawiania, itd.
Jeśli podsumowanie jest na początku dnia, w terminie Daily lub krótko po nim, to pełna zgoda. Prace powinny być już ukończone i nie ma co planować. Chociaż zawsze na takim Daily można szybko zaplanować, kto, co i jak prezentuje podczas Podsumowania Sprintu.
Co innego, jeśli do podsumowania jest jeszcze kilka godzin. Wówczas, wyprzedzając nieco Scrum Guide, podpowiem, że Codzienny Scrum jest po to, aby zaplanować pracę na kolejny dzień – w tym przypadku ostatni. To tak, jakby drużyna piłkarska miała doskonałą strategię na wyprowadzenie piłki od swojej bramki w pole karne przeciwnika, ale ostatni, decydujący strzał był dziełem przypadku i nie trafiał w bramkę. Ich celem nie jest rewelacyjny drybling, świetne podania w trakcie prowadzenia piłki po boisku, lecz piłka w siatce przeciwnika. W Zespole Scrumowym celem jest UKOŃCZENIE zaplanowanego przyrostu – osiągnięcie celu Sprintu. Ostatnie godziny pracy w Sprincie mają kolosalne znaczenie, czy zakończymy sukcesem czy porażką. Dlatego bardzo ważne jest, aby ten czas był rozsądnie i bez emocji zaplanowany przez Zespół Deweloperski. Wracając do sedna – warto robić Daily w dniu podsumowania sprintu.
W jego trakcie Zespół Deweloperski planuje pracę na najbliższe dwadzieścia cztery godziny. W ten sposób, poprzez inspekcję pracy wykonanej od poprzedniego Codziennego Scruma, zespół optymalizuje współpracę i efektywność oraz prognozuje nadchodzącą pracę w Sprincie.
W tym akapicie dochodzimy do sedna, do praprzyczyny Codziennego Scruma. Ma on na celu, aby CAŁY Zespół Deweloperski, na podstawie inspekcji prac z poprzedniego dnia, zidentyfikowanych nowych ryzyk i przeszkód, wspólnie ustalił i znał plan prac poszczególnych osób. Plan ten powinien przybliżać zespół do realizacji przyjętego celu sprintu.
Zabierzcie proszę z tego akapitu przesłanie, że Codzienny Scrum to nie jest status, gdzie każdy grzecznie melduje, co wczoraj zrobił i w zasadzie na tym kończy swą wypowiedź. To nie jest odprawa, na której jakiś WIELKI DYSPOZYTOR przydziela pracę innym osobom z zespołu.
Jeśli podczas Daily mówimy o tym, co zrobiliśmy poprzedniego dnia, to nie po to, aby „statusować”, ale po to, aby na podstawie tych informacji, tego gdzie jesteśmy, zaplanować pracę na kolejny dzień.
Scrum Masterze, ucz tego swój zespół oraz całą organizację.
W celu zredukowania złożoności Codzienny Scrum odbywa się codziennie w stałym miejscu i o stałej porze.
Nic dodać, nic ująć. Praktyczne rozwiązanie – nie musimy pamiętać salek, godzin, sprawdzać kalendarza. Za każdym razem spotykamy się w tym samym miejscu o tej samej porze. Nie ma wyjątków – to musi „wejść w krew”.
Zespół Deweloperski używa Codziennych Scrumów do oceny postępów prac nad realizacją Celu Sprintu i trendu względem ukończenia pracy opisanej w Backlogu Sprintu. Codzienny Scrum zwiększa szanse osiągnięcia przez Zespół Deweloperski Celu Sprintu.
Jak wcześniej pisałem, Zespół Deweloperski, planując kolejny dzień, bazuje na inspekcji prac wykonanych od dnia poprzedniego. To daje mu możliwość oceny postępu prac nad realizacją celu Sprintu. Znając trend, zespół może szybko dostrzegać ryzyko nieosiągnięcia celu Sprintu i równie szybko reagować, odpowiednio planując prace. Zdarza się, że w trakcie Sprintu zespół modyfikuje Backlog Sprintu, aby osiągnąć cel. Do wizualizacji postępów prac zespoły mogą używać narzędzia w postaci Wykresu Wypalania Sprintu (Wykresu Spalania), który pokazuje postęp prac i trend. Wkrótce szerzej opiszemy Wam to narzędzie w osobnym artykule.
Każdego dnia Sprintu samoorganizujący się Zespół Deweloperski powinien wiedzieć jak będzie przebiegała dalsza współpraca by możliwe było osiągnięcie Celu Sprintu i stworzenie przed końcem Sprintu oczekiwanego Przyrostu.
Praca zespołowa ponad wszystko. Kropka.
Przebieg spotkania jest ustalany przez Zespół Deweloperski. Może ono być przeprowadzane na wiele sposobów, jeśli tylko pozostaje poświęcone postępom prac w kierunku osiągnięcia Celu Sprintu. Niektóre Zespoły Deweloperskie wykorzystują pytania, inne prowadzą dyskusje.
Oto przykład pytań, które mogą być wykorzystywane podczas tego spotkania:
• 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?
Kolejny istotny akapit. Zapamiętać z niego warto, że te trzy słynne pytania to jedynie propozycja, a przebieg spotkania zależy od Zespołu Deweloperskiego! Zdarza się, że zespoły prowadzą Daily w sposób standardowy, gdzie po kolei głos zabierają wszystkie osoby z Zespołu Deweloperskiego i jeśli nawet wprost nie odpowiadają na zaproponowane w Scrum Guide trzy pytania, to swoimi wypowiedziami do nich nawiązują. Zdarza się też, że zespoły zmieniają formę i dyskusja przebiega nie „po ludziach”, a „po historyjkach” na tablicy scrumowej. Omawiamy wówczas po kolei wszystkie historyjki, nad którymi pracujemy lub planujemy rozpocząć pracę. Z reguły każdy zespół z pomocą Scrum Mastera wypracowuje swój przepis na Codziennego Scruma.
Cały Zespół Deweloperski lub poszczególni jego członkowie często spotykają się bezpośrednio po Codziennym Scrumie, aby szczegółowo przedyskutować wybrane zagadnienia, dostosować lub zredefiniować plan prac na pozostałą część Sprintu.
Jest to bardzo dobra praktyka. Podczas Codziennego Scruma nie ma czasu na rozwiązywanie problemów, za to jest czas na ich sygnalizowanie. Przykładowo, jeden z deweloperów oznajmia, że natknął się wczoraj na poważny problem w kodach aplikacji i nie jest w stanie go samodzielnie rozwiązać. Wówczas można ustalić, że bierzemy temat na „po Daily”. W ten sposób odkryty problem nie zdominuje całego spotkania, a zespół zdoła zaplanować pracę na kolejny dzień. Rozwiązanie zgłoszonego problemu będzie elementem tego planu.
Scrum Master zapewnia, że Zespół Deweloperski spotyka się w ramach Codziennego Scruma, jednak to Zespół Deweloperski jest odpowiedzialny za przeprowadzenie tego spotkania. Scrum Master uczy Zespół Deweloperski, jak utrzymać piętnastominutowe ograniczenie czasowe Codziennego Scruma.
Nic dodać, nic ująć. Scrum Masterze, możesz po każdym Daily podpowiadać zespołowi ciekawe praktyki, możesz poprosić ich o informację zwrotną, jak oceniają to spotkanie. Możesz uświadamiać zespół, że jeśli na 15-minutowym spotkaniu będą chcieli wchodzić w niskopoziomowe dyskusje, to się nie uda. Działaj!
Codzienny Scrum jest wewnętrznym spotkaniem Zespołu Deweloperskiego. Jeśli inne osoby są obecne, Scrum Master upewnia się, że nie zaburzają one jego przebiegu.
Scrum Masterze, znowu wyzwanie dla Ciebie. Jeśli ktoś wtrąca „swoje trzy grosze” do wypowiedzi Zespołu Deweloperskiego, przejmuje inicjatywę, zadaje pytania – zrób coś z tym. Uświadamiaj te osoby, że są to zachowania niepożądane i źle wpływają na samoorganizację i odpowiedzialność Zespołu Deweloperskiego, że utrudniają dobre zaplanowanie dnia. Staraj się reagować natychmiast, natomiast dyskusje i wyjaśnienia przekładaj na „po Daily”.
„Product Ownerze”, zapamiętaj proszę, że Twój jest Backlog Produktu, o którym rozmawiamy podczas planowania i podsumowania sprintu. Na Daily natomiast rozmawiamy o Backlogu Sprintu – a ten należy do Zespołu Deweloperskiego. Podobnie z odpowiedzialnością – deweloperzy odpowiadają za przekucie elementów Backloga Sprintu w przyrost. Nie odpytuj ich, jak idzie praca, nie rób „statusu” – to przeszkadza zaplanować dzień w 15 minut.
Codzienne Scrumy poprawiają komunikację, eliminują inne spotkania, identyfikują i usuwają przeszkody, sprzyjają szybkiemu podejmowaniu decyzji i podnoszą poziom wiedzy Zespołu Deweloperskiego. Jest to spotkanie kluczowe dla procesu inspekcji i adaptacji.
Amen.