Jaki jest sens daily przy dużym zespole?

Cześć,

Mam taki problem, zespół powiększył się do 20 osób i daily moim zdaniem jest bezsensowne w pracy zdalnej w takim układzie. Ludzie nie słuchają się nawzajem, a dla leadera raportowy charakter też jest ciężki do słuchania, bo za dużo osób do śledzenia. Zespół ciężko podzielić na mniejsze zespoły bo klient potrzebuje dynamiczną liczbe osób per serwis/portal co tydzien/2 tygodnie.

Jakieś pomysły jak to usprawnić?

W mojej głowie przychodzi tylko wyrzucenie daily i pisanie na wspólnym kanale progresu i blokerow i zapotrzebowań pojedynczych członków zespołu.

Ale co w tym nietuzinkowego? To dość przewidywalne, że na spotkaniu w pracy, na którym jest więcej niż 5 osób nie będzie jednego tematu, który zainteresuje wszystkich.
Daily to generalnie komunikacja jednostronna, tj. zdawanie raportu do dowódcy. Czy to jest dowódcy potrzebne, to już on musi zdecydować.

IMHO stand-upy nie mają wiele sensu nawet w małych zespołach, to kolejny z szeregu nonsensów wprowadzanych przez oderwanych od rzeczywistości reformatorów.

Jakoś projekty open-source'owe, których rozproszeni po świecie developerzy wcale nie widują się twarzą w twarz, potrafią funkcjonować. Wystarczy im zwykły changelog z zapisywanymi w miarę aktualizacji release'ów linkami do PR-ów bądź tasków. Każdy zainteresowany może sprawdzić i śledzić, co się zmieniło od ostatniej wersji.

Ja tam widzę, że daily jest potrzebne - duża część programistów, nawet seniorów, szczególnie tych co mają bóg wie ile lat, łatwo leci w maliny - siedzą dłubią tydzień swoje rozwiązanie, które i tak nie ma rąk i nóg, i trzeba na review prostować - a tak da się przynajmniej w porę zareagować, jak komuś coś zajmuje długo dłużej niż powinno.

Ale myślę, że gdyby się miało dobry zespół ad-hoc meetingi pomiędzy członkami i jakieś weekly byłoby wystarczające, ale zwykle przecież w zespołach jest 80 / 20 - 20% tych co ogarniają, i 80% tych co rozumieją składnie :P

Jak to, zespół nie potrafi się sam zorganizować na takim daily? ;-) Klient potrzebuje ilość osób? :| A może dostarczoną ilość "czegoś" (funkcjonalności w określonym czasie?)

Rozsądnym wydaje się podzielić te 20 osób na 3 mniejsze zespoły i niech sobie daily robią osobno. Dodatkowo liderzy takich zespołów niech mają raz czy 2 w tygodniu spotkanie synchronizacyjne, a raz w tygodniu spotkanie z liderem tych 20 osób. Częstotliwość takich spotkań i ich długość wyniknie z bieżących potrzeb.

20 osób idealnie żeby się podzielić na 2 zespoły...

Podzielcie się na więcej zespołów. Nikt nie powiedział, że jeden zespół musi się specjalizować w jednej usłudze. podobno idealna wielkość zespołu to 5-8 osób.
Drugi element absolutna dyscyplina na daily:

• punktualność, co do sekundy, 900 zaczynamy, nie ważne czy wszyscy już są, po miesiącu zaczną zdążać
• przygotowanie - jak ludzie mają z tym problem, to niech sobie robią wcześniej notatki co chcą powiedzieć
• zero "wczoraj coś tam robiłem, ale trochę mi nie poszło, więc będę robił dalej, a gadam tylko po to, bo coś muszę powiedzieć"
• raportowane są tylko ukończone prace, przeszkody, potrzeby pomocy
• absolutne zero technicznych dyskusji "jak coś zrobić", jedynie proste - wiem jak to zrobić, zagadaj po daily

Pixello napisał(a):

Ja tam widzę, że daily jest potrzebne - duża część programistów, nawet seniorów, szczególnie tych co mają bóg wie ile lat, łatwo leci w maliny - siedzą dłubią tydzień swoje rozwiązanie, które i tak nie ma rąk i nóg, i trzeba na review prostować - a tak da się przynajmniej w porę zareagować, jak komuś coś zajmuje długo dłużej niż powinno.

Początkujących, juniorów i nowo zatrudnionych trzeba obserwować tak czy inaczej, ale od tego jest z reguły oddelegowana jedna mentorująca osoba, która pilnuje tych ich rozwiązań, odpowiada na ich pytania i regularnie zagląda im przez ramię. Co do reszty, wypadałoby zaufać, że wiedzą jak wykonywać swoje zadania lub komu dać znać, jeśli zderzą się z jakimś blokerem lub muszą przedyskutować design. Co najwyżej potrzebna jest uważniejsza kontrola dla tasków krytycznych (również dlatego, by można informować klienta o statusie prac) oraz tych z widocznym opóźnieniem, ale to spokojnie da się załatwić na bezpośredniej linii architekt/lead - deweloper. Reszty to tak naprawdę nie dotyczy, po cholerę mają stać w kółeczku i słuchać. A seniorzy, którzy "lecą w maliny" to jakaś patologia i oksymoron, albo nie są tak naprawdę seniorami i trzeba ich pilnować jak juniorów, albo może nawet nie nadają się do zespołu, skoro wymagają takiej ciągłej troski?

Sam pracuję już od 2 lat zdalnie, zacząłem jeszcze przed pandemią, która ten tryb upowszechniła, siłą rzeczy żadnej formy stand-upów i innych form szczegółowej kontroli nie ma (co innego, oczywiście, w przypadku mentorowania juniorów/nowo zatrudnionych), co sobie bardzo chwalę.

Mikrozarządzanie to nonsens.

Mam opory przed sztywnym dzieleniem ludzi np. na grupy 5 osobowe, 10 osobowe itp. Większy sens ma gdy jest jakieś duże zadanie i po prostu wrzucamy temat grupie osób.

@Spearhead jeśli dobrze rozumiem to z Twojej perspektywy daily to mikrozarządzanie i na poziomie zespołu byś to wyrzucił jako praktyke..

Dla mnie te wszystkie sztywne pogadanki są bez sensu. Jeżeli manager nie wie co robi jego zespół to znaczy że system zarządzania zadaniami jest do d**y.

Spearhead napisał(a):

IMHO stand-upy nie mają wiele sensu nawet w małych zespołach, to kolejny z szeregu nonsensów wprowadzanych przez oderwanych od rzeczywistości reformatorów.

Nieprawda, stand-upy potrafią być bardzo owocne: