AgileAdept.pl
daily scrum timebox

Daily Scrum – fakty i mity

Daily Scrum, określany też często jako Daily Standup , to najkrótsze i teoretycznie najprostsze ze wszystkich pięciu, Wydarzenie Scrumowe. Jego maksymalny czas trwania to 15 minut. W ich trakcie zespół powinien zweryfikować czy przybliża się do realizacji Celu Sprintu i ewentualnie przeplanować swój Sprint Backlog.

Sprawa wydaje się banalnie prosta. Jednak z biegiem lat, wokół Daily Scruma narosło bardzo dużo mitów i błędnych interpretacji. Chyba nie muszę dodawać, że nie przyczyniają się one do poprawy skuteczności wspomnianego wydarzenia, a jedynie tworzą konfuzje. Te z kolei nierzadko zamieniają się w koszmar Scrum Masterów, czyli sytuację, w której zespół z czasem dochodzi do terminalnego sformułowania “u nas Scrum nie działa…” 😉

A zatem jakie są mity związane z Daily Standupem? Zacznijmy od kwestii fundamentalnych, czyli jak poprawnie nazywa się to wydarzenie w Scrumie.

Daily Scrum czy Daily Standup?

Mogłoby się wydawać, że samo nazewnictwo nie jest jakoś szczególnie istotne. Ważne, aby wszyscy rozumieli cel wydarzenia i przestrzegali zasad określonych przez dany framework. Aż chciałoby się rzec, parafrazując klasykę, jakie jest Daily, każdy widzi.

Otóż różnica jest znacząca. Konkretna nazwa i stojący za tym przebieg wydarzenia jest zależny od tego w jakim pracujemy frameworku. W Scrumie, codzienne spotkanie, odbywające się dla uproszczenia w tym samym miejscu i o tym samy czasie, służące inspekcji Celu Sprintu i adaptacji Spring Backlogu (czyli Scrumowego artefaktu) to Daily Scrum.

Z kolei Daily Standup to spotkanie będące częścią Programowania Ekstremalnego.
W jego trakcie Developerzy raportują co udało się osiągnąć wczoraj, co planują zrobić dzisiaj i czy występują jakieś problemy powodujące opóźnienia.

daily standup xp
Źródło: extremeprogramming.org


Odpowiedzi na te pytania mogą nieco przypominać Daily Scruma. W poprzedniej wersji Scrum Guide’a z roku 2017, występowały one jako pewna propozycja struktury Daily Scruma. Ostatecznie jednak (w wersji z 2020) z nich zrezygnowano, aby wydarzenie to skupiało się na czynności planowania i aktualizowania Backlogu Sprintu, a nie wspomnianym wyżej raportowaniu.

Scrum Guide 2016
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?

Scrum Guide 2017
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?

Scrum Guide 2020

Developerzy mogą zdecydować się na dowolną strukturę oraz techniki, o ile tylko Daily Scrum dotyczy postępów w realizacji Celu Sprintu, a efektem tego wydarzenia jest możliwy do wykonania plan na nadchodzący dzień pracy.

Podsumowując, pomimo tego, że oba wydarzenia są do siebie podobne, to posiadają też znaczące różnice w swoim przebiegu i regułach. A zatem jeżeli pracujesz w Scrumie, to poprawnym określeniem jest Daily Scrum.
Jeżeli natomiast twój zespół działa w oparciu o zasady Extreme Programming, to codziennie rano udasz się na Daily Standup. Swoją drogą pracowałem kiedyś w zespole, który na Daily Scrumy mówił Stan Dupy 😉

Czy Daily zawsze odbywa się na stojąco?

Prosta odpowiedź na to pytanie to nie, wcale nie musi! Scrum nie wymaga stania na Daily. Wyobraź sobie sytuację, w której w dobie pracy zdalnej, członkowie zespołu codziennie rano muszą obowiązkowo wstawać przed kamerkami swoich komputerów. Pomijając fakt, że wypadałoby wtedy zawsze zmienić spodnie od piżamy, to byłoby to dosyć absurdalne i dziwne. Czemu w zasadzie miała by służyć ta praktyka? Jaki jest w tym sens?

Ponownie zahaczymy w tym miejscu o Programowanie Ekstremalne, z którego Scrum czerpie pełnymi garściami. Jak już wiesz, podobne wydarzenie w tym frameworku to Daily Standup. A zatem sama nazwa sugeruje, że odbywa się ono na stojąco i tak też jest to opisane w zasadach XP.

Dlaczego? Głównym powodem jest unikanie przydługich dyskusji, które z pewnością dużo przyjemniej przeprowadza się w wygodnych fotelach, w sali konferencyjnej, z kubkiem kawy. Na stojąco nie mamy tego komfortu, wiec w naturalny sposób przyspieszamy dyskusję, rozmawiając tylko o kwestiach priorytetowych.

Założenie Daily, zarówno tego Scrumowego jak i Extreme Programmingowego jest proste. Spotykamy się często i na krótko, dzięki czemu eliminujemy dodatkowe, formalne spotkania, które rozpraszają i marnują czas Developerów.

Pamiętaj, jeżeli twój zespół uczestniczy w Daily Scrumach, to odbywanie go na stojaka nie jest obligatoryjne.

daily standup

Ile powinien trwać Daily Scrum?

Przewodnik po Scrumie określa maksymalny czas trwania tego wydarzenia na 15 minut. Jak powinno wyglądać w praktyce przestrzeganie tego time-boksu? Czy Daily Scrum jest przerywany po upływie tego czasu?

Widywałem w swojej karierze Scrum Masterów, którzy ortodoksyjnie wręcz pilnowali tej zasady, nie do końca rozumiejąc chyba cel samego wydarzenia. Często na taką postawę mówi się “Scrum Policjant”. Przykładowo jeden z nich potrafił wyłączyć światło w salce konferencyjnej, albo zerwać połączenie na Skypie po przekroczeniu przez zespół wyznaczonego czasu… Jak możesz się domyśleć, nie wpływało to zbyt pozytywnie na skuteczną inspekcję Celu Sprintu i adaptację Backlogu Sprintu. Na opinię odnośnie Scrum Mastera i zasadności korzystania z frameworku też nie.

Rolą Scrum Mastera nie jest, niczym wspomniany wcześniej policjant, karanie swojego zespołu, a nauczenie go przestrzegania pewnych reguł. Daily Scrum powinien być krótki, a 15 minut powinny w zupełności wystarczyć na niezbędne przeplanowanie i ewentualne przegrupowanie się zespołu.

Jeżeli natomiast początkowo zespół przekracza podręcznikowy kwadrans, to na prawdę nic strasznego się nie stanie. Kluczowa jest tutaj inspekcja i adaptacja, a nie odmierzanie czasu co do sekundy. Jeżeli Daily notorycznie przeciąga się do 20-30 minut to należałoby poruszyć wątek na Retrospekcji Sprintu i wypracować usprawnienia mające na celu ograniczenie tego czasu. Z pomocą oczywiście przyjdzie tutaj Scrum Master. Można poprosić go/ją o obserwację i podzielenie się wnioskami czy też wprost podpytać o konkretne praktyki i narzędzia facylitacji, które mogą pomóc.

A zatem, nie ulega wątpliwości, że Daily Scrum nie powinien przekraczać 15 minut i taki czas w zupełności wystarcza na osiągnięcie jego celów. Nie należy jednak zapominać, że początkowo może być to trudne i dopiero z czasem zespół nauczy się jak to robić.

daily scrum

Co robi Scrum Master na Daily Scrumie?

Najprościej rzecz ujmując, jego lub jej w ogóle nie musi tam być. Zadaniem Scrum Mastera jest jedynie zapewnienie, że wydarzenia Scrumowe się odbywają, są produktywne czyli realizują swój cel i mieszczą się w przewidzianym przez framework time-boksie. Szerzej o tym temacie pisałem już w osobnym artykule, zachęcam do lektury: “Scrum Master na Daily Scrum.

Kto uczestniczy w Daily Scrumie?

Zauważyłem, że niektóre Zespoły Scrumowe popadają ze skrajności w skrajność. Początkowo w Daily uczestniczą wszyscy, łącznie z menedżerami, Product Ownerem, Scrum Masterem i kto tam się jeszcze po drodze nawinie. Po czasie członkowie zespołu odkrywają w Scrum Guidzie (lub przekazuje im to Scrum Master), że przecież Daily Scrum to spotkanie, w którym mogą uczestniczyć tylko Developerzy! Wówczas zaczyna się krucjata w drugą stronę i obcinanie z zaproszenia wszystkich nie-Developerów.

Czy to oznacza, że w takim razie dostęp do tego wydarzenia dla osób niebędących Developerami jest całkowicie zakazany? Otóż nie, tego typu podejście byłoby przecież przejawem ograniczenia transparencji. Nierzadko zdarza się przecież, że tymczasowo w Daily uczestniczy jakiś ekspert spoza Zespołu Scrumowego, np. z działu prawnego czy bezpieczeństwa.

Często zespoły decydują się też na dopraszanie Product Ownerów, aby na bieżąco móc wyjaśniać wątpliwości co do implementacji danych Historyjek Użytkownika. Czy jest to zatem pogwałcenie zasad frameworku? Wszystko co nie jest w nim zabronione, jest dozwolone. W Przewodniku po Scrumie z 2017 mamy wspomniane wyraźnie, że jeżeli w tym wydarzeniu uczestniczy ktoś poza Developerami, to po prostu należałoby się upewnić, że nie przeszkadza 🙂

A zatem, jeżeli Developerzy nie mają nic przeciwko i dodatkowi uczestnicy nie zaburzają spotkania, to nic nie stoi na przeszkodzie, żeby pojawili się na Daily Scrumie.

daily scrum mem

Dodatkowe źródła

Jarek Łojko

komentarz

  • Jedna rzecz mnie boli w narzucaniu time-boxa dla Daily.
    O ile dla pozostałych Qydarzeń (ściślej mówiąc pozostałych nie będących Sprintem :P) Przewodnik opisuje, że dla krótszych Sprintów Wydarzenie będzie zwykle krótsze, tak dla Daily tego nie ma. 15 minut i już. I niby się wszystko zgadza, bo DAILY jest robione co JEDEN DZIEŃ, więc jest niezależne od długości Sprintu.
    Jednak obserwuję, że mogłoby być zależne od wielkości Zespołu. Siłą rzeczy jeśli więcej osób pracowało to więcej się zadziało w kierunku Celu Sprintu i plan na kolejny dzień będzie obszerniejszy. Szczególnie jeśli wyjściowo opieramy się na “trzech pytaniach”.
    W zasadzie efekt ten dotyczy też pozostałych Wydarzeń. Mam tylko wrażenie, że przy “dużych” timeboxach do nich stosowanych bardziej się rozmywa.
    Efekt jest potęgowany gdy Cel Sprintu czy Sprint Backlog składa się z kilku niezależnych torów działań, np. funkcjonalności. Bo nie da się ich zaplanować/przeglądnąć jako spójną całość. W tej sytuacji można jeszcze podregulować długość Sprintu, żeby Cele/Backlogi Sprintów były bardziej spoiste, ale przy Standupach… Dupa 😉
    I tu klamra kompozycyjna ze ścisłością nazewnictwa wydarzeń ;), bo długość Sprintu nie jest zależna od długości Sprintu (meh), a logika (nie Scrum Guide!) sugeruje, że powinna być zależna od m.in. wielkości zespołu (rzutującej na wydajność) w relacji do złożoności Celów.

    Uff… to takie żale wylałem. Co myślicie o tym fenomenie?

AgileAdept.pl