Dokładnie 25 lat temu, między 11 a 13 lutego 2001 roku, siedemnastu praktyków software developmentu spotkało się w ośrodku narciarskim Snowbird w górach Wasatch w stanie Utah. Przyjechali pojeździć na nartach, odpocząć i podyskutować o frustracjach, które ich łączyły. Nie reprezentowali jednej metody ani jednej firmy. Nie mieli planu na stworzenie ruchu. A mimo to do końca weekendu napisali krótki dokument z czterema wartościami, który zmienił sposób, w jaki świat tworzy oprogramowanie.
Ten dokument to Manifesto for Agile Software Development. I dzisiaj, w dniu jego 25. rocznicy, warto się zatrzymać i uczciwie odpowiedzieć na pytanie: co się zmieniło przez te 25 lat? Moim zdaniem odpowiedź jest dużo bardziej optymistyczna, niż sądzi wielu sceptyków z LinkedIn'a ;-)
Zanim pojawił się Agile: kryzys, od którego wszystko się zaczęło
Żeby zrozumieć i docenić drogę, jaką przeszliśmy, trzeba cofnąć się do momentu, w którym branża uderzyła w ścianę.
W październiku 1968 roku, w Garmisch w Niemczech, NATO zorganizowało konferencję, na którą zaproszono pięćdziesięciu czołowych informatyków z jedenastu krajów. Wśród nich byli tacy giganci jak Edsger Dijkstra, Tony Hoare, Peter Naur czy Niklaus Wirth (kto studiował informatykę, to właśnie mu stanął przed oczami egzamin z algorytmów i struktur danych). Temat konferencji brzmiał prowokacyjnie: Software Engineering - termin celowo wybrany, żeby zmusić uczestników do refleksji nad tym, że tworzenie oprogramowania potrzebuje dyscypliny inżynierskiej.
To właśnie tam po raz pierwszy padło sformułowanie „software crisis". Projekty informatyczne regularnie przekraczały budżety, nie dotrzymywały terminów i produkowały oprogramowanie, które nie spełniało wymagań. Dijkstra podsumował to dobitnie:
„Masowe rozpowszechnianie oprogramowania obciążonego błędami jest przerażające."
Odpowiedzią branży był model Waterfall - sekwencyjne wytwarzanie oprogramowania, w którym najpierw planujesz wszystko, potem projektujesz wszystko, potem budujesz wszystko, potem testujesz wszystko. Projekty trwały miesiącami lub latami. Zmiana wymagań w połowie? Katastrofa. Raport Standish Group CHAOS (badanie z 1994 roku, opublikowane w 1995) potwierdził skalę problemu: zaledwie 16,2% projektów IT kończyło się sukcesem.
To był punkt wyjścia. Ale na szczęście nie punkt docelowy.
Developerzy, którzy znaleźli lepszy sposób
W latach 90. coś zaczęło się zmieniać. Nie w korporacjach - wśród praktyków, którzy postanowili szukać lepszego sposobu pracy.
Kent Beck stworzył Extreme Programming (XP) - zestaw praktyk opartych na krótkich iteracjach, pair programmingu, ciągłej integracji i testach automatycznych. Ken Schwaber i Jeff Sutherland formalizowali Scrum. Alistair Cockburn rozwijał Crystal, Jim Highsmith - Adaptive Software Development. Każdy z nich szedł nieco inną ścieżką, ale kierunek był wspólny: mniej planowania z góry, więcej uczenia się przez działanie. Mniej dokumentacji, więcej współpracy. Mniej przewidywania przyszłości, więcej adaptacji do rzeczywistości.
Te podejścia nazywano wtedy „lightweight methods". I to właśnie ich twórcy spotkali się w Snowbird. Robert C. Martin (Uncle Bob) wysłał zaproszenie mailem do ludzi znanych z eksperymentowania z lekkimi metodami pisząc:
"I want two things done. 1. Setup a website that people can go to learn about LWPs (Lightweight Processes). 2. Create a manifesto that the group signs, describing the fundamental tenets of LWPs and recommending them to the industry at large."
Jim Highsmith przyznał później - „trudno byłoby zebrać większą grupę organizacyjnych anarchistów" :)
A jednak się dogadali. Stworzyli cztery wartości, które do dziś brzmią świeżo:
- Ludzie i interakcje ponad procesy i narzędzia
- Działające oprogramowanie ponad obszerną dokumentację
- Współpraca z klientem ponad negocjowanie kontraktów
- Reagowanie na zmiany ponad podążanie za planem
Co do samej nazwy - „Lightweight" miało negatywne konotacje („brzmi jak banda wątłych lekkoduchów próbujących sobie przypomnieć, jaki jest dzień tygodnia" - jak to określił Cockburn). Rozważano też słowo „Adaptive". Ale firma i metoda Jima Highsmitha nazywała się "Adaptive", więc w środowisku konsultatnów software'owych... rozumiecie. Propozycja odpadła ;-) Ostatecznie wybrano Agile. Martin Fowler (Brytyjczyk) wyraził co prawda pewną obawę co do mocy marketingowej wybranego słowa:
„Większość Amerykanów nie wie, jak wymówić słowo agile".
Ale i tak nazwa została.
Co się naprawdę zmieniło przez 25 lat
Dobre wieści: tworzenie software'u jest dziś nieporównywalnie lepsze niż w 2001 roku. I to w dużej mierze zasługa idei, które Agile Manifesto zebrał w jednym miejscu.
Wtedy Continuous Integration było radykalnym pomysłem z XP. Dziś CI/CD to standard. Wtedy deploy raz na kwartał, czy pół roku był normą. Dziś najlepsze organizacje deployują wiele razy dziennie. Wtedy testy automatyczne były egzotyczną praktyką entuzjastów. Dziś bez nich nie wyobrażamy sobie poważnego produktu. Infrastructure as Code, konteneryzacja, cloud-native architecture, trunk-based development - to wszystko wyrosło z ducha zwinności i eliminowania marnotrawstwa w procesie wytwarzania.
Program badawczy DORA (ponad 39 000 profesjonalistów w ponad dekadzie badań, opisanych m.in. w książce Accelerate) potwierdza to danymi: organizacje o najwyższej wydajności osiągają deployment wiele razy dziennie, lead time poniżej jednego dnia i jednocześnie niski change failure rate. Szybciej i stabilniej - to nie jest kompromis, to efekt dobrych praktyk inżynierskich.
Widzę tę zmianę też u moich klientów. W G2A skróciliśmy czas dostarczania (Time-to-Market) pięciokrotnie - z 214 do 40 dni. W tym roku firma osiąga najlepsze wyniki przychodowe (Revenue) w historii. To nie przypadek - to efekt zmiany systemu pracy, odblokowania ludzkiego potencjału i przepływu wartości.
Da się. Naprawdę da się. Delivery jako dyscyplina inżynierska przeszedł w ciągu 25 lat ogromną drogę. I oczywiście - wiele organizacji nadal ma problemy ze strukturą zespołów powodującą mnóstwo marnotrawstwa: przestoje i kolejki, wysoki WIP, długie cykle integracji, dużą inwentorykę kodu i błędy wynikające z integrowania zbyt późno. Pisałem o tym szczegółowo w artykule o problemach z delivery. Ale trend jest jednoznacznie pozytywny - firmy, które poważnie podchodzą do zmiany systemu pracy, osiągają spektakularne rezultaty.
Ale teraz pojawia się prawdziwe pytanie
Skoro delivery jest coraz lepszy - co jest dziś faktycznym wyzwaniem? I tu dochodzimy do czegoś, co moim zdaniem niewielu ludzi w branży naprawdę rozumie - a co jest kluczem do następnych 25 lat.
Większość firm traktuje Agile jako metodę usprawnienia delivery. Szybsze dostarczanie ficzerów. Przewidywalność sprintów. Velocity jako miara sukcesu. „Jak dostarczać szybciej?" - to pytanie, które słyszę najczęściej od nowych klientów.
Ale to jest fundamentalne niezrozumienie tego, o co chodziło twórcom Agile Manifesto.
Spójrzmy na pierwszą zasadę z dwunastu:
„Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
Kluczowe słowo to nie „delivery". Kluczowe słowo to „valuable".
Agile nie powstał po to, żeby szybciej dostarczać ficzery. Agile powstał, żeby szybciej odkrywać, co jest wartościowe - i mieć lekkość w zmianie kierunku, gdy okaże się, że to, co budujemy, nie jest tym, czego potrzebuje rynek.
Krótkie cykle dostarczania to nie cel. To narzędzie do uczenia się. Dostarczasz szybko, żeby szybko się dowiedzieć, czy to ma sens. A druga kluczowa zasada?
„Welcome changing requirements, even late in development."
To nie jest zasada o elastycznym backlogu. To jest zasada o tym, że cały sens istnienia zwinnej organizacji polega na umiejętności zmiany kierunku, gdy dowiesz się czegoś nowego. Bez komitetów, zatwierdzeń, marnowania czasu na decyzje ludzi, którzy i tak nie pracują na codzień przy tworzeniu produktu.
Innymi słowy: Agile to nie jest o delivery. Agile to Value Discovery - odkrywanie wartości poprzez krótkie cykle dostarczania, uczenia się i łatwość zmiany kierunku.
I właśnie dlatego dziś, gdy delivery jest coraz lepszy, największym wyzwaniem staje się Discovery - umiejętność znajdowania właściwych Szans Produktowych (Product Opportunities).
Odpowiedź na pytanie „co budować?" stała się trudniejsza i ważniejsza niż „jak budować szybciej?".
Gdzie branża zabłądziła - i jak wraca na ścieżkę
Oczywiście, nie wszystko w historii Agile'a poszło idealnie. Craig Larman opisał w swoich Prawach Zachowań Organizacyjnych mechanizm, który widzieliśmy wielokrotnie: „Każda inicjatywa zmian zostanie zredukowana do zredefiniowania nowej terminologii, aby znaczyła w zasadzie to samo co obecne status quo."
Scrum w wielu firmach stał się dwutygodniowym mini-waterfallem. Product Owner stał się nową nazwą dla Analityka Biznesowego. A SAFe (Scaled Agile Framework) - najbardziej popularny framework do skalowania - w wielu implementacjach to waterfall z nowymi nazwami ceremonii: planowanie kwartalne, release trainy zarządzane top-down, obsesja na punkcie przewidywalności.
Klasyczny mem branżowy: „I don't always do Agile, but when I do, I do it like waterfall." :)
Ale - i to jest ważne - branża się tego uczy. Coraz więcej liderów widzi, że Scrum na poziomie jednego zespołu to za mało. Że certyfikat to nie transformacja. Że prawdziwa zmiana wymaga zmiany struktury organizacyjnej, a nie tylko nazewnictwa ról, "kołczowania" i facilitacji spotkań.
Marty Cagan i SVPG (Silicon Valley Product Group) wykonali ogromną robotę, odświeżając tę samą ideę pod nazwą Modelu Produktowego. Cagan otwarcie mówi, że większość organizacji to „feature factories" - fabryki ficzerów na zamówienie. I proponuje model oparty na decyzyjnych zespołach produktowych, ciągłym Product Discovery i orientacji na outcome'ach zamiast output'ach.
Cagan niby "opluwa" Agile, ale mówi dokładnie to samo, co twórcy Agile Manifesto - tylko lepszym językiem i z adresatem skierowanym nie do deweloperów, ale do liderów biznesowych. Ogólny kierunek jest cały czas ten sam: budować lepsze, bardziej wartościowe produkty - szybciej się ucząc, co jest wartościowe.
AI: turbosprężarka, ale do czego?
Jednocześnie żyjemy w erze sztucznej inteligencji. I tu widzę fascynującą szansę.
AI to potężne narzędzie do generowania kodu, analizy danych, syntezowania wyników badań użytkowników, automatyzacji powtarzalnych zadań. Organizacje, które mądrze wdrożą AI, mogą radykalnie przyspieszyć zarówno Discovery, jak i Delivery.
Ale jest warunek, o którym mało kto mówi.
Prawdziwa potęga tkwi w Discovery boostowanym przez AI. Zespoły, które potrafią szybko formułować hipotezy produktowe, walidować je z użytkownikami, analizować dane i podejmować decyzje - te zespoły z AI stają się niesamowicie skuteczne. Mogą w ciągu tygodnia przerobić więcej Szans Produktowych niż tradycyjna organizacja w kwartale.
Ale to zadziała jedynie w odpowiedniej strukturze organizacyjnej - z zespołami cross-funkcyjnymi, krótkimi pętlami zwrotnymi i realnymi uprawnieniami do podejmowania decyzji. AI bez dobrego org designu to turbosprężarka zamontowana w samochodzie z przekrzywionymi kołami. Moc jest, ale daleko nie zajedzie.
O tym, dlaczego struktura organizacyjna jest fundamentem każdej transformacji, pisałem w artykule o grze w szachy warcabami.
Co będzie kolejnym Agile'em?
Myślę, że po zakończeniu obecnej fazy zachłyśnięcia się AI, organizacje zobaczą to, co wielu z nas widzi już teraz: najpierw zmień org design, a dopiero później boostuj prędkość.
Mam wielką nadzieję, że kolejnym „Agile'em" nie będzie żaden nowy framework ani kolejna fala certyfikacji, tylko dojrzalsze połączenie tego, czego nauczyliśmy się przez ostatnie 25 lat:
- Adaptive Org Design - projektowanie organizacji, w których struktura wspiera przepływ wartości, nie hierarchię kontroli. To podejście, które od lat stosuję z moimi klientami w ramach wielozespołowych transformacji opartych o LeSS (Large-Scale Scrum).
- Ciągłe Product Discovery boostowane przez AI - osadzone w zespołach, nie w osobnych działach. Zespoły, które same odkrywają, walidują i dostarczają - bez przekazywania pracy między silosami (tak! UX jest w zespole!)
- Krótkie cykle dostarczania i uczenia się - nie jako cel sam w sobie, ale jako mechanizm odkrywania wartości. Dokładnie to, o czym mówił Agile Manifesto od samego początku.
- Lekkość w zmianie kierunku - bo w świecie, który zmienia się szybciej niż kiedykolwiek, organizacja, która nie potrafi się adaptować, przegrywa. A ta, która potrafi - wygrywa.
To jest ten sam kierunek, o którym mówili twórcy Agile Manifesto w 2001 roku. Ten sam, o którym pisze Marty Cagan. Ten sam, który wynika z prac Larmana, Deminga, Senge i Seddona. Tylko teraz mamy lepsze narzędzia, lepsze dane i - co najważniejsze - 25 lat doświadczeń, które pokazują, że to naprawdę działa.
Podsumowanie
Dwadzieścia pięć lat temu siedemnastu praktyków napisało cztery wartości na kartce papieru. Ich przesłanie było proste: budujcie małymi krokami, uczcie się szybko, adaptujcie się do rzeczywistości i ufajcie ludziom, którzy wykonują pracę.
Tylko tyle i aż tyle.
Przez te 25 lat delivery przeszło rewolucję. Teraz czas, żeby ta sama rewolucja dotknęła sedna ruchu Agile - Discovery. Żeby organizacje nie tylko szybko budowały, ale przede wszystkim szybko odkrywały, co warto budować. Szczególnie, że AI otwiera wspaniałe możliwości analityczne.
Trzeba tylko umieć je zastosować. W odpowiedniej strukturze.
Z odwagą, aby zmienić system pracy, w którym rozkwitną zblokowane talenty.
Źródła i inspiracje
- Agile Manifesto (2001). agilemanifesto.org - Jim Highsmith, History: The Agile Manifesto
- Agile Alliance (2026). 25 Years Ago, a Manifesto Was Born - agilealliance.org
- NATO Software Engineering Conference (1968). Raport konferencyjny, red. Peter Naur i Brian Randell
- Standish Group (1994/1995). CHAOS Report
- Forsgren, N., Humble, J., Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps
- Larman, C. - Larman's Laws of Organizational Behavior, LeSS framework
- Cagan, M. (2024). Transformed - SVPG
- Reinertsen, D.G. (2009). The Principles of Product Development Flow
- Senge, P. (1990). The Fifth Discipline
- Seddon, J. - Freedom from Command and Control
Krzysztof Niewiński - Transformation Manager & Product Coach, ProductOrg.com Pomagam firmom budować wielozespołowy Model Produktowy, który skraca czas od pomysłu do wartości.