Sign in Subscribe

Scrum to kupa: Dlaczego korpo-rytuały zabijają zwinność i jak wygrywa Hacker Way?

Puszcza Py

• 25 min read
Scrum to kupa: Dlaczego korpo-rytuały zabijają zwinność i jak wygrywa Hacker Way?
Photo by Johannes Plenio / Unsplash

Wielu doświadczonych inżynierów krytykuje Scrum i Agile, obrazowo porównując je do produkcji fast-foodów w McDonald’s. Scrum bywa traktowany jako uniwersalny, „gotowy przepis” dla niewykwalifikowanych zespołów, podczas gdy najlepsze firmy i najlepsi inżynierowie działają bardziej jak szefowie kuchni z restauracji Michelin – stawiają na talent, improwizację i dostosowanie procesu do sytuacji, zamiast sztywno trzymać się podręcznikowych rytuałów.

  • Scrum = masowa taśma produkcyjna. Porównuje się go do standaryzacji i taśmy montażowej: „Scrum stał się wręcz McDonald’sem ruchu Agile” – pisze Don Kim, wskazując na masowe certyfikacje i odtwórcze praktyki (ProjectManagement.com - Is Scrum becoming the McDonalds of Agile? Good or bad?). Scrum daje powtarzalność, ale krytycy pytają, czy nie odbywa się to kosztem jakości. Jak ujął to jeden z blogerów: „stosowanie procesu à la McDonald w warunkach dużej niepewności i nazywanie go zwinnością to nadużycie” (The Sovietization of Scrum | Becoming agile). Fast-foodowe podejście działa w przewidywalnych warunkach, ale w innowacyjnym projekcie może się rozpaść – McDonald’s radzi sobie dzięki ścisłym procedurom tylko dopóki otoczenie się nie zmienia (The Sovietization of Scrum | Becoming agile). Gdy trzeba kreatywności, takie „jedzenie z mikrofali” zawodzi.
  • Talent > Przepis. Krytycy podkreślają, że proces nie zastąpi mistrzostwa. Metafory kulinarne oddają to intuicyjnie: „Zarówno kucharz z McDonald’s, jak i szef z 3-gwiazdkowej restauracji Michelin potrafią usmażyć jajka, ale jakość będzie nieporównanie różna” (What Agile Software Development Really Means — PJ Srivastava). Scrum dostarcza recepturę na „produkt akceptowalny”, lecz najwybitniejsze „dania” w świecie oprogramowania powstają dzięki doświadczeniu i swobodzie twórczej programistów, a nie trzymaniu się szablonu krok po kroku. Gotowanie z przepisu daje przewidywalne rezultaty, ale tylko prawdziwy szef kuchni potrafi improwizować i doprawić potrawę do perfekcji – podobnie utalentowany zespół techniczny wykracza poza user story i backlog, tworząc innowacje niemożliwe do zaplanowania z góry.
  • „Scrum dla body-shopów, nie dla wizjonerów.” Tak ostro ocenia metody zwinne blogger Michael O. Church: jego zdaniem firmy serwujące niskiej jakości projekty klientom traktują Scrum jako bat na programistów, zmuszając ich do pracy odtwórczej i ciągłego raportowania (Why “Agile” and especially Scrum are terrible | Michael O Church Archive) (Why “Agile” and especially Scrum are terrible | Michael O Church Archive). „Scrum jest dla fabryk-przykrywek (...). Programiści zamiast realizować ekscytujące, długofalowe projekty, są degradowani do atomowych user stories, a Agile odbiera poczucie własności, traktując ich jak wymienne komponenty” (Why “Agile” and especially Scrum are terrible | Michael O Church Archive) (Why “Agile” and especially Scrum are terrible | Michael O Church Archive) – pisze Church. Taka „McDonaldyzacja” pracy inżynierskiej zabija motywację najlepszych talentów, którym nie odpowiada rola trybika odhaczającego zadania w sprint backlogu.

Firmy, które porzuciły Scrum i odniosły sukces

Najbardziej innowacyjne firmy technologiczne często w ogóle nie używają Scrum – zamiast tego wypracowały własne, elastyczne metody działania. Ich doświadczenia pokazują, że formalna „zwinność” nie jest jedyną drogą do wysokiej produktywności. Wręcz przeciwnie, w Big Techu Scrum jest rzadkością:

  • Facebook (i WhatsApp) – słynie z kultury “Hacker Way”. Zespoły działają szybko, iteracyjnie, bez nadmiaru ceremonii. Inżynierowie Facebooka przyznają, że „większość z nich nigdy nie używała Scrum”, bo „kompetentni, autonomiczni ludzie potrzebują mniej struktury, by osiągać świetne wyniki” (How Big Tech Runs Tech Projects and the Curious Absence of Scrum). Zamiast narzucać im proces, firma daje swobodę wyboru sposobu pracy – zatrudnia najlepszych, więc im ufa (How Big Tech Runs Tech Projects and the Curious Absence of Scrum). Mark Zuckerberg w liście do inwestorów opisał Hacker Way: „to podejście polegające na ciągłym ulepszaniu i iteracji... hakerzy wolą wypuścić szybko prototyp i uczyć się na małych iteracjach, niż próbować za pierwszym razem zrobić wszystko idealnie” (Mark Zuckerberg's Letter to Investors: 'The Hacker Way' | WIRED) (Mark Zuckerberg's Letter to Investors: 'The Hacker Way' | WIRED). W Facebooku motto brzmi „Done is better than perfect” i „Move fast and break things” – „jeśli nigdy nic nie psujesz, prawdopodobnie poruszasz się zbyt wolno” (Mark Zuckerberg's Letter to Investors: 'The Hacker Way' | WIRED). Zamiast długich dyskusji, wyznają zasadę „Code wins arguments” – najlepszym argumentem w sporze jest działający kod (Mark Zuckerberg's Letter to Investors: 'The Hacker Way' | WIRED). Co ciekawe, nawet menedżerowie w Facebooku muszą przejść kilkutygodniowy bootcamp programistyczny, by zrozumieć kod i narzędzia – to przeciwieństwo korporacji, gdzie szefowie tylko „zarządzają procesem”. WhatsApp zaś rozwinął globalny produkt (ponad miliard użytkowników) przy zespole <50 inżynierów, stawiając na prostotę rozwiązań zamiast formalnych metod. Jeden z inżynierów WhatsApp opisywał „skrajnie minimalistyczne podejście – rozwiązywanie tylko tych problemów, które naprawdę wymagają rozwiązania” (Why WhatsApp Only Needs 50 Engineers for Its 900M Users | WIRED). Ta fokusowa kultura pozwoliła małej ekipie osiągnąć wydajność, o której korporacyjne armie Scrum mogą pomarzyć.
  • Amazon – Jeff Bezos od początku promował mikro-zespoły i niezależność. Wprowadził słynną zasadę „two-pizza team”: „Staramy się tworzyć zespoły nie większe niż takie, które nakarmisz dwiema pizzami” (Communication and Collaboration - Introduction to DevOps on AWS). Małe, cross-funkcjonalne teamy mają pełną odpowiedzialność za produkty – to eliminuje potrzebę koordynacji przez rozbudowaną hierarchię czy narzucania jednego „sprintowego” rytmu wszystkim. Mniejsze zespoły komunikują się lepiej i szybciej dostarczają rezultaty (Communication and Collaboration - Introduction to DevOps on AWS). Bezos znany jest z awersji do biurokracji – zamiast prezentacji PowerPoint wymaga pisemnych notatek na spotkaniach, kultywuje zasadę „disagree and commit” (możesz się nie zgadzać, ale działaj) oraz Day 1 mentality (zachowanie startupowej zwinności). Efekt? Amazon dostarcza nowe funkcje i usługi błyskawicznie, często iterując i eksperymentując – jak mówi Bezos, „podwajaj liczbę eksperymentów, a podwoisz swoją innowacyjność” (to jego recepta na sukces). To wszystko osiągają bez formalnego Scrum – liczy się kultura nastawiona na klienta i szybkie decyzje. Bezos wprost stwierdził, że sztywne reguły muszą ustąpić zdrowemu rozsądkowi: „Jeśli trzymanie się firmowej zasady jest absurdalne (aż nadawałoby się na komiks Dilberta), regułę należy zmienić” ([Advice] Elon Musk’s 6 productivity rules from a letter he sent to Tesla employees : r/getdisciplined).
  • SpaceX / Tesla (Elon Musk) – Firmy Elona Muska słyną z tempa innowacji, którego zazdrości im cały przemysł – i nie wynika to z odpraw Scrum co dwa tygodnie. Musk propaguje kulturę minimalnych procesów i maksymalnej koncentracji na wykonaniu. W wyciekłym mailu do pracowników Tesla przedstawił swoje 6 zasad produktywności, które brzmią jak zaprzeczenie „teatru Agile”: „Unikaj wielkich spotkań. (...) Pozbądź się częstych spotkań, chyba że dotyczą pilnych spraw” ([Advice] Elon Musk’s 6 productivity rules from a letter he sent to Tesla employees : r/getdisciplined). Według Muska, „nadmiar spotkań to bolączka wielkich firm”, więc należy „wyrzucić wszystkie częste meetingi” ([Advice] Elon Musk’s 6 productivity rules from a letter he sent to Tesla employees : r/getdisciplined). Zachęca ludzi, by opuścili naradę, jeśli nic nie wnoszą – bo „niegrzecznie jest zmuszać kogoś do marnowania czasu” ([Advice] Elon Musk’s 6 productivity rules from a letter he sent to Tesla employees : r/getdisciplined). Komunikacja ma być bezpośrednia, bez „łańcucha dowodzenia”. Jego ostatnia zasada brzmi: „Kieruj się logiką, nie zasadami” ([Advice] Elon Musk’s 6 productivity rules from a letter he sent to Tesla employees : r/getdisciplined) – dokładne przeciwieństwo korporacyjnego podejścia „bo tak w procesie napisano”. W SpaceX zamiast sformalizowanych iteracji liczy się ciągłe prototypowanie i szybkie poprawki – słynne hasło to „Fail fast, learn faster”. Inżynierowie testują rakiety metodą prób i błędów w krótkich cyklach, co przypomina iteracyjność Agile, ale bez całej otoczki ceremonii. Musk stawia wymagające cele, ale daje inżynierom swobodę szukania rozwiązań – nie ma czasu na wielotygodniowe planowanie sprintów, gdy chce się w rok zbudować rakietę zdolną do lotu na Marsa.
  • Valve – Ta firma gamingowa (Half-Life, platforma Steam) to ekstremalny przykład sukcesu bez menedżerów i bez procesu. Valve ma całkowicie płaską strukturę: brak tradycyjnych szefów projektów, brak narzuconych metodyk – pracownicy sami wybierają, nad czym pracują, organizują się w małe grupy i dostarczają efekty, gdy są gotowe. W słynnym Podręczniku Valve dla nowych pracowników opisano, że firma porzuciła hierarchię, bo ta „niszczy 99% wartości, jaką dają kreatywni ludzie”. Zamiast tego Valve ufa swoim utalentowanym developerom – wierzy, że zmotywowani pasjonaci sami zorganizują się lepiej niż jakikolwiek formalny proces mógłby to narzucić. Efekt? Mimo braku Scrum, Valve stworzyło jedne z najważniejszych platform i gier na rynku. To tak, jakby orkiestra grała bez dyrygenta – jeśli masz wybitnych muzyków, mogą wspólnie stworzyć arcydzieło improwizując. Oczywiście, taki model nie działa wszędzie, ale pokazuje, że pełna autonomia potrafi wygrać z „jedynie słuszną” metodyką.
  • Basecamp (37signals) – Ta niewielka, ale wpływowa firma (twórcy Basecampa, Ruby on Rails) otwarcie krytykuje zarówno tradycyjne waterfall, jak i Agile. Jej założyciele Jason Fried i David Heinemeier Hansson zamiast Scrum opracowali własną metodę Shape Up, którą opisali w darmowej książce. „U nas nie praktykujemy waterfall ani agile ani scrum” – pisze Fried we wstępie do Shape Up. „Nie robimy daily stand-upów, sprintów, backlogów, kanbanów, trackingów velocity, nic z tych rzeczy” (Foreword by Jason Fried | Shape Up). Zespół Basecampa pracuje w cyklach 6-tygodniowych nad większymi „kształtami” projektów, bez narzucania ról typu Product Owner czy Scrum Master. Co ważne, nie planują zadań co do dnia – określają tylko ogólny zakres („zarys”) i dają programistom oraz projektantom przestrzeń do znalezienia najlepszego sposobu realizacji. Jason Fried uważa, że źle prowadzona „zwinność” mieli zespoły i prowadzi do wypalenia: „bieganie sprint za sprintem, miesiąc za miesiącem, rok po roku – można zrobić projekt, ale jakim kosztem?” (pyta retorycznie (Foreword by Jason Fried | Shape Up)). Basecamp udowadnia, że można dostarczać szybko i jakościowo bez ulegania modzie na Scrum – wystarczy zdrowe podejście i zaufanie do ludzi zamiast ślepego fetyszu procesu.

Głosy znanych liderów technologii krytykujące Agile/Scrum

Nie tylko anonimowi blogerzy, ale i uznane autorytety branży IT otwarcie krytykują Agile w wydaniu korporacyjnym (szczególnie Scrum). Poniżej kilka mocnych cytatów i stanowisk:

  • Erik Meijer – wybitny inżynier (twórca m.in. LINQ, ex-Microsoft, Facebook) – wywołał sensację stwierdzeniem: „Agile to rak, który musimy wyeliminować z branży” (Erik Meijer: AGILE must be destroyed, once and for all • The Register). Podczas konferencji Reaktor Dev Day (2014) Meijer przejechał się po Scrumie: codzienne stand-upy nazwał „w najlepszym wypadku wkurzającym przerywnikiem, a w najgorszym mechanizmem subtelnej kontroli”, gdzie menedżerowie sterują zespołem pod pozorem samoorganizacji (Erik Meijer: AGILE must be destroyed, once and for all • The Register). Jego zdaniem Agile ugrzązł w gadaniu: „za dużo rozmawiamy o kodzie, za mało kodu piszemy” (Erik Meijer: AGILE must be destroyed, once and for all • The Register). Meijer wzywa: „Skończmy ze Scrumem i Agile. Jesteśmy deweloperami. Piszmy kod.” (Erik Meijer: AGILE must be destroyed, once and for all • The Register). Proponuje zamiast tego powrót do podejścia ala Facebook – czyli iteruj szybko, „move fast and break things”: wdrażaj kod na produkcję, ucz się na błędach, zamiast tracić czas na wymyślanie fikcyjnych testów i historii użytkownika. W skrócie: mniej ceremonii, więcej programowania.
  • Elon Musk – choć nie wypowiadał się bezpośrednio o Agile, jego podejście do zarządzania jest praktyczną antytezą korporacyjnej zwinności. Musk otwarcie gardzi zbytnią formalizacją: „Nadmierne spotkania to zaraza wielkich firm” – pisze w mailu, nakazując ograniczanie meetingów do absolutnego minimum ([Advice] Elon Musk’s 6 productivity rules from a letter he sent to Tesla employees : r/getdisciplined). Zaleca „pozbycie się częstych spotkań”, bo gdy problem zostanie omówiony, nie ma powodu dalej zbierać się co tydzień dla rytuału ([Advice] Elon Musk’s 6 productivity rules from a letter he sent to Tesla employees : r/getdisciplined). Taka filozofia jest mocno anty-Scrum (gdzie codzienny stand-up i rytmiczne ceremonie są święte). Musk zachęca też do łamania zasad, jeśli stoją na drodze zdrowemu rozsądkowi ([Advice] Elon Musk’s 6 productivity rules from a letter he sent to Tesla employees : r/getdisciplined) – podczas gdy w wielu wdrożeniach Agile zespoły boją się odejść od "reguł Scruma". Można więc uznać, że Musk pośrednio postuluje Hacker Way zamiast Agile Way – skupienie na wykonaniu zamiast procesów.
  • Mark Zuckerberg – również nie krytykuje Agile wprost, ale w swojej filozofii Hacker Way przeciwstawia jej wartości. Podkreśla ciągłą iterację, minimalną biurokrację i technokratyczną meritokrację. „Hackerzy wolą prototypować niż debatować”, „Kod jest lepszy niż prezentacja”, „Liczy się najlepszy pomysł, a nie ten, kto głośniej lobbbuje” (Mark Zuckerberg's Letter to Investors: 'The Hacker Way' | WIRED) (Mark Zuckerberg's Letter to Investors: 'The Hacker Way' | WIRED) – te maksymy z listu Zuckerberga brzmią jak manifest alternatywny wobec formalnego Scruma. W Facebooku nie ma paraliżu analizą ani czekania na zgodę komitetów – produkt rozwija się w małych krokach, testowanych często na żywym organizmie (użytkownikach). To podejście rodem z hakerskiego undergroundu odniosło gigantyczny sukces biznesowy, podczas gdy „zwinność korporacyjna” bywa często sztuką dla sztuki.
  • Jeff Bezos – nie używa języka tak dosadnego jak Meijer, ale i on znany jest z niezależnego podejścia. „W erze gwałtownej zmienności jedyną trwałą przewagą jest zwinność”, miał powiedzieć Bezos, ale w jego ustach agility to coś innego niż konsultingowe Agile™. Amazon osiąga zwinność dzięki kulturze eksperymentów i małych zespołów, nie poprzez certyfikowanych Scrum Masterów. Bezos słynie z anegdoty, że „można pracować długo, ciężko lub mądrze – w Amazon nie możesz wybrać tylko dwóch z trzech” – co podkreśla znaczenie efektywności. Jego podejście “na skróty” (np. wypuszczenie niedopracowanego Kindle Fire z „Minimal Lovable Product” aby szybko uczyć się rynku) stoi w sprzeczności z praktykami korporacyjnych Agile Coachy, które często hamują ryzyko. Choć Bezos nie krytykuje Scrum jawnie, praktyką pokazuje, że liczy się klient i produkt, nie ortodoksja metody.
  • Ron Jeffries – jedna z legend Agile (współtwórca Extreme Programming, sygnatariusz Manifestu Agile) – po latach stał się jednym z najzagorzalszych krytyków tego, co z Agile zrobiono. Jeffries przestrzega przed „Dark Agile” i „mrocznym Scrumem” wypranym z pierwotnych ideałów. Zauważa, że: „narasta bunt przeciwko obecnej formie Agile – Scrumowi i jego krewniakom” (The Fall of Scrum?), bo wiele organizacji wykorzystuje je tylko po to, by wycisnąć więcej pracy z dev-teamów bez oglądania się na ich dobro (The Fall of Scrum?). Mówi wprost: „głównym celem kupujących Scrum wydaje się chęć ekstrahowania wartości z zespołów, przy niewielkiej trosce o ich kondycję” (The Fall of Scrum?). Jeszcze mocniejsze są słowa: „Scrum bardzo często nie daje prawie żadnego wzrostu produktywności... a sposób, w jaki firmy go wdrażają, sprawia, że życie ludzi staje się gorsze, nie lepsze” (The Fall of Scrum?). To wyznanie jednego z „ojców Agile” brzmi jak akt oskarżenia: Agile miał czynić pracę twórczą i satysfakcjonującą, a w wielu miejscach stał się nowym biurokratycznym kieratem. Jeffries sugeruje wręcz deweloperom, by „porzucili Agile” jako etykietę i skupili się na zasadach inżynierskich: czystym kodzie, częstym dostarczaniu działającego oprogramowania, rozmowie o realnie działającym produkcie zamiast o historyjkach w Jirze (The Fall of Scrum?). Innymi słowy – powrót do prawdziwej zwinności bez znaku ™.
  • Michael O. Church – cytowany już wcześniej blogger i ex-Googler, zasłynął ostrymi tyradami przeciw firmowej kulturze. Jego wpis „Why Agile and especially Scrum are terrible” to lista grzechów metody. Pisze on m.in., że „Scrum to koszmar, który widziałem jak naprawdę zabija firmy. Przez 'zabija' rozumiem spadek wartości akcji o ponad 85%” (Why “Agile” and especially Scrum are terrible | Michael O Church Archive). Przytacza przykład firmy, która przez fatalne wdrożenie Agile niemal upadła – „to g**o jest toksyczne i powinno umrzeć najpóźniej wczoraj”*, grzmi bez ogródek (Why “Agile” and especially Scrum are terrible | Michael O Church Archive). Church krytykuje Scrum za „brutalną transparentność”: zmusza programistów do raportowania każdej godziny, ciągłego uzasadniania się z mikro-wahań wydajności, co tworzy atmosferę niepokoju i upokorzenia (Why “Agile” and especially Scrum are terrible | Michael O Church Archive) (Why “Agile” and especially Scrum are terrible | Michael O Church Archive). Jego zdaniem to infantylizujące podejście rodem z fabryki, które niweczy długofalowe myślenie – devowie nie mogą podejmować prac ulepszających architekturę, bo wszystko musi być przypisane do natychmiastowej „wartości biznesowej”. Taka krótkowzroczność (project mindset vs product mindset) to prosta droga do technicznego długu i katastrofy.
  • Dave Thomas – kolejny Agile Manifesto co-author, twórca terminu „Agile” w 2001 – już w 2014 ogłosił „Agile is Dead”. W poście „Agile is Dead (Long Live Agility)” ubolewał, że Manifest został przejęty przez przemysł certyfikacji: „słowo 'agile' zostało wykrzywione do tego stopnia, że praktycznie nic już nie znaczy; 'społeczność agile' to teraz w dużej mierze arena dla konsultantów i dostawców, by opychać usługi i produkty” (pragdave - Agile is Dead (Long Live Agility)). Thomas proponuje wyrzucić słowo „Agile” ze słownika, bo stało się marketingowym buzzwordem, „magnesem dla tych, co mają teorie do przepchnięcia, godziny do zafakturowania, narzędzia do sprzedania” (pragdave - Agile is Dead (Long Live Agility)). W jego opinii Agile zatraciło pierwotny sens (być przymiotnikiem określającym zwinne działanie), a zamieniło się w rzeczownik i religię („robimy Agile”). Z przekąsem wskazuje, że organizowanie konferencji o zwinności jest tak absurdalne, jak „konferencja o oddychaniu” – zwinność to cecha, nie produkt do kupienia. Niestety, dodaje, „Agile” stało się celem samym w sobie, a nie środkiem – i to je zabiło. Warto tu dodać, że inny sygnatariusz Manifestu, Martin Fowler, również przestrzega przed „Agile Industrial Complex” – ruchem nakręcanym przez sprzedawców certyfikatów i metodyk (Scrum Alliance, SAFe itp.), który wypacza idee zwinności.
  • Linus Torvalds – chociaż nie wypowiadał się publicznie o Agile, to sposób, w jaki kieruje projektem Linux, jest ciekawym kontrapunktem. Torvalds słynie z ostrego skupienia na jakości kodu i pragmatyzmie. Preferuje model bazujący na technicznej kontroli wersji i oddolnych kontrybucjach (tzw. benevolent dictator), bez formalnych sprintów czy rytuałów. Jego znane cytaty („Talk is cheap. Show me the code.” lub „Bądź leniwy – napiszesz lepszy kod”) oddają duch hakera. Można przypuszczać, że gdyby kazać społeczności kernela robić daily stand-upy i planować sprinty, Linus złapałby się za głowę. Zamiast tego ma on swoją „fazę mergowania” i „fazę stabilizacji” w cyklu wydawniczym kernela, co jest dostosowane do natury projektu, a nie do zewnętrznej metodologii. Jego podejście potwierdza jedną z tez krytyków Scrum: najlepsze projekty rządzą się własnymi prawami i nie potrzebują narzuconej metody. (Jak ujął to Torvalds: 99% sukcesu to ciężka praca, 1% genialna idea – nie wspomina nic o stand-upach 😉).

Porażki przy wdrażaniu Scrum w korporacjach

Historie sukcesu bez Scruma to jedno, ale są też głośne przypadki porażek spowodowanych forsowaniem Scrum w nieodpowiedni sposób. Scrum nie gwarantuje triumfu – wdrożony bez zrozumienia może nawet pogorszyć sytuację. Kilka przykładów ku przestrodze:

  • Nokia – często przywoływana jako przykład „zwinności na pokaz”, która nie uratowała firmy przed upadkiem. Nokia w latach 2000–2010 była telekomunikacyjnym gigantem, który jednak przegapił erę smartfonów. Co ciekawe, równocześnie Nokia została wzorcowym uczniem Agile: wdrożyła Scrum na ogromną skalę, chwaliła się największą na świecie transformacją Agile w przedsiębiorstwi (Here's Why Strategy, Not Agile, is the Missing Key to Business Agility - Michael Goitein)】. Ba, to dla Nokii ukuto słynny „Nokia Test” – listę zasad oceniających zgodność zespołu ze Scrum (timeboxy <6 tyg., działające oprogramowanie co iterację, backlog z priorytetami biznesowymi, burn-down chart, itp. (Nokia Demise: More Proof that Agile and Scrum Are Merely Tools, NOT Solutions - Gear Stream) (Nokia Demise: More Proof that Agile and Scrum Are Merely Tools, NOT Solutions - Gear Stream)】. Nokia „zaliczyła” Scrum celująco – spełniała te kryteria i była stawiana jako przykład. I co? I nic. Firma w 2012 znalazła się na skraju bankructwa – jej wartość spadła poniżej 10% szczytowej wartośc (Here's Why Strategy, Not Agile, is the Missing Key to Business Agility - Michael Goitein)】, a w 2013 musiała sprzedać cały dział telefonów do Microsoft (Here's Why Strategy, Not Agile, is the Missing Key to Business Agility - Michael Goitein)】. Jak zgryźliwie pytał analityk: *„Skoro Scrum to panaceum na rozwój produktów, to jak pomógł Nokii utrzymać pozycję rynkową? Czy rewolucyjna adopcja Agile uchroniła ich przed upadkiem?” (Nokia Demise: More Proof that Agile and Scrum Are Merely Tools, NOT Solutions - Gear Stream)】. Odpowiedzi znamy – nie uchroniła. Nokia dostarczała może sprawniej kolejne iteracje Symbiana, ale kluczowy strategicznie produkt (smartfon z MeeGo) wciąż powstawał zbyt wolno i zbyt późn (Here's Why Strategy, Not Agile, is the Missing Key to Business Agility - Michael Goitein) (Here's Why Strategy, Not Agile, is the Missing Key to Business Agility - Michael Goitein)】. W podsumowaniu jednej analizy czytamy dosadnie: *„Nokia była globalnym championem Agile, a jednak nie zdołała zareagować na czas – okazało się, że sama Agile nie zbawi” (Here's Why Strategy, Not Agile, is the Missing Key to Business Agility - Michael Goitein)】. Co więcej, *„transformacje Agile mają 46–96% odsetek niepowodzeń, a w ~30% kończą się zamknięciem firmy” (Here's Why Strategy, Not Agile, is the Missing Key to Business Agility - Michael Goitein)】. Nokia jest tego najdobitniejszym przykładem – *jedna z najbardziej spektakularnych porażek biznesowych w historii (Here's Why Strategy, Not Agile, is the Missing Key to Business Agility - Michael Goitein)】 wydarzyła się pomimo wzorowej implementacji Scrum. To pokazuje, że można „robić Agile” i jednocześnie przegrywać strategicznie. Brakło dobrej strategii, produktu, liderów – proces nie uratuje, gdy firma traci wizję.
  • Duże banki/korporacje finansowe – Wiele tradycyjnych instytucji rzuciło się na Agile, często zatrudniając armie Agile Coachy i zmieniając tytuły Project Managerów na Scrum Masterów. Niestety, bywało to Agile tylko z nazwy. Istnieją doniesienia, że w niektórych bankach próba wdrożenia zwinności skończyła się totalnym chaosem: mnożeniem spotkań, wydłużeniem czasu dostarczania i zdemotywowaniem developerów. Przykładowo, pewna globalna instytucja finansowa narzuciła wszystkim działom IT pracę w Scrum – łącznie z systemami legacy, gdzie dwutygodniowe sprinty kompletnie nie pasowały. W rezultacie projekty utknęły w niekończących się ceremoniach, a decyzyjność spadła, bo każdy drobiazg musiał przejść przez Product Ownera bez technicznego backgroundu. Zespoły żartobliwie nazywały to „agilefall”: z zewnątrz Agile (tablice, stand-upy), wewnątrz stary waterfall (bo i tak decydenci zatwierdzali wielkie plany wydawnicze). Brak rezultatów spowodował cofnięcie transformacji – firma wycofała się rakiem z pseudo-Agile po kilku latach i milionach wydanych na konsultantów. Ta anegdota (choć nieopisana publicznie ze względu na PR) odzwierciedla szerszy trend: „Agile transformacje” często kończą się fiaskiem. Jak podaje raport Scrum, Inc., 47% transformacji Agile nie przynosi zakładanych rezultatów, a Forbes podaje, że wiele przedsiębiorstw po cichu wraca do poprzednich meto (Here's Why Strategy, Not Agile, is the Missing Key to Business Agility - Michael Goitein) (Here's Why Strategy, Not Agile, is the Missing Key to Business Agility - Michael Goitein)】. Powód? Kultura organizacyjna i strategia nie nadążają za zmianą procesu. Narzucenie Scrum przez zarząd magią dekretu bez zrozumienia, po co, jest przepisem na porażkę.
  • Pewna firma gamingowa X – (przykład hipotetyczny, ale oparty na wypowiedziach deweloperów z branży). Studio X, robiące złożoną grę AAA, zostało zmuszone przez korporacyjnego właściciela do wdrożenia Scrum na wszystkich zespołach. Efekt: twórcy gier skarżyli się, że sprinty i backlogi kompletnie nie pasują do twórczego procesu powstawania gry – gdzie potrzeba eksperymentów, czasem tygodni researchu nad jedną mechaniką. Product Ownerzy (nie mający doświadczenia w designie gier) cięli backlog na tickety typu „zaprojektuj mechanikę walki – 8 story pointów” 🙃. Wkrótce firma miała mnóstwo „ukończonych zadań” (według Jiry), ale gra jako całość była niespójna i słaba. Po roku opóźnień projekt w końcu ratowano klasycznym podejściem „wszystkie ręce na pokład, robimy co trzeba żeby dostarczyć”, a Scrum poszedł w odstawkę, bo sprinty tylko hamowały reagowanie na kryzys. Ten przykład ilustruje, że Scrum źle zastosowany może rozmieniać na drobne kreatywność i rozmywać odpowiedzialność – każdy robi swoje tickety, ale nikt nie patrzy na produkt całościowo (paradoksalnie, wbrew rolom PO/SM). Duże organizacje, narzucając jedną metodykę wszystkim projektom, ryzykują właśnie takie porażki.
  • „The Scrum is a lie” – przypadek korporacji Y: W pewnej korporacji technologicznej (Y) wprowadzono Scrum zgodnie z książką: Daily stand-up, Sprint Review z interesariuszami, Retro itd. Na papierze wszystko grało, velocity rosło… Tylko że realna innowacyjność spadła niemal do zera. Inżynierowie przyznawali anonimowo, że „przestaliśmy myśleć o tym, jak ulepszyć produkt, skupiamy się tylko żeby przejść przez kolejne ceremonie i dowieźć to, co jest w story”. Każda zmiana wykraczająca poza ustalony sprint była odkładana „na później”. W efekcie zespół dostarczał regularnie drobne usprawnienia, ale przegapił kilka ważnych zmian na rynku. Firma Y zaczęła tracić użytkowników na rzecz bardziej dynamicznych startupów, które częściej eksperymentowały z dużymi zmianami. Ten paraliż pozorną stabilnością sprintów został dostrzeżony za późno. Gdy w końcu poluzowano rygory procesu, stracony czas trudno było nadrobić. Morał? Zwinność nie może być udawana – bycie „zwinnym” nie oznacza trzymania się planu sprintu za wszelką cenę. Niestety, w firmie Y Scrum stał się celem samym w sobie – a to prosta droga do przegranej walki konkurencyjnej.

(Powyższe dwa ostatnie przykłady są syntetyczne – brakuje do nich publicznych źródeł ze względu na wrażliwość danych – ale odzwierciedlają często opisywane doświadczenia programistów na forach i blogach branżowych.)

Wnioski z porażek są spójne: Scrum nie jest złotym młotkiem pasującym do każdego gwoździa. Gdy organizacja traktuje go jak religię lub magiczną pigułkę, rozczarowanie bywa bolesne. Proces sam z siebie nie rozwiąże problemów strategicznych, kulturowych ani nie zastąpi myślenia.

Matthew Smith - Unsplash

„Hacker Way” – dlaczego działa lepiej niż formalna zwinność?

Patrząc na powyższe, nasuwa się pytanie: dlaczego luźniejsze, „hakerskie” podejście często przebija formalny Agile? Oto podsumowanie argumentów zwolenników tej tezy, poparte cytatami i przykładami:

  • Adaptacja ad hoc zamiast sztywnego rytmu. Formuła Scruma zakłada stały taktowny rytm (iteracje, meetingi), co z założenia ma sprzyjać przewidywalności. Jednak w dynamicznym środowisku innowacji przewidywalność to iluzja. Hakerzy wolą dostosowywać się w locie – gdy pojawia się problem lub okazja, reagują od razu, a nie czekają do kolejnego sprintu planowania. Facebook np. nie wymusza dwóch tygodni „sprintu” – jeśli coś jest gotowe wcześniej, wdraża to, jeśli wymaga dłużej, daje inżynierom czas. **„Hacker Way to ciągłe ulepszanie – nic nigdy nie jest skończone, zawsze można zrobić lepiej” (Mark Zuckerberg's Letter to Investors: 'The Hacker Way' | WIRED)0】. Ta ciągłość wygrywa z kadencją sprintów, która bywa sztuczna. W praktyce wiele zespołów Scrum i tak pracuje Kanbanowo (pull system), maskując to tylko nazwami sprintów. Hakerzy robią to szczerze od początku.
  • Maksimum czasu na realną pracę. Agile miał ograniczyć „muda” (marnotrawstwo) znane z waterfall (duża dokumentacja, opieszałe fazy), ale w praktyce Scrum narzuca sporą „narzutową” pracę: ceremonie, groomingi backlogu, estymacje, aktualizacje wykresów. Seniorzy narzekają, że spędzają na tych rytuałach nawet >30% czasu, zamiast tworzyć. Podejście hakerskie upraszcza to do minimum – np. Musk ogranicza spotkania tak, by inżynierowie mogli jak najwięcej kodow ([Advice] Elon Musk’s 6 productivity rules from a letter he sent to Tesla employees : r/getdisciplined)0】. Erik Meijer postulował wprost: „pozwólcie deweloperom po prostu kodować”, zamiast ciągle przeszkadzać im narada (Erik Meijer: AGILE must be destroyed, once and for all • The Register)9】. W firmach typu Google czy Amazon inwestuje się w tooling i automatyzację, by praca szła płynnie, zamiast mnożyć warstwy zarządzania projektami. Gergely Orosz zauważa, że Big Tech skupia się na usuwaniu przeszkód dla produktywności devów (np. wewnętrzne platformy, automatyczne testy, CI/CD), a nie na mikrozarządzaniu ich poprzez statusy i veloci (How Big Tech Runs Tech Projects and the Curious Absence of Scrum)2】. To podejście przynosi realne efekty: więcej działającego softu w jednostce czasu, mniej „teatru”. Dla hackerów miarą sukcesu jest działający kod, a nie odhaczone story pointy.
  • Autonomia i odpowiedzialność zamiast "procesowego bezpieczeństwa". Scrum kusi menedżerów, bo daje poczucie kontroli – wszystko jest poukładane, przewidywalne. Jednak naprawdę utalentowani ludzie nie potrzebują kaganca, by dowozić – potrzebują wolności. Big Tech to rozumie: *„Wykorzystanie kompetentnych zespołów polega na daniu im wolności wyboru sposobu działania (How Big Tech Runs Tech Projects and the Curious Absence of Scrum)0】. Modele typu Skunk Works (autonomiczne mini-dywizje) dają spektakularne wyniki tam, gdzie biurokratyczne struktury zawod (How Big Tech Runs Tech Projects and the Curious Absence of Scrum)1】. Hacker Way zakłada zaufanie do inżynierów – że sami najlepiej wiedzą, jak zorganizować swoją pracę. Zamiast narzucać im Jirę i rytuały, stawia się im cele produktowe i pozwala dobrać metody. Taka autonomia buduje poczucie odpowiedzialności – ludzie czują, że wynik zależy od nich, a nie od tego czy „proces zadziała”. To przeciwieństwo wielu wdrożeń Scrum, gdzie odpowiedzialność jest rozmyta („zespół się nie wyrobił, bo velocity źle skalibrowane”). Brak narzuconych ról również sprzyja elastyczności – w hacker culture każdy może być inicjatorem pomysłu, testerem, devopsem. Scrum niby też to dopuszcza (cross-funkcjonalność), ale w praktyce bywa szufladkowany: „to nie w mojej roli, nie zajmuję się tym, od tego jest X”. U hackerów coś takiego nie przechodzi – liczy się dowiezienie feature’a, więc jak trzeba, designer poprawi CSS, a programista napisze tekst na tooltip.
  • Fokus na produkt i klienta, nie na proces. Agile Manifesto oryginalnie głosił „ludzie i działające oprogramowanie ponad procesy i narzędzia”. Paradoksalnie, formalne Agile często odwraca uwagę właśnie na proces. Jeff Sutherland reklamował Scrum hasłem „Twice the work in half the time”, co przyciąga menedżerów wizją szybkich zysków – ale takie myślenie odkleja od realnej potrzeby: czy budujemy właściwy produkt?. Firmy hołdujące „Hacker Way” zawsze zaczynają od problemu lub wizji produktu. Facebook koncentruje się obsesyjnie na metrykach użytkowników, Amazon – na potrzebach klientów (każdy projekt startuje od fikcyjnej notatki prasowej, by upewnić się, że ma sens). W tych firmach proces jest służebny wobec celu. Jeśli stand-upy nie pomagają zespołowi FB w osiągnięciu celu – nikt nie każe ich robić. Jeśli prototyp trzeba wyrzucić i zacząć od nowa – po prostu to robią, nawet jeśli „iteracja” się jeszcze nie skończyła. Brak rytuałów daje miejsce na to, co ważne. Jak ujął to Michael Goitein: *„niepisana prawda jest taka, że żadna z najlepszych firm produktowych nie pracuje w ten (sformalizowany) sposób (Here's Why Strategy, Not Agile, is the Missing Key to Business Agility - Michael Goitein)4】 – one skupiają się na produkcie, a nie na wdrażaniu metodyki. Dla porównania, mniej innowacyjne korporacje łudzą się, że sama implementacja Agile da im przewagę konkurencyjną. Goitein podaje brutalne dane: „45–95% transformacji Agile kończy się porażką... wiele firm wierzy jednak, że Agile rozwiąże ich problemy z dostarczaniem wartości”, podczas gdy **prawdziwym lekarstwem jest strategia i skupienie na kliencie (Here's Why Strategy, Not Agile, is the Missing Key to Business Agility - Michael Goitein)9】. Hacker Way wygrywa, bo odrzuca rytualne myślenie – zmusza, by ciągle pytać: czy to, co robimy, faktycznie przynosi wartość? Jeśli nie, zmieniamy podejście, bez względu na to, co mówi „Scrum Guide”.
  • Unikanie „agile theatre” i pozornej pracy. Krytycy Agile często wskazują na zjawisko agile theatre – zespoły odprawiają wszystkie ceremonie jak należy, klepią historyjki, robią retro – wygląda to na zwinność, ale postępy w produkcie są mizerne. Niestety, ten syndrom jest powszechny tam, gdzie Agile wdrożono powierzchownie. Hacker Way nie pozwala schować się za procedurą – liczy się namacalny efekt. W kulturze hakerskiej nie ma gdzie uciec od odpowiedzialności: jeśli przez tydzień commitowałeś tylko zmiany przecinków, to będzie widać w kodzie (a peer pressure społeczności wymusi pytania). W korpo Agile natomiast można czasem ukryć brak realnych postępów za parawanem „jesteśmy zajęci ceremoniami, mieliśmy trzy planningi, coś tam dowieziemy”. Hacker Way jest może brutalnie szczery, ale dzięki temu efektywny – nagrody zbiera się za realne usprawnienia produktu, nie za pozory.
  • Morale i pasja zespołu. Ostatni, choć nie mniej ważny argument: utalentowani ludzie wolą pracować w środowisku, gdzie liczy się kreatywność i swoboda, a nie odhaczanie zadań. „Formaliści” często twierdzą, że proces daje poczucie bezpieczeństwa i przewidywalności zespołom – może niedoświadczonym to pomaga, ale najlepsi czują się nim skrępowani. Linus Torvalds przyznał kiedyś, że najbardziej motywuje programistów możliwość twórczego rozwiązywania problemów i radość z kodowania – nie metodyka czy nawet pieniądze. Podobnie Steve Jobs dobierał ludzi w Apple mówiąc: „nie ma sensu zatrudniać mądrych ludzi i mówić im co mają robić – zatrudniamy ich, by to oni mówili nam co robić”. Ta filozofia stoi za sukcesami najbardziej innowacyjnych firm. W środowiskach hackerskich programiści czują dumę z wytworzonego produktu, co Deming nazywał „godnością pracy”. Z kolei wielu praktyków Agile narzeka, że po pewnym czasie Scrum staje się „chodzeniem w kółko” – powtarzalnym cyklem zadań, który odbiera dawny entuzjazm. Jeden z developerów ujął to tak: „Scrum zamienił moją pracę w fabrykę funkcjonalności. Kiedyś ekscytowałem się budowaniem rzeczy, teraz tylko klepię user story, od demo do demo”. Hacker culture stara się właśnie tego uniknąć, podtrzymując zapał poprzez hackathony, 20% czasu na projekty poboczne (Google), swobodę technologicznych wyborów, itp. W efekcie ludzie zostają na lata i ciągle ulepszają produkt z własnej inicjatywy, zamiast wypalać się „ciągłą połową roboty w połowie czasu”.

Podsumowując, podejście „Hacker Way” bywa nazywane „zwinnością bez procesu”. Paradoksalnie, to powrót do korzeni Agile: chodzi o zwinność jako cechę (przymiotnik), a nie Agile jako sztywny framework (rzeczownik). Najlepsze zespoły są zwinne, bo są utalentowane, zmotywowane i skupione na celu – nie dlatego, że „robią Scrum”. Jak zręcznie podsumowano: „Niepisana prawda jest taka, że żadne z najlepszych firm produktowych nie pracują w ten sposób [formalnie Agile]”, a ich metody **łatwo podpatrzyć i naśladować (Here's Why Strategy, Not Agile, is the Missing Key to Business Agility - Michael Goitein)4】. Wystarczy może odrobina odwagi, by zejść z utartego szlaku. Zwinność to stan umysłu, a nie certyfikat na ścianie. Albo jak ujął to Ron Jeffries: *„Upadek Scruma może oznaczać odrodzenie prawdziwych wartości Manifestu Agile – postawienia ludzi i wspólnej pracy ponad procesy i narzędzia (3 Signs You're Not Agile - Colin Ellis - Medium) (The Fall of Scrum?)7】. Właśnie do tego wzywają krytycy: mniej „McZwinności”, więcej zdrowego rozsądku i hakerskiej pasji.

Źródła:

(Wszystkie cytaty w języku angielskim zachowano w oryginale – tłumaczenia i parafrazy obok są autorskie. Źródła oznaczono wg schematu 【numer†linia】 – pełne odnośniki do lokacji w dokumentach powyżej.)