3 sposoby na naprawę Daily Scrum

Daily Scrum, zwany pieszczotliwie “standupem”, jest tym wydarzeniem, które najczęściej psuje się samo i bez niczyjej złej woli. Dziś #białko pokazuje trzy sposoby na naprawę Twojego daily.

 

Problemy z Wydarzeniami Scrum

Na wstępie warto dodać, że w temacie Wydarzeń Scrum problemów nie ma chyba tylko z Planowaniem Sprintu. Tam doskonale wiemy, co mamy zrobić. Nawet jeśli zapominamy, że ma ono dwie części, to zwykle cel jest osiągany sprawnie i przed upłynięciem timeboxu. Inaczej rzecz ma się z pozostałymi “stałymi elementami gry”.

Sprint Retrospective najczęściej jest pomijany jako “coś niepotrzebnego”, co oczywiście źle się kończy dla całego podejścia Inspect & Adapt. Zaś Sprint Review często zmieniane jest w “demo”, co też nie odpowiada intencjom autorów Scrum Guide’a. Ale to właśnie Daily psute jest nieświadomie.

Zwykle nie mamy problemów ze zrozumieniem Daily Scrum. W podlinkowanym tekście poruszyliśmy wszystkie niuanse dotyczące celu tego wydarzenia, obecności osób i sposobu dyskutowania o pracy. Ale pomimo znajomości tych wszystkich szczegółów, zespoły powoli i niezauważalnie zmieniają je w spotkanie raportujące postępy prac.

Przypomnijmy więc jeszcze raz: Daily Scrum służy do zaplanowania następnych 24 godzin, a nie do rozmawiania o przeszłości czy zdawania raportów!

 

Raportowanie do Kogoś Ważnego na Daily

Najczęstszym powodem dla którego nie planujemy i nie synchronizujemy bieżącej pracy jest obecność na Daily Kogoś Ważnego. Oczywiście “ważnego” w naszym mniemaniu, bo przecież nie ma żadnej hierarchii ról w Scrum. A sama tylko obecność PO czy SM-a może u niektórych powodować stres i skłonności do raportowania. Jeszcze gorzej, jak na spotkanie przychodzi ktoś z kierownictwa projektu. Z tym mamy nadzieję, że wszyscy Scrum Masterzy walczą dzielnie i zażarcie.

Drogi Product Ownerze, to spotkanie nie jest dla Ciebie. W dowolnym momencie trwania Sprintu możesz podejść do Development Teamu i zapytać o co tylko chcesz, w tym także o status prowadzonych prac. Ale te maksymalnie 15 minut jest tylko i wyłącznie dla Zespołu Deweloperskiego. Nie zabieraj im tego czasu.

Scrum Masterze, jeżeli widzisz, że ktokolwiek z zespołu mówi do Ciebie, usuń się z pola widzenia. Najczęstszą formą przeprowadzania Daily jest spotkanie na stojąco w miejscu, gdzie widzimy Scrum Board. Gwarantuję, że jeżeli nie będziesz razem z innymi stał w jednym kółku, ale na przykład usiądziesz gdzieś obok i nie będziesz utrzymywał kontaktu wzrokowego, to ludzie przestaną mówić do Ciebie.

A jeżeli zespół jest już dojrzały, to obecność SM-a na Daily w ogóle jest niewskazana. Wystarczy raz na jakiś czas odwiedzić takie spotkanie (stojąc z boku i nie przeszkadzając), żeby upewnić się, czy wszystko jest w porządku.

 

Mówienie o przeszłości, a planowanie

Drugim powodem zdawania raportów jest mówienie o przeszłości, czyli dniu wczorajszym. Oczywiście ten temat też powinien być poruszony, ale nacisk na Daily zawsze kładziemy na to “co będziemy dzisiaj robić”, a nie na to “co wydarzyło się wczoraj”.

Bo przecież jeżeli powiemy o tym, że dzisiaj będziemy dokańczać jakąś rzecz, to musimy zaznaczyć, że zaczęliśmy robić ją wczoraj. Jeśli wspomnimy o rozpoczęciu testów, to od razu wiemy że dana funkcjonalność jest w jakimś zakresie gotowa. Mówiąc o dniu dzisiejszym i o naszych planach będziemy przekazywać bardziej istotne informacje dla całego zespołu.

Kogo obchodzi co zrobiliśmy wczoraj, jeżeli nie ma to żadnego przełożenia na nasze dzisiejsze prace? Z tego samego powodu zwykle powstrzymujemy się od dokładnego opisywania spotkań, na których byliśmy lub będziemy. Zespołu to po prostu nie interesuje.

Jeśli chodzi o zmianę spotkania ze statusowego na planistyczne, to z naszego doświadczenia jeden prosty trick działa za każdym razem i w każdym zespole. Sugerujemy, żeby każda osoba na Daily zaczynała mówić od tego, co będzie robiła dzisiaj, a o dniu wczorajszym mówiła na koniec swojej wypowiedzi.

Ten trick jest skuteczny z kilku powodów. Po pierwsze, jak już się wygadamy o dniu dzisiejszym, to nie będzie nam się chciało gadać o wczoraj. A jeśli zaczniemy mówić o wczoraj, to będziemy zdawać raport, a na “planowanie i synchronizację” zabraknie nam weny. Po drugie, mówiąc o dniu dzisiejszym i tak przemycimy całkiem sporo informacji o tym, co już się zadziało. Po trzecie, z jakiegoś powodu zwykle w ten sposób skupiamy się na rzeczach bardziej istotnych.

Umówcie się więc w zespole, że na Daily każdy rozpoczyna swoją wypowiedź od omówienia tego, czym będzie zajmował się dzisiaj. Oczywiście ze szczególnym uwzględnieniem rzeczy, które interesują innych. W końcu chodzi o planowanie i synchronizację, a nie o wymianę kalendarzy!

 

Żarty, Śmiechy, Pogaduchy, Daily

Trzeci najpopularniejszy problem z Daily jest jednocześnie najmniej szkodliwy. Wiele zespołów wykorzystuje ten czas dla siebie, po to, żeby sobie pożartować i pogadać. Z jednej strony ma to świetne skutki dla samego Development Teamu. Sprawia to, że zespół jest bardziej zżyty i czuje się ze sobą lepiej. Gorzej, jeżeli cel spotkania nie jest osiągany albo przekraczamy w ten sposób timebox.

“Okej, każdy wie co kto robi”, to najgorsza rzecz, którą można usłyszeć na początku Daily. Otóż nie, nie wiemy. Co najwyżej nam się wydaje. Bez “zmuszenia” ludzi do opowiedzenia, czym będą się dzisiaj zajmowali nie będziemy w stanie osiągnąć celu spotkania.

Nie chcemy rezygnować ze świetnej atmosfery w zespole i na Daily. Ale skupmy się na tym, żeby zrobić co trzeba w czasie przewidzianym na te wydarzenie. Przypominam, że jest to “aż” 15 minut, więc gdy będziemy rozmawiać o najnowszym odcinku serialu czy wczorajszym meczu, to możemy po prostu nie zdążyć zsynchronizować naszych prac.

Umówmy się więc, że najpierw zrobimy co trzeba, a przez pozostały czas będziemy rysować kalambury, opowiadać dowcipy albo omawiać “pozapracowe” wydarzenia dnia wczorajszego. Sprawne zespoły są w stanie zamknąć Daily nawet i w kilka minut. I co prawda zgodnie z ideą timeboxu powinniśmy się rozejść, ale jeżeli czas spędzony na pogaduchach albo wspólnym piciu kawy działa zbawiennie na zespół, na pewno bym ich przed tym nie powstrzymywał.

Oczywiście pod warunkiem, że cel Daily jest osiągany.

 

Dziesiątki podobnych porad przekazujemy na naszych szkoleniach Scrum. A jeżeli jesteś SM-em i chcesz poszerzyć swój warsztat, zapraszamy na Narzędzia Scrum Mastera. Tam w praktyczny sposób zajmujemy się wszystkimi wydarzeniami (i nie tylko).

Tomasz Dzierżek

16 lat doświadczenia w IT, 8 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: