Waterfall, Agile, hybryda - która metoda zarządzania projektami jest najlepsza? #11

Cześć! Witaj w podcaście I See Project. Wejdź razem z nami do świata nieszablonowego zarządzania projektami. Cześć! Witamy w kolejnym odcinku podcastu I See Project. Dzisiaj wchodzimy na grząski grunt. Temat, który od lat dzieli środowisko zarządzania projektami. Waterfall, Agile czy hybryda? Która z metod jest najlepsza? A może to zależy? No właśnie, ile ludzi, tyle opinii. Często słyszymy, że Agile to jedyna słuszna droga, inni za to bronią Waterfalla, a jeszcze inni próbują łączyć obie metody. Porozmawiamy dzisiaj z Norbertem o zaletach i wadach każdego podejścia, przyjrzymy się przykładom z życia, no i spróbujemy dojść do jakichś wniosków, która z tych metod jest najskuteczniejsza.

No więc zacznijmy od początku Norbert. Na początku korzenie zarządzania projektami to waterfall, czyli podejście kaskadowe. Model ten był i jest stosowany od dekad, zwłaszcza on jest do dzisiaj stosowany w inżynierii, w budownictwie, w takich bym powiedział stabilnych, przewidywalnych właśnie branżach, ale też zdarza się, że jest w dużych projektach IT. I tu, dla krótkiego przypomnienia, czym jest waterfall, tam są sekwencje, etapy, jak na przykład analiza, projektowanie, implementacja, testowanie, są jakieś kamienie milowe i z grubsza wiemy, co chcemy osiągnąć, realizując taki projekt. To wszystko brzmi logicznie, Dawid, bo wszystko przede wszystkim jest zaplanowane od A do Z.

Tylko tyle, że jak coś pójdzie nie tak na późniejszym etapie, to wracanie do początku jest bardzo bolesne. I to jest, myślę, taka pierwsza bolączka właśnie metody waterfall, bo waterfall sprawdza się tam, gdzie mamy jasne wymagania i nie przewidujemy większych zmian w trakcie realizacji. I teraz pewnie jak nas ktoś słucha i tak myśli o swojej branży, to gdzieś tam w głowie ma ta, u mnie nie ma zmian. Być może są takie branże, które są bardziej przewidywalne, natomiast Waterfall ma jakby swój udział w projektach z dużą stabilnością. Natomiast tutaj pojawia się pytanie, co jeśli klient w połowie chce zmienić połowę funkcjonalności, na przykład nowego oprogramowania IT.

No i tutaj właśnie pojawia się ten kluczowy problem. Waterfall to podejście, które zakłada, że wymagania są dobrze zdefiniowane na początku, czyli tej pracy początkowej jest naprawdę dość dużo, bo zmiany w trakcie projektu są trudne i kosztowne. To może być właśnie duży problem pod kątem zmian, które pojawiają się w trakcie projektu, zwłaszcza w dynamicznych branżach, gdzie rynek, technologia czy same wymagania klienta mogą się zmieniać w trakcie realizacji tego projektu. No i widzisz, i właśnie w takich projektach, gdzie zmienność jest duża, waterfall jest wyzwaniem. Bo jak masz do czynienia z projektem, który będzie ewoluował, gdzie klient może zmieniać zdanie, to takie podejście niestety może być nieefektywne. Często trzeba wrócić do początku, co jak wiesz oznacza czas i pieniądze wyrzucone w błoto po prostu, bo jakaś część pracy nasza nie zostaje wykorzystana.

A nie mówimy tu o małych zmianach często, bo to są duże zmiany, często dodatkowe funkcjonalności, jak powiedziałeś, albo w ogóle zmiana kierunków, w jakich chcemy rozwiązać problem. No i to jest właśnie główna krytyka podejścia. Waterfall uważany jest za metodę sztywną. On się doskonale sprawdzi w projektach, gdzie od początku mamy zdefiniowane, przewidywane i jasno określone wymagania, np. duże budowlane inwestycje, produkcja jakiegoś sprzętu, jakiejś maszyny, gdzie zmiany w trakcie realizacji są naprawdę wyjątkiem niż normą i takim, bym powiedział, codziennością. I tutaj, Dawid, pojawia się pytanie. Czy to znaczy, że Waterfall jest kompletnie nieprzydatny w projektach IT, zwłaszcza tych bardziej dynamicznych?

Moim zdaniem nie. Wciąż ma swoje miejsce, ale nie w każdej sytuacji. I tutaj to nasze popularne to zależy. Przyznam, że w ostatnich latach dość często spotykam się z przypadkami, gdzie Zbyt sztywne podejście do waterfall kończy się fiaskiem. Na przykład właśnie w firmach IT, będąc w tym sektorze, które pracują nad oprogramowaniem, zmiany są po prostu nieuniknione. Ta praca z klientem bardzo często wiąże się z tym, że te zmiany się pojawiają. Mimo że nie jesteśmy w stanie tego przewidzieć na starcie, No to prędzej czy później gdzieś będziemy musieli te zmiany wprowadzać i tutaj waterfall staje się naprawdę problematyczny. Warto zrozumieć natomiast, kiedy waterfall się sprawdzi, a kiedy lepiej sięgnąć po bardziej elastyczne podejście, które będzie w stanie odpowiedzieć na zmieniające się potrzeby projektu.

I tutaj, Dawid, powstał właśnie Agile. To podejście, Zakłada, że nie wszystko da się przewidzieć na starcie, czyli to jest taka konkretna alternatywa do tego, o czym do tej pory rozmawialiśmy, czyli Waterfalla. Tutaj pracujemy iteracyjnie, mamy sprinty, feedback, dostarczanie wartości małymi krokami, czyli to takie podejście step by step, kanban, wszystko pod hasłem bądźmy zwinniejsi. No i ta zwinność świetnie działa w dynamicznych środowiskach, czyli wiesz, startupach, software house'ach, czy firmach, gdzie rozwijamy produkt w odpowiedzi na to, czego oczekują nasi użytkownicy, nasi klienci. Ale, jak zawsze, Agile wymaga dużej dyscypliny, to znaczy uważam, że uważa bardzo dużego zaangażowania zespołu, no i dojrzałości organizacyjnej.

Agile nie pasuje do każdego produktu i do każdego projektu. Dzisiaj próbuje się na siłę odejść od tego, że waterfall to przestarzała metoda, a już Agile jest jedyną odpowiedzią i zbawieniem na projekty. No bo jak masz regulacje prawne, jak masz procedury bezpieczeństwa czy projekty o bardzo określonym budżecie i zakresie, to Agile naprawdę będzie trudny do wdrożenia. Może wtedy warto wrócić do waterfalla? Dlatego Agile to świetne narzędzie, ale też niezłoty graal, mam wrażenie. Jeśli firma nie jest gotowa na zmianę sposobu myślenia albo branża tej firmy po prostu wymaga troszeczkę innego podejścia, bardziej ustrukturyzowanego, gdzie mamy etap po etapie, rozplanowane, to są w jakimś stopniu powtarzalne projekty, tutaj zdecydowanie Waterfall.

Natomiast myślę, że lepiej nie udawać, że stosuje się Agile, bo efekt będzie odwrotny do zamierzonego. Podsumowując, Agile daje elastyczność, szybkość reakcji, ale wymaga dobrej organizacji i świadomości, kiedy rzeczywiście warto tę metodę stosować. Osobiście jestem fanem, bo nie lubię za dużo zmieniać w tył szczególnie, ale naprawdę trzeba to robić z głową na karku. No i właśnie, dochodzimy do tego złotego środka, czyli podejścia hybrydowego. Czy uważasz, że jest to możliwe, by połączyć strukturę z jednej strony Waterfalla, a z drugiej strony elastyczność Agila? No słuchaj, metody są po to, żeby je wykorzystywać, natomiast to my podejmujemy decyzje i myślę Dawid, że wracamy do tego kluczowego elementu każdego projektu, czyli ludzi.

My dostosujmy sobie metodę do tego, jakie mamy potrzeby, jakie mamy wymagania, w jakiej branży funkcjonujemy, z jakiego rodzaju projektami pracujemy, więc moim zdaniem jak najbardziej tak, choć trzeba to zrobić mądrze. Widzimy coraz więcej firm, które stosują waterfall na poziomie makro, czyli weźmy pod uwagę na przykład planowanie budżetu, strategiczne cele, a agile na poziomie operacyjnym, zespoły deweloperskie, sprinty, czyli można mieć plan, ale też reagować na zmiany. Pytanie tylko, kiedy hybryda faktycznie ma sens? Ja uważam, że hybryda ma sens, gdy masz złożony projekt, ale chcesz mieć możliwość dostosowania jego elementów. Pierwszy przykład z brzegu to bankowość.

Pewne rzeczy muszą być zgodne z regulacjami. Dzień dobry, Waterfall. Ale rozwój nowych funkcjonalności może być iteracyjny. Witamy Agile, nie? Więc możesz w ten sposób do tego podejść. I to jest... Moim zdaniem największa zaleta hybryd. Ona daje firmom pewien komfort. Nie musisz wybierać skrajności, tylko właśnie wybierasz ten złoty środek. I na przykład w dużych organizacjach widzę często taki model, że zarząd czy inwestorzy oczekują harmonogramu klasycznego, z budżetem, z milestone'ami, z etapami co się będzie działo. Ale zespoły w środku, zespoły projektowe na co dzień pracują w sprintach, lubią dostarczać wartość iteracyjnie. I to działa, o ile ludzie rozumieją, jak łączyć te dwa światy, bo problem pojawia się wtedy, gdy ktoś myśli, że można mieć wszystkie zalety Waterfalla i Agile'a, ale żadnych ich wad.

Wydaje mi się, że to jest jakby nieosiągalne, tak się nie da. Elastyczność Agile i struktura Waterfall muszą być ze sobą dobrze zsynchronizowane. I tutaj znowu wchodzimy na poziom dojrzałości organizacyjnej. Bo hybrydowe podejście wymaga dużej świadomości tego, co działa, a co nie. Złe wdrożenie może sprawić, że zamiast najlepszego z obu światów, dostaniemy najgorsze elementy obu metod, a tego zdecydowanie chcielibyśmy uniknąć. Zdecydowanie, bo wiesz, Musimy dojść do takiego momentu, że hybryda to jest świetne rozwiązanie dla organizacji, która z jednej strony potrzebuje pewnego rodzaju stabilności, no bo mamy harmonogramy, bo mamy planowanie budżetów roczne na przykład, bo mamy jakieś okresy sprawozdawcze do inwestorów, do klienta, a z drugiej strony jest potrzebna taka elastyczność, no bo na co dzień dzieje się tyle i zmiany są taką oczywistą rzeczą, która będzie się zdarzała,

Ale trzeba umiejętnie zarządzać tym połączeniem, żeby uniknąć chaosu, uniknąć konfliktów między tymi podejściami, bo zawsze znajdą się fanatycy Waterfalla i fanatycy Agila i trzeba spróbować ożenić te dwa światy. 11. Names mentioned. 12. Names mentioned.

Z tym ryzykiem ono zawsze istnieje. Znów, to jest też pytanie, jak bardzo jesteśmy dojrzali, jaki mamy apetyt na ryzyko. Czy mamy fundusze nieograniczone, że wiesz, możemy testować, bo to jest nowy projekt w ogóle, nowy produkt, coś innowacyjnego odkrywamy w firmie, no to wiadomo, że zagnieżdżenie się w Waterfallu będzie katastrofą i to się nie uda po prostu. No nie ma co się oszukiwać od początku i obiecywać inwestorom czy zarządowi, wiesz, że dowiezie się na dany moment takiej, takiej usługi. Bardzo mi się podoba to trzecie pytanie, które sformułowałeś, czyli jak dojrzały jest zespół i organizacja? No nie wyobrażam sobie, wiesz, jak masz zespół bardzo młody, juniorski, z krótkim doświadczeniem, czy nawet zespół z dużym doświadczeniem, wiesz, każdy zawodowo, ale krótko ze sobą pracujący, to będzie ciężko, no bo ten zespół musi się dograć, wiesz, musimy poznać jak pracuje Norbert,

I czwarte, super zastanowić się, co wpływa z zewnątrz. Inne projekty, które są w organizacji, inne zespoły, twój szef, ktoś inny z managementu, klienci, otoczenie też może wymuszać, że niestety będą wymagane jakieś terminy od ciebie i musisz waterfall wybrać. Albo nie będzie terminów, więc idziesz w kierunku agile'a albo w ogóle wybierasz jakieś takie zwinne metody. Bardzo mi się podoba ta lista czterech pytań, żeby zastanowić się nie tylko, wiesz, ja jako PM, ale z zespołem projektowym, nie? Zastanowić się z inwestorem, z klientem, no i dostosować to podejście,

Ale też wybrać taką drogę, która będzie po prostu najefektywniej, najskuteczniej dostarczała wartość, no bo tak na koniec to chodzi o to w projekcie, żeby dostarczyć jakąś wartość. Więc jak masz przewidywalny i dobrze opisany projekt, Waterfall myślę, że będzie fajnym wyborem. Jak masz zmiany nieuniknione i trzeba ciągle feedbackować się, czy to co robimy jest właściwe, czy klient jest zadowolony, no to Agile. Ale jak masz miks tych dwóch rzeczy i z jednej strony masz jakieś sztywne terminy, a z drugiej strony nie do końca w którym kierunku chcesz pójść, to pomyśl o hybrydzie. No i właśnie, ja osobiście przeprowadziłem wiele projektów, wielu uczestniczyłem wewnątrz, natomiast też jestem bardzo blisko jakby w tej pierwszej linii przy projektach naszych klientów.

Mam na myśli I See Project i program do zarządzania projektami, gdzie mamy przeróżne branże, od branży budowlanej, przemysłowej, produkcyjnej, aż po takie typowo właśnie zwinne, jak na przykład obecne IT, branża marketingowa. Powiem szczerze, że te projekty są bardzo różnie prowadzone. Są właśnie branże, gdzie zdecydowanie kierujemy się do Waterfalla. Dlaczego? Dlatego, że mamy to podejście kaskadowe, gdzie mamy w definiowane etapy i nawet na poziomie procesu sprzedażowego I See Project, całego oprogramowania dla firmy, My już na poziomie badania potrzeb jesteśmy w stanie od razu wyciągnąć etapy danego projektu. To jest projekt powtarzalny. Jeżeli jest to projekt powtarzalny, jeżeli jesteśmy w stanie wyłapać etapy i tam nie ma nieprzewidzianych teoretycznie sytuacji, zdecydowanie idziemy w kierunku Waterfalla i wbrew pozorom multum projektów dalej prowadzonych jest kaskadowo, więc to żaden wstyd, jeżeli będziemy chcieli prowadzić projekty w metodzie Waterfall, bo teraz bardziej popularny jest Agile.

I Ty też to wiesz i Wy to wiecie przy wdrażaniu oprogramowania, że trzeba zastanowić się dokładnie, gdzie my jesteśmy dzisiaj i co trzeba zmienić, bo niestety będziemy zmieniali nawyki pewne, pewne sztampowe podejścia, które dzisiaj mamy. I musimy trochę się przeswitchować. I to jest super, co powiedziałeś, że co branża ma swoją specyfikę pewnego rodzaju, pewne zależności i nie ma co na siłę się zmieniać, bo jest moda, tak? Agile, za chwilę będziemy, coraz częściej się słyszy właśnie o podejściach hybrydowych, a w ogóle mówi się, że za chwilę może Scranban albo jakieś, wiesz, połączenie Waterfalla i Agile'a jeszcze inne powstanie. No bo potrzebujemy i nie zabijajmy tych metod, które dzisiaj już mamy, czerpmy najlepsze praktyki.

To jest też to wartościowe, co dodałeś Norbert, żeby ze spokojem podejść, wybrać to, co jest też łatwe do wdrożenia na początek, zobaczyć, jak się z tym czujemy, czy to się sprawdza, czy rzeczywiście ten efekt jest lepszy niż pierwotny zakładany. To chyba bym powiedział, że tyle naszego podsumowania, bo pewnie temat jest bardzo duży i moglibyśmy wyszukiwać jeszcze dodatkowych plusów i minusów. Wydaje mi się, że na ten moment warto w ogóle zorientować się, że mamy te różne podejścia. Ja jestem w ogóle ciekaw doświadczeń naszych słuchaczy, czy to jest Agile, czy to jest Waterfall, czy to jest hybryda.

Zachęcam do takiej dyskusji z nami, bo łatwo nas znaleźć i skontaktować się, bo tak jak mówisz, firmy mają swoje podejścia, Ja też słucham na różnych, czy to konferencjach, szkoleniach, czy meetupach, jak to jest w tych firmach tak naprawdę, które na sztandarach niosą waterfall albo agile, a jaka jest rzeczywistość, więc chętnie dowiemy się też, jaka jest ta wasza rzeczywistość projektowa. Dokładnie. Piszcie do nas ze swoimi doświadczeniami. Dawid wspomniał o tym, jeżeli będziecie coś wdrażać, natomiast może jesteście już po wdrożeniach, może macie już swoje przemyślenia. Też jesteśmy tego bardzo ciekawi. Jeżeli macie pomysły na nowe odcinki naszego podcastu, chętnie weźmiemy je na warsztat, chętnie przedyskutujemy z Dawidem.