Czy spowiadasz się na daily?

W utopijnej scrumowej wizji na daily informujemy o ważnych rzeczach, aktualizacjach, czy żalimy się z problemów. W praktyce słucham takich pierdół jak to że jeden kolega drugiemu sprawdził pull requesta, bo ten musi coś powiedzieć, żeby nie było że nic nie robił.

Dałem tak, bo miałem coś ala spowiedź właśnie przez ostatnie lata pracy i trwało to długo do pół godziny(rekordowo nawet do godziny). Dodatkowo był obowiązek kamerek i ocenianie Ciebie. System gratyfikujacy tych przegrywów co byli w szkole i chcieli się przypodobać nauczycielowi/systemowi, więc nawalali jak najszybciej i nic z tego nie mieli poza pochwałą.

Teraz daliy 2x w tygodniu po 5-10 min i jest luksus. Polecam, czasem warto zrezygnować z pensji za komfort. Chociaż mam wrażenie, że jak jest ogarnięty TL to daliy nie jest w ogóle potrzebne.

Jak robię postępy i mam co powiedzieć to mówię, jak nie to mówię, że wciąż pracuję nad X i nikt się nie czepia. Ogólnie w moim korpo scrum działa całkiem nieźle, nie identyfikuję się z powszechnym na niego narzekaniem.

Najważniejsze to żeby móc powiedzieć że się zrobiło progres. A czy progres zajął 10 minut czy 8h to już drugorzędna sprawa.

Nie mam daili

Tak, codziennie o 10 mówię przed managerem co robiłem wczoraj - 7 lat expa w Javie. Swoją drogą jak opowiadam to ludziom z innych branż to robią wielkie oczy, że tak mam codziennie. Kolega z branży finansowej ma takie spotkanie raz na tydzień w piątek, pracuje całkowicie zdalnie. Koleżanka z korpo marketingu ma takie spotkania raz na 2 tygodnie, też zdalnie. W IT jest się nowoczesnym, dobrze opłacalnym niewolnikiem, więc taka jest tego cena, że śledzą Twój postęp dokładnie i patrzą na ręce.

Nie, ale ja nie muszę.

Natomiast napiszę wam, jak to wygląda z punktu widzenia "zarządczego": te wszystkie ceremonie scrumowe - nawet jeśli nie masz Scruma - są megapomocne w wyłapywaniu patologii. Jeśli one są nudne i nic się tam nie dzieje to jest super, i można przelecieć daily na autopilocie. Natomiast jeśli jest konflikt pomiędzy dwoma devami, albo jeden z devów się zakopał i od czterech dni mówi to samo - wtedy te 15 minut dziennie okazuje się przydatne.

Sztuką jest ucinać niepotrzebne rozmowy na daily tak, żeby nie rozlewało się one zbytnio - ale za to nie mogę odpowiadać.

Nie mam scrum'a, nie mam daily. Mam jedno spotkanie a'la daily ale nie jest obowiązkowe. To jest spotkanie dla nas dev'ów a nie dla mangaerów. Menago wgrywa się raz na tydzień aby zapytać czy są jakieś problemy. Tyle.

mam daily, nie spowiadam się, udaje że słucham

Na daily jedziemy nie po osobach tylko po taskach, więc odzywa się ten który ma coś do powiedzenia na temat każdego taska z listy. Zazwyczaj osoba która go robi.
Jest też czas żeby poruszyć dowolny inny temat, jeśli ktoś odczuwa taką potrzebę.

u mnie zrezygnowalismy z daily a wczesniej mielismy zdzwonke 3 razy w tygodniu max 15min ale ludziom sie nie podobal taki system

Niby tak, ale głównie chodzi o to aby faktycznie przedstawić jaki progress jest z taskami, raczej nikt nie ocenia tego jakoś nadmiernie, a nawet jak trzeba wersje dowieźć to mniej spowiedzi a więcej pytań o dany feature.

wartek01 napisał(a):

Natomiast napiszę wam, jak to wygląda z punktu widzenia "zarządczego": te wszystkie ceremonie scrumowe - nawet jeśli nie masz Scruma - są megapomocne w wyłapywaniu patologii.

Sam się sobie dziwię, że bronię Scruma, ale z tym powyżej się w 100% zgadzam i w tym zakresie daily są pomocne. Zwłaszcza, jak są w zespole juniorzy, lub ogólnie ludzie średnio ogarniający swoją robotę. Wtedy taki delikwent zmarnuje max 1 dzień pracy na brnięciu np. w zupełnie złą stronę z zrobieniem jakiegoś zadania.

wartek01 napisał(a):

Natomiast napiszę wam, jak to wygląda z punktu widzenia "zarządczego": te wszystkie ceremonie scrumowe - nawet jeśli nie masz Scruma - są megapomocne w wyłapywaniu patologii.

Ale jak to? Przecież te wszystkie spotkania podobno są dla zespołu, żeby efektywniej pracować. A nie dla nadzorców do ułatwiania nadzoru

Ja tam widzę taką korzyść w daily, że niektórzy są tak pozbawieni umiejetności miękkich, że jak się ich nie pociągnie za język to nie powiedzą, że mają z czymś problem. Jeśli chociaż raz dziennie powiedzą, że pracują nad czymś, ale coś nie wychodzi to jest szansa zareagować i rozwiązać problem szybciej. Rozumiem szanowanie pracy, ale wszystko ma swoje granice.

Nie wiedziałem że gdzieś nie ma daily, od początku miałem coś tego rodzaju, poza pierwszą pracą gdzie w sumie byłem jedynym programistą.
Na początku wydawało mi się strasznie głupie i przez większość czasu nie ma sensu ale zdarzyło się parę razów że zaoszczędziło to dużo czasu bo na przykład usłyszałem że ktoś wynajduje koło od nowa i implementuje coś co już dawno jest w systemie i mogłem się odezwać, zmusza też do robienia czegokolwiek i czasem to jedyny kontakt w ciągu dnia z innymi kolegami z zespołu i szansa przedyskutowania czegoś albo umówienia się na kolejne spotkanie.

Gdybym miał własną firmę i własny zespół programistyczny to też bym im kazał robić daily bo jednak ma więcej zalet niż wad. Jedynie wyrzuciłbym przez okno ludzi którzy faktycznie każą się ustawić w kółeczku i stać bo to "standup meeting" więc musimy stać. W dobie pracy zdalnej odpowiednikiem są osoby które każą włączać kamerkę.

wartek01 napisał(a):

Nie, ale ja nie muszę.

Natomiast napiszę wam, jak to wygląda z punktu widzenia "zarządczego": te wszystkie ceremonie scrumowe - nawet jeśli nie masz Scruma - są megapomocne w wyłapywaniu patologii. Jeśli one są nudne i nic się tam nie dzieje to jest super, i można przelecieć daily na autopilocie. Natomiast jeśli jest konflikt pomiędzy dwoma devami, albo jeden z devów się zakopał i od czterech dni mówi to samo - wtedy te 15 minut dziennie okazuje się przydatne.

Sztuką jest ucinać niepotrzebne rozmowy na daily tak, żeby nie rozlewało się one zbytnio - ale za to nie mogę odpowiadać.

one są tą patologią

patologiczna wiarą w zespoły bez nadzoru

Pracowałem z daily oraz bez daily i uważam że daily ma o wiele więcej plusów niż minusów.

Szkoda tylko że niektórzy nie lubią daily z tego względu że pracowali w pato teamie gdzie daily było jak spowiedź i musieli kombinować jak przekazać że jeszcze coś nie jest done.

Daily jest jak najbardziej spoko, niestety zostało to wypaczone przez Januszów biznesów jako "spowiadanie devów" z tego co robili i micromanagement pod przykrywką Scruma. Ja 7 lat robię i bardzo często na Daily byli Product Ownerzy i Managerzy. Tylko 2 razy przez ten okres miałem coś takiego że Daily było tylko dla programistów, ale i tak krótko trwało.

wartek01 napisał(a):

Nie, ale ja nie muszę.

Natomiast napiszę wam, jak to wygląda z punktu widzenia "zarządczego": te wszystkie ceremonie scrumowe - nawet jeśli nie masz Scruma - są megapomocne w wyłapywaniu patologii. Jeśli one są nudne i nic się tam nie dzieje to jest super, i można przelecieć daily na autopilocie. Natomiast jeśli jest konflikt pomiędzy dwoma devami, albo jeden z devów się zakopał i od czterech dni mówi to samo - wtedy te 15 minut dziennie okazuje się przydatne.

Jako dev nie mam problemu z opisywaniem postępów nawet jak jestem od iluś dni "Zakopany".
O wiele prościej byłoby po prostu wystawić jakiś alert oparty o JIRĘ / Issues (tu wstaw swój tracker) i brutalnie robić akcję (np. wymiana taska między programistami) jeśli ktos ma IN PROGRESS na zadaniu przez kilka dni.

Generalnie daily stan d**y jest ok, ale idealny to po prostu log w jakimś slacku.
A 2-3 razy w tygodniu można sobie zrobić spotkanie devów pod tytułem PITOLENIE. Pitolenie czasem jest przydatne.

jarekr000000 napisał(a):

Jakp dev nie mam problemu z opisywaniem postępów nawet jak jestem od iluś dni "Zakopany".

Gdy jestem zawalony robotą (jednak czasem się nazbiera w krótkim czasie) to mówię, że mam dużo. To i to i tamto a w kolejce jeszcze A, B, C. Wtedy wyznacza się priorytety lub część zadań przejmuje ktoś inny, ponieważ te górę tasków trzeba przekopać.

O wiele prościej byłoby po prostu wystawić jakiś alert oparty o JIRĘ / Issues (tu wstaw swój tracker) i brutalnie robić akcję (np. wymiana taska między programistami) jeśli ktos ma IN PROGRESS na zadaniu przez kilka dni.

To też jest dobry pomysł. Ja zawsze zapominam o statusach w Jira xD

Generalnie daily stan d**y jest ok, ale idealny to po prostu log w jakimś slacku.
A 2-3 razy w tygodniu można sobie zrobić spotkanie devów pod tytułem PITOLENIE. Pitolenie czasem jest przydatne.

Pitolenie jest bardzo potrzebne. Bo jak ma się głowę zawaloną zadaniami to trzeba się odstresować i dla odmiany pogadać o głupotach.

Mam daily codziennie i mówię nad czym pracowałem i jaki plan mam na dzisiaj. Mogę przez X czasu mówić, że "still working on" i nikt mnie nie pogoni, czy ochrzani, że za długo. Generalnie nie ma ciśnienia na dowożenie co sprawia, że to daily nie jest takie uciążliwe, mimo, że ma miejsce codziennie.

Mam też slack daily w drugim projekcie i to jest moim zdaniem najlepsza i jedyna sensowna forma tego typu zjawisk. 3 linijki -> co zrobiłem wczoraj, co robię dzisiaj, czy mam problemy. Jednozdaniowe odpowiedzi, czasami nawet 1-2 słowne, wysyłane na początku / końcu dnia. Ogromna oszczędność czasu + filtruje się nie potrzebne informacje., bo nie oszukujmy się. Przynajmniej w moim przypadku, 95% tego co robią inni nie ma wpływu na moją pracę i zwyczajnie takie info nie jest mi potrzebne. Na pewno nie potrzebne jest czekanie 20-30min i wysłuchiwanie każdego.

ledi12 napisał(a):

Na pewno nie potrzebne jest czekanie 20-30min i wysłuchiwanie każdego.

Co dwa tygodnie mam jakiś meeting godzinny gdzie jest taki przegląd tematów z każdego projektu/systemu (mamy w zespole kilka systemów).
Ja na takim spotkaniu zwykle mówię 2-3min, zazwyczaj na końcu meetingu. Trzeba być i jako tako słuchać więc ciężko coś wtedy robić sensownego więc zwykle wieszam pranie albo robię obiad xD

wartek01 napisał(a):

Nie, ale ja nie muszę.

Natomiast napiszę wam, jak to wygląda z punktu widzenia "zarządczego": te wszystkie ceremonie scrumowe - nawet jeśli nie masz Scruma - są megapomocne w wyłapywaniu patologii. Jeśli one są nudne i nic się tam nie dzieje to jest super, i można przelecieć daily na autopilocie. Natomiast jeśli jest konflikt pomiędzy dwoma devami, albo jeden z devów się zakopał i od czterech dni mówi to samo - wtedy te 15 minut dziennie okazuje się przydatne.

Sztuką jest ucinać niepotrzebne rozmowy na daily tak, żeby nie rozlewało się one zbytnio - ale za to nie mogę odpowiadać.

Ale czekaj czekaj, to ja tu widzę błędy w rekrutacji. Powinno się zaturniać ludzi zdrowych psychicznie co potrafią się spytać kiedy mają z czymś problem a nie codzienna odpytka, żeby nie sprawdzić czy ktoś przypadkiem za bardzo nie utknął.

Nie mam daily, mam tylko jedno weekly w tygodniu], ale w poprzednim projekcie jak miałem normalne daily to zawsze dwa zdania i elo, jakością pracy zasluzylem, ze nic mnie o nic nigdy nie wypytywali

miiiilosz napisał(a):

Ale jak to? Przecież te wszystkie spotkania podobno są dla zespołu, żeby efektywniej pracować. A nie dla nadzorców do ułatwiania nadzoru

A to nie uczyli, że na daily jest scrummaster i pełni rolę służebną wobec zespołu?

Miang napisał(a):

one są tą patologią

patologiczna wiarą w zespoły bez nadzoru

Być może u ciebie zespół bez jakiegokolwiek nadzoru poradziłby sobie dobrze.
Praktyka jest taka, że ludzie w większości są tylko ludźmi, i odwlekają przekazywanie wieści, które uważają za złe tak długo, jak się da.

jarekr000000 napisał(a):

Generalnie daily stan d**y jest ok, ale idealny to po prostu log w jakimś slacku.
A 2-3 razy w tygodniu można sobie zrobić spotkanie devów pod tytułem PITOLENIE. Pitolenie czasem jest przydatne.

IMO w cholerę zależy od dojrzałości zespołu i jego członków. Inaczej wygląda praca z zespołem, gdzie masz pięciu seniorów, a inaczej wygląda praca z zespołem gdzie masz jednego seniora, dwóch midów i dwóch juniorów. Opisany przez ciebie przykład, czyli wszystko w ticketach i na Slacku - IMO może zadziałać w mocnym, dobrze zgranym zespole, ale już nie zadziała w świeżym zespole.

Kwestia jest taka, że naprawdę nie ma sensu wymyślać koła od nowa. Jeśli masz framework, który się sprawdza całkiem dobrze w 95% przypadków to nie wymyślasz koła od nowa tylko po prostu go stosujesz. Podobnie jest z organizacją zespołów - jak ktoś przedstawi gotowy przepis na zespół, który sprawi, że:

• nie będzie trzeba patrzeć prawie codziennie, co się dzieje w zespole
• i sprawi, że ludzie nie będą się opieprzać
• nie będzie tam nierealnych warunków

to będzie to rewolucja na miarę Agile manifesto.

wartek01 napisał(a):

miiiilosz napisał(a):

Ale jak to? Przecież te wszystkie spotkania podobno są dla zespołu, żeby efektywniej pracować. A nie dla nadzorców do ułatwiania nadzoru

A to nie uczyli, że na daily jest scrummaster i pełni rolę służebną wobec zespołu?

Jakby pełnił służebną rolę to by się nazywał scrumservant. Była przecież wielka akcja pt nazywanie brancha master uciska czarnych, bo jak jest jakiś master to zawsze w domyśle musi też być jakiś slave. No i potem firmy zmieniały nazwy na main. Ale jakoś scrummaster się ostał, no to wiesz... widać tak ma być

Być może u ciebie zespół bez jakiegokolwiek nadzoru poradziłby sobie dobrze.
Praktyka jest taka, że ludzie w większości są tylko ludźmi, i odwlekają przekazywanie wieści, które uważają za złe tak długo, jak się da.

Nie tylko to nie działa w samoorganizującym się zespole scrumowym, team lead jednak się przydaje.

jak ktoś przedstawi gotowy przepis na zespół ... to będzie to rewolucja na miarę Agile manifesto.

Ale sam się nabijasz z tych scrumowych wymysłów jak samoorganizujące się zespoły, albo "daily jest dla zespołu", albo "story pointów nie przeliczamy na dni" (to jest jedno z moich ulubionych). W większości firm nie wprowadza się "prawdziwego scruma", bo jest nieżyciowy. Wprowadza się spotkania nazwane daily, retro i refinement a potem jakoś ten projekt się toczy. Wg mnie powinno się to nazywać metodyką scrumopodobną. Tak samo jak rzadko kiedy występuje API restowe, zazwyczaj jest to API zwracające JSONa (albo RESTopodobne).

Nie mówię, że koniecznie trzeba się trzymać scruma albo RESTa. Chodzi mi tylko o błędne nazewnictwo

wartek01 napisał(a):

jarekr000000 napisał(a):

Generalnie daily stan d**y jest ok, ale idealny to po prostu log w jakimś slacku.
A 2-3 razy w tygodniu można sobie zrobić spotkanie devów pod tytułem PITOLENIE. Pitolenie czasem jest przydatne.

IMO w cholerę zależy od dojrzałości zespołu i jego członków. Inaczej wygląda praca z zespołem, gdzie masz pięciu seniorów, a inaczej wygląda praca z zespołem gdzie masz jednego seniora, dwóch midów i dwóch juniorów. Opisany przez ciebie przykład, czyli wszystko w ticketach i na Slacku - IMO może zadziałać w mocnym, dobrze zgranym zespole, ale już nie zadziała w świeżym zespole.

Dobry punkt. Zgadzam się. Zespół niekoniecznie musi być IMO zgrany, ale faktycznie lepiej jak jest przewaga "seniorów"

Kwestia jest taka, że naprawdę nie ma sensu wymyślać koła od nowa. Jeśli masz framework, który się sprawdza całkiem dobrze w 95% przypadków to nie wymyślasz koła od nowa tylko po prostu go stosujesz.

Po pierwsze się sprawdza całkiem dobrze w 95% przypadków również pocieranie patykiem o patyk jeśli chcemy rozpalić ogień. Ale niekoniecznie jest to najszybsza i najłatwiejsza metoda.

Praktycznie każdy scrum, który widziałem to była jakaś patologia, a zupełnym rozczarowaniem był ten "podręcznikowy" (bo już nie było na co zrzucić winy). I jak po podobnych wątkach widać - problemy i rozczarowania są powszechne.

Podobnie jest z organizacją zespołów - jak ktoś przedstawi gotowy przepis na zespół, który sprawi, że:

• nie będzie trzeba patrzeć prawie codziennie, co się dzieje w zespole
• i sprawi, że ludzie nie będą się opieprzać
• nie będzie tam nierealnych warunków

to będzie to rewolucja na miarę Agile manifesto.

a) można patrzeć co się dzieje w zespole, ale niekoniecznie wymaga to ustnej spowiedzi. osobiście jestem zwolennikiem stalinowskich metod -> patrzymy co kto pushuje do repozytoriów
b) ludzie będą się opieprzać, co gorsza jest prawdopodobne, że odpowiednio rozwinięta AI też będzie się opieprzać. W każdym systemie raportowania ludzie ogarną jak udawać pracę, nawet jak będzie to sprawdzanie rezultatów. IMO im bardziej jednak sprawdzamy rezultaty, a nie opowieści tym bardziej udawanie robi się pracochłonne, aż do tego stopnia, że części przestanie się chcieć udawać (ale dla pewnego procenta do zawsze będzie ciekawy sport). Z drugiej strony to nie jest tak, że wiekszość devów się opieprza - raczej raz na jakiś czas spotykam kogoś takiego.
c) nie wiem o co chodzi z nierealnymi warunkami

jarekr000000 napisał(a):

a) można patrzeć co się dzieje w zespole, ale niekoniecznie wymaga to ustnej spowiedzi. osobiście jestem zwolennikiem stalinowskich metod -> patrzymy co kto pushuje do repozytoriów
b) (...) W każdym systemie raportowania ludzie ogarną jak udawać pracę, nawet jak będzie to sprawdzanie rezultatów. IMO im bardziej jednak sprawdzamy rezultaty, a nie opowieści tym bardziej udawanie robi się pracochłonne, aż do tego stopnia, że części przestanie się chcieć udawać (ale dla pewnego procenta do zawsze będzie ciekawy sport). (...)

to tak czy siak będzie pchanie sztucznie rozdmuchanych commitów. mam ziomków w zespole co pchają pierdylion commitów dziennie. kolejny nadpisuje poprzedni i summa summarum przez kilkadziesiąt commitów niewiele się zmieniło. niektóry mają takie podejście, że wolą rozwijać programy przez pchanie śmieciowych commitów i testowanie ich dopiero wtedy, niż przez testowanie lokalnie i pchanie dopiero porządnych commitów.

ponadto w mojej korpo jest sporo roboty, która nie wiąże się z pchaniem commitów. jak zaraportować negocjowanie rozwiązań problemów z innymi zespołami, mając do dyspozycji jedynie liczenie commitów?

całe to automatyczne monitorowanie można podsumować tym prawem: https://en.wikipedia.org/wiki/Goodhart%27s_law

Goodhart's law is an adage often stated as, "When a measure becomes a target, it ceases to be a good measure".

Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.

jestem zdania, że interaktywna codzienna rozmowa (czyli to 'spowiadanie się na daily') jest elastycznym i skutecznym sposobem na wyłapywanie problemów, pod warunkiem, że jest ktoś ogarnięty w zespole, kto faktycznie bierze na klatę obowiązki team leada i interesuje się tym co i jak ludziom idzie w projekcie. my mamy takiego team leada.

dodatkowo na standupie mogę wyłapać np. czy ktoś robi coś nieoptymalnie, czy wymyśla koło od nowa, czy robi coś ciekawego na co chciałbym popatrzeć, itp itd. gdybym miał to robić przez przeglądanie wszystkich commitów, które ludzie wrzucają to spędziłbym na takim wyłapywaniu rzędy wielkości czasu więcej. podczas pracy w zespole trzeba skupiać się na aspekcie zespołowym, a daily to dość dobrze uskutecznia. na telespotkaniu dużo skuteczniejsze są prośby o pomoc, o planowanie release'ów i wykorzystania infrastruktury żeby uniknąć konfliktów, czy ogólnie o pomysły jak sobie z jakimś nieintuicyjnym problemem poradzić. pytanie na czacie jest zwykle zbywane, bo po pierwsze można wyjść z założenia, że ktoś inny odpowie, a poza tym przede wszystkim mało kto śledzi czat na bieżąco, zwłaszcza po południu. jeśli na telespotkaniu następuje cisza to popycha to do odezwania się, a natomiast cisza na czacie to norma, nikogo to nie obchodzi. jest pewien kompromis - gadając o problemach na daily trzeba czekać, aż do tego daily, ale przynajmniej jest dużo większa szansa, że ktoś się do tego odniesie niż przy pisaniu na czacie. z drugiej strony, zwykle mam na tyle dużo roboty, że z większością problemów mogę czekać ten kawałek dnia, bo w międzyczasie zajmę się czymś innym, także potrzebnym. zawracanie gitary na standupie ma też tę zaletę, że standup jest od zawracania gitary (tzn. wiadomo kiedy jest standup, więc pracę rozplanowujemy tak, żeby nam jej nie rozpieprzał), natomiast zawracanie gitary w przypadkowych momentach w środku dnia mniej lub bardziej rozpieprza pracę. zależy od dyscypliny. ja mam problemy ze skupieniem.

na nasze daily (ja to wciąż nazywam standupami, mimo że wszyscy siedzą) przychodzą zarówno programiści (włączając team leada, ludzi od backendu, frontendu i devopsów) jak i menedżerka i product owner. nie widzę problemu z tym, że menedżerka czy product owner są obecni. menedżerka zwykle nie ma wiele do dodania, a product owner, jeśli ma dużo do powiedzenia, to można mu powiedzieć, żeby pogadał z zainteresowanymi ludźmi po standupie, tzn. w mniejszym gronie. ogólnie robimy tak, że jeśli podczas standupu wyjdzie jakiś grubszy temat do obgadania to ogólnie naciskamy na skończenie 'codziennej spowiedzi', a grubsze tematy są zepchane na tuż po standupie albo jeszcze później (zależy kto ma ile czasu i kiedy). ktoś tu pisał o 'nadzorowaniu' zespołu w sytuacji, kiedy menedżer wbija się na standupy. ja nie widzę dużego problemu jeśli jest spokój. niech się przygląda jeśli to nie skutkuje mikrozarządzaniem czy toksyczymi wstawkami.

celujemy w standupy półgodzinne. jeśli standupy zaczynają wielokrotnie się przedłużać i trwać dużo dłużej niż pół godziny to można wprowadzić odliczanie czasu, pokazywane w telekonferencji dla wszystkich. jak się ustabilizuje czas standupu (tzn. zejdzie do średnio pół godziny) to można przestać bawić się w widoczne odliczanie czasu, ale jak problem wróci to wracamy do zabawy itd.

p.s. oczywiście wszystko zależy od zespołu i projektu. można wypracować inne metody skutecznej komunikacji w zespole. trzeba jednak wziąć pod uwagę to, że lakoniczna krytyka, bez podawania solidnej i kompleksowej alternatywy, może wyrządzić więcej szkody niż pożytku. do wszystkiego można się przyczepić. na wszystko można narzekać. co byście nie wymyślili, i tak może znaleźć się duża grupa osób, która zaorze wasze pomysły, o ile w ogóle duża grupa osób się zainteresuje waszymi pomysłami.

Wszystko nadal sprowadza się do ludzi i to od nich zależy jak będzie wyglądać praca. Albo ludzie zachowują się dojrzale, albo nie dojrzale. Jakieś półgodzinne standupy z menadżerką to nic innego jak zwykła kontrola, która nikomu oprócz menadżerce nie służy.