Czy we wszystkich firmach scrum = patologia?

Wiadomo sama nazwa wskazuje Scrum (Szybciej Ciągle Robić Upodlony Masz). A z tym wiąże się:
a) Poganianie, wrzeszczenie na pracownika, wymuszanie skracania szacowań - "bo to co jest do zrobienia jest proste".
b) Budzenie się z ręką w nocniku na dzień przed terminem.
c) Wybieranie drogi na skróty, aby tylko dowieść "bo na przykład kary finansowe w umowie".
d) Sugestie dotyczące siedzenia w nadgodzinach (w większości firm bezpłatnych) - teksty typu "jak dzisiaj tego nie skończysz, opóźniony będzie cały projekt, bo na ciebie czeka x,y,z", "no przecież to prosta rzecz - jeszcze tego nie zrobiłeś?", sugestywne niby żarty typu "wiesz jeszcze jest weekend".
e) Myślenie typu jak Pan X który jest konserwatorem zarabia kwotę $$$$, a programista zarabia $$$$ * 4 to programista powinien 4 razy więcej pracować.
f) Enigmatyczne opisy zadań do wykonania, często jedno zdaniowe frazesy.
g) Analiza która rodzi się razem z implementacją.
h) Nadmiar spotkań, dyskusji na komunikatorach i innych odrywających od pracy bodźców.

1. Czy we wszystkich firmach scrum = patologia?
2. Czy są firmy/projekty/metodyki w których nie pracuje się pod presją czasu?

Tak sa firmy, gdzie praca to nie bycie koniem zaprzęgowym

Scrum jest trochę jak komunizm. Ma bardzo dobre założenia, ale ludzie jeszcze do niego nie dorośli.

Scrum stawia na jakość produktu bez kompromisów, a klient zazwyczaj chce jakiegoś kompromisu ceny, czasu i jakości.

Zespół scrumowy musi mieć bardzo dużo kompetencji, a w praktyce dzisiaj jest takie ssanie na rynku, że bierze się każdego kto umie IDE odpalić. Mało firm stać na rekrutowanie osób z kompetencjami miękkimi czy wiedzą domenową. Trudno znaleźć programistów zaangażowanych.

Scrum jest bardzo wymagający dla liderów, bo oni powinni kierować z tylnego siedzenia, a to mało osób umie.

Sama rola scrum mastera to jest cholernie ważna sprawa, ale znalezienie osoby z zestawem kompetencji wymaganych na takim stanowisku graniczy z cudem.

Finalnie mamy zazwyczaj do czynienia z bieda scrumem i raczej to się szybko nie zmieni.

Oczywiście czasami trafi się na zespół, który nadaje sie do scruma, ale to raczej spora mniejszość.

Przecież to nie jest żaden Scrum, tylko jakieś januszsofty, ewentualnie polska szkoła zarządzania.

Ach, czyli znowu to nie był prawdziwy komunizm Scrum?

Punkty e, f - tak. Reszta nie

metodyki są np. progmofo
srum jest modny więc każda patologia go wybiera. przy okazji pozwala na zatrudnianie kolesi na pozycję które nie wymagają technicznych umiejętości
oczywiście wtedy dla osób które naprawdę coś robią kasy jest mniej i są poganiani jak niewolnicy lub juniorom są dawane zadania które są dla nich zbyt trudne

Problem ze scrumem polega na niskim poziomie scrum masterów. To ludzie, którzy dowiedzieli się, że na tej pozycji można siedzieć i nic nie robiąc jednocześnie zarabiając dobre pieniądze. Faktycznie tak jest, ciężko w korporacji udowodnić, że scrum master nic nie robi. Pracowałam już w 4 firmach i w każdej scrum master był zwolniony z obowiązku logowania czasu, a jego zadanie to siedzenie na spotkaniach i patrzenie w telefon. Zawsze są oderwani od projektu, nie wiedzą co robi zespół, całymi dniami wpatrując się w kalendarz na outlooku, gdy akurat nie siedza na spotkaniu i nie ogladaja facebooka, czekając na koniec dnia.
W niektórych firmach scrum masterzy, chcąc pokazać swoją użyteczność, donoszą.

Scrum i agile nie wszedzie pasują - to o czym piszesz wyglada jak jakies srodowisko regulowane z nienegocjowalnymi terminami. Wtedy pozostaje waterfall i dopychanie kolanem oraz walka na UAT w koncowce.

Agile pozwala te niedogodnosci rozlozyc w czasie i problemy zaadresowac odpowiednio wczesniej. Mowi sie, ze agile nie jest recepta na problemy, tylko pozwala je wczesniej zauwazyc, jednak zeby to jakkolwiek dzialalo wymaga elastycznego srodowiska akceptujacego niepewnosc i zlozonosc + dojrzalego zespolu, ktory bedzie partnerem dla PO, a nie przeciwnikiem.

Dodam jeszcze, ze z tego co widze czesto narzekanie nie dotyczy tyle Scruma per se (moze poza rezimem spotkan, ale to tez Scrum mowi, ze mozna zmienic pod siebie), co XIX-wiecznego srodowiska pracy lub - uwaga - koniecznosci podawania estymat i szeroko rozumianego commitmentu. [offtop]To ostatnie wynika IMHO z wygodnego pozycjonowania sie jako wyrobnik, ktory w dodatku nie musi umiec planowac swojej wlasnej pracy i ponosic za nia odpowiedzialnosci (nazywam to tumiwisizmem).[/offtop]

JoeStrong napisał(a):

c) Wybieranie drogi na skróty, aby tylko dowieść "bo na przykład kary finansowe w umowie".

Z ciekawości: jakbyś miał wybór
a) zrobić na skróty i uniknąć kar umownych
b) zrobić "normalnie", przekroczyć termin i przez to firma płaci karę
to jak byś wybrał? Czy Twój wybór byłby taki sam, gdybyś wiedział, że potem firma wygra w sądzie sprawę przeciwko Tobie i ostatecznie to Ty będziesz płacił tę karę?

c) Wybieranie drogi na skróty, aby tylko dowieść "bo na przykład kary finansowe w umowie".

To wystarczy przestać pracować w Software Housie.

To co opisałeś to nie koniecznie wina samego Scruma, tylko bezpośrednia, patologiczna polityka firmy. Abstrahuję już, że większość firm nie rozumie Scruma i nie potrafi go odpowiednio zaimplementować. Finalnie potem są miliony nic nie wnoszących spotkań, tym samym, zabieranie czasu dla developerów który mogli by spożytkować na realną pracę. Potem zdziwienie, płacz i zgrzytanie zębami, bo przecież story pointy, kpi i inne hipsterskie wymysły się nie zgadzają.

Druga strona medalu, to sami ludzie - programiści, którzy zgadzają się na takie traktowanie. Gdy by ludzie otwierali mordę i byli bardziej asertywni to nie dochodziło by do takich sytuacji typu praca po godzinach za darmo i ogólnie bycie traktowanym jak śmieć i parobek.

JoeStrong napisał(a):

Wiadomo sama nazwa wskazuje Scrum (Szybciej Ciągle Robić Upodlony Masz). A z tym wiąże się:
a) Poganianie, wrzeszczenie na pracownika, wymuszanie skracania szacowań - "bo to co jest do zrobienia jest proste".

Nie wiem co to ma wspólnego ze SCRUM. Czyli jak nie ma SCRUM to nie wrzeszczą. Na mnie nikt nigdy nie wrzeszczał (nawet jak położyłem na kilkadziesiąt minut duży portal), niezależnie czy był SCRUM, waterfall czy metodyka ułańska.

b) Budzenie się z ręką w nocniku na dzień przed terminem.

Ale że kto się budzi? Programista, który spędził 80% czasu na 4p i nie może dowieź zadań. Kolejny punkt, który w żaden sposób nie tyczy się Scruma jako takiego.

c) Wybieranie drogi na skróty, aby tylko dowieść "bo na przykład kary finansowe w umowie".

Kary umowne potrafią zabić projekt. Więc ja się nie dziwię, że ktoś dopycha kolanem, żeby ich uniknąć i np wywiązać się z jakiegoś zakresu. Inna sprawa jak to robi. Jest na to wiele metod.

d) Sugestie dotyczące siedzenia w nadgodzinach (w większości firm bezpłatnych) - teksty typu "jak dzisiaj tego nie skończysz, opóźniony będzie cały projekt, bo na ciebie czeka x,y,z", "no przecież to prosta rzecz - jeszcze tego nie zrobiłeś?", sugestywne niby żarty typu "wiesz jeszcze jest weekend".

A co to ma wspólnego ze SCRUMem? Zwykłe metody manipulacji. Widać ktoś za bardzo uwierzył w twoje umiejętność i dał ci zbyt ambitne zadanie.

e) Myślenie typu jak Pan X który jest konserwatorem zarabia kwotę $$$$, a programista zarabia $$$$ * 4 to programista powinien 4 razy więcej pracować.

Jak konserwator pracuje 8 h to programista ma pracować 32 h na dobę (przypomnę że doba ma 24 h). Problem nie leży ilości pracy, ale w ilości wypracowanej kasy. Czyli powinien zarobić dla firmy przynajmniej tyle ile zarabia i na koszty inne. Fajnie jakby z tego coś zostało, żeby to maiło jakikolwiek sens.

f) Enigmatyczne opisy zadań do wykonania, często jedno zdaniowe frazesy.

To po co bierzesz takie zadania?

g) Analiza która rodzi się razem z implementacją.

To świadczy o źle wdrożonym SCRUMIe.

h) Nadmiar spotkań, dyskusji na komunikatorach i innych odrywających od pracy bodźców.

Jakich spotkań? A komunikator można wyłączyć i nie brać udziału w dyskusji.

1. Czy we wszystkich firmach scrum = patologia?

Jakoś SCRUMa bardzo zależy od ludzi biorących w nim udział, jak jest słaby PO i SM i zespół deweloperski ma wszystko gdzieś to się to nie uda. Potrzeba jednego mocnego lidera (nie poganiacza baranów ) który pociągnie całość do przodu.

2. Czy są firmy/projekty/metodyki w których nie pracuje się pod presją czasu?

Są 3 podstawowe parametry budowania projektu: czas - zakres -kasa. Jak nie będzie parcia na czasie to na kasie, jak nie na kasie to na zakresie. Czyli jak chcesz dobrze zarabiać, to musisz dowozić odpowiednie rzeczy w określonym czasie.
A projekty, w jakich nie ma parcia na żaden parametr z powyższych to tak zwane projekty, po godzinach których skuteczność jest poniżej jednego promila, bo albo skończą na etapie wiecznego dewelopowania, albo okazują się spóźnione o lata, albo ich zakres jest taki, że nikt tego nie chce.

To zależy, w jednej firmie co pracowałem był patologią (co dzień było tłumaczenie się że ktoś robił taska na 10h o godzinę dłużej, co potem powodowało oddawanie tasków na odpiernicz i masę bugów, szef dzwonił np. o 12 z pytaniem o taska bo z godzin mu wyszło że powinien być zrobiony o 11), natomiast teraz pracuję w innej i jest luzik, patrzymy całościowo za cały sprint ile jako zespół zrobił Scrum Pointów i nie ma spin czy ktoś zrobił mało czy dużo bo tego nie da się wprost zmierzyć. Zespół wypełnił cele = cały zespół się cieszy.

JoeStrong napisał(a):

1. Czy we wszystkich firmach scrum = patologia?

Tak, ale nie taka jaką opisałeś.
Za to dowolna metodyka w polskich software house'ach to patologia.

2. Czy są firmy/projekty/metodyki w których nie pracuje się pod presją czasu?

Tak, nazywa się SCRUM. Jej ideą jest uśrednienie i spowolnienie wydajności pracy programistów, w zamian za to, że management jest w stanie zaplanować na kiedy dany ficzer zostanie wyprodukowany. (A programiści mają w ciągu dnia czas na śledzenie wiadomości i siedzenie na fejsie.)
I całkowicie nie nadaje się do projektów fixed price ani do pracy z nierozsądnymi ludźmi, którzy szacują zadania w godzinach i wypełniają nimi 40 godzin w tygodniu.

To, co OPie opisałeś to nie jest scrum, to zwykły burdel. Teraz wszyscy muszą być agile i pracować w scrumie, mimo że szefostwo to januszerka lub amatorka.
Nie jestem fanem scrum-by-the-book, ale strzelasz do chochoła.

Dla mnie Scrum i cala ta otoczka było jednym z powodow do opuszczenia programowania. Wszedzie sprowadza sie to do jednego moim zdaniem, aby programistę wydoic, wyeksploatować jak najbardziej. Nie jest to w moich priorytetach życiowych w tym uczestniczyć. 4 lata uczestniczyłem w tym cyrku i postanowilem sobie ze nigdy wiecej.

Doswiadczony programista walczy ze Scrumem jego bronia. Po to masz estymaty, planowania, DOD, zeby nie siedziec po godzinach. Chyba ze np. masz liste taskow ktore ktos inny wycenil i masz zniej brac zadania, ale to nie jest Scrum :P

WhiteLightning napisał(a):

Doswiadczony programista walczy ze Scrumem jego bronia. Po to masz estymaty, planowania, DOD, zeby nie siedziec po godzinach. Chyba ze np. masz liste taskow ktore ktos inny wycenil i masz zniej brac zadania, ale to nie jest Scrum :P

Też walczyłem ze Scrumem jego bronią, ale uwierz mi że po prostu mi się już nie chciało. Wszędzie było to samo poganianie, jeszcze jak po raz kolejny trafiłem na jakiś młodych dynamicznie rozpędzonych absolwentów informatyki gdzie mieli mentalność wyniesioną ze studiów robić wszystko na dany termin, kosztem własnego czasu to, weekendów, nocy to już miałem dość. W czerwcu tamtego roku zrobiłem 60h bezpłatnie aby wyrobić się przed DEMO dla klienta, bo Sprinty i tak dalej.

Teraz też robię w IT jako konsultant AWS i nie mam żadnych spotkań z biznesem, nie mam Daily, nie mam Scruma, mam tylko jednego przełożonego z którym spotykamy się raz na 2 tygodnie. Szkoda kopać się z koniem, serio mówię. W IT jest masa fajnych stanowisk, z fajną kulturą pracy, gdzie można zarobić nawet więcej niż DEV, a szczerze mówiąc robię teraz 80% mniej niż kiedyś w tych Sprintach.

ledi12 napisał(a):

To co opisałeś to nie koniecznie wina samego Scruma, tylko bezpośrednia, patologiczna polityka firmy.

Takie wątki na forum pojawiają się co chwilę i ja to rozumiem w sumie, po prostu trzeba się liczyć z tym że jako Dev jest się zazwyczaj ostatnią osobą w łańcuchu "korporacyjnym" jako osoba do poganiania, a Sprinty tylko po to powstały, by mieć większą kontrolę.

Nie macie wrażenia że opinie osób które pracowały tylko w scrumie są trochę mniej miarodajne? Jakby, skoro pracowały tylko w jednej metodologii metodyce to nie znają alternatyw.

_{Updated according to @somekind professor.}

Taka metodologia jest przyjemna tylko dla osób nietechnicznych a działa jedynie jak team jest złożony z programistów o identycznym poziomie znających produkt gdzie nie ma dużo kreatywnej pracy.
Bardzo przypomina toksyczny model szkolnictwa, który jest obecny nadal w Polsce, w którym dobrze czują się ludzie którzy dużo robią i mogą chwalić się codziennie rano przez co czują się lepiej. Miałem takich ziomków, nawet nie chodzili na kawę, żeby pogadać.

Do tego u mnie dochodziło do takich absurdów, ze ludzie brali sobie urlop (przypominam, ze na UOP jest ograniczona ilość) a i tak przychodzili na np planning czy jakies spotkania w dniu urlopu. Oczywiście to patologia, bo robi presję na innych ludziach w firmie.
Ktoś mi powie, że to jego decyzja tylko. No niby tak, ale niektórzy są bardziej podatni na toksycznego scruma(ukrytą manipulacje i mini mobbing) i na nich to bardziej oddziałuje.

Czitels napisał(a):

gdzie nie ma dużo kreatywnej pracy.

Czyli jakieś 90% roboty programistów.

Do tego u mnie dochodziło do takich absurdów, ze ludzie brali sobie urlop (przypominam, ze na UOP jest ograniczona ilość) a i tak przychodzili na np planning czy jakies spotkania w dniu urlopu. Oczywiście to patologia, bo robi presję na innych ludziach w firmie.

Ale co to ma wspólnego z SCRUMem? To bardziej podchodzi pod pracoholizm i to już lata temu (jeszcze przed tym, jak powstał SCRUM czy Kanban) zostało zdefiniowane jako szkodliwe dla środowiska pracy.

Ja tylko przypomnę, że scrum nie jest metodologią, bo metodologia to nauka o metodach badań naukowych.

2/10 :/

Jeśli to ma być dowód na coś, to chyba jedynie na żenujący poziom znajomości angielskiego u co poniektórych. Widać nawet z levelem "denmark from chicken" da się czytać dokumentację. :)

@somekind:

somekind napisał(a):

Jeśli to ma być dowód na coś, to chyba jedynie na żenujący poziom znajomości angielskiego u co poniektórych. Widać nawet z levelem "denmark from chicken" da się czytać dokumentację. :)

raczej brak znajomości polskiego i wmawianie sobie że programowanie jest miedzynarodowe więc wystarczy znać angielskie słówka (bez znajomości ich prawdziwego znaczenia) i ich losowo używać

Pytanie jest źle zadane, powinno być "Dlaczego scrum to patologia?"

Czitels napisał(a):

Do tego u mnie dochodziło do takich absurdów, ze ludzie brali sobie urlop (przypominam, ze na UOP jest ograniczona ilość) a i tak przychodzili na np planning czy jakies spotkania w dniu urlopu. Oczywiście to patologia, bo robi presję na innych ludziach w firmie.
Ktoś mi powie, że to jego decyzja tylko. No niby tak, ale niektórzy są bardziej podatni na toksycznego scruma(ukrytą manipulacje i mini mobbing) i na nich to bardziej oddziałuje.

Zauważ, że scrum polega na tym, że masz zespół scrumowy gdzie za dowożenie rzeczy odpowiedzialny jest zespół, a nie indywidualne jednostki. Czyli scrum wręcz został celowo stworzony, żeby przeciwdziałać bottleneckom w postaci geniuszów, którzy siedzą po godzinach i podczas urlopów. Mimo to nie jest tak łatwo wyeliminować takie osoby. To nie jest porażka scruma, że niektóre osoby nie nadają się do pracy zespołowej i nie są graczami zespołowymi. Mylisz przyczynę ze skutkiem.

Głównym wrogiem z którym walczy scrum są osoby, które boją się okazać słabość w postaci tego, że czegoś nie wiedzą. Takie osoby podświadomie starają się zagarnąć możliwie dużo wiedzy domenowej, żeby niemożliwe było ich zwolnienie. To jest przegrana walka bo kolektyw będzie zawsze lepszy niż jednostka. To jest jak porównywanie ucieczki do peletonu. Ucieczki są fajne na krótkich odcinkach, ale na bardzo długich odcinkach peleton zawsze połknie ucieczkę. Niekiedy warto być w ucieczce, np. kiedy firma agresywnie zdobywa nowe rynki, ale w 99% (instytut danych z d**y) przypadków lepiej być w peletonie. Juniorowi wydaje się, że musi wiedzieć wszystko. Dla seniora stan niewiedzy jest czymś tak naturalnym, że nauczył się zarządzać swoją niewiedzą.

Niestety scrum masterzy po kursach weekendowych nie rozumieją tego i w momencie kiedy zespół nie dowozi to zaczynają robić coś złego czyli micromanagement co tylko pogorsza sprawę. Odpowiednim działaniem powinno być zidentyfikowanie i usunięcie przeciwności czyli to do czego scrum master został powołany. Niestety niektórym scrum masterom się wydaje, że oni są managerami/poganiaczami, a nimi nie są.

Dla rozluźnienia atmosfery Scrum Masterka z rosji

profil

Kubuś PHPapek kiedyś był PHP-owcem a teraz jest Scrum Masterem