Z nadejściem Agile wiązały się duże nadzieje. Wszelkie szkolenia i manifesty obiecywały przysłowiowe złote góry. Waterfall miał być zły, dostarczać biznesowi coś, czego już nie chciał albo nigdy nie chciał, zaś metodyki zwinne wprowadzały nas w świat, w którym klienci są zadowoleni, a produkt powstaje przyrostowo…
W większości przypadków obietnice Agile okazały się kłamstwem.
Widziałem projekty. Wielkie projekty. Małe projekty. Długie i krótkie. Zabite przez Scrum.
Przed
Jak wspomniałem, w narracji Agile pojawia się omal zawsze manicheizm, czyli walka dobra ze złem. Dobry Agile przybywa nas zbawić od złego Waterfalla. Tyle tylko, że w projektach, w których pracowałem ja i moi współpracownicy nie było mitycznego Waterfalla. Zamiast niego były jakieś nieustrukturyzowane próby zarządzania projektami. Bez nazwy, bez dziesięciu przykazań jak działać, za to z doświadczeniem i mądrością organizacji, które te projekty organizowały. Co ciekawe te metodyki ad hoc działały. Nie były sformalizowane, ale przynosiły wartość przedsiębiorstwom.
W żadnym „pre-Agile’owym” projekcie, o którym słyszałem nie była problemem nadmierna analiza, czy kurczowe trzymanie się planu, jakie rzekomo miało miejsce w Waterfallu. Być może obserwowałem już inny świat, niż twórcy metodyk zwinnych, może był to jakiś złoty środek, moment przejściowy – tego nie wiem.
Transformacja
Początek implementacji Agile w kraju, w mojej percepcji, zaczął się od szkoleń. Robiły wrażenie. Na warsztatach wszystko się udawało, teoria brzmiała rozsądnie. Wszyscy przecież chcieliśmy zadowolić klientów i dostarczać wartość biznesową od pierwszwego sprintu. To szlachetne pobudki.
Wykresy wyglądały ciekawie i idea oglądania postępu pracy w czasie rzeczywistym była kusząca – technokratyczna i nowoczesna. Estymacja nie czasu, a złożoności wydawała się odsuwać od nas odwieczną czarę goryczy – podawania czasu, jaki zajmie nam wykonanie zadania. Byliśmy dość entuzjastyczni.
Dodam, że w lokalnej, polskiej specyfice Agile oznaczał omal zawsze Scrum. Moje uwagi krytyczne dotyczą głównie, jeśli nie wyłącznie tej metodologii.
Efekty
Dość szybko okazało się, że Agile jest trochę jak komunizm – idee brzmią pięknie, ale w praktyce już tak cudownie nie jest. Co więcej zarzuty, że Scrum nie przynosi korzyści bywają również krytykowane na sposób sowiecki – „to nie był prawdziwy scrum”.
By nie pozostać gołosłownym, co do problemów, przejdę przez kolejne dysfunkcjonalne elementy…
Estymacja
Estymacja oderwana od czasu i ograniczona do liczb z ciągu Fibonacciego stała się rytuałem nużącym i w istocie bezużytecznym. W większości zespołów, z którymi pracowałem można było bez zastanowienia „wycenić” zadanie. W jednym z nich w zasadzie wyceny sprowadzały się do 3 i 5. Mimo tego poświęcało się zawsze mnóstwo czasu na wyjaśnianie natury zadań.
We wszystkich zespołach wyceny różnicowały się szybko do 3-5-8. Osiem zwykle zaś było rozbijane na mniejsze zadania. De facto zadania były małe albo duże, lub też za duże – i wtedy przekształcane w małe albo duże. Mnóstwo na to czasu zwykle było marnotrawione, a trafność estymacji “pojemności” sprintu i tak znikoma.
Wykres spalania i planowanie sprintu
Wykres spalania to chyba najbardziej zabawna rzecz w Scrumie. Prawdę mówiąc w żadnym zespole nie widziałem jeszcze, by wykres choć odrobinę przypominał to, jak wyglądać powinien. Albo nic nie jest „spalane” przez tydzień, a potem nagle spada. Albo rośnie, bo nowe zadania są dodawane do sprintu. Albo znów jest stałą, bo praca jest wykonywana, ale zadania nie są zamykane z powodu blokad.
Oczywiście powodem niewydolności jest binarność statusu zadań. Zadania nie mają natury „do zrobienia” albo „zrobione”. Jeśli w życiu zaplanujemy sobie w przyszłym roku kupić mieszkanie, stracić 10 kilo, zrobić kurs Vue.js i kupić psa, to o ile to ostatnie może odbyć się szybko, to kolejne zadania będą na rocznym wykresie nieustannie linią prostą – aż do momentu zakończenia. Co przecież przeczy celowi samego wykresu – ilustracji postępu.
Planowanie sprintu też z kolei nigdy się nie udaje. Jest to pochodna wadliwych estymat, ale też złożoności procesu wytwarzania oprogramowania, którą próbuje się kolanem dopchnąć i ukryć. Jacek robi średnio 12 story pointów na sprint, Marek 10, Łukasz 5, a Maks 6. Jacek poszedł na urlop na 2 tygodnie. Wszyscy zrobiliby 33. Zakładamy, że odpadnie 8.25, bo przecież nie będziemy wyliczać velocity każdemu z osobna. I co? 3.75, czyli małe zadanie nie zmieści się w sprincie, choć pozornie powinno. Nie mówiąc już o tym, że Łukasz jest praktykantem i bez Jacka robi 3 zamiast 5 story pointów, a Maks 4 zamiast 6, bo jest juniorem i też Jacka potrzebuje. Sprint nie dojedzie.
Bezmyślna zmienność
Klient powinien móc zmienić kierunek, w którym idzie projekt, jeśli istotne parametry biznesowe uległy zmianie. To bez wątpienia zaleta metodyk zwinnych, ich duża przewaga. Jednakże w wielu przypadkach pojawia się bezmyślna zmienność. Zamiast rozpocząć od prototypu, od rysunku, zaczyna się od pełnej implementacji, mając świadomość, że wszystko może być następnie zmienione, bo działamy zwinnie.
W jednym z projektów Agile coach tłumacząc ideę zwinności narysował zespołowi kolejno hulajnogę, skuter, motor i samochód. Narysował, popatrzył i powiedział – oto zwinność, oto iteracyjny rozwój. Cóż jednak, gdy od początku wiemy, że chcemy zbudować samochód? Czy naprawdę budowa hulajnogi na początku pomaga nam w budowie auta później? Czy nie jest wręcz przeciwnie? Czy nie będziemy próbowali wykorzystać amortyzatorów z motocykla do projektu samochodu, narażając użytkowników na niebezpieczeństwo?
Nie muszę chyba dodawać, że powoduje to marnotrawstwo zasobów i frustrację programistów, których praca jest wyrzucana do kosza przez kolejne miesiące i pory roku…
Trudne początki
Założenie, że będziemy dostarczać wartość biznesową od pierwszego sprintu jest całkowicie idealistyczne. Zawsze, ale to zawsze konieczne jest przygotowanie choćby pobieżnego planu, wykonanie pewnych czynności wstępnych i początkowa organizacja. Szczególnie naiwne jest twierdzenie, że da się „dostarczać od razu” w dzisiejszych czasach, gdy często konfiguracja infrastruktury na chmurze, konteneryzacja i projekt architektury średniej wielkości projektu może zająć tygodnie.
Spotkania
Czasami trzeba się spotkać. Przeważnie jednak trzeba się raczej skupić i zastanowić, niż spotkać. Spotkania są moim zdaniem przekleństwem Scrum. Widziałem spotkania, na których dwadzieścia osób obserwowało jedną, która wpisywała do Jiry zadanie. Widziałem spotkania, na których połowa zespołu milczała. Widziałem takie, gdzie dwadzieścia procent gapiło się w telefony.
Spotkania mają to do siebie, że często nie dotyczą bezpośrednio uczestników. Pojawia się wtedy nuda. Nuda oraz marnotrawstwo czasu. Dlaczego pracownik, który na spotkaniach spędza 20% swojego czasu, a z tego połowa jest marnowana, ma być efektywny po spotkaniu? Skoro nie szanuje się jego czasu, to czy nie zabija się jego nawyku szanowania czasu pracodawcy, klienta?
Oczywiście rozwiązaniem powyższego jest tworzenie spotkań w małych grupach. Ma to jednak miejsce rzadko i naturalna jest tendencja do gromadzenia dużej ilości osób.
O spotkaniach można by pisać wiele:
- zabijają produktywność programistów wyrywając ich ze skupienia,
- często stają się bezproduktywną dyskusją o niczym, o ile nie ma agendy i dobrego prowadzącego,
- organizowane za wcześnie, za późno, zbyt długie, w okolicach obiadu – potrafią uczestnikom odebrać sen, radość i entuzjazm
- zbyt częste – rujnują poczucie produktywności, sensu pracy, irytują
Rezultaty
Wbrew początkowemu entuzjazmowi na własne i cudze oczy przekonałem się, że implementacja Scrum w wielu, chyba nawet w większości przypadków, nie podniosła efektywności zespołów i zadowolenia klientów, a chaos przypudrowany rytuałami, spadek wydajności i opóźnienie w dostarczaniu produktów.
Nie chciałbym sprawić wrażenia, że odrzucam ideę zwinności, która nadal wydaje się bardzo sensowna i kusząca. Jednakże Scrum wydaje się zabijać – zabijać entuzjazm, zabijać zespoły, projekty. Moje przelotne doświadczenia z Kanban pokazują, że Scrum może być ślepą uliczką, a jednocześnie warto nie obrażać się na metodyki zwinne.
Więcej o metodyce Scrum w mojej książce – Programista. Przewodnik po zawodzie.
Jakie ty piszesz głupoty!! Pracuje w Holandii od 12 lat i od 6 lat implementuje agile w wielkich organizacjach m. in. Ministerstwach, bankach. ING wprowadziło agile jako jedno z pierwszych i jest podawany jako wzór działania firmy, całej firmy bo agile trzeba zaimplementować po całości a nie tylko działy IT. To co widziałeś to jakaś nieudolna transformacja, prowadzona przez i z ludźmi, którzy nie wiedzą po co to robią. Każda transforacja, w której ja brałam udział była udana i trwa do dziś.
To co widziałem sam i o czym mi opowiadano, to z pewnością przykłady porażek. Jak one w szczegółach przebiegały opisuję w tekście. Jeśli da się “transformację” przeprowadzić lepiej i coś robiliśmy źle – chętnie się dowiem, jak to usprawnić. Proszę o konkrety, o odniesienie się do przykładów.
To, że coś jest wprowadzane od wielu lat nie oznacza, że cudownie działa. Przykład instytucji, która podałaś jest najlepszy. Czy rozmawiałaś z ludźmi, którzy pracują w Scrumie, czy tylko widziałaś przypudrowane wyniki podane przez Scrum Master lub Agile Coach. Kalkus opisał dużo prawdy rzeczywistej, a nie upudrowanej.
Gdy od początku wiemy że chcemy samochód i jesteśmy powiedzmy fabryka FSO a auto to prosty projekt. Wtedy mówimy ze to co najmniej 12 storisów a nie jedna jak w przypadku hulajnogi a workload to 350 storypointow. Problemem tutaj są debile którzy niewiele wiedzą o faktycznym technicznym wysiłku jaki musi być zrobiony i niektórzy twierdzą że story to tak średnio jeden tydzień pracy dla jednej osoby i myślą że to jednoznacznie znaczy że może jako 1 story zakwalifikować misję na Marsa. Może jeśli jest kosmitą który ma ufo. Problemów jest znacznie wiecej. SCRUMi formalizowany agile to bardziej religia z głupimi ceremonialami programisty którego trzymali w piwnicy i chciał się bawić w swoje własne spotkania gdzie może pogadać o dupie Marynie (impacty na cały team zdarzają się raz na ruski rok) i potrzymać tokena 😂 są jednak też i zalety. Nie ma biasu tak wiele bo nie ma jednego project managera który zwykle jeśli jest debilem to potrafi położyć i skłócić cały zespół ale problem z kolei jest często choć nie zawsze że SCRUM masterem który chciałby więcej coś znaczyć niż być tylko sekretarka zespolu
To o czym piszesz to wszystko prawda, jest wiele anglojęzycznych artykułów na ten temat. Na Quora jest ponad 100 odpowiedzi na pytanie “Why developers hate Scrum?”
Ale nie o tym chciałem… Otóż Agile zaczął zabijać ludzi naprawdę, a to za sprawą Boeinga, który wdrożył zasady Agile w projektowaniu samolotów. Podobno jeszcze rok temu na szkoleniach Agile podawano “klasyczny” przykład, jak Boeing “edżajlowo” dopasował nowe silniki do starego samolotu i powstał 373MAX, za ułamek kosztów projektu maszyny budowanej od podstaw. Dziś wiemy, że było to zbrodnicze oszustwo: zginęło ok.350 osób, firma poniosła dziesiątki miliardów USD strat i zmaga się z bezprecedensową katastrofą wizerunkową. Niech to będzie ostrzeżeniem dla wierzących w cudowną moc “edżajla”.
Wszyscy nietechniczni w agileu doprowadza zespół prędzej czy pozniej do katastrofy bo Agile nie kontroluje faktycznej jakości dostarczonego produktu i ślepa wiara w kilka punktów z manifestu w końcu kogoś zabije przez ślepe klepanie agileowych ‘swietosci’
To, że wam się udała transformacja, nie znaczy wcale, że była dobra dla zmienianej firmy. Pracuję w firmie, która przeszła taką transformację kilka lat temu. Budowane przez dziesięciolecia know-how wywalono do śmietnika, rozwiązano dobrze działające zespoły ludzkie, wprowadzono plemienną strukturę organizacyjną opartą przeważnie na Scrumie. Kulturę biznesowa zastąpiono kulturą strachu – inaczej nie dałoby się wdrożyć tego szaleństwa. I tak, to jakoś działa, ale tylko dzięki desperackim wysiłkom ludzi znających biznes i starających się utrzymać całość w ruchu. Niestety, kadra nie wytrzymuje tego psychicznie, wielu odeszło, część usunięto, bo nie popierali nowej polityki. W rezultacie – twarde liczby pokazują zbliżający się upadek firmy. W moim odczuciu za dwa lata bęfzie pozamiatane.
@LNA – Jak czytam to co piszesz o wdrożeniu Scrum w firmie w której pracujesz, to mam wrażenie jakbym czytał o swoim byłym pracodawcy. Wszystko tak świetnie pasuje, że się zastanawiam, czy przypadkiem to nie ta sama firma 😀
Intrygujący i mroczny artykuł oraz ciekawe dyskusje w komentarzach. To czego się nauczyłem o Scrum, projektach w przeciągu ostatnich 2 lat, to to, że nie ma czegoś takiego jak zła metoda obsługi projektu. Można jedynie dobrać niewłaściwą metodę do potrzeb projektu i tym powoli zabijać…
Kiedy widzimy, że przychodzi nowy projekt do realizacji, analizujemy:
1. Co jest do zrobienia?
2. Kogo projekt potrzebuje?
3. Czego projekt potrzebuje?
4. Jakie już teraz widzimy ryzyka i czy potrafimy je obsłużyć?
Na tej podstawie, dobieramy metodą obsługi projektu. Dla mnie waterfall też jest spoko, jeśli tylko projekt go potrzebuje.
Największym zagrożeniem dla każdego projektu są moim zdaniem:
– niewłaściwa komunikacja w zespole i z klientem
– nierozumienie przez zespół tego co tworzy
– dawanie zobowiązań np. terminowych czy funkcjonalnych klientowi bez analizy wymagań.
Tyle ode mnie, tak w skrócie, bo to temat rzeka 🙂
Agile to nie spotkania, to nie nomenklatura, to nie jedyna słuszna droga. Agile to ludzie i od nich zależy czy coś jest stosowane dobrze czy źle. Scrum jest łatwy w rozumieniu a trudny w implementacji. Scrum to nie idee tylko empirycznie udowodniona rama postępowania. Trzeba znać jej zasady i rozumieć sens.
Każde podejście (nie tylko do pracy) można wypaczyć, zepsuć a potem powiedzieć, że nie działa. Można wziąć młotek i wbijać stalową śrubę w żelbetonowy słup i powiedzieć, ze młotek nie działa. Równie dobrze można wziąć wyspecjalizowany skalpel i próbować nim ukroić chleb. No skalpel jest bez sensu!
Podejście zwinne zakłada częstą inspekcję tego co się robi/wytwarza. To jest clue zwinności. To weryfikacja czy to co robimy jest na pewno uzasadnione, czy założenia się nie zdezaktualizowały. To sprawdzenie czy nasze myślenie nie zaczyna się różnić od myślenia klienta. To synchronizacja. Po to są spotkania, rozmowy, ustalanie, doprecyzowanie. Na żądanie i to najczęściej zespołu developerskiego.
Często-gęsto zdarza się, że ludzie nieznający pojęcia “agile” pracują agile i wypracowali swoje świetne, autorskie i jednak zwinne podejście do pracy. Transformacja w świadomą organizację zwinną polega na tym, że organizacja chce być zwinna i tę zwinność rozumie i ją wspiera i jak najbardziej bazuje na swoim know-how.
Odniosę się jeszcze do przykładu z hulajnogą/deskorolką. To bardzo dobry przykład, ale specjalnie w tym tekście pokazany prześmiewczo. Zwinność (i scrum) zakładają dostarczenie rozwiązania problemu najszybciej, iteracyjnie i najniższym kosztem. Przy problemie “chcę dojechać z punktu A do B” takie rozwiązanie (deskorolka) ma jak najbardziej sens (iteracje to modyfikacje założeń przez klienta: chcę kierownicę (hulajnoga), chcę lepszy napęd (rower), chce się mniej męczyć (motorower), chcę jeździć szybciej i bardziej komfortowo (samochód)). Jeśli klient mówi “chcę samochód” a dostarczamy deskorolkę czy hulajnogę, to bez znaczenia jaką “wiarę” wyznajemy – po prostu nie słuchamy klienta i dajemy klientowi to czego on nie chce.
I faktycznie źle wdrożony scrum i źle przeprowadzana (tak, czas nie dokonany) transformacja niszczy wydajność, entuzjazm i generuje frustrację. Jeśli stosuje się jakiekolwiek rozwiązanie, czego się nie rozumie, to nic dziwnego.
Ludzie idą da łatwiznę, szukają tutoriali na YT, bo nie chce im się myśleć, chcą iść na skróty, bazować na czyjejś wiedzy bezkrytycznie. To samo tyczy się stosowania scrum.
Przykładem tego, jak wiele organizacji nie rozumie zwinności a później mówi, że “zwinność (czy scrum) zabija”, albo “scrum nie działa”, jest np. próba adaptacji tzw. modelu Spotify, do swojej organizacji, bez zrozumienia skąd się wziął, dlaczego powstał i w jakiej kulturze jest osadzony.
Scrum to marketing, bo nie działa, a przecież miał działać!
@Marcin Wszystko się zgadza, zwinność powinna oznaczać zdolność do adaptacji w zmiennych warunkach, płynność zasad, optymalizację zasobów itd.. Jednak występuje tu swoisty paradoks, bowiem korporacje rozumieją Agile jako uniwersalne lekarstwo na wszelkie problemy – bo tak pisał Gatner, lub tak mówiono w Davos – i dokonują siłowej transformacji w to, co niektórzy uważają za zwinność, tj. wspomniany model Spotify, Scrum lub Kanban na każdym stanowisku pracy. Oczywiście jest to zaprzeczeniem zwinności w naszym rozumieniu; stąd mój wniosek, że wdrożenie kultury Agile na poziomie korpo zawsze staje się jej zaprzeczeniem, ergo – prawdziwa zwinność istnieje tylko, jeśli jest spontanicznie implementowana na najniższym poziomie, przez zespoły wykonawcze. Do tego nie jest potrzebny Scrum, nie są potrzebni Scrum Masterzy ani inni przeszkadzacze. Wystarczy satysfakcja z dobrze wykonanej pracy i przyjemność z jej wykonywania. I tak rozumiem ten artykuł.
Po pierwsze, Scrum nie jest zwinny. Scrum jest uciążliwym, sformalizowanym procesem, który ignoruje ludzi i ich potrzeby, a zajmuje się jedynie kontrolą i potrzebami nietechnicznego kierownictwa.
Tylko informatycy dają się sterroryzować Scrumowi, ponieważ są zazwyczaj introwertykami i skupiają się na wykonywaniu swoich zadań. Dlatego też można nimi orać.
Jeśli potraktować SCRUM i AGILE, jak narzędzie, to nie jest są to złe, ani dobre narzędzia.
Tak samo jak nóż i młotek. Są jakie są i tyle.
Można ich używać dobrze lub źle i wyciąć coś przydatnego lub uciąć sobie palec.
Wtedy przyjdzie refleksja (twórcza lub nie), albo frustracja, jaką można wyczuć w komentowanym artykule.
Pozostaje życzyć udziału w przedsięwzięciu z dobrze zastosowanym narzędziem typu AGILE / SCRUM.
Są różne narzędzia. Jest nóż ze stali damasceńskiej i tępy majcher ze “stali Mielec”.
I ten drugi nie przydaje się w innych scenariuszach, on zawsze jest do kitu.
Najlepszy projekt przy którym pracowałem to był podobno “waterfall” a pracowaliśmy tak zwinnie, jak tylko się da. Raz na tydzień telco z klientem. Przed projektem kick-off albo wizyta u klienta. Testerzy, programiści i analitycy wspólnie pracowali nad dokumentacją, która była świetna. Nowe funkcje przeplatane bugami oraz czasem na refactoring oraz głęboką analizę.
Projekty scrumowe w mojej firmie zawsze rozbijają się o to, że po 53 sprintach niby mamy produkt ale nagle okazuje się, że nikt nie pomyślał o paru ważnych kwestiach na poziomie architektury, bezpieczeństwa, niezawodności, integracji a w ogóle to jeszcze trzeba dołożyć ludzi i czasu, bo jednak to miało być troszkę inaczej.
Moim zdaniem problem nie leży w metodyce, bo prawdopodobnie te same projekty byłyby też złe w “waterfallu” albo w niescrumowej metodyce zwinnej. Mój zarzut do scruma jest taki, że większość problemów jest ortogonalna do metodyki pracy ale to “wieczna transformacja” jest kosztowna czasowo oraz kognitywnie. Scrum obiecuje złote góry a efekty są często marne.