Kiedy daily stand-up staje się kosztem, a nie wartością

9:30: „Co robiłeś wczoraj? Co robisz dzisiaj? Jakieś blokery?”

Proszę, zatrzymaj się na chwilę

Daily to w najlepszym przypadku spotkanie statusowe, a w najgorszym okazja dla menedżera do uskuteczniania mikrozarządzania.

Rozumiem, dlaczego dogmat 3 pytań stał się tak popularny i naprawdę nie zamierzam obrażać żadnego scrum mastera, który przestrzega tego utartego rytuału. Kiedy jednak ostatnio zastanawiałeś się nad jego sensem i wpływem na pracę Twoją i zespołu?

Zwróciłem uwagę na ogromną liczbę artykułów próbujących odpowiedzieć na pytania typu „jak sprawić, by codzienny stand-up był bardziej produktywny”, „bądź mniej do bani” itp. Jeśli potrzebujemy tysięcy artykułów, które powiedzą nam, jak prowadzić powtarzające się 15-30-minutowe spotkania, to mamy tu jakiś problem.

Codzienny scrum został pierwotnie wymyślony dla programistów. Gdy członkowie zespołu są zaangażowani, z założenia szybkie i zwięzłe spotkania przeciągają się. Najbardziej nieefektywne spotkania mają miejsce wtedy, gdy każdy po kolei informuje o swoim harmonogramie pracy. Czy naprawdę po to się spotykamy?

Jeszcze bardziej zabawne jest to, że coraz więcej działów wprowadza ten model "szybkiego" kick-offa. Jakby ceremonie deweloperskie nie były wystarczające, zespoły niezwiązane z developmentem zaczynają teraz nazywać siebie „FinOps”, „SalesOps” itp. Nawet konsultanci od zarządzania poczuli się chyba pominięci, bo coraz częściej słyszę określenie „programista PowerPointa”.

Stand-upy wiążą się z wieloma kosztami organizacyjnymi i finansowymi. Ludzie muszą zablokować sobie czas przez 5 dni w tygodniu, na 30 minut (tak, to już nie jest 15 minut jak kiedyś, change my mind). Wyobraźmy sobie 10-osobowy zespół zarabiający średnio ~65 dolarów na godzinę. To około 6500 dolarów miesięcznie. A nawet nie weszliśmy głębiej w pozostałe niezbędne spotkania, takie jak retro, dema, kanbany itd..

Daily to spotkanie statusowe. Kropka.

Bez względu na to, jak bardzo ktoś chciałby to zmienić, stand-up ma być spotkaniem statusowym a nie sprawozdawczym. Jak pytania „co robiłeś wczoraj? Co robisz dzisiaj? Jakieś blokery?” mogą być aktualizacją statusu? Serio?

Codzienny scrum „służy utrzymaniu koordynacji zespołu na właściwym torze” (według Moreira, 2010). Bądźmy szczerzy - jeśli zespół nie jest w stanie sam utrzymać się na właściwej ścieżce działania, oznacza to, że jego członkowie nie wypracowali sobie podstawowych zasad swojej pracy lub nie rozumieją projektu, a codzienny scrum służy kierownictwu do trzymania programistów na krótkiej smyczy.

Jak możemy działać inaczej?

Nie mam tutaj jednoznacznej odpowiedzi, ale mogę powiedzieć, że w absolutnie najlepsze projekty programistyczne, nad którymi pracowałem, zaangażowanych było bardzo niewielu programistów. Idealna wielkość zespołu to 3 osoby. Przy takim rozmiarze nie jest potrzebny formalny proces synchronizacji, a następujące elementy:

• Dostęp do analityków biznesowych i product ownera.
• Wspólna wizja i zrozumienie tego, co robicie i dokąd zmierzacie.
• Zestaw wspólnych zasad, tj. kiedy zwrócić się o pomoc, do jakiego poziomu jakości kodu należy dążyć i jak często każdy członek demonstruje postępy (najlepiej codzienne dema).
• Częsty pair-programming. 

Głównym celem jest zadbanie o to, by zespół był zgrany i zapewniał wartość swoim klientom. To wszystko! I nagle nie potrzeba do sukcesu kilku wydarzeń koordynujących.

Rozumiem, że nie możemy zlikwidować daily (przynajmniej całkowicie)

Wyeliminowanie codziennego stand-upu jest bardzo często niewykonalne, ale możemy go znacznie usprawnić, koncentrując się na właściwych aspektach. Powszechna praktyka pytania każdego programisty o to, co zrobił wczoraj, co planuje zrobić dzisiaj i czy napotyka jakieś przeszkody, nie jest moim zdaniem zbyt skutecznym podejściem.

Zamiast tego zespół, z którym obecnie pracuję, odkrył bardziej efektywny rytm. Koncentruje się on wokół aktualnie wykonywanych zadań. Odpowiadamy na następujące kluczowe pytania:

• Jakie są postępy w realizacji zadania i jakie prace pozostały do wykonania?
• Czy pojawiły się jakieś nowe spostrzeżenia dotyczące zadania lub funkcji?
• Czy zakres uległ zmianie lub czy złożoność jest większa niż początkowo przewidywano?

Pytania te służą jako punkt wyjścia i nie trzymamy się ich sztywno. Ponadto należy zauważyć, że pytania te nie są skierowane do nikogo konkretnego. Ma to zachęcić każdego, kto posiada odpowiednią wiedzę, do zabrania głosu i podzielenia się swoimi spostrzeżeniami. To może być tak proste.

Oryginał tekstu w języku angielskim przeczytasz tutaj.