Agile i waterfall – łączyć czy nie?

Czy jest sens łączyć podejście zwinne i tradycyjne kaskadowe (tzw. waterfall)? Wskazujemy dziewięć cech odróżniających agile i waterfall. Pokazujemy potencjalne korzyści, jak i zagrożenia wynikające z łączenia tych dwóch sposobów pracy. 

Wątek ten wypłynął podczas jednej z naszych rozmów z klientem i postanowiliśmy podzielić się naszymi przemyśleniami. Rozważamy o perspektywie łączenia obu podejść, poprzez dodanie zwinności do istniejącego w organizacji działania w sposób kaskadowy.

Poniżej celowo prezentujemy dosyć spolaryzowane podejścia . Chcemy wyostrzyć różnice między tymi modelami, bez odnoszenia się do źle wdrożonych podejść. Ten materiał nie jest ani o źle prowadzonej zwinności ani o toksycznej pracy kaskadowej.

Agile i waterfall – jakie są różnice między nimi?

Różnice w obu podejściach można ująć w 9 wymiarach:

1. Moment definiowania ostatecznego kształtu rozwiązania

Podczas pracy w sposób zwinny, produkt powstaje stopniowo, pomysł na docelowe rozwiązanie wyłania się wraz z postępem czasu. Natomiast w podejściu waterfallowym zazwyczaj precyzyjnie definiuje się produkt (wraz z zakresem prac) już na samym początku działań.

2. Moment dostarczenia wartości

W dobrze realizowanym podejściu zwinnym wartość dostarczana jest w sposób ciągły, przez cały czas trwania danej inicjatywy. Z kolei w waterfallu bardzo często wartość pojawia się pod koniec lub na faktycznym końcu inicjatywy.

3. Kontakt z użytkownikiem

Zwinność cechuje się tym, że dba się o bliski i częsty kontakt z użytkownikiem produktu. Z kolei w waterfallu zespół nie ma zazwyczaj bezpośredniego kontaktu z użytkownikiem, a kontakt ten odbywa się przez pośredników. 

4. Nastawienie do zmiany

Agile wprost zakłada, że zmiany są dobre i trzeba wykorzystać okazję do ulepszenia produktu i procesu. W klasycznym podejściu zmiany zazwyczaj nie są mile widziane. Dużo energii poświęca się początkowo, aby dobrze określić zakres i zaplanować pracę, aby ewentualnej zmiany można było uniknąć. Dba się też mocno o sformalizowane podejście do zarządzania zmianą w projekcie, co w praktyce zniechęca do prób ich wprowadzania.

5. Interakcje w zespole

Zwinność skupia się na zespole, jest on w centrum i interakcje między osobami zaangażowanymi w inicjatywę są ważne. Waterfall koncentruje się na procedurach i procesach, zakładając, że poukładane i sformalne praktyki podnoszą szansę sukcesu i obniżają ryzyka związane z zależnościami pomiędzy członkami zespołu. 

6. Odpowiedzialność za końcowy sukces

W agile to cały zespół odpowiada za finalny rezultat prac. Z kolei w podejściu kaskadowym pracę rozdziela się pomiędzy różne osoby i to im przydziela się odpowiedzialność za dany wycinek pracy. Najczęściej powołuje się też pojedynczą osobę albo wąskie grono zarządzające całością przedsięwzięcia i to w tych osobach szuka się realnej odpowiedzialności za efekt.

7. Rola managera zespołu

W agile manager kreuje środowisko pracy dla zespołu, aby miał on warunki do sprawnego dostarczania wartości. W waterfallu natomiast rolą managera bywa (w zależności od zasad zarządzania w danej firmie):

• planowanie i rozdzielanie zadań
• koordynowanie pracy pomiędzy osobami lub zespołami
• rozliczanie wykonania zadań i ich jakości
• weryfikacja standardów i zgodności z procedurami.

8. Integracja składowych produktu

Zwinność zakłada jak najczęstsze integrowanie małych kawałków pracy, aby jak najczęściej uzyskiwać kolejne wersje działającego produktu. W podejściu kaskadowym integracja zwykle odbywa się na końcu działań, blisko wdrożenia ostatniej wersji rozwiązania.

9. Usprawnienia

W agile doskonalenie odbywa się w trybie ciągłym i przebiega w trakcie prac (np. na koniec każdej iteracji). Klasyczny model kaskadowy zazwyczaj usprawnienia przewiduje w postaci jednorazowej sesji lessons learned na koniec projektu. 

Czy łączenie agile i waterfall ma sens?

Pokazaliśmy powyżej cechy odróżniające oba podejścia – agile i waterfall – od siebie. Czy zatem jest sens je łączyć w ramach jednej organizacji lub nawet pojedynczego projektu?

Obaj mamy doświadczenie w pracy w podejściu waterfall i przez pewien czas byliśmy jego zwolennikami. Gdy poznaliśmy agile, zmieniliśmy swoje podejście, zdecydowanie odrzucając kaskadowość. Wraz z doświadczeniem zaczęliśmy dostrzegać jednak sens łączenia obu modeli. Łączenie to zawsze zależy mocno od kontekstu i sytuacji danej organizacji. 

Głównym powodem do łączenia modeli jest transformacja zwinna, gdzie etap współegzystowania agile i waterfall traktujemy jako coś przejściowego. Może to być niewygodna ale nieunikniona faza ewolucji danej organizacji.

Dlaczego nie łączyć agile i waterfalla?

Wykluczające się założenia podejść agile i waterfall

Przede wszystkim agile i waterfall mają różne fundamentalne założenia, które często się wykluczają.

Przykładowo trudno jest połączyć iteracyjność z unikaniem zmiany. W pracy iteracyjnej wraca się do pewnych elementów produktu, by je poprawiać albo rozbudowywać. W waterfallu ceni się dobrze przygotowany plan, który sprawnie zrealizowane oznacza, że zmiany nie będą potrzebne.

Innym przykładem wykluczających się założeń jest kwestia współpracy. W agile stawia się na zespołowość. Trudno mówić o zwinności w organizacji, w której procesy zabraniają ludziom blisko współpracować, polegać na sobie i pomagać. Podejście waterfallowe może się sprawdzać bez bezpośredniej współpracy członków zespołu, zamiast której ważną rolę odgrywa koordynator. Takim koordynatorem może być na przykład kierownik projektu, wskazany lider zespołu czy manager jednostki.

Agile łączony z waterfallem może nie dawać zauważalnej różnicy

W organizacjach, w których są niekorzystne zasady funkcjonowania i środowisko pracy, inspiracja zwinnością może niewiele zmienić. Szkoda tracić czas na próbę wdrażania elementów zwinności, wprowadzać zamieszanie i inwestować pieniądze w szkolenia. W skrajnych sytuacjach może to być jeszcze gorsze niż zostawienie wszystkiego tak, jak działało do tej pory.

Przykładem takiej sytuacji jest przypadek, gdy wdraża się elementy zwinności do pracy zespołu, ale nie zmienia się nic w procesie planowania prac w dłuższych horyzontach czasowych (np. z góry zaplanowana lista projektów na kwartał / rok / kilka lat). Trudno liczyć na efekty eksperymentów z agile, jeśli z dużym wyprzedzeniem i bez zespołu, cały projekt już przeanalizowano i zaplanowano. Możliwość zmiany założeń projektowych jest ograniczona a czasami wręcz niemożliwa.

Fasadowe zmiany bez zmiany sedna funkcjonowania procesu

Przestrzegamy też przed łączeniem agile i waterfall, jeśli wiesz, że agile będzie tylko fasadą zmian. Pojawią się nowe stanowiska, powstanie Backlog Produktu, ale istota działania procesu wytwórczego czy projektowego nie ulegnie zmianie. Nie wystarczy nazwać grupę ludzi Zespołem Scrumowym, bez zadbania o ich zespołowość czy współpracę z Product Ownerem. W takiej sytuacji trudno będzie o uzyskanie efektów, jakie można osiągnąć, gdyby zadbać o wszystkie niezbędne elementy głębszej zmiany.

W szczególności nie oczekuj rezultatów, jeśli po prostu zmienisz nazwy już istniejących stanowisk (analityk dostaje etykietę Product Owner, a kierownik zespołu to od teraz Scrum Master) lub spotkań (cotygodniowe spotkania będą określane jako Sprint Review). Gdy realne zmiany nie zajdą także w działaniach zespołów oraz managerów, to będziecie oszukiwać siebie i otoczenie.

Rozbudzenie i późniejszy zawód oczekiwań

Uważaj też na “koszty utraconych nadziei”. Pojawią się one, gdy przez pewien czas współegzystowanie agile i waterfalla będzie przynosiło pewne zmiany ku lepszemu. Wśród osób zaangażowanych w zmianę tlą się zazwyczaj nadzieje na jeszcze głębszą transformację, ale w pewnym momencie korzystne trendy się zatrzymują. To może negatywnie wpłynąć na osoby, które uwierzyły w zmianę i zdążyły się w nią mocniej zaangażować.

Jeśli organizacja postanowi wycofać się ze zmian w stronę agile i waterfall ponownie będzie dominować, osoby te stracą motywację, a nawet mogą zdecydować się na odejście z firmy. Dla organizacji to może być duża strata, bo mogą to być najbardziej zaangażowani pracownicy, którzy są ogromną wartością w procesie projektowym.

Zamykanie drogi do faktycznego skorzystania z dobrych praktyk

Łączenie podejścia zwinnego z podejściem kaskadowym może doprowadzić do sytuacji, w której zużyją się pewne pojęcia. Często spotykamy się z tym u klientów, gdzie słyszymy, że „już robili Scruma” lub „już próbowali zwinności”, ale w ich przypadku to nie działało.

Najczęściej to nie jest tak, że ta firma jest naprawdę szczególnym przypadkiem, w którym nowoczesne metody zarządzania nie zadziałają. Zwykle jest to po prostu kwestia tego, że to, co było już testowane, zostało wdrożone w ograniczony czy powierzchowny sposób i nie miało szans zadziałać. To niestety będzie wymagało odczarowania niektórych pojęć i nadania im nowego kontekstu.

Unikanie rozmowy o głębszych usprawnieniach procesu

Odradzamy łączenie podejść agile i waterfall, jeśli ma to doprowadzić do zaprzestania rozmów o prawdziwej zmianie. Jako przykład podamy przypadek banku, o którym słyszeliśmy na pewnej konferencji. Pracownicy tego banku zaangażowani w transformację zwinną, już na samym początku zmian usłyszeli, że mogą wdrażać agile, ale cały proces zarządzania portfelem, projektem i organizacją zostanie bez zmian. Nawet jeśli powstały tam Zespoły Scrumowe, próbujące pracować trochę inaczej, wciąż zderzały się z niezmienioną strukturą i zasadami działania projektów.

Oczywiście na początku transformacji zwinnej i być może przez długi czas jej trwania będziesz łączyć oba podejścia. Jeśli jednak już na samym początku zakładasz sobie taki stan rzeczy na zawsze i określasz, czego nie będziecie poddawać transformacji, to takie łączenie naszym zdaniem mija się z celem.

Kiedy łączyć agile i waterfall?

Oprócz argumentów przeciw łączeniu obu podejść, mamy też 3 konkretne argumenty za tym, że jednak warto ostrożnie próbować korzystać z dobrodziejstw każdej z metod.

Każde usprawnienie zasad prowadzenia prac ma sens

Czasem nawet niewielka zmiana może być korzystna dla zespołu, produktu czy organizacji. Co prawda trochę tu przeczymy samym sobie z wcześniejszego akapitu, jednak z pragmatycznego punktu widzenia czasem warto spróbować. Jeśli nie zachodzą jakieś radykalne sprzeczności w założeniach albo celach działania zespołu, to możesz skorzystać z łączenia zwinności z waterfallem poprzez lepszą współpracę w zespole, lepsze usprawnianie się czy częstsze dostarczanie wartości. Nawet jeśli nie będzie to idealne, to jeśli można skorzystać z jakiejś drobnej i ewidentnie korzystnej zmiany, to czemu by tego nie zrobić.

Czasami specyfika danego projektu wymaga elementów agile i waterfall

Da się pogodzić zwinną realizację bardzo sztywnie zdefiniowanego projektu. Nie będzie to zwinność w czystej postaci – można się zainspirować agile, ale nie zrealizuje się jego wszystkich wartości i fundamentalnych zasad. Temat poszerzyliśmy choćby w materiale “Praca na termin w agile”. Jeśli na przykład dysponujesz bardzo sztywnym budżetem, wciąż możesz korzystać z części praktyk zwinnych, które będą np. zapewniały wyższą jakość poprzez automatyzację testów na bardzo wczesnym etapie.

Mały krok we właściwą stronę 

Niezależnie od tego, jaki jest dzisiejszy stan procesu, zawsze warto szukać większej zwinności. W zasadzie nie istnieje coś takiego, jak absolutna zwinność, rozumiana jako osiągnięty stan ostateczny. Każda organizacja będzie mocniejsza w jednym wymiarze, a słabsza w innym. Ponadto nie ma co porównywać się z innymi. Porównujcie się w swojej organizacji sami do siebie z przeszłości. Najważniejszy postęp jest w różnicy między tak, jak działaliście kiedyś, jak działacie teraz i czy możecie być jeszcze trochę lepsi w którymś z wymiarów.

Przestrogi przy łączeniu agile i waterfall’a

Jeśli zdecydujesz się w organizacji na łączenie podejścia zwinnego z waterfallem, to pamiętaj o tym, że:

• łączenie agile z waterfallem prawdopodobnie przyniesie mocno ograniczone korzyści. Łatwo jest się zainspirować zwinnością, jednak mocne i dobrze udowodnione rezultaty pozytywne z agile wynikają z głębokiej zmiany. Skopiowanie tylko wybranych praktyk zapewne przyniesie jakieś rezultaty, ale będą one ograniczone i w szczególności mało widoczne w wyniku finansowym firmy. 
• należy zapewnić zestaw minimalnych warunków, by godzić agile i waterfall. Bez tego istnieje duże ryzyko, że rezultaty będą po prostu gorsze. Przykładowo, pomimo posiadania sztywnego zakresu na starcie, możesz się umówić na to, że będziecie się usprawniać w trakcie i będzie zapewnione wsparcie managementu do eksperymentowania z procesem współpracy.
• ważne jest zadbanie o punkty styku pomiędzy zespołami o różnym podejściu. Punkt ten nawiązuje do poprzedniego materiału, w którym opisaliśmy podejście do zależności zewnętrznych. Punkt styku między metodami pracy będzie rodzajem zależności zewnętrznej. Zespoły zwinne, które są mocno zależne od reszty organizacji działające w metodologii kaskadowej, mają ograniczone możliwości i często utrudnioną pracę. Warto zastanowić się, jak można tym zespołom zwinnym zapewnić wsparcie.

Jak widzisz, temat porusza wiele aspektów i trudno o jednoznaczną opinię. Są zalety łączenia agile i waterfall, jednak trzeba być świadomym ryzyk, jakie to za sobą pociąga.

FAQ: Agile i waterfall – łączyć czy nie?

Jakie wymiary rozróżniają agile i waterfall’a?

• Moment definiowania ostatecznego kształtu rozwiązania
• Moment dostarczenia wartości
• Kontakt z użytkownikiem
• Nastawienie do zmiany
• Interakcje w zespole
• Odpowiedzialność za końcowy sukces
• Rola managera zespołu
• Integracja składowych produktu
• Usprawnienia

Dlaczego nawet niewielka zmiana w stronę agile może być korzystna dla zespołu, produktu czy organizacji?

Ludzie docenią małe zmiany. Może to być chociażby głębsza współpraca w zespole, trochę lepsze usprawnianie się, trochę częstsze dostarczanie wartości dla odbiorcy końcowego.

Dodatkowe materiały na temat łączenia agile i waterfall

• Praca na termin w agile
• Zależności zewnętrzne w zespole
• Refleksje nad hybrydowym zarządzaniem projektami
• Materiał pokonferencyjny z PMI na temat praktyk zwinnych w waterfallowych projektach
• Artykuł pokazujący jak usprawnić konkretne wady waterfalla praktykami zwinnymi

📄TRANSKRYPCJA „Agile i waterfall – łączyć czy nie?”

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”.

Jacek: Rozmawiałem ostatnio z klientem o możliwej współpracy i w toku rozmów wstępnych pojawił się ciekawy temat. Mianowicie, pojawiło się pytanie jakie, jest nasze zdanie w temacie agile i waterfall? Łączyć czy nie? I uznaliśmy z Kubą, że jest to interesujący temat na odcinek. 

Kuba: Odcinek składał się będzie z następujących punktów. Na początek zdefiniujemy, co mamy na myśli pod pojęciami agile i waterfall, bo to nie jest oczywiste. Odpowiemy też na pytanie, czy i kiedy ma sens łączyć te podejścia. I podzielimy się na koniec przestrogami, jakie są ważne, jeśli zdecydujemy się na łączenie zwinności z waterfallem?

Jacek: Zanim wystartujemy, krótkie przypomnienie. Wszystkie nasze płatne webinary znajdziesz na stronie porzadnyagile.pl/sklep. 

Kuba: I takie ważne zastrzeżenie na początek merytoryczne, że będziemy patrzeć na tę perspektywę łączenia agile i waterfall z tej perspektywy, że mamy gdzieś waterfall i do niego dokładamy agile. Czyli gdzieś tam wiatr zmiany w stronę zwinności i niekoniecznie odcinek będzie zachętą do ukaskadowienia czy uwodospadowienia istniejącego agile’a.

Czyli raczej myślimy o tym, żeby do istniejącej organizacji lub struktur czy procesów, które są jednak bardziej waterfallowe dokładać zwinność, stosować zwinność, czy używać jakichś technik zwinnych. A nie taki absolutny odcinek, gdzie pod wszystkimi możliwymi kombinacjami będziemy się tematowi przyglądać. I takie wstępne założenie wprowadzające nas tę definicję to to, że każdy pod pojęciem waterfall i agile może rozumieć inne rzeczy, więc na początek musimy je zdefiniować.

Jacek: I będziemy mówić celowo o takich dosyć dwóch spolaryzowanych podejściach, czyli kiedy będziemy definiować i podejście zwinne i podejście kaskadowe, no to one oczywiście będą w pewien sposób takie troszeczkę przeciwstawne. Z czego to wynika? Wynika to z tego, że widzieliśmy zarówno lepiej realizowane projekty klasyczne, jak i widzieliśmy mało zwinne zespoły, które deklarowały, że są zwinne. No więc troszeczkę jakby te różnice będziemy starali się wyostrzyć. 

Kuba: Więc od razu odpuśćmy sobie argumenty, że bywają słabe agile i dobre waterfalle. Ten odcinek, żeby nabrał takiego smaku, musi być taki wyrazisty, więc też tą wyrazistość tutaj spróbujemy zarysować. Czym zatem różnią się agile i waterfall? Wyróżnimy 9 cech, czy takich 9 wyraźnych, wyraźnie odróżniających wymiarów.

Jacek: Pierwszy wymiar to jest wymiar rozwiązania, które powstaje. W podejściu zwinnym chcemy, żeby produkt wyłaniał się w trakcie prac. Natomiast w podejściu waterfallowym ten produkt zwykle jest dosyć precyzyjnie zdefiniowany na początku.

Kuba: Druga różnica, która może odróżnić waterfall od agile’a, to wartość dostarczona. W zwinnym podejściu dobrze realizowanym, wartość jest dostarczana w ciągu prac, przez cały czas trwania jakiejś inicjatywy. W waterfallu o wiele częściej spotkamy zjawisko, w którym ta wartość pojawi się bliżej końca, albo dosłownie tylko i wyłącznie na końcu danej inicjatywy.

Jacek: Trzecia cecha wyróżniająca to jest użytkownik. W podejściu zwinnym chcemy mieć bliską i częstą interakcję z użytkownikiem naszego produktu. Natomiast w podejściu waterfallowym bardzo często ten użytkownik jest dotykany przez zespół poprzez pośredników. 

Kuba: Czwarta rzecz, która będzie odróżniała agile i waterfall, to temat zmiany. Agile, zwłaszcza jeśli patrzymy z perspektywy definicji zawartej w Manifeście wytwarzania zwinnego oprogramowania, wprost zakłada, że będą zmiany, że trzeba z nich skorzystać. Że to jest dobra sytuacja. No i trzeba być na to gotowym jako zespół.

Natomiast w takim klasycznym podejściu waterfallowym po to ustala się na początku zakres działań i poświęca się dużo energii na to, żeby wszystko zaprojektować tak, żeby sprawnie tę zmianę zignorować, albo nie jest to mile widziane, żeby zmiany były lub w tym takim, powiedzmy alternatywnym podejściu, zmiana jest przepuszczona przez ścieżkę zdrowia. Jakieś change i questy, po to, żeby jednak jak najrzadziej ta zmiana miała miejsce.

Jacek: Piąta cecha wyróżniająca te dwa podejścia to są interakcje. Jeśli chodzi o podejście zwinne, no to jednak w centrum mamy zespół. I na zespole, na interakcjach wewnątrz tego zespołu kładziemy dosyć dużą uwagę. Natomiast w podejściu waterfallowym to skupienie jest trochę mocniej przesunięte, zwykle na procedury i na procesy. 

Kuba: Następny wyróżnik to odpowiedzialność. W podejściu zwinnym mocno kładzie się nacisk na to, że cały zespół zwinny odpowiada za finalny, całościowy rezultat, za produkt jako całość. Natomiast w podejściu waterfallowym często stosuje się techniki dzielenia pracy na mniejsze cząstki, ustalania je też harmonogramowo po to, żeby każda osoba czuła odpowiedzialność za swój wybrany wycinek pracy. 

Jacek: Kolejna cecha odróżniająca to rola managera. W podejściu zwinnym zwykle jest to osoba, która kreuje środowisko dla zespołu. Zapewnia, żeby systemowo były stworzone warunki do tego, żeby dostarczanie wartości przebiegało jak najpłynniej. Natomiast w podejściu kaskadowym menedżer często jest osobą, która odpowiada za koordynowanie pracy. 

Kuba: Przedostatni punkt, który nam odróżni agile od waterfalla to temat integracji, rozumianej jako integracji składowych produktu. W agile’u bardzo pożądane jest jak najczęstsze integrowanie małych kawałków, jak najczęstsze uzyskiwanie kolejnych wersji produktu, która działa. W podejściu waterfallowym najczęściej ryzyko integracji przesuwane jest na koniec prac. Dopiero te składowe łączone są blisko końca, blisko np. wdrożenia ostatniej wersji rozwiązania. 

Jacek: I ostatnia cecha odróżniająca, to usprawnianie się, podejście do tematu usprawnień. W podejściu zwinnym chcielibyśmy, żeby doskonalenie przebiegało i działo się w trakcie prac, żeby było ciągłe i nieustające. W podejściu klasycznym waterfallowym najczęściej to usprawnianie jest wyrażone jako jakaś forma lessons learned na koniec projektu. Czyli bardziej jednorazowo w jakimś tam momencie, niż dbanie o to, żeby to usprawnianie było ciągłe. 

Kuba: Czyli podsumowując, wymieniliśmy przed chwilą dziewięć wymiarów, których ten agile i waterfall jednak się dosyć wyraźnie różni od siebie. Czyli te podejścia mają pewne charakterystyki rozłączne. No, ale nieuchronne jednak jest pytanie, na ile łączenie w ramach jednej struktury albo w ramach jednego projektu w jednej firmie, na ile łączenie podejścia zwinnego i podejścia takiego klasycznego ma sens?

Jacek: Jeżeli chodzi o mnie, to mi się to na przestrzeni czasu zmieniało. Opracowałem różnymi metodami pracy. Zupełnie na samym początku to był właściwie chaos, jakieś takie moje pierwsze interakcje. Jako freelancer z klientami, no to muszę przyznać, że to było kompletnie niepoukładane i płaciłem za to wysoką cenę.

Więc w pewnym momencie, jak wskoczyłem w pracę taką dosyć waterfallową, no to z jednej strony poczułem, że to jest trochę poukładane, ale z czasem zaczęło mnie to uwierać. Wszystkie te rzeczy, o których powiedzieliśmy przed chwilą w tabelce, no, ich nagromadzenie powodowało, że czułem, że nie do końca to jest najlepsze, co może być. I w momencie, kiedy poznałem podejście zwinne, no to miałem podejście takie dosyć radykalne. Na takiej zasadzie, że jakby odrzuciłem wszystko to, co było w przeszłości. Uznałem to za złe rzeczy, za ciemną stronę mocy.

No i jakby wierzyłem, że tylko czysta zwinność, tylko takie podejście alternatywne do tego, co znałem, może mieć sens. Dziś patrzę na to trochę bardziej z chłodną głową, trochę bardziej kontekstowo. I to jest taka można powiedzieć ścieżka, którą w skrócie oczywiście przeszedłem. 

Kuba: Tutaj też, zaczynając od takiej historycznej perspektywy. Sam zawodowo miałem bardzo dużo wspólnego z waterfallem i osoby, które mnie znają zawodowo długo wiedzą, że czy to w analizie biznesowej, czy w zarządzaniu portfelem projektu, długo się spełniałem, na początku swojej kariery. Więc długo, długo wierzyłem mocno w waterfall i mocno go wręcz wprowadzałem w organizacje. Potem gdzieś tam agile mnie dopadł i wytarmosił.

Natomiast dzisiaj temat łączenia agile i waterfall, nie wchodząc jeszcze w niuanse, bo na nie zaraz będzie czas, punkt po punkcie. Ale taka moja osobista perspektywa jest taka, że jestem za tym, żeby dopuścić myśl o łączeniu podejścia zwinnego z waterfall, ale tylko takim z takiej perspektywy, że transformacja zwinna to jest pewna ewolucyjna droga. Rzadko kiedy możemy sobie pozwolić na takie bardzo radykalne przebudowanie wszystkiego i to totalne odcięcie się od dotychczasowych struktur, procesów, zasad działania, pewnego nawyku, w jakim organizacja funkcjonuje.

Więc takim trochę nieuniknionym procesem jest to, że między tym złym etapem przeszłości a tym idealnym światem przyszłym, jest też taki przykry okres pośredni, w którym to podejście zwinne będzie sobie w organizacji egzystować, czy koegzystować wspólnie, równolegle istnieć ze światem tradycyjnym. Więc powiem tak. Łączmy agile i waterfall, ale tylko z tą myślą, że jest to pewien taki niewygodny etap przejściowy, typu mieszkamy w mieszkaniu, w którym jeszcze trwa remont.

Przez chwilę jest niewygodnie, przez chwilę jest dużo pyłu, kurzu i być może nie mamy tyle przestrzeni, ile byśmy chcieli, ale jednak robimy to z perspektywą na to, żeby we właściwą stronę wyjść. Z tej metafory niestety jest też odwrotny scenariusz. Nie pozwólmy sobie zostać w mieszkaniu, które jest w niedokończonym remoncie. Czyli ten świat egzystowania agile i waterfall to powinien być raczej coś na zasadzie przejściowego etapu, a nie na zasadzie coś, z czym już zostaniemy na zawsze, albo coś, do czego się tak bardzo przyzwyczaimy. 

Kuba: Ale przechodząc do tej wspomnianej listy punktów, wymienimy w tej chwili argumenty przeciwko łączeniu agile i waterfall. Jak słyszysz słuchaczu lub słuchaczko, sami mamy tutaj podejście dosyć pragmatyczne, ale jednocześnie nie unikniemy tego, żeby bardzo wyraźnie zaznaczyć, że są takie warunki, w których to łączenie nie jest do końca dobrym pomysłem. No i w tej części odcinka je powymieniamy.

Jacek: Pierwszym argumentem za tym, żeby nie łączyć agile i waterfall jest to, że pewne fundamentalne założenia obu tych podejść diametralnie się wykluczają i różnią. Przeszliśmy przed chwilą z Kubą przez tę tabelkę, więc jak słyszałeś, czy słyszałaś, no to tak naprawdę? W pewnych kwestiach są to zupełnie różne podejścia. No i trochę tak, jakby nie można mieć jajka i zjeść jajka.

A mówiąc tak bardziej konkretnie, na przykład trudno pogodzić podejście iteracyjne czy podejście przyrostowe, gdzie jednak dosyć jasno zakładamy, że będziemy wracać do pewnych elementów projektu, produktu, inicjatywy, którą wytwarzamy. Będziemy poprawiać, rozbudowywać, zmieniać, usprawniać. Z takim klasyczną, taką niechęcią do zmiany, gdzie jednak chcielibyśmy mieć dobry plan i po prostu ten plan przeprowadzić z jak najmniejszą liczbą change requestów, no bo to zawsze jest problem do obsłużenia. I to oczywiście tylko jeden z takich przykładów, które moglibyśmy mnożyć, ale myślę, że całkiem dobrze pokazuje, że pewne aspekty będą się ze sobą gryzły.

No i może być tak, że przykładowo zespół będzie chciał funkcjonować w jakiś sposób, natomiast organizacja będzie się przed tym podejściem bronić, no i to może prowadzić do sporego tarcia.

Kuba: I tutaj ja dorzucę drugi przykład, takich bardzo wykluczających się perspektyw. Wśród wymiarów agile’a wymieniamy zespołowość. Jeśli w organizacji funkcjonuje albo nawyk, albo kultura, albo funkcjonują jakieś procesy, procedury, które uniemożliwiają stworzyć zespół, taki prawdziwie rozumiany zespół.

Czyli ludzie nie mogą ze sobą blisko współpracować, nie muszą, nie mogą sobie pomagać, mają być zajęci, rozrywani przez kierowników, którzy dokładają im jakiś innych zleceń, albo naraz są w wielu, wielu perspektywach. Czyli każdy jest w jakiś tam kilku zespołach teoretycznych, zespołach. To tutaj ze zwinnością może być bardzo trudno.

I potencjalnie jest kilka takich punktów krytycznych, czy takich punktów zapalnych, w których jeśli organizacja nie pozwoli na lekkie zmiany, albo chociaż na odstępstwo od ogólnie obowiązującej reguły, to nawet jeśli w całej reszcie punktów wypełnimy jakąś praktykę zwinną, czy konkretne frameworki, takie jak np. Scrum, no to niestety nie widzę tu szansy dla powodzenia. I ta zmiana będzie wyłącznie jakimś tam deklaratywnym złudzeniem, że coś robimy, ale tak naprawdę skutecznie tutaj nic się nie wydarzy. 

Kuba: No i przechodząc do drugiej przestrogi, to to, że właśnie w skrajnych przypadkach taka inspiracja zwinnością czy agilem niewiele albo nic nie zmieni. Czyli jeśli mamy naprawdę niekorzystne środowisko, niekorzystne zasady funkcjonowania organizacji, to szczerze, z ręką na sercu, mimo że wierzę w agile, to po prostu odradzam. Nie ma najmniejszego sensu próbować takiego podejścia, bo po prostu ogrom tych czynników niekorzystnych spowoduje, że tutaj nie będzie żadnej różnicy.

Stracimy pieniądze, które zainwestujemy w jakieś szkolenia tych ludzi. Być może będzie to jakieś dodatkowe zamieszanie organizacyjne, procesowe, ktoś tam gdzieś będzie niepotrzebnie na kolejnych spotkaniach. Może lepiej, żeby organizacja funkcjonowała jak funkcjonuje do tej pory, nieważne czy to jest dobry, czy zły styl. Dokładanie tak na przyczepkę jeszcze agile’a, w najgorszych przypadkach po prostu będzie tylko na gorsze dla organizacji, a w szczególności nie będzie na lepsze. 

Jacek: Taki przykład, który mi przychodzi do głowy to np. niezmienienie nic w temacie planowania, jakiś road map produktowych czy podejścia do definiowania projektów, które realizujemy. Jeżeli to nadal będzie coś, co się dzieje z dużym wyprzedzeniem, coś, co chcemy mieć dobrze opanowane, rozpisane, przeanalizowane, często bez udziału tego docelowego zespołu, który będzie miał to rozwijać, to po prostu zmiana nie będzie zbyt spektakularna, tak jak wspomina Kuba. 

Jacek: Kolejna przestroga jest taka, że może łączenie agile i waterfall doprowadzi do sytuacji, w której zmienią się tylko etykiety i cała zwinność będzie pewnego rodzaju fasadą. Czyli w pewnym sensie przemalujemy sobie organizację. Pojawiają się jakieś nowe stanowiska, pojawiają się jakieś nazwy, jakieś Backlogi Produktu. Pojawiają się jakieś odpowiedzialności. No ale tak naprawdę, jakby esencja czy taki core naszej działalności nie ulegnie zmianie.

Czyli przykładowo możemy nadal nazywać sobie grupę ludzi Zespołem Scrumowym, ale jeżeli tam nie ma, faktycznie zespołowości nie ma wspólnego celu, nie ma Product Ownera i pewnie paru jeszcze innych rzeczy, to nie spodziewajmy się, że nazywanie takiej grupy osób niepowiązanych ze sobą Zespołem Scrumowym spowoduje, że będziemy uzyskiwać rezultaty, takie jak byśmy uzyskiwali, gdybyśmy taki zespół posiadali. 

Kuba: I ta fasadowość, nieuchronnie kierujemy w stronę dosyć mocnej ironii. Ale taka ironia, która jest taką prostą receptą na transformację. Przy czym dla ścisłości mówię to z dużym przekąsem. To nazwijmy analityka Product Ownera, kierownika zespołu albo kierownika projektu Scrum Masterem, jakiegoś tam dyrektora, nazwijmy jakimś tripe leadem albo chapter leadem, jakkolwiek sobie to ciągniemy. Przemianujmy status mitingi tygodniowe lub dwutygodniowe w projekcie na Sprint Review i cyk mamy. W zasadzie jeszcze może jeszcze musimy w Outlooku stopki pozmieniać.

No i mamy wszystko i jednocześnie nie mamy nic. To znaczy, przemalowaliśmy objawy zewnętrzne, ale realna zmiana nie następuje. No i ironizuję, szanuję, empatyzuję, ale jednocześnie to nie ma nic wspólnego z agilem. I tutaj jakby to właśnie poddajemy tym sosem skutecznego, udanego łączenia świata klasycznego zarządzania ze światem zwinnym. To tak naprawdę z ręką na sercu, powiedzmy sobie wprost. Tu nie ma żadnego łączenia.

To jest tylko i wyłącznie udawanie, że się coś z tym agilem robi. No i niestety historii są dziesiątki lub setki tego typu. Robimy to, bo nam centrala tak każe. Robimy to, bo się nowy CEO uparł. No ale realnie zmiana tutaj nie następuje. I nie oszukujmy siebie i nie oszukujmy też otoczenia.

Kuba: Czwarta przestroga. Przestroga, którą już kiedyś w podcaście wspominaliśmy, ale było to dawno temu, to to, że pojawiają się koszty utraconych nadziei. Czyli idąc tropem tego podejścia, o którym ja wspomniałem, że takie współegzystowanie agile i waterfall przez jakiś czas jest jakimś krokiem ku lepszemu, ku głębszej transformacji zwinnej.

Ale może zdarzyć się tak, że ta pogłębiona transformacja jednak się nie uda. Zatrzyma się na jakimś etapie albo wręcz się cofnie. Nieuchronny koszt to koszt stracenia serc ludzi, którzy uwierzyli. Ludzi, którzy zdecydowali się trochę mocniej zaangażować. Może odważyli się wejść w role związane ze zwinnością. Zrozumieli też, że to jest coś dla nich. Zrozumieli też, że można inaczej. No, jeśli organizacja nie dotrzyma danego słowa o tym, że chce się zmieniać, to te osoby albo dosłownie odejdą z organizacji, albo udadzą się na wewnętrzną emigrację i już przestanie im się chcieć.

Nie wiem, czy nawet nie gorszy przypadek, niż jakby po prostu normalnie, najnormalniej w świecie odeszli. Czyli koszty utraconych nadziei to przypadki, w których ludzie się zapalą do idei i spróbują inaczej. Być może trochę otworzą im się głowy na to, że można działać inaczej, po czym organizacja nie pozwoli im spełnić tych marzeń. I niestety te osoby już są stracone.

A paradoks może polegać na tym, że w całej populacji pracowników firmy to mogą być najbardziej wartościowe osoby, które wykazują się dużym zaangażowaniem. Mają dobre intencje, bardzo mocno chcą, a jednocześnie takie osoby stracone też mogą najszybciej, boleśnie zaprocentować w przyszłości dla tej organizacji. 

Jacek: Przedostatnia myśl, przedostatnia porada jest taka, że łączenie podejścia zwinnego z podejściem kaskadowym może doprowadzić do sytuacji, w której zużyją się pewne pojęcia. Znacznie trudniej będzie nam porządnie realizować zmianę w przyszłości. Jest to pewna taka melodia czy pewien refren, który powraca, kiedy pracuję z klientami. Na takiej zasadzie, że my już robiliśmy Scruma, my już próbowaliśmy tej zwinności.

My już sobie ćwiczyliśmy tam jakieś praktyki Kanbanu. No i to nie działało. Jest takie trochę oczekiwanie, jakby to, co jest lepsze od tego. No i najczęściej to nie jest tak, że firma jest super wyjątkowa i żadna z nowoczesnych metod prowadzenia projektów, czy rozwijania produktów nie pykła. Tylko raczej to jest kwestia taka, że zostało to najprawdopodobniej wprowadzone w jakiś ograniczony sposób, może w niechlujny sposób, może zbyt taki powierzchowny. No co po prostu nie miało szans dać rezultatów.

Natomiast długofalowy problem, jaki z tego się rodzi, jest taki, że praca nad zmianą być może będzie wymagała odczarowania pewnych pojęć. Otoczenia, pewnych nawyków, które zostały je, które się wytworzyły. No i niestety powoduje to, że wprowadzanie nowych sposobów pracy, będzie po prostu z pewnym takim długiem technologicznym, nazwijmy to, z takim bagażem, na który po prostu będzie trzeba unieść. 

Kuba: I ostatnia przestroga związana z pomysłem łączenia agile i waterfall to to, że łączenie podejść może prowadzić do unikania rozmowy o prawdziwej zmianie. Byłem świadkiem takiej historii w pewnym banku.

Nie był to bank, w którym działałem zarówno wewnątrz, jako konsultant, tylko bank, o którego historii dowiedziałem się na konferencji, gdzie osoby zaangażowane w transformację zwinną w tej organizacji z takim dosyć dużym smutkiem powiedziały, że już na samym początku zmiany zostało mocno zapowiedziane, że OK, te agile możecie sobie robić, ale cały proces zarządzania portfelem, zarządzania projektem i całe struktury i sposób organizacji Project Management Office pozostają bez absolutnie żadnej zmiany.

I dosyć szybko, łatwo sobie wyobrazić, ile to się mieściło, bo gdzieś, nawet jeśli powstały jakieś Zespoły Scrumowe, które zaczęły próbować działać trochę inaczej, no to się regularnie ścierały i regularnie zderzały z absolutnie niezmienioną strukturą i właśnie zasadami działania projektów. Co wzbudzało cały szereg kłopotów, o których może już nie będę w szczegółach mówił.

Ale ten mały przykład jest dla mnie takim dosyć wyrazistym potwierdzeniem tego, o czym chcę powiedzieć w tej przestrodze. Czyli to, że gdy siadamy do jakiejś kolejnej wersji, kolejnego etapu, czy kolejnego kroku transformacji zwinnej, nieważne czy pierwszy, czy siedemnasty w naszej organizacji, to warto jednak sobie powiedzieć, że zmianie powinno podlegać wszystko. Cały system, cały proces, wszystkie struktury.

Przyjrzeć się trzeba tematowi całościowo. I niestety, ale takie dosyć wczesne powiedzenie sobie dobra, będziemy łączyć podejścia – „pogodzimy jakoś tego agile i waterfall” – może doprowadzić do sytuacji, w której z góry sobie zakładamy, że są jakieś tematy tabu, święte krowy czy jakieś nienaruszalne podstawy, które powodują, że później cała reszta tej zmiany będzie cierpieć. Będzie miała ograniczone efekty. Więc tu taki ostatni argument z perspektywy transformacyjnej.

Nie zaczynajmy od założenia, że będziemy łączyć podejścia agile i waterfall. Realnie, pragmatycznie, prawdopodobnie będziemy. I być może bardzo długo będziemy, ale nie przyjmujmy tego założenia jako pierwszy wstępny krok, z którego powodu pewnych rzeczy po prostu ruszać nie będziemy.

Jacek: No dobrze, to pokryliśmy sobie sześć takich argumentów, czy przestróg wskazujących na to, żeby nie łączyć agile i waterfall. Natomiast mamy też trzy konkretne argumenty za tym, żeby jednak próbować, ale ostrożnie. Jaka będzie Kuba pierwsza nasza porada?

Kuba: Pierwsza porada jest taka, że nawet niewielka zmiana, nawet niewielka poprawa, może być korzystna dla zespołu, produktu czy organizacji. Czyli tak trochę pragmatycznie, może nawet w pewnym sensie przecząc sam sobie. Z pierwszej części tego nagrania, powiem tak, że jeśli tylko nie zachodzą takie jakieś radykalne sprzeczności, to po prostu trochę lepsza współpraca w zespole, trochę lepsze usprawnianie się, trochę częstsze dostarczanie wartości.

Nawet jeśli to nie będzie taki ideał, który mi chodzi, to prawdopodobnie ludzie docenią. Dla biznesu może być szansa, że będzie to korzystny rezultat. I tutaj, jeśli jest możliwość skorzystania z jakiegoś usprawnienia, dosłownie drobnego, jeśli ono będzie ewidentnie korzystne, to dlaczego tego nie zrobić?

Jacek: Drugi argument jest taki, że nawet w sytuacji, kiedy mamy bardzo sztywnie, zdefiniowane wszystkie boki naszego projektu, no to da się całkiem zwinnie z zespołem taki projekt zrealizować. Może całkiem zwinnie, to jest zbyt duże słowo, ale można się zainspirować praktykami zwinnymi, jeśli chodzi o realizację. Trochę o pracy zwinnej na termin powiedzieliśmy w 23. odcinku podcastu, do którego odsyłam.

Natomiast żeby dać taki konkretny przykład, możemy mieć sztywny zakres, możemy mieć sztywny budżet. Natomiast nadal możemy np. wykorzystywać pewne konkretne techniczne praktyki, które np. będą nam zapewniały czy wyższą jakość, poprzez automatyzację testów na bardzo wczesnym etapie, czy np. ciągłą integrację. Czyli będziemy w trakcie trwania projektu obniżać ryzyko, że integracja kawałków produktu wytworzona przez różne osoby w zespole, czy nawet patrząc na szerszą skalę przez różne zespoły, integracja po prostu będzie wcześniejsza i będzie szybsza. 

Kuba: I kwestia takich z góry zdefiniowanych projektów. Jacek powiedział o bokach projektu. Chodzi o boki trójkąta projektowego, takiej klasycznej metody zarządzania projektami, że projekt ma swój zakres, budżet i czas. Jeśli te rzeczy są usztywnione, to wiele osób, które jest w środku, ma poczucie, że to już z góry nas skazuje czy determinuje nam, że to musi być w takim razie waterfall, skoro mamy tak usztywnione ramy projektu.

No i też wiele osób, które spogląda na takie sprawy z zewnątrz, gdy słuchamy jakiejś np. opowieści o organizacji, która próbuje w takich niekorzystnych warunkach mimo wszystko pracować zwinnie, no to wiele osób od razu tak ma odruch i takie wzmożenie, że to jest waterfall. Tu w ogóle nie ma mowy o żadnej zwinności. Ja się z tym mocno nie zgadzam. Zwłaszcza gdy np. wspieramy jakiś Scrum Masterów czy Product Ownerów, którzy siłą rzeczy od czasu do czasu trafiają na takie projekty.

I bardzo konkretne przypadki, to będą w organizacjach finansowych, gdy np. zmienia się prawo i w bardzo krótkim czasie trzeba wprowadzić pewne zmiany w systemach, albo w zmianę w podejściu do procesu biznesowego. No i tam niestety, ale mnóstwo rzeczy już jest z góry założonych. Prawo zmienia się w bardzo konkretny sposób, więc ten zakres jest mocno podyktowany. Data wejścia w życie przepisów też jest z góry znana i często jest dosyć krótka.

Budżet też zazwyczaj nie jest z gumy, więc z góry wiadomo ile osób mamy do dyspozycji, ale to jeszcze nie znaczy, że nie możemy spróbować zwinnie poradzić sobie z tym przypadkiem. Oczywiście z tego powodu jest o wiele trudniej, ale to nie jest niemożliwe. 

Kuba: I ostatni argument za łączeniem agile i waterfall to to, że niezależnie jaki jest dzisiejszy stan procesu, zawsze warto szukać większej zwinności. Mam tu na myśli taki przypadek trochę filozoficzny o tym, że w zasadzie to nie istnieje coś takiego jak absolutna zwinność. Albo inaczej mówiąc, w przyrodzie nie występuje taki przypadek, że jest organizacja, która we wszystkich możliwych wymiarach, cała jako cała firma jest maksymalnie możliwie zwinna.

Nawet wracając do tej listy dziewięciu wymiarów, pewnie każda organizacja będzie miała trochę lepsze i trochę słabsze zespoły, trochę więcej dostarczania regularnie wartości, ale w wybranych miejscach jednak nie będzie to tak różowo. Więc idąc tym tropem, wyobraźmy sobie jakąś taką super wielowymiarową przestrzeń, w której po prostu ta zwinność dla każdej organizacji to będzie jakiś przedział. To po pierwsze. Czyli to nie jest jeden punkt, tylko dana organizacja jest między czymś a czymś, ale nawet jest też tak, że nie ma co się porównywać do innych. Bardziej porównujmy się sami do siebie.

Czyli jak zwinną organizacją jesteśmy jak z innym projektem jak zwinnym zespołem. Jakim byliśmy kiedyś i czy możemy być jeszcze troszkę lepsi, chociaż w którymś z tych wymiarów. Czyli tutaj jest konkurencja, w której startujemy sami ze sobą i też uzyski czy poprawy, które uzyskujemy. Jeśli są dla nas dobre to, dlaczego ich nie spróbować? 

Jacek: Jak o tym mówisz, to mi się automatycznie uruchamia metafora sportowa dotycząca wytrenowania. Weźmy na przykład bieganie. Tak naprawdę ludzie, którzy biegają, są na bardzo różnym poziomie wytrenowania. Na zupełnie innym poziomie jest osoba, która regularnie biega kilka razy w tygodniu, ma za sobą jakieś dłuższe starty czy to półmaraton, czy maraton, a zupełnie w innym miejscu jest osoba, która dopiero wstała z kanapy i wystartowała.

I tak naprawdę chyba nawet w przypadku tej osoby, która dopiero startuje, uważam, że tym bardziej powinna spróbować. Nawet jeśli tak patrząc przez porównanie, to jest zupełnie na początku drogi i pewnie te parametry organizmu na dzień dzisiejszy są dosyć niskie. Całkiem sprawnie można uzyskać pierwsze rezultaty poprzez wypróbowanie pierwszych kroków, poprzez zrobienie tych pierwszych ruchów, które nas prowadzą w stronę tego, żeby ten tryb był trochę bardziej sportowy. I to się bardzo ładnie przekłada na organizację. Każdy może być w innym miejscu, każda organizacja może być w innym miejscu i zawsze można tak naprawdę próbować uzyskiwać lepsze rezultaty. 

Jacek: Na koniec chcielibyśmy podzielić się z Kubą trzema przestrogami. Skoro jesteśmy w temacie łączenia podejścia zwinnego z waterfallem, tak żeby zwrócić Twoją uwagę na istotne aspekty. 

Kuba: Pierwszy z nich to taki, że warto sobie uświadomić, że łączenie agile i waterfall, zwłaszcza takie bardzo dyskretne, prawdopodobnie da ograniczone korzyści. Bardzo łatwo się zainspirować czy zapalić do podejścia zwinnego. Słuchając case studies, czytając wyniki i słuchając jakiejś fajnej opowieści czy to praktyków, którzy tę drogę przeszli, czy konsultantów, którzy do tego do tej zmiany namawiają.

Natomiast jednak trzeba sobie powiedzieć, że jeśli gdzieś są mocne i dobrze udowodnione rezultaty, to one wynikają z tego, że ta zmiana była głęboka, że to podejście zwinne zostało zastosowane bardzo mocno i bardzo szeroko, bardzo na poważnie. Czyli takie skopiowanie pewnych tylko objawów, wybranych pojedynczych praktyk w najlepszym razie da rezultaty, ale będzie to rezultat ograniczony, lokalny w szczególności nie będzie być może widoczne na wyniku finansowym całej firmy lub to będzie coś naprawdę drobnego. 

Jacek: Druga przestroga, zapewnij zestaw minimalnych warunków, by godzić oba podejścia. Jest trochę tak, że pewne minimalne warunki muszą zostać spełnione lub po prostu będziemy musieli pogodzić się z ryzykiem, że rezultaty będą po prostu gorsze. Czyli trochę to zahacza o to, co Kuba powiedział. Przykładowo, pomimo posiadania sztywnego zakresu na starcie możemy się umówić na to, że będziemy się usprawniać w trakcie i zyskać np. wsparcie managementu do eksperymentowania z procesem współpracy. 

Kuba: I ostatnia przestroga to to, żeby zadbać o punkty styku pomiędzy zespołami o różnym podejściu. To nawiązuje trochę do poprzedniego odcinka naszego podcastu, gdzie mówiliśmy o zależnościach zewnętrznych. No i takim szczegółowym przykładem czy przypadkiem zależności zewnętrznej może być punkt styku między zespołem, który jest bardzo zwinny, ale w organizacji, ponieważ łączony jest agile i waterfall, to być może są też zespoły czy specjaliści, którzy są nadal w takim trybie bardzo waterfallowym.

No i tutaj te zespoły, które będą, powiem to poetycko, wyspą zwinności na oceanie waterfalla – sam kiedyś byłem w takim zespole, mają bardzo ciężko. Mają bardzo trudno i ten agile nie dość, że ma ograniczone możliwości z powodu takiego lokalnego zastosowania, no to też może być też tak, że cała reszta organizacji robi sporo, żeby temu zwinnemu zespołowi się odechciało. A nawet jeśli nie ma tam jakichś intencji wzajemnego zwalczania się, to po prostu jest mnóstwo pewnych niekompatybilności, więc tutaj warto zastosować porady, które były zawarte w odcinku 104.

I czy to z perspektywy liderów danego zespołu, czy w ogóle z managementu całej organizacji jednak zaopiekować temat tego, jak te wybrane lokalne zespoły zwinne dostają wsparcie, czy jakie specjalne zasady współpracy mogą mieć na styku z zespołami waterfallowymi.

Jacek: Podsumowując dzisiejszy odcinek. Jakie widzimy argumenty za łączeniem podejścia zwinnego i kaskadowego? 

Kuba: Nawet niewielka poprawa może być korzystna. Da się pogodzić zwinną realizację bardzo sztywne zdefiniowanego projektu i niezależnie od dzisiejszego stanu procesu warto szukać większej zwinności. Ale przy łączeniu agile i waterfall mamy też trzy przestrogi. 

Jacek: Uświadom sobie istnienie ograniczonych korzyści z łączenia tych podejść. Zapewnij zestaw minimalnych warunków, by godzić te podejścia i zadbaj o punkty styku między zespołami z różnymi podejściami. 

Kuba: Na koniec nieduża reklama z naszej strony. Jesteśmy już o włos z wypuszczeniem na świat webinar o agile – czyli na temat podstaw zwinności, które już reklamowaliśmy w odcinku setnym. Znajdziesz ten webinar pod adresem porzadnyagile.pl/wa. Prawdopodobnie nasi wierni słuchacze nie są w grupie docelowej materiału o podstawie z agile’a. Ale jest szansa i będziemy wdzięczni za to, jeśli polecisz nas swoim znajomym, którzy chcą poznać agile z rzetelnego źródła. Powtórzę adres tego webinaru porzadnyagile.pl/wa. 

Jacek: WA od webinar agile. Natomiast notatki do tego odcinka, artykuł, transkrypcje i zapis wideo tego nagrania znajdziesz na stronie porzadnyagile.pl/105.

Kuba: I to by było wszystko na dzisiaj. Dzięki Jacek.

Jacek: Dzięki Kuba i do usłyszenia wkrótce.

———

To była pełna transkrypcja odcinka podcastu „Porządny Agile”. Dziękujemy za lekturę!