Agile i waterfall – łączyć czy nie?

Odpowiadamy na pytanie, czy jest sens łączyć podejście agile i waterfall. Tłumaczymy, co mamy na myśli pod tymi dwoma pojęciami. Wskazujemy dziewięć cech odróżniających podejście zwinne od kaskadowego. Pokazujemy potencjalne korzyści, jak i zagrożenia wynikające z łączenia tych dwóch sposobów pracy. 

Czy łączyć ze sobą podejście agile i waterfall? Z czym należy się liczyć, jeśli zdecydujemy się na taki krok i jakie jest nasze zdanie na ten temat?

Wątek ten wypłynął podczas jednej z naszych rozmów z klientem i postanowiliśmy podzielić się naszymi przemyśleniami. Ważnym zastrzeżeniem jest to, że nie chcemy ukaskadowienia agile. Poniżej rozważamy o perspektywie łączenia obu podejść, poprzez dodanie zwinności do istniejącego w organizacji działania w sposób kaskadowy.

Celowo też będziemy prezentować 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. Rozwiązanie, które powstaje

Podczas pracy w sposób zwinny, produkt powstaje stopniowo, wraz z postępem czasu. Natomiast w podejściu waterfallowym zazwyczaj precyzyjnie definiujemy produkt już na samym początku działań.

2. Dostarczona wartość

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. Użytkownik

Zwinność cechuje się tym, że chcemy mieć 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. Zmiana

Agile wprost zakłada, że zmiany są dobre i trzeba z nich korzystać. W klasycznym podejściu zmiany 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ąć.

5. Interakcja

Zwinność skupia się na zespole, jest on w centrum i interakcje między członkami są ważne. Waterfall koncentruje się na procedurach i procesach. 

6. Odpowiedzialność

W agile to cały zespół odpowiada za finalny rezultat prac. Z kolei metodologia waterfall pracę rozdziela się pomiędzy różne osoby i to im przydziela się odpowiedzialność za dany wycinek pracy.

7. Rola managera

W agile manager kreuje środowisko pracy dla zespołu, aby miał on warunki do sprawnego dostarczania wartości. W waterfallu natomiast rolą managera jest koordynowanie pracy.

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, 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?

1. Przede wszystkim agile i waterfall mają różne fundamentalne założenia, które wręcz się wykluczają. Trudno jest połączyć iteracyjność z unikaniem zmiany. W pracy iteracyjnej wracamy do pewnych elementów produktu, wiemy, że będziemy je poprawiać, zmieniać, czy rozbudowywać. W waterfallu chcemy mieć dobrze przygotowany plan, który sprawnie zrealizujemy bez problematycznych zgłoszeń, że coś trzeba zmienić. Innym przykładem wykluczających się założeń jest kwestia współpracy. W agile stawiamy 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.
   
2. 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 na 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, 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.
   
3. Przestrzegamy też przed łączeniem agile i waterfall, jeśli wiemy, ż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, ale bez zadbania o ich zespołowość czy współpracę z Product Ownerem. W takiej sytuacji trudno będzie o uzyskanie efektów, jakie moglibyśmy uzyskać, gdybyśmy zadbali o wszystkie niezbędne elementy głębszej zmiany. W szczególności nie oczekujmy rezultatów, jeśli po prostu zmienimy 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 zmiany nie zajdą także w naszych działaniach, to będziemy oszukiwać siebie i otoczenie.
   
4. Uważajmy też na “koszty utraconych nadziei”. Pojawią się one, gdy przez pewien czas współegzystowanie agile i waterfalla będzie przynosiło jakieś zmiany ku lepszemu. Wśród osób zaangażowanych w zmianę tla się 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.
   
5. Łą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.
   
6. 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 jakiejś 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 taki sam. Nawet jeśli powstały tam jakieś 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 i być może przez długi czas jej trwania będziemy tylko łączyć oba podejścia. Jeśli jednak już na samym początku zakładamy sobie taki stan rzeczy na zawsze i określamy, czego nie będziemy poddawać transformacji, to mija się to 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.

• Czasem nawet niewielka zmiana może być korzystna dla zespołu, produktu czy organizacji. Co prawda trochę tu przeczymy samym sobie, jednak z pragmatycznego punktu widzenia, jeśli nie zachodzą jakieś radykalne sprzeczności, to możemy na tym skorzystać 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ć.
• Jesteśmy w stanie pogodzić zwinną realizację bardzo sztywnie zdefiniowanego projektu. Nie będzie to zwinność w czystej postaci, ale pewnymi praktykami można się zainspirować. Trochę o tym mówiliśmy w 23 odcinku podcastu “Praca na termin w agile”. Przykładowo możemy mieć sztywny budżet, natomiast wciąż możemy korzystać z jakichś praktyk, które będą np. zapewniały wyższą jakość poprzez automatyzację testów na bardzo wczesnym etapie. 
• 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ść. Każda organizacja będzie mocniejsza w jednym wymiarze, a słabsza w innym. Ponadto nie ma co porównywać się z innymi, tylko porównujmy się sami do siebie. Najważniejszy postęp jest w różnicy między tak, jak działaliśmy kiedyś, jak działamy teraz i czy możemy być jeszcze trochę lepsi w którymś z wymiarów.

Przestrogi przy łączeniu agile z waterfallem

Jeśli zdecydujecie się w organizacji na łączenie podejścia zwinnego z waterfallem, to pamiętajcie 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żemy się umówić na to, że będziemy się usprawniać w trakcie i będziemy mieć 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. Jesteśmy ciekawi, jak w Twojej organizacji to wygląda? A może masz jakieś doświadczenia z łączeniem zwinności z kaskadowością i podzielisz się nim z nami?

Dodatkowe materiały

• Praca na termin w agile
• Zależności zewnętrzne w zespole

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

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.