Planować odkrycie czy odkrywać plan?
Waterfall vs Agile to nie wybór między starym a nowym ani między lepszym a gorszym. To dwa różne narzędzia odpowiadające na dwa różne pytania. Waterfall pyta: co dokładnie chcemy zbudować i jak to zaplanować od początku do końca? Agile pyta: czego się jeszcze musimy nauczyć, żeby dostarczyć właściwą wartość? Wybór między nimi zależy od natury problemu, nie od mody ani przyzwyczajeń zespołu.
Historia waterfall i Agile – skąd się wzięły te metodyki?
Zanim sięgniemy po narzędzie, warto wiedzieć, skąd pochodzi i do czego zostało zaprojektowane. To nie jest historia liniowa i właśnie o to chodzi.
W 1969 roku powstał PMI (Project Management Institute, pierwsza organizacja, która podjęła się standaryzacji zarządzania projektami. Rok później, w 1970 roku, Winston Royce opublikował artykuł opisujący sekwencyjny model wytwarzania oprogramowania, w którym kolejne fazy (analiza, projektowanie, implementacja, testowanie, wdrożenie) następują po sobie jak woda spływająca kaskadą: każda zaczyna się dopiero po zakończeniu poprzedniej.
Co istotne i często przemilczane: w tym samym tekście Royce wprost ostrzegał, że brak podejścia iteracyjnego generuje ogromne ryzyko. Ten model sekwencyjny przyjął się jednak jako standard przemysłowy nie dlatego, że Royce go polecał, ale dlatego, że pasował do logiki dużych organizacji i kontraktów rządowych. Przez dekady cytowano pierwszą część jego wywodu, ignorując zastrzeżenie autora.
W 1996 roku PMI opublikował pierwszą edycję PMBOK (Project Management Body of Knowledge), dziś w wydaniu ósmym (2025). Ten podręcznik stał się swoistą biblią project managera i usankcjonował waterfall jako dominujący sposób prowadzenia projektów: konkretny rezultat, konkretny czas, założony budżet.
Z kolei w lutym 2001 roku17 praktyków różnych metodyk (Scrum, Extreme Programming, Crystal i innych) spotkało się w górskim kurorcie Snowbird w stanie Utah i w ciągu dwóch dni sformułowali Manifest Agile. Niektórzy pytają: jak można coś takiego wymyślić w dwa dni? Otóż nie wymyślili. Scrum czy Extreme Programming powstały już w połowie lat 90. 17 praktyków, wywodzących się z różnych środowisk, postanowiło wspólnie wyrazić przekonanie, że tradycyjne podejście do realizacji projektów nie odpowiada wyzwaniom, z jakimi mierzyli się w swojej codziennej pracy.
Manifest nie stworzył zwinności, jedynie nazwał i ujednolicił to, co już działo się w praktyce. I tu widzę pewien wzorzec: w obu przypadkach najpierw mamy konkretne praktyki, a dopiero potem próbę ich zebrania i standaryzacji. To ważne, bo oznacza, że waterfall nie jest przestarzałym poprzednikiem Agile. To dwa, równoległe nurty odpowiadające na różne wyzwania.
Co to jest metodyka waterfall?
Waterfall (kaskada) to model prowadzenia projektu zakładający, że wymagania są wystarczająco znane na początku, by zaplanować wszystkie etapy aż do końca. Każda faza (analiza, projektowanie, implementacja, testowanie, wdrożenie) ma swoje wejście, wyjście i warunki odbioru. Zmiana jest wyjątkiem wymagającym formalnej zgody.
Kluczowa cecha waterfalla: koszt błędu rośnie wykładniczo wraz z fazą, w której zostaje wykryty. Błąd znaleziony w fazie analizy kosztuje symboliczną złotówkę. Ten sam błąd wykryty po wdrożeniu może kosztować stukrotnie więcej.
Kiedy waterfall ma sens?
Podejście kaskadowe sprawdza się, gdy spełniony jest co najmniej jeden z poniższych warunków:
| Czynnik | Przykład |
| Stabilne wymagania | Systemy regulowane prawem (lotnictwo, farmacja, finanse) |
| Wysoki koszt zmiany | Budowa mostu, produkcja hardware, centrum danych |
| Wymogi dokumentacyjne | Wdrożenie ERP z wymogami audytowymi |
| Rozproszony zespół | Gdy synchronizacja ciągła jest trudna lub niemożliwa |
Dobrym przykładem jest branża lotnicza. Wymagania określone przez prawo, kod pisany jeden do jednego zgodnie z wymogami prawnymi, zero zaskoczeń. To jest właśnie przypadek rynku regulowanego, gdzie waterfall nie tylko ma sens, ale jest jedyną rozsądną odpowiedzią. Podobnie farmacja czy hardware. Nie można przecież w trakcie produkcji kilku milionów sztuk stwierdzić, że robimy upgrade. To, co już wyprodukowane, jest wyprodukowane i stanowi koszt.
Ale, i tu jest sedno, waterfall w świecie dynamicznym, bez żadnej z powyższych przesłanek, to w czystej postaci teatr kontroli. Udajemy, że nad czymś panujemy, kiedy zmiany i tak się dzieją. Tam, gdzie koszt pomyłki jest wyższy od kosztu sztywnego planowania, powinniśmy poważnie rozważyć kaskadę. Tam, gdzie nie zmuszanie zespołu do formalnych change requestów przy każdej drobnej zmianie to przepis na frustrację i stratę czasu.
Co to jest metodyka Agile (zwinne podejście do projektu)?
Agile to podejście do prowadzenia projektu zakładające, że nie wiemy wszystkiego na początku i celowo budujemy tak, by uczyć się po drodze. Zamiast jednego dużego planu mamy ciągłe planowanie. Zamiast dostarczenia wszystkiego na końcu – regularne, przyrostowe dostarczanie wartości.
Manifest Agile z 2001 roku określa cztery fundamentalne wartości. To nie są hasła marketingowe, lecz cztery konkretne wybory, każdy z realnych konsekwencjami:
- 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
Jim Highsmith, jeden z 17 sygnatariuszy Manifestu Agile, opisał istotę zwinności tak: „Agile methodologies allow us to create change and respond to change in a way that reflects the business value we’re delivering.” Kluczowe słowo: wartość. Nie szybkość, nie brak dokumentacji.
I tu zatrzymuję się, bo to jest najczęstsze nieporozumienie, z jakim się spotykam. Manifest nie mówi, że dokumentacja jest zbędna. Mówi, że gdy produkt nie działa, priorytetem jest jego naprawa, a dokumentacja schodzi na drugi plan. Jeśli ktoś mówi „nie dokumentujemy, bo jesteśmy Agile” to albo nie rozumie manifestu, albo po prostu mu się nie chce. Żadna z tych opcji nie jest dobra.
Kiedy Agile ma sens?
- Wymagania są niejasne lub będą ewoluować
- Koszt zmiany jest stosunkowo niski
- Klient chce i może aktywnie współtworzyć produkt
- Szybkość uczenia się jest ważniejsza niż szybkość dostarczania gotowego produktu
- Rynek jest nieprzewidywalny (startupy, nowe produkty cyfrowe)
Niektórzy myślą, że Agile jest po to, żeby było szybko. Ale nie chodzi o szybkość dostarczania oprogramowania tylko o szybkość uczenia się. Netflix w 2011 roku podzielił usługę na DVD i streaming, tworząc osobną markę Qwikster. Klienci powiedzieli stanowcze nie. Po trzech tygodniach firma musiała się wycofać i przepraszać. Gdyby przetestowali ten pomysł wcześniej na małej grupie, zaoszczędziliby fortunę na późniejszych kampaniach wizerunkowych. To jest właśnie ta przewaga: szybkość uczenia się, nie szybkość kodowania.
Waterfall vs Agile – 5 kluczowych różnic
| Wymiar | Waterfall | Agile |
| Podejście do planu | Kontrakt – szczegółowy i wiążący od początku | Hipoteza – weryfikowana i doprecyzowywana w toku pracy |
| Zmiana | Formalny change request; zaburza plan i kosztuje | Trafia do backlogu i jest priorytetyzowana jak każde zadanie |
| Dostarczanie | Pełny produkt na końcu projektu | Regularnie, iteracyjnie i przyrostowo – każdy inkrement dodaje wartość |
| Ryzyko | Identyfikowane i zarządzane z góry (dane historyczne, rejestry ryzyk) | Ujawniane stopniowo – każda iteracja odsłania nowe ryzyka do zaadresowania |
| Rola klienta | Odbiorca pojawia się przy podpisaniu kontraktu i przy odbiorze | Współtwórca uczestniczy w przeglądach co iterację, jego feedback kształtuje produkt |
Zwrócę uwagę na jedną rzecz, która jest często pomijana przy tym porównaniu: wybór kolumny to nie jest wybór lepsze czy gorsze. To wybór tego, co najbardziej odpowiada naturze naszego przedsięwzięcia. I nie każdy klient, mówiąc wprost, chce być współtwórcą. Są tacy, którzy mówią: „ja chcę to, a jak to zrobicie, nie chcę nawet wiedzieć.” Z tym też trzeba się liczyć.
Matryca wyboru: waterfall, Agile czy hybryda?
Moje ulubione narzędzie diagnostyczne to dwuwymiarowa matryca. Zanim wybierzesz metodykę, oceń dwie zmienne:
- Oś X: jak bardzo znane są wymagania? (od niejasnych do precyzyjnie spisanych)
- Oś Y: jak kosztowna jest zmiana? (od taniej do bardzo drogiej)
Ta ostatnia ćwiartka (tania zmiana i znane wymagania) to naturalna granica, gdzie projekt przechodzi w proces. Gdy praca staje się powtarzalna i zależy nam na eliminowaniu strat oraz standaryzacji, mówimy już o czymś innym niż projekt. Pisałem o tym szerzej w artykule Projekt czy proces — czym się różnią i co wybrać?
6 najczęstszych pułapek przy wyborze metodyki
Największe błędy, jakie widzę, nie wynikają ze złej woli. Wynikają z braku zadania właściwego pytania na początku: jak bardzo jesteśmy pewni tego, co chcemy dowieźć, w jakim czasie i jak bardzo jesteśmy usztywnieni regulacjami?
1. Dobór metodyki przez nawyk, nie przez analizę
To chyba najdroższy wybór, bo niepodejmowany świadomie. Firma od lat prowadzi projekty kaskadowo, przychodzi nowy projekt i automatycznie: robimy jak zawsze. Po roku okazuje się, że wymagania zmieniały się trzykrotnie, a zespół spędził więcej czasu na procedurze change request, niż na samej zmianie.
2 Cargo kult – forma bez treści
To termin z obserwacji antropologicznych z czasów II wojny światowej. Na Pacyfiku, gdzie stacjonowali Amerykanie, mieszkańcy wysp widzieli jak samoloty przywożą zaopatrzenie dla żołnierzy. Po wojnie, gdy samoloty przestały przylatywać, zaczęli budować z bambusa imitacje lotnisk, pasów startowych i wież kontrolnych, żeby przyciągnąć te towary z powrotem. Wpisz sobie „kult cargo” w wyszukiwarce obrazów – zdjęcia mówią same za siebie.
Organizacje wdrażające Agile bez zrozumienia działają dokładnie tak samo: kopiują zewnętrzną formę (sprinty, daily standup, backlog), nie rozumiejąc po co, i w efekcie mają dużo rytuału, zero zwinności. Wszyscy są tacy zwinni, tylko tej zwinności tak naprawdę nie ma.
3. Agile jako wymówka do braku planowania
Wspominałem o tym, więc pokrótce: Agile zmienia horyzont planowania, nie eliminuje go. To jest bardzo istotne. Zwinność w gruncie rzeczy wymaga często wyższej dyscypliny, niż kaskada zamiast jednego raportu na końcu projektu mamy codzienne synchronizacje i przeglądy co iterację.
4. Kaskada jako wymówka do unikania rozmowy z klientem
Ta wymówka nie zastępuje rozmowy, tylko odkłada ją w czasie i powiększa rachunek. W modelu tradycyjnym klient pojawia się dwa razy: przy podpisaniu kontraktu i przy odbiorze. Wszystko pomiędzy to praca za zamkniętymi drzwiami. Czasem to zaleta – brak zmian. Częściej ryzyko, bo dużo możemy nie odkryć.
5. Mieszanie podejść bez świadomości
Hybryda może być najmądrzejszym wyborem albo największym chaosem. Zależnie od tego, czy ktoś ją świadomie zaprojektował, czy tylko zgodzono się na nią przez brak weta. Widziałem to wiele razy: projekt startuje zwinnie, mamy sprinty, backlog, daily. W połowie klient naciska na datę końcową i stały zakres. Backlog się zamraża, sprinty stają się etapami, nikt tego nie nazywa, nikt nie zmienia kontraktu, nikt nie informuje zespołu. Efekt: chaos metodyczny, chaos ról, Scrum Master staje się poganiaczem zamiast edukatorem.
6. Fixed price Agile – zwinność w sztywnym kontrakcie
Jeszcze jako freelancer, gdy rozmawiałem z trudnym klientem, rysowałem trójkąt. W rogach pisałem: szybko, tanio, dobrze i mówiłem: wybierz dwa. To nie jest metoda sprzedażowa, uprzedzam, sam nigdy nie byłem sprzedażowcem i to pewnie było widać. Ale oddaje istotę problemu.
Agile i Fixed Price nie są sprzeczne, ale wymagają świadomego przeprojektowania kontraktu. Nie da się mieć jednocześnie sztywnej ceny, sztywnego czasu i zmiennego zakresu, jeśli klient nie rozumie, że rezygnuje z kontroli nad detalami na rzecz dostarczanej wartości.
Sprawdzone podejścia:
| Model | Na czym polega |
| Stały budżet, zmienny zakres | Klient określa budżet, zakres jest priorytetyzowany iteracyjnie |
| Faza Discovery poza kontraktem | Odkrycie wymagań przed podpisaniem głównego kontraktu |
| Time & Material z górnym limitem | Elastyczność przy zachowanym caps na całkowity koszt |
Podsumowanie
Dobry lekarz nie przepisuje lekarstwa przed badaniem. Zanim wybierzesz metodykę, sprawdź jaki masz problem, bo kaskada i zwinność to odpowiedzi na różne pytania.
Trzy rzeczy, które chcę, żebyś zapamiętał:
- Diagnoza przed wyborem. Matryca wymagania/koszt zmiany to minimum, od którego warto zacząć.
- Obie strony mają rację- w odpowiednim kontekście. Ani waterfall nie jest reliktem, ani Agile nie jest panaceum.
- Największe ryzyko to brak świadomości. Kult cargo, nawykowy dobór metodyki, nienazwane hybrydy to nie zła wola, to brak zatrzymania się i zadania pytania: dlaczego właśnie tak?
Artykuł powstał na podstawie wewnętrznego szkolenia z cyklu zarządzania projektami prowadzonego w fireup.pro. To druga część serii. W pierwszej omówiłem różnicę między projektem a procesem. W kolejnej przyjrzymy się konkretnym frameworkom: Scrum, Kanban i podejściom do skalowania.
