Blog

Od jakiegoś czasu krąży w sieci obrazek Zespołu Scrum odbywającego Daily Scrum w następujący sposób: Developerzy podparci na łokciach i czubkach palców u stóp leżą w kółeczku i rozmawiają. Podpisy pod tym obrazkiem mniej lub bardziej dowcipnie sugerują, że każdy sposób jest dobry, by spowodować, aby Daily nie trwało dłużej, niż kwadrans. Nie wiem, w jakim stopniu uwieczniona na fotografii sytuacja wynikała z chęci zażartowania, a w jakim stopniu zaangażowani w nią działali serio. Mam ochotę wierzyć, że to dowcip, lecz niestety na portalach, także tych dla profesjonalistów, pojawiać zaczęły się opinie od poważnych osób, że to świetny pomysł. Początkowe lekkie rozbawienie zastąpiła u mnie konsternacja.

Bo tak na logikę, jeśli zasadniczym celem Developerów miałoby być skończenie Daily po 15 minutach, co powstrzymuje ich od tego, by po prostu… skończyć po kwadransie, niezależnie od efektów, choćby urywając komuś w pół zdania? Skoro to czas trwania zdarzenia miałby być sprawą najistotniejszą, prostszego rozwiązania nie da się zaproponować. Nie trzeba leżeć na podłodze i robić z siebie błazna.

Po co komu ten Daily Scrum?

Jeśli nawet Developerzy pracują w tej samej lokalizacji, siedząc obok siebie, nie są w stanie na bieżąco w sposób ciągły dostosowywać planów działania w Sprincie bez znaczącego ograniczenia własnej produktywności. A brak synchronizacji między Developerami może być katastrofalny w skutkach. Dlatego w dowolnym momencie (nie tylko w czasie Daily) dyskutują oni o problemach i podejmują wspólnie decyzje, zmieniają plany etc. Aby upewnić się, że żadnemu Developerowi nic nie umknęło – a o to łatwo, jeśli tempo pracy jest duże – konieczne jest zebranie się raz dziennie po to, by:

• podsumować, co udało się zrobić w Sprincie do tej pory (czyli dokonać inspekcji stanu bieżącego),
• oraz zaplanować działania na kolejne 24 godziny tak, by zmaksymalizować prawdopodobieństwo osiągnięcia Celu Sprintu (czyli dokonać adaptacji planu działania).

Nie chodzi więc tylko o wymianę wiedzy (bo ta może być synchronizowana w miarę na bieżąco), ale o ujednolicenie wniosków, jakie z tej wiedzy wynikają. Bo zdarzyć się może, że są one skrajnie rozbieżne i kierując się nimi, bez uzgodnienia czegokolwiek wspólnie, Zespół popadnie w chaos.

Gdy spotkanie odbywa się zawsze o tej samej porze i w tym samym miejscu, zaczyna wyznaczać pewien rytm i wprowadza ład (stabilizację), pomagając radzić sobie ze złożonością otoczenia i problemów, jakie Zespół próbuje rozwiązać.

Daily Scrum, jak każde zdarzenie w Scrumie, ma ograniczony czas trwania – powinno trwać nie dłużej, niż wspomniany wcześniej kwadrans. Chodzi tu nie o zminimalizowanie ilości czasu spędzonego na spotkaniach, ale o wsparcie dla jednej z wartości Scrum, jakim jest skupienie (ang. focus). Pozwalając spotkaniu rozlać się na dowolną długość, Developerzy mogliby stracić z oczu cel spotkania. Zamieniłoby się ono wtedy pewnie w dyskusję technologiczną lub warsztat architektoniczny. Te również są potrzebne, ale nie mogą odbywać się zamiast zdarzeń, których celem jest zapewnienie empirycznej kontroli nad procesem.

Zmieścić się w kwadransie

Jeśli Developerzy mają stałe problemy z upchnięciem Daily Scruma w piętnastu minutach, generowanie dodatkowych fizycznych bodźców, by się streszczać, niewiele pomoże, a w niejednej sytuacji spowoduje dodatkowe problemy (poza nieuniknionym bólem łokci). Jeśli spotkanie odbywa się na stojąco (stąd jego potoczna nazwa: stand-up), w większości przypadków faktycznie sprzyja to zwięzłości wypowiedzi, ale dodatkowego biczowania się nie warto stosować. Zamiast tego na Retrospekcji Sprintu (albo od razu, kiedy problem stanie się widoczny) Developerzy muszą poszukać przyczyny przeciągania się Daily i spróbować ją wyeliminować.

I tak na przykład często okazuje się, zwłaszcza w przypadku niedoświadczonych Developerów, że po prostu nie mają pojęcia, jaki jest cel Daily Scruma i podchodzą do niego, jak do obowiązkowej „ceremonii” (czyli czegoś, co jest im zbędne, a odbywa się jedynie ze względu na niepojęte wymogi formalne). Tacy Developerzy mają tendencję do rozgadywania się na temat pierwszego zgłoszonego problemu, a czas leci…

Inny problem to pojawianie się na Daily Scrumie osób, które z racji swej pozycji (kierownika, architekta itd.) odbierani są przez Developerów jako przełożeni, przez co spotkanie zamienia się w raportowanie statusu tymże przełożonym. Wariantem tego przypadku jest sytuacja, gdzie kierownicy, a czasami Product Owner, przepytują Developerów wymaganie po wymaganiu albo osoba po osobie, próbując ustalić, co zostało zrobione; tłumaczenie się bywa czasochłonne, a cel Daily zostaje zapomniany.

Kolejnym scenariuszem rujnującym Daily Scrum jest tendencja do wchodzenia w szczegóły techniczne i próba rozwiązywania problemów w trakcie spotkania.

Bywa, że przyczyną jest prozaiczna niepunktualność: niby zaczynamy o wyznaczonej godzinie, ale ludzie schodzą się przez cały kwadrans, więc potem brakuje czasu, by zdążyli cokolwiek powiedzieć.

Jeszcze innym przypadkiem jest tendencja Developerów do rozpoczynania pracy równolegle na raz nad zbyt wieloma zagadnieniami (wymaganiami, zadaniami czy historyjkami użytkownika). Realizowanie ich jedno po drugim, wedle określonej przez Product Ownera kolejności, nie jest dla każdego oczywiste. W efekcie w wielu Zespołach smutnym standardem jest, że każdy Developer robi co innego i sporo musi się nagadać, by cokolwiek pozostałym wyjaśnić w czasie Daily. Oczywiście w tym przypadku ciężko spodziewać się, że w ciągu kwadransa pozostanie czas na jakąkolwiek adaptację planów i często zdarzenie zamienia się w ceremonię bez realnej wartości.

Efektywny Daily Scrum

Scrum Master powinien zadbać, by cały Zespół Scrum (nie tylko Developerzy) rozumiał cel spotkania – to warunek kluczowy. Należy też dążyć do tego, by ilość rzeczy będących w trakcie realizacji była rozsądnie mała, bo nie dość, że zwiększy to szanse na zrealizowanie zaakceptowanych do Sprintu wymagań, to jeszcze zminimalizuje ilość informacji, jakimi Developerzy będą wymieniali się w czasie Daily. Developerzy muszą oczywiście ustalić formułę spotkania i trzymać się jej (dokonując świadomych zmian, jeśli są niezbędne). Obserwatorów i gości należy uświadomić, że spotkanie służy wyłącznie Developerom (czasem zdarza się, że co bardziej krewkich i odpornych na naukę kierowników trzeba od Daily Scruma trzymać z daleka – to doskonałe zadanie dla Scrum Mastera).

A nade wszystko, jak z każdym zdarzeniem i praktyką w Scrum, Zespół musi regularnie poddawać ocenie to, jak skutecznie Daily wspiera planowanie i koordynowanie pracy w Sprincie i szukać usprawnień, bo te zawsze są możliwe. Istnieje bardzo małe, jeśli nie zerowe prawdopodobieństwo, że na jakimś etapie pomocnym okaże się prowadzenie Daily w formule opisanej na początku tego artykułu. Leżenie na podłodze może zaiste wyglądać efektownie, ale niekoniecznie w czymkolwiek pomaga.