Psychologiczne wymuszanie dokańczania wszystkich zadań pod koniec Sprintu w Scrumie

Cześć,

Pracuję w korporacji. W ten piątek mam koniec Sprintu a w poniedziałek DEMO dla klienta. Dzisiaj skończyłem zadanie które miało 3 Story Pointy w dwa dni w normalnych roboczych godzinach. Zostało na mnie jedno zadanie wycenione na 5 Story Pointów, do końca piątku muszę je zmergować.

Już teraz wiem, że tego zadania nie dokończę bez crunchu jutro i w piątek, pracując zdalnie i robiąc nadgodziny które nie są płatne. Mój manager doskonale wie, że jesteśmy w plecy z pracą, zamiast podjąć jakieś kroki nic się nie dzieje. Ja boję się odezwać, jestem nieśmiały i trochę zastraszony, może mam skille słabe (4 lata doświadczenia jako Java Developer i 1 rok doświadczenia jako iOS Dev), sam nie wiem.

Do tej pory, od 6 miesięcy robiłem tak jak napisałem wyżej że pod koniec Sprintu, jakieś 75% iteracji kończyło się tym, że ulegałem temu magicznemu "końcowi Sprintu", sloganom jak dowożenie, estymatom, burndown chartom i robiłem nadgodziny nie mówiąc o tym, a naprawdę się nie obijam.

Jak wyjść z tej toksycznej sytuacji w pracy?

Ja boję się odezwać, jestem nieśmiały i trochę zastraszony, może mam skille słabe (4 lata doświadczenia jako Java Developer i 1 rok doświadczenia jako iOS Dev), sam nie wiem.

sam znalazłeś odpowiedź na swoje pytanie:

Jak wyjść z tej toksycznej sytuacji w pracy?

albo się ogarniasz i mówisz, że przestymowaliście i nie dacie rady dowieźć (bo jesteście zespołem prawda?), albo poświęcasz swoje życie dla firmy (protip: nie warto), albo się zwalniasz ;)

Grow some balls. Czlowiek uczy się mówić 'nie' w wieku 3 lat.

• proponuję przeszacowywać taski, jeżeli mówisz że to nie pierwszy raz. Najwidoczniej zakładacie że zrobicie zadania bez żadnych problemów. Może są czynniki które wypływają podczas developmentu?

Po prostu powiedz, że nie zdążysz. Tylko tyle i aż tyle. Masz kilka lat doświadczenia, żeby Cię zwolnili musiałbyś usunąć bazę klientów na prodzie (i to nie przypadkiem, ale z premedytacją xd).

A inni tez siedza po godzinach, zeby dopychać taski? Jeśli tak to problem leży poza Tobą i nic z tym nie zrobisz, dla równowagi proponuję zrobić quiet quitting, poopierzielać się aż faktycznie Cię wywalą (ale obawiam się, że dużo czasu może minąć i szybciej sam odejdziesz), a w międzyczasie szukać mniej toksycznej roboty.

Dodatkowo ten menadżer wykorzystuję Twoją nieśmiałość i "strach". Widzi, że nie potrafisz się odezwać, więc ciśnie. dopóki nie otworzysz gęby to będziesz tak dryfował.

Jeszcze jedna opcja, umow sie ze dowieziesz, zrob po godzinach, ale sobie odbij ten czas np. w przyszlym tygodniu.

Dziękuję wszystkim za odpowiedź i wsparcie, o ile raczej managerowi się nie postawię, po prostu nie potrafię to będę starał się stosować "quiet-quitting" i w międzyczasie szkolić na na rozmowy i od nowego roku wyślę parę CV do innych firm.

@fastis: obejrzyj sobei w ramach quiet quitingu:

Jak czytam takie posty to mam wrażenie, że powinien powstać jakiś państwowy oddział psychologiczny do spraw walki z nieśmiałością.

Ręce opadają (sorry OPie).
Jesteś dorosły, pracujesz w branży gdzie nową pracę znajdziesz w kilka dni a trzesiesz portkami praktycznie godząc się z darmowymi nadgodzinami (więc ktoś Cię w zasadzie okrada na przynajmniej kilka stów) zamiast powiedzieć w piątek na daily coś w stylu "zadanie X jest w trakcie i nie uda się go dokoncYc w tym sprincie" a jak menago będzie smarkal pod nosem to mówisz, że zagrożenie było zgłaszane wczesniej, wynika z tego i tego I SIEMA.

Zero magii, zero strachu bo i czego tu się bać?

Come on bo trace wiarę w ludzi :(

Zgadza się, to nie jest żadne "stawianie się" tylko normalna komunikacja - im wcześniej tym lepiej. Nie czekaj z tym do końca sprintu, tylko od razu pisz o tym (np. zrobię to i tamto, ale w tym sprincie nie zdążę tego i tamtego). Poza tym, w Scrumie jest jakiś zespół - nie może cię jakoś wesprzeć?
Stawiać to się możesz, jak powiesz że planowany nowy projekt to pomyłka i potencjalna katastrofa. Ale na to trzeba mieć argumenty, a nie tylko przeczucia (choć raz miałem takie przeczucia i projekt faktycznie zakończył się spektakularną porażką).

Jeśli twierdzisz, że dopchasz tego taska to powinieneś go zrobić, a jak nie dasz rady to wyciągnij wnioski i następnym razem daj sobie więcej czasu.

Lepiej dać sobie o jeden dzień więcej, bo zawsze ci zleci czasu na jakieś pierdoły, w myślach problem jest zawsze znacznie prostszy niż jest w rzeczywistości.
Musisz być uczciwy i szczery i przyznać się, do własnego błędu, że nie dasz rady wykonać bo źle oszacowałeś i zaskoczyły cię problemy, o których nie pomyślałeś, bo były nieszablonowe lub nie miałeś nigdy doświadczenia z takim czymś.

Psychologiczne wymuszanie dokańczania wszystkich zadań pod koniec Sprintu w Scrumie

Jak to leciało? "To nie był prawdziwy Scrum" czy jakoś tak

robiąc nadgodziny które nie są płatne

Czyli pan stoi z batem i "będziecie mieli do portfolio"? xD Jak czytam kolejny wątek, o tym, że ktoś przez własny brak asertywności zgadza się na darmową pracę, to myślę, że związki zawodowe dla programistów to nie musi być taki zły pomysł. Bo może by wymuszały godne warunki w takich JanuszSoftach, które stosują cichy mobbing wobec pracowników.

Mój manager doskonale wie, że jesteśmy w plecy z pracą, zamiast podjąć jakieś kroki nic się nie dzieje.

Manager do wymiany w takim razie.

Ja boję się odezwać, jestem nieśmiały i trochę zastraszony, może mam skille słabe (4 lata doświadczenia jako Java Developer i 1 rok doświadczenia jako iOS Dev), sam nie wiem.

Skille nie wiem, ale jak masz (4 lata doświadczenia jako Java Developer i 1 rok doświadczenia jako iOS Dev), to już powinieneś mieć jakąś pozycję na rynku pracy przez same wyrobione dupogodziny. Więc możesz zacząć rozsyłać CV. Albo znajdziesz lepszą pracę, albo jeśli będziesz chciał zostać w tej, to nie będziesz pod ścianą (bo rozumiem, że jeśli dana praca to twoja jedyna opcja życiowa, to jest lęk, że ja stracisz. Ale jak masz inne opcje, to możesz mieć bardziej wyje*ane. Najwyżej cię zwolnią, ale wtedy już będziesz miał inne opcje).

fastis napisał(a):

Do tej pory, od 6 miesięcy robiłem tak jak napisałem wyżej że pod koniec Sprintu, jakieś 75% iteracji kończyło się tym, że ulegałem temu magicznemu "końcowi Sprintu", sloganom jak dowożenie, estymatom, burndown chartom i robiłem nadgodziny nie mówiąc o tym, a naprawdę się nie obijam.

Na tym polega Scrum właśnie w praktyce. Na tym, że będą ci mydlić oczy, żebyś tylko uwierzył w ich przekaz i zaczął zapieprzać ponad miarę. Może pierwsi świadkowie Scruma inaczej to zaplanowali, ale jednak ta ideologia została mocno wypaczona i sprowadzona do tego, że goście, którzy nawet nie umieją programować tylko są po kursach zarządzania będą rzucać slogany, a programiści albo uwierzą albo będą zmuszeni się stosować do tego.

Jak wyjść z tej toksycznej sytuacji w pracy?

Zmienić na inną. Poduszka finansowa też się przydaje, bo wtedy nie masz takiego strachu.

BTW nawet ChatGPT mówi, że pracujesz w niezdrowej atmosferze

Mówi się, że "coworkers are not your friends", a tym bardziej przełożeni. Sam z tym walczę, ale trzeba się uczyć mieć w dupie ten psychologiczny nacisk "leadów" na dowożenie i przestać szukać w ich oczach akceptacji i poklepania po plecach

ta zdrowa czynność, której nie trzeba się bać ani wstydzić nazywa się "eskalowaniem problemu". Jeśli jakiś lider wycjsza eskalowanie realnych problemów, zacznij narzekać na lidera, tylko o pięterko wyżej...

WhiteLightning napisał(a):

Jeszcze jedna opcja, umow sie ze dowieziesz, zrob po godzinach, ale sobie odbij ten czas np. w przyszlym tygodniu.

I mu velocity spadnie i będzie musiał się tłumaczyć, dlaczego w jednym sprincie zrobił dużo zadań, a w innym mało :D

O kurde niezła patologia.

Powoływanie się na numerki (robię 2 story pointy w dwa dni, 75% itp.) wskazują na jakieś totalne pogubienie wszystkich w tym miksie, twoje pogubienie najbardziej. Darmowe nadgodziny? Wtf?

Robisz tak szybko jak potrafisz, a osoby zarządzające są od tego żeby: dorzucić osobę, przekazać komuś innemu (szybszemu, lepszemu), przesunąć termin, zmniejszyć zakres itp itd. To oni są od zarządzania.

Szukaj innej pracy, jednocześnie zostawiając miły profesjonalny zapach za sobą.

Z ciekawości: kim jest klient? Bo mówisz że korpo, ale korpo to zazwyczaj klient wewnętrzny.

4 lata doświadczenia to możesz już sobie pozwolić na asertywność.
Managerzy się pewnie na to wkurzą, więc przygotuj się na zmianę pracy.

Jak pracowałem w kołchozie to wymagali od ludzi pracy ponad normę, także w weekendy. Zarabiałem wtedy bardzo mało.
Przeszedłem do korpo. Praca po 2 godz. dziennie. Zarobki 3 razy wyższe.

Nie daj sobie wmówić, że jesteś za słaby czy coś.

Kup sobie tę książkę: https://helion.pl/ksiazki/mistrz-czystego-kodu-kodeks-postepowania-profesjonalnych-programistow-robert-c-martin,mckkvv.htm#format/d
i stosuj porady mistrza:
https://www.youtube.com/@oodelhoff/videos

Jakbyś przeczytał Spring Guide to wiedziałbyś że podczas sprintu nie można robić nic, co naruszyłoby Sprint Goal. Jeśli oczywiście mówimy o normalnym scrumie, a nie takim scrumie jaki jest "praktykowany" w większości firm.

Po prostu mówisz, że nie dasz rady dowieźć danego zadania. Czy to kwestia tego, że niedoszacowaliście skomplikowania, czy wyszły jakieś nieprzewidziane komplikacje, czy po prostu się obijasz - to już inny temat.

Swoją drogą, jak myślę o firmach, w których pracowałem, to przez 4 lata Scrumów widziałem chyba 2 (słownie: dwa) sprinty dowiezione w 100%. Prawie zawsze czegoś się nie dowiozło i dokańczało w następnej iteracji.

A niby Scrum powstał właśnie, aby unikać takich nonsensów.

Ja uważam, że jakieś ciśnienie na deadliny programista powinien czuć, ale dowożenie regularnie co dwa tygodnie, jak w zegarku, musi się skończyć patologią.

Próbowałeś sprawdzić, co się stanie, jak nie dowieziesz? Przecież za jedno spóźnienie cię nie zwolnią. Może się okazać, że zgodnie ze Scrumem task przejdzie do następnego sprintu, będziecie lepiej robić estymację następnym razem, i w ogóle sam sobie tworzysz problemy.

Technika wiecznego niedoboru - czasy, zasobów, narzędzi, etc. to jedna z tych z podręcznika mendżera psychopaty i jedna z podstaw kultury wypalenia. Pytanie, czy nie dajesz rady, bo estymaty dramatycznie rozjechały się z rzeczywistością, czy np. brakuje Ci wiedzy z jakichś obszarów, czy jeszcze coś innego? Generalnie jak rozumiem model SCRUMowy, to to co zespół zdążył zrealizować, a to czego nie zdążył to jest materiał do dalszej refleksji i replanowania. Zespół po jakimś czasie już będzie miał ustabilizowany output i to powinno być brane pod uwagę przy planowaniu kolejnych sprintów. Inna sprawa, że w obszarach, które nie są dobrze rozpoznane estymaty to są często takie trochę "ile byśmy chcieli, żeby to zajęło", a nie ile ma to rzeczywiście szansę zająć.

To zabrzmi banalne, ale: nie jesteś w stanie zrobić więcej niż jesteś w stanie zrobić.
Jak się nie da, to powiedz, że się nie da. Jak to wyjdzie poza Twoje godziny pracy, to powiedz, że okej, ale albo zapłacą Ci za nadgodziny, albo trzeba to rozbić i rozłożyć w czasie. Tylko Ty, jako developer wiesz jak coś zrobić i ile to zajmie czasu. Reszta (PM, PO) mogą jedynie odpowiedzieć na pytanie co zrobić i o tym jak coś zrobić zazwyczaj nie mają totalnie pojęcia. Jak widzą, że dowozisz i nic nie mówisz, to skąd mają wiedzieć, że jesteś przeładowany.
Jak im na to pytanie nie odpowiadasz szczerze albo nie wyprowadzasz ich z błędu, to sami sobie wymyślają odpowiedzi, więc powinieneś obwiniać siebie równie mocno, jak obwiniasz ich.