Waterfall (model kaskadowy) to sekwencyjne podejście do wytwarzania oprogramowania: wymagania → projekt → implementacja → testy → wdrożenie → utrzymanie, przy czym każda faza kończy się formalnym zatwierdzeniem, zanim ruszy następna. Wymagania zamraża się na początku, a późniejsze zmiany przechodzą przez formalny proces kontroli zmian.
Wbrew obiegowej opinii waterfall nie umarł. Analityk spotka go w zamówieniach publicznych (specyfikacja jest częścią przetargu), kontraktach fixed-price, branżach regulowanych i wszędzie tam, gdzie zakres naprawdę jest stabilny i znany z góry. W tych warunkach kaskada bywa uczciwsza niż udawana zwinność: dostawca wie, co wycenia, zamawiający wie, co odbiera.
W MediFlow waterfallowo poprowadzono wybór i wdrożenie systemu od zewnętrznego dostawcy: pełna specyfikacja wymagań (SRS) jako załącznik do zapytania ofertowego, wycena na jej podstawie, odbiór według matrycy zgodności z wymaganiami. Próba poprowadzenia tego „zwinnie" skończyłaby się sporem o to, co właściwie zamówiono - przy umowie z zewnętrzną firmą na konkretną kwotę ktoś musi wcześniej spisać, co wchodzi w cenę.
Częsta pomyłka: traktowanie waterfalla jako synonimu złego zarządzania. Model ma sens przy stabilnych wymaganiach; problem zaczyna się, gdy wymagania są niepewne, a mimo to zamraża się je na rok. Druga, częstsza na polskim rynku: hybryda zwana złośliwie „wagile" - formalnie sprinty i daily, ale zakres, budżet i termin zamrożone jak w kaskadzie. To łączy wady obu podejść: ceremonie agile bez elastyczności, którą miałyby uzasadniać.