Agile i Scrum to obecnie religia

Krótko:

Ruch Agile/Scrum to obecnie religia.

Jak to wiele religii te wyznania przyniosły mniej więcej 0 nowości czy rozwoju dla branży IT.

Lightweight Project Development jest znane od około 1960 roku.

Co przyniósł nam Agile/Scrum

• projekty robione we sprintach - co za różnica dla wyrobnika? Nihil novi od 1960 roku czy nawet wcześniej.
• kumbaya soft skills - miłe gadanie nie napisze kodu ani nie zrobi deploya. Facylitacja spoko, natomiast dalej - nie napisze kodu.
• rozmydlenie zarządzania czyimś hajsem - brak risk/change/deploy management, nie wspominając o praktykach DevOps
• brak zrozumienia dla strony maintenance - gdzie utrzymanie jakoś se tam poradzi po deployu
• nadmiar konsultantów/trenerów/guru odnośnie "prawidłowej" interpretacji agile - nie no, albo ziemia jest płaska albo jest sferoidą, ktoś tu się musi mylić, podobnie w agile, albo X albo Y. To kto ma jedyną słuszną i niesprzeczną definicję "Agile" czy "Scrum"?
• wiele innych

Czas po prostu odciąć się od tego całego religijnego szajsu.

Iteracje/przyrosty - legitne procesy podlegające statystycznemu zarządzaniu procesem czy innym metodom zarządzania pracą.
Magiczne wierzenia na temat Scrum czy Agile - brak jakichkolwiek kryteriów, nic nie idzie stwierdzić, pozostaje interpretacja i opinia.

Już pomijam nawet ogólnie magiczne praktyki zarządzania projektami w Polsce w niektórych firmach.

Najwyższy czas powiedzieć dość tej edżajlowej sekcie po prostu.

Pracowałem dobrych kilka lat jako edżajl skram monter kołczer - tu nie ma nic prócz hajsu.

Fistandantilus napisał(a):

Pracowałem dobrych kilka lat jako edżajl skram monter kołczer - tu nie ma nic prócz hajsu.

A może to po prostu Ty byłeś ch*jowym edżajl kołczem i zwyczajnie trzeba było Cię zwolnić

ToTomki napisał(a):

Fistandantilus napisał(a):

Pracowałem dobrych kilka lat jako edżajl skram monter kołczer - tu nie ma nic prócz hajsu.

A może to po prostu Ty byłeś ch*jowym edżajl kołczem i zwyczajnie trzeba było Cię zwolnić

Klasyczna odpowiedź, gdzie przy braku jakicholwiek kryteriów pozostaje jeno opinia. Nie uważałem siebie za takiego, klient był zadowolony, natomiast między klientem (zarząd, dyrekcja, high management) a pracownikami (team level) jest przepaść ... dużego typu.

Oczywiście Twoja wypowiedź ma się dość dobrze do argumentu ad populum - skoro skończona ilość devów/studentów krzyczy, że majster zły to wychodzi na to, że zły jest. Na tym edżajl żeruje jakby nie patrzeć - poparcie społeczne, tak dalej.

Przypomnę tylko, że nawet jeśli 9124809128409821948091284 ludzi twierdzi, że coś co jest głupotą jest dobre, to nie zmienia to faktu, że głupota to głupota.

I klasyka argumentacji ToTomki - na kim leży ciężar dowodu?

Ja tylko przedstawiłem hipotezę. Nie będę jej udowadniał, bo nigdy nie widziałem Cię w pracy. Jak dla mnie brzmi sensownie, bo generalnie prawie żadna osoba wdrażająca w firmach skrama jaką spotkałem nie wiedziała nic o jego implementowaniu i totalnie negowała wszystkie jego założenia.

Założyłeś temat we Flame'ie, wyrzuciłeś żale i obsrałeś temat osmarowując go tylko z jednej strony zamiast dogłębnie omówić (np. podając co przyniósł Agile wyrzuciłeś negatywy, ale zupełnie pominąłeś pozytywy - np. przesunięcie mikromenedżmentu przez menedżera na sam zespół. Z perspektywy pracownika to słabe, z perspektywy pracodawcy - dobre). Spodziewałeś się rzetelnej dyskusji kiedy sam zacząłeś od czegoś innego?

ToTomki napisał(a):

Ja tylko przedstawiłem hipotezę. Nie będę jej udowadniał, bo nigdy nie widziałem Cię w pracy. Jak dla mnie brzmi sensownie, bo generalnie prawie żadna osoba wdrażająca w firmach skrama jaką spotkałem nie wiedziała nic o jego implementowaniu i totalnie negowała wszystkie jego założenia.

Założyłeś temat we Flame'ie, wyrzuciłeś żale i obsrałeś temat osmarowując go tylko z jednej strony zamiast dogłębnie omówić (np. podając co przyniósł Agile wyrzuciłeś negatywy, ale zupełnie pominąłeś pozytywy - np. przesunięcie mikromenedżmentu przez menedżera na sam zespół. Z perspektywy pracownika to słabe, z perspektywy pracodawcy - dobre). Spodziewałeś się rzetelnej dyskusji kiedy sam zacząłeś od czegoś innego?

Fair enough Panie Kolego, nie ma złej krwi między nami, dzięki za rzetelną odpowiedź.

W sumie to nowy tu jestem i nie bardzo wiem gdzie co wrzucam także sry, ale nie mam naeabane 989 postów czy co;)

"Jak dla mnie brzmi sensownie, bo generalnie prawie żadna osoba wdrażająca w firmach skrama jaką spotkałem nie wiedziała nic o jego implementowaniu i totalnie negowała wszystkie jego założenia."

Ja uważam to samo! To wszystko to magia i czary, bez podstaw a matematyce, statystycem, probabilistyce itd. Ot przychodzi kołczer i pierdzieli swoje farmazony. Owszem, ci lepiej płatni z zagranicy gadali z sensem, natomiast ci z kraju to co, kumbaya my lord kumbaya, dla zespołów jedno, dla klienta drugie czyli - 2x wincy w czasie/2

To nie do końca religia.

Zamysł za Agile jest zacny, i wprowadzony dobrze podobnosi produktywnosc.

Problem jest taki ,że żeby go wprowadzić sporo pracowników musiałoby zmienić swoje nawyki. Nikt nie lubi tego robić, więc zmienią nazwę "tydzień" na "sprint", zrobią "daily" i powiedzą "jesteśmy agile".

Mam wrażenie że Twój post z wątku hejtuje źle wprowadzone agile, ewentualnie "agile z nazwy".

Riddle napisał(a):

To nie do końca religia.

Zamysł za Agile jest zacny, i wprowadzony dobrze podobnosi produktywnosc.

Problem jest taki ,że żeby go wprowadzić sporo pracowników musiałoby zmienić swoje nawyki. Nikt nie lubi tego robić, więc zmienią nazwę "tydzień" na "sprint", zrobią "daily" i powiedzą "jesteśmy agile".

Mam wrażenie że Twój post z wątku hejtuje źle wprowadzone agile, ewentualnie "agile z nazwy".

Tyle, że zobacz - co to jest "dobrze wprowadzony agile"?

Co, zarząd postawimy przed komisją ds. Zwinności i każemy majty w dół ściągnąć by zbadać czy przypadkiem nie mają agile w dupie?

Klient płaci, klient wymaga.

Wszelkie apologie wyznawców agile wsadzam pomiędzy fantastykę z Conanem i Kullem z Atlandyty.

Klient chce czegośtam od agile, np McKinsey to sprzeda za 1 000 000 $, to co tam żuczkowi gnojarzowi do gadania, czym ma być agile.

Przychodzi konsultant z niemiec, wcześniej pańcia z salonu kosmetycznego, odpytuje według excela pytanka by ocenić czy ekipa jest zgodna z ich wydumanym CMMI czy innym średnio-warzonym modelem.

Nie masz tu żadnej obrony bo zawsze ktoś może powiedzieć, żeś niezbyt zwinny, co już widziałem jako wymówkę dla wyjebki jakiejśtam ilości ludzi pod wycinkę żeby EBIDTA na koniec roku się zgadzała.

@Riddle: Największym rakiem jest to, że wprowadza się Agile tam, gdzie on wcale produktywności nie poprawia - bo zwyczajnie to tylko metodyka pracy. Metodyk jest wiele, każda ma plusy, każda ma minusy, trzeba dopasować odpowiednią do projektu ;)

@Fistandantilus:
Nie umiem zdefiniować Agile, ale jeśli ja widzę Scrum mastera, który prowadzi spotkania, zaraz terminem wyznaczonym na zrobienie czegoś przez KNF (bo inaczej kara) każde rysować zespołowi wyjścia z labiryntu na kartce papieru, jeśli scrum master prowadzi DAILY (na którym go nie powinno być, bo nie jest członkiem zespołu deweloperskiego), ogólnie jeśli milion różnych rzeczy - to jestem w stanie łatwo wykryć, że to jest zły Agile i w zasadzie zawsze widziałem tylko ten zły (chociaż raz mieliśmy SM, który wiedział co robi, ale w banku to próby wdrażania metodyki swoje, a dyrektorzy swoje). Zresztą wystarczy poczytać co tutaj ludzie na forum piszą żeby się zorientować, że ludzie nie wiedzą nic o podstawach mimo pracy w tej metodyce, np. standardem na forum jest wiara w to, że jak się wyczyści wszystkie taski wzięty na dany sprint to już można zamknąć laptopa i elo, bo nie można ściągać tasków z backlogu nie wziętych na sprint. Jeśli to jest standard, a to tylko jeden punkt, to te scrumy serio są źle wdrażane praktycznie wszędzie

ToTomki napisał(a):

@Riddle: Największym rakiem jest to, że wprowadza się Agile tam, gdzie on wcale produktywności nie poprawia - bo zwyczajnie to tylko metodyka pracy. Metodyk jest wiele, każda ma plusy, każda ma minusy, trzeba dopasować odpowiednią do projektu ;)

To pewnie też jest rakiem samym w sobie.

Ale widziałem projekty gdzie ludzie robili release co pół roku i nie było żadnej kooperacji z klientem, a zarzekali się że są agile. No żart.

Fistandantilus napisał(a):

Tyle, że zobacz - co to jest "dobrze wprowadzony agile"?

Taki w którym krótkie iteracje, kilku godzinne, dniowe, tygodniowe, max. dwutygodniowe dostarczają klientowi lub użytkownikowi jakichś wartościowych feature'ów, klient potem ocenia jakość produktu, i priorytetyzuje kolejne najważniejsze zmiany. Deweloperzy słuchają feedbacku i planują kolejną najmniejszą możliwą zmianę, która zawsze musi być zmianą która aktualnie ma największy priorytet dla klienta.

Są oczywiście inne kryteria, ale już tego najprostszego 90% zespołów nie spełnia.

@Riddle ok definicja do mniejszych projektów.

Owszem, dużo pracowników nie spełnia dowolnej definicji bo nie daje im się jej spełnić.
Jeśli osoba A ma płacone premie za ilość dowiezionych stories to nie ważne jak osoba B się stara - osoba A zawsze zasabotuje działania osoby B, inaczej straci premie do czego oczywiście nie dojdzie.
To jest przerabiane w wielu firmach, tyle że nie jawnie - kierownik obieca coś komuś na boku, jakiś strzęp ze stołu pańskiego, bo sam dostanie większą premię za KPI projektowe.

I tu scrum monter czy inny kołcz zrobi dokładnie 0 bo nie ma na nic wpływu, władzy i budżetu też nie ma.

Fistandantilus napisał(a):

@Riddle ok definicja do mniejszych projektów.

Owszem, dużo pracowników nie spełnia dowolnej definicji bo nie daje im się jej spełnić.
Jeśli osoba A ma płacone premie za ilość dowiezionych stories to nie ważne jak osoba B się stara - osoba A zawsze zasabotuje działania osoby B, inaczej straci premie do czego oczywiście nie dojdzie.
To jest przerabiane w wielu firmach, tyle że nie jawnie - kierownik obieca coś komuś na boku, jakiś strzęp ze stołu pańskiego, bo sam dostanie większą premię za KPI projektowe.

I tu scrum monter czy inny kołcz zrobi dokładnie 0 bo nie ma na nic wpływu, władzy i budżetu też nie ma.

Wiele zasad Agile jest tak na prawdę łatwo wprowadzić, tylko nie można na to patrzeć przez pryzmat aktualnych rozwiązań w zespole.

Tak, to religia. Tak jak w wielu innych religiach mamy kapłana (scrum mastera, agile coacha), ceremoniał (cykliczne spotkania), budowanie strachu i poczucia winy (estymaty, niedowożenie, złe estymowanie), które sprawiają, że to wszystko trzyma się kupy.

Czemu tak jest? Bo jak gdzieś może wygrać religia to wygrywa, inne metodologie pracy nie dostarczają takich wrażeń, więc giną,

Jasne, że to religia. Przecież te przekładanie karteczek, kajanie się przy tablicy w kółeczku, albo rysowanie obrazków na retro to obrzędy. Scrum master to kapłan.

Religia wymyślona w celu przymuszenia programistów do robienia jak konie w kieracie.

"Religia wymyślona w celu przymuszenia programistów do robienia jak konie w kieracie."

Niekoniecznie. Moim zdaniem całkiem prawdopodobne jest to, że w momencie tego Agile summit czy jak to nazwali grupa osób która pracowała głównie nad custom made software (w przeciwieństwie do COTS) miała obiekcje co do skuteczności metod kaskadowych (waterfall, spirala, V, parallel), a jako że prawdopodobnie byli bardziej techniczni niż procesowi czy biegli w mowie i piśmie to napisali sobie takie wysokopoziomowe hasełka, z którymi łatwo się identyfikować, natomiast nie posiadają żadnego znaczenia, tylko niekończące się interpretacje.

W porzadku. Idźmy dalej - nie pamiętam już kto otworzył certyfikacyjną puszkę harna... a nie, pandory. Może Schwaber, może Sutherland, może ktoś inny. Jak tylko osoby wyczuły w tym pieniądz to zaczęli to promować i sprzedawać.

Teraz tak, obecnie scrum to biznes przede wszystkim. Agile nie wiem bo to słowo nie posiada jednolitego znaczenia. Na certyfikatach robi się duże pieniądze - zobaczcie koszta akredytacji na trenera Scrumorg czy alliance czy innej, porównajcie z kosztami szkoleń, wyliczcie marżę nawet i 50% od ceny rynkowej.

Krótka analiza ilości certyfikatów Scrum org wskazuje, że PSM 1-3 ma więcej ludzi niż wszystkich innych certyfikatów razem wziętych.

Scrum stoi na PSM i niczym więcej moim zdaniem. Więc naturalne, że muszą powstawać coraz to nowsze opracowania, książki, tak dalej na temat Scrum i Scrum Master, bo na tym się zarabia.

Byłem na kilku szkoleniach Scrum org, doświadczenia fajne(ogólnie miło i koleżeńsko), tyle że wiedza jest wysokopoziomowa, a jak kto zapyta o szczegół techniczny to trener się poci. No chyba, że akurat wie albo zrobi unik i powie, że o tym kiedy indziej albo to nie jest w zakresie kursu.

Natomiast to nie ma żadnego znaczenia. Widzimy obecnie wzrost popularności SAFe który wypiera Scrum jak i wzrost popularności Kanban które to podejście nie ma tak dużego narzutu ideologicznego.

W sumie - osobiście nie słyszałem by kto narzekał na kanban. Owszem, niektóre implementacje Kanban jak Flight Levels Leopolda czy KMM od Andersona mi osobiście wydają się napompowane i przekombinowane na siłę, natomiast sam proces jest prosty jak 1 2 3.

Niektórzy (w tym biznes) lubią się nonstop porównywać. Więc są te wszystkie abstrakcyjne metryki typu story point, velocity i potem można sobie robić wykresiki, ładnie będą wyglądać na prezentacjach. Tylko to nie ma sensu, bo sam story point jest jednostką abstrakcyjną, której nie da się porównywać między zespołami, bo każdy zespół może mieć swoją definicję story pointu. Dla mnie scrum to jest niepotrzebna komplikacja pracy, sam Kanban board i część spotkać spokojnie by wystarczyła. Te wszystkie refinementy i planningi to często strata czasu i energii, bo koniec końców estymaty mogą okazać się złe, albo tickety źle opisane, więc i tak będzie trzeba się o coś dopytywać. Nie mówiąc o jakichś daily, które często wyglądają jak spowiedź i rzadko kiedy przekazywana jest jakaś wartość, co kto zrobił. Dla mnie wystarczyłyby spotkania dwa razy w tygodniu, żeby skoordynować pracę na kilka dni do przodu, a tak to zdzwaniać się, kiedy będzie taka potrzeba.

Niedawno stworzyłem wątek z pytaniem, czy dobieracie nowe tickety do sprintu, kiedy wszystkie już zostały zrobione. Wielu pisało, że tak co przeczy idei Scruma i sprintów i pokazuje, że zwykły Kanban board z regularną i systematyczną pracą wystarczyłby, a ta cała reszta abstrakcyjnych mierników jest co najwyżej po to, żeby zadowolić biznes i mieć bat na programistów w postaci fancy wykresików na prezentacjach.

Problem w tym, że:

• programiści często mają za mały kontekst biznesowo-projektowy i dają sobie wchodzić na głowę każdemu, kto im powie, jak mają pracować (mentalność najemnika, a dobrze widzieliśmy, co się dzieje, jak najemnik uzyskuje świadomość i zaczyna się buntować. Są reperkusje. Bo najemnik musi znać swoje miejsce, albo każą mu spadać).
• scrumiści z kolei niekoniecznie będą wiedzieć cokolwiek o wytwarzaniu oprogramowania. Będą operować wyuczonym bullshitem. Przynajmniej na początku swojej kariery. Potem sami będą umieli wymyślać własny bullshit i będą myśleli, że są dobrzy, ale w rzeczywistości będą operować na easy mode i spychać odpowiedzialność gdzie indziej.
• sprzedawcy będą sprzedawać. To działa jak piramidka finansowa. Zakazić jak największą liczbę osób ideą po to, żeby kupowali kursy, certyfikaty po to, żeby później sami mogli robić szkolenia i rozdawać innym certyfikaty.

Innymi słowy sprzedawcy Scruma wlewają wiedzę cwaniaczkom, a cwaniaczki cisną nerdów i wyciskają z nich kod. A nad wszystkim czuwa biznes, który sypie groszem, żeby każdy był zadowolony.

Tak sobie myślę, że scrum stał się popularny, bo dotyka dwóch punktów ważnych dla kadry zarządzającej:

• przedstawianie wszystkiego do postaci numerycznej a.k.a excela (bo inaczej nie ogarną): estymaty, burndown chart, procent skończonych tasków
• ciężki i stabilny proces, gdzie wiedzą co się dzieje: estymaty, określone spotkania

Najważniejszą cechą agilu jest myślenie o procesie w taki sposób, że nie jest to prawda objawiona i może się zmienić, jeśli team uzna, że coś to da. I teraz warto sobie zadać pytanie: jak często w firmie możesz podyskutować z górą o tym, że scrum jest be i chcesz coś innego? Scrum daje ułudę, że team jest odpowiedzialny za proces, gdzie w rzeczywistości jest na odwrót

@slsy Odkryłeś bardzo istotną rzecz. Scrum nie mając żadnych kryteriów jest tym co chcesz by był.
Teraz niektorzy starają się badać Scrum jak jakieś religijne teksty, odkrywać meandry metafor, myśli autorów, nawiązań do innych pism religijnych - g**no.
Nic tam takiego nie ma. Ot dwóch mężczyzn kiedyś napisało, że Scrum Master to Servant Leader potem True Leader (gdzie to nic nie znaczy) i zarabiają na tym.

Ludzie naiwni wierzą w zbawczą moc Scrum - devy bo Scrum obiecuje co napisałeś, a Scrum Masters bo dobrze płacą.

Mądry decydent używa Scrum jak zanęty - Devi chcą Scrum, mamy, zapraszamy, jest pracownik jest kim wykonać pracę.
Jak pracownikowi przestaje się podobać nieustający akord robienia w Sprintach to można go zwolnić, by nie obniżał morale innych devów. Powie się, że sam odszedł, bo wolał jednak waterfall.

@Fistandantilus: Już gdzieś zapytałem ale nie odpisałeś. To jakia metodyka zarządzania projektami jest wg ciebie dobra ?

@Schadoow Możliwe, nie zauważyłem.

Poniżej dobry artykuł na temat metod prowadzenia projektu.
https://it-consulting.pl/2011/03/22/co-wybrac-czyli-cykl-zycia-projektu-tworzenia-oprogramowania/

Która metodyka jest dobra jest więc determinowane przez kilka parametrów projektu.
Do tego należy jeszcze oszacować niepewności aleatoryczne i epistemiczne.

Fani Agile nie czytają tego typu artykułów, raczej preferują czytać o emocjach w zespole czy co zrobić jak kierownik zwalnia kolegę z zespołu.

@Fistandantilus: Ale to co wysłałeś jest mi znane. Chodziło mi bardziej które metodyki uważasz za dobre. Bo jedziesz po scrumowych, tam chyba gdzie indziej smialeś sie z SAF'e.

Btw w jednej organizacji w ktorej pracowałem sprawdził sie genialnie. Np pracowałem tam z przerwami 6lat i byłem świadkiem tradycyjnego waterfalla i przejscia na SAFe (2,5r w SAF) i z takich plusów to time to market z 12m do 1-3m, ograniczenie błędnych zamówień prawie do 0, ograniczenie problemów z przestojami i wykrywanie zaleznosci na wczesnym etapie planowania.

Dlatego jestem ciekaw którę metodyki wg ciebie są uznawane.

Np taki ASPICE wymaga w c**** wiecej spotkań, papierologi, osób do ogarniania samego procesu a nie widziałem żeby ktoś za bardzo narzekał.

@Schadoow To moja tylko preferencja - Theory of Constraings, TameFlow, ogólnie Flow jako praca ciągna, z ustalanymi przez zespół politykami których się trzymają. Na to nakładamy bramki kontrolne, milestones, liczymy bufor. Do tego praktyki ITIL i DevOps.
Tego typu podejście dla mnie sprawdza się w projektach developmentu custom software, gdzie jest względnie dużo zmienności, a gdzie też potrzebne jest utrzymanie.

Do projektów prowadzonych w dużej skali dobrym wyborem będzie SAFe uważam.

Scrum jako "metodyka" organizowania pracy jest zbyt luźny, wielu rzeczy nie uwzględnia, za to względnie dużo rzeczy narzuca - role, wydarzenia, konieczność korzystania z backloga produktu i sprintu, mętne estymaty w niematematycznych story points z których nic nie wynika i dużo więcej.

Owszem, śmieję się z fanatyków Scrum bo są jak apologeci religijni - mają dogmat i przesuwają ciężar dowodu na oponenta. Czyli np ktoś kto krytykuje Scrum ma wykazać, że Scrum nie działa, gdzie nauka nie zajmuje się udowadnianiem, że czegoś nie ma. Fanatycy Scrum stosują presupozycje, że Scrum po prostu działa i nie ma z tym dyskusji, a jak coś Tobie nie działa to Twoja wina i robisz coś źle.

Co, nie wiadomo.

Stąd to dziwne połączenie zarobków fanów Scrum około 12-15k netto + vat na średniej, brak kryteriów by coś stwierdzić true/false, odgrywanie roli bycia bardzo ważną osobą, bycie ograniczonym do team level oraz brak wiedzy na temat działania biznesu, robienia pieniędzy czy prowadzenia prac dają w efekcie obraz takiego chłopskiego filozofa który przeczyta Scrum Guide, Agile Manifesto i już poznał wszelkie prawdy jakimi rządzi się biznes.

Przecież to oczywiste. Jak nie działa, robisz to źle.

Z SAFe nie ma śmiechu - tam się robi pieniądze.

Ejże, ejże, sekta nie religia.

Religia ma już jakiś kapitał.

Fistandantilus napisał(a):

Nic tam takiego nie ma. Ot dwóch mężczyzn kiedyś napisało, że Scrum Master to Servant Leader potem True Leader (gdzie to nic nie znaczy) i zarabiają na tym.

Dlatego droga do unicestwienia Scruma to wrzucenie tam lewaków i zrobienie większego diversity. Wtedy Scrum Masterzy i Servant Leaderzy czy Product Ownerzy polecą pierwsi za skojarzenia z niewolnictwem. Plus nawiązywanie do agresywnego męskiego sportu, jakim jest rugby. Nie mówiąc już o tym, kto to wymyśla te wszystkie Scrum i Agile - spójrzcie sobie na zdjęcie z Agile Manifesto - sami biali mężczyźni xD
https://agilemanifesto.org/
https://siamchamnankit.co.th/history-some-pictures-and-pdfs-of-the-agile-manifesto-meeting-on-2001-a33c40bcc2b

Fistandantilus napisał(a):

Do projektów prowadzonych w dużej skali dobrym wyborem będzie SAFe uważam.
(...)
Z SAFe nie ma śmiechu - tam się robi pieniądze.

xD Przecież SAFe to większy rak niż Scrum, który krytykujesz

Pracowałem już w wielu projektach, w różnych firmach. Najlepiej, jak podejście jest nie nazwane i panuje po prostu zdrowy rozsądek. Jak już pojawiają się święte frameworki, to 1000x lepiej jest trafić tam gdzie jest Scrum, niż SAFe. Różnica jest taka, że w tym pierwszym jeszcze jako tako można mieć wpływ na sposób pracy, a w tym drugim jest się tylko trybem. I jedno podejście i drugie nie działa, różnią się tylko ilością dodatkowej biurokracji, bezsensownych spotkań i ról. A im tego mniej, tym lepiej

@NightDev: Powodzenia ze zdrowym rozsądkiem przy projektach wieluletnich gdzie np pracuje ze 150 osób w developmencie + biznes I zarządzanie tym, dodatkowo biznes jest wieloaspektowy i wiele zmian musisz analizować pod kątem nie tylko twoich lokalnych wymagań biznesowych ale wpływu na innych.

Jak ktoś pisze, "jak podejście jest nie nazwane i panuje po prostu zdrowy rozsądek" to oznacza, że robił systemy wielkości notatnika co najwyżej.

Ot przykład że to nie zadzaiała. Masz projekt gdzie wszystkich zaangażowanych osób masz 200 osób weźmy rotacje 10% rocznie to ci daje 20 osób co roku które musisz wdrożyć w waszą autorską metodykę. Czyli co miesiąc ktoś spala czas tylko na to xD.

Wdrażanie SAF'e ma sens w ogromnych systemach w których nie możesz frywolnie wprowadzać zmian. Tj masz dużo zespołów które są odpowiedzialne za inne części systemu. I musicie zgrywać wdrażanie zmian. Dodatkowo w systemach gdzie masz wielu "PO" pozwala na łatwiejsze zarzązanie (zmusza ich do kłótni miedzysobą tylko :p).

@Schadoow: Tak się składa, że przeżyłem kilka akcji gdzie firma myśląc że SAFe to rozwiązanie, wycofywała się z tego rakiem po 1-2 latach. Poza tym, te nazwy to tylko zaciemnianie i wyłączanie myślenia, większość i tak nie potrafi się zastosować do "metodyki" i robi logiczne fikołki żeby tylko "dostosować pod siebie" - to jeszcze gorsze niż własna "nie nazwana metodyka". Wystarczy trochę popatrzeć na ogłoszenia "BigTech" żeby zauważyć że jak jeszcze czasami się pojawi w wymaganiach "Scrum / Agile", tak skalowalnego g*** jak SAFe próżno szukać

adżajl sradżajl :P

@LukeJL Agile/Scrum już same się zjadają od środka.
Inflacja wartości certyfikatów - więcej Scrum Masterów którzy chcą 12k+, większa konkurencja.
Osoby te rzadko posiadają realną wiedzę więc wymyślają czary jak jakiś agile mindset, którego nie potrafią skwantyfikować ani sparametryzować.
Każda rozmowa z innymi agile people która nie skutkuje pracą to wpis do książeczki, kogo w razie jak dana osoba będzie rekrutować odwalić od razu z biegu.
Czyli mamy dużo mało wykształconych, za to gniewnych i łasych na kaskę ludzi.
Popcorn mam pod ręką.

Scrum ma sensowne założenia, tylko to powinno polegać na zmianie tego, w jaki sposób jest naprawdę zorganizowana praca.

A jeśli polega na:

• pakowaniu waterfalla w sprinty
• nazywania chaosu "samoorganizującym się zespołem"
• skupiania się na ceremoniach i zabawach (planning poker XD)

To przestaje to spełniać swoją rolę.

Poza tym ludzie powinni się ze sobą sensownie komunikować, bo jak nie ma komunikacji i porozumienia, tylko są jakieś domysły czy brak zrozumienia jednych przez drugich, to żaden Scrum nie pomoże.