Blog

Od jakiegoś czasu krąży w sieci obrazek Zespołu 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ą (rzeczone zdjęcie znaleźć możecie na przykład tutaj). 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, na ile uwieczniona na fotografii sytuacja wynikała z chęci zażartowania, a na ile zaangażowani w nią działali serio. Mam ochotę wierzyć, że to dowcip, niestety na portalach, także tych „dla profesjonalistów”, pojawiać zaczęły się całkiem serio 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 Zespołu miałoby być skończenie Daily po 15 minutach, co powstrzymuje go 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 przysłowiowego 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. Brak synchronizacji między Developerami również byłby katastrofalny w skutkach. Dlatego Zespół w dowolnym momencie, w granicach możliwości i zdrowego rozsądku dyskutuje o problemach i podejmuje decyzje, zmienia plany etc. Aby nic nie umknęło – a o to łatwo, jeśli tempo pracy jest duże – konieczne jest zbieranie się raz dziennie po to, by podsumować to, co udało się zrobić (dokonać inspekcji stanu bieżącego) i zaplanować działania na kolejne 24h tak, by zmaksymalizować prawdopodobieństwo zrealizowania Celu Sprintu (dokonać adaptacji planu działania). 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 tej metodzie, ma ograniczony czas trwania – do wspomnianego wcześniej kwadransa. 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ść, Zespół mógłby stracić z oczu cel spotkania jakim jest inspekcja stanu spraw i adaptacja planów, a tym samym synchronizacja działań Developerów. Zamiast tego spotkanie zamieniłoby się 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 Zespół ma 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…). To, że spotkanie odbywa się na stojąco (stąd jego potoczna nazwa: „stand-up”), w większości przypadków powinno być drobną niedogodnością promującą zwięzłość wypowiedzi i dodatkowego biczowania się nie warto stosować. Zamiast tego na Retrospektywie (albo od razu, jak 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 Zespołów, że po prostu nie mają pojęcia, jaki cel Daily Scruma jest i podchodzą do niego jak do obowiązkowej ceremonii. Taki Zespół ma 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 (managera, architekta) odbierani są przez Zespół jako przełożeni, przez co spotkanie zamienia się w raportowanie statusu tymże przełożonym. Wariantem tego przypadku jest sytuacja, gdzie managerowie, a czasami Właściciel Produktu, przepytują Zespół 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 nie po, ale 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 Zespołu do rozpoczynania na raz zbyt wielu zagadnień (wymagań, zadań, historyjek użytkownika). Realizowanie ich po kolei wedle określonych przez Właściciela Produktu priorytetów nie jest dla każdego oczywiste. Niestety, jeśli każdy Developer robi co innego, sporo musi się nagadać, by cokolwiek pozostałym wyjaśnić. Oczywiście w tym przypadku ciężko spodziewać się, że w czasie Daily nastąpi jakakolwiek adaptacja planów i często zamienia się ono w ceremonię bez realnej wartości.

Efektywny Daily Scrum

Scrum Master powinien zadbać, by Zespół rozumiał cel spotkania – to warunek kluczowy. Należy 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, jaką Zespół będzie wymieniał w czasie Daily. Zespół musi też ustalić formułę spotkania i trzymać się jej (dokonując oczywiście świadomych zmian, jeśli są niezbędne). Obserwatorów i gości należy uświadomić, że spotkanie służy wyłącznie Zespołowi (czasem zdarza się, że co bardziej krewkich i odpornych na naukę manageró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 wpisu. Leżenie na podłodze może zaiste wyglądać efektownie, niekoniecznie w czymkolwiek pomaga.