To jest 288. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiamy o Agile w IT.

Notatkę, linki i transkrypcję znajdziesz na porozmawiajmyoit.pl/288.

Myślisz o zmianie pracy lub przebranżowieniu się do IT? Zajrzyj na SolidJobs, gdzie znajdziesz przejrzyste te z informacją co do zarobków, technologii i projektów.

Nazywam się Krzysztof Kempiński, prowadzę ten podcast i jestem autorem książki Marka osobista w branży IT. Moją misją jest pomaganie ludziom z IT patrzeć szerzej i rozwijać się świadomie. Możesz mi w tym pomóc. Wystarczy, że ocenisz podcast w swojej aplikacji lub udostępnisz link do tego odcinka. Wystarczy tylko tyle. A teraz zapraszam Cię już do rozmowy.

Odpalamy!

 

Cześć, mój dzisiejszy gość pomaga przejść przez zmianę firmom, które chcą wykorzystać potencjał tkwiący w zwinności. Konsultant, mentor i trener w firmie 202procent.pl, specjalizuje się w tematach zwinnych transformacji dużych organizacji. Jego misją jest propagowanie porządnej zwinności w zespołach i firmach i przeciwstawianie się płytkim zmianom oraz stosowania Agile in the name only. Współautor portalu Agile247 i portalu Porządny Agile. Moim i Waszym gościem jest Jakub Szczepanik.

Cześć, Kuba, bardzo miło mi gościć Cię w podcaście.

 

Cześć, również jest mi bardzo miło.

 

Dzisiaj będziemy rozmawiać o temacie, który jest w IT już, myślę, grubo ponad 20 lat. I dla niektórych jest to jeden z tych motorów, który spowodował, że IT właśnie w XXI wieku mogło się tak rozwinąć. Dla innych jest źródłem swego rodzaju frustracji, może pewnych problemów, o których też na pewno będziemy dzisiaj z Kubą rozmawiać. Mowa oczywiście o zwinnym podejściu, czyli Agile.

Ciekawy temat. Myślę, że wiele różnych kontrowersji wokół niego narosło. Jedni są fanami, drudzy wręcz przeciwnie. Myślę, że takie zdroworozsądkowe podejście, które tutaj, mam nadzieję, Kuba zaprezentuje, będzie pewnie najsensowniejsze. Ale zanim do tego przejdziemy, to chciałbym Cię, Kuba, zapytać, czy słuchasz podcastów, i może jakieś ciekawe tutaj audycje będziesz w stanie zarekomendować.

 

Jest w tym pewien paradoks, bo choć sam prowadzę swój podcast Porządny Agile, to tak za dużo podcastów nie słucham. Jakby patrzeć na moje statystyki w Spotify, bo tam słucham podcastów, to pewnie na pierwszym miejscu jest Porządny Agile. To jest takie jakby odsłuchiwanie samego siebie, jak wypadło, czy coś jeszcze poprawić, czy gdzieś tam w tle nie słychać jakichś szumów albo błędów.

Ale też bardzo dużo słucham podcastu drugiego. Jest to taki podcast dosyć niszowy, nazywa się Ditching Hourly. Jest autorstwa Jonathana Starka, i to jest podcast, tak jak sama nazwa w sumie wskazuje, o tym, żeby odejść od naliczania swojej pracy na godziny. Jest cały podcast, setki odcinków na temat tego, jak można pracować jako freelancer, jako konsultant, jako jakiś specjalista, też jako mały przedsiębiorca z modelu rozliczania innym niż godzinowy. I tam różne modele są eksplorowane na przykładach różnych gości, a czasami też sam Jonathan o tym opowiada.

Bardzo niszowy podcast, ale mi samemu do biznesu bardzo mocno pomaga, bardzo mnie rozwija i daje mi do myślenia, żeby właśnie nie rozliczać się na godziny za swoją pracę.

 

Nie znałem, muszę przyznać, ale faktycznie zerknę, zerknę, bo też mi jest bliski właśnie ten temat, więc poszukam, wyszukam i podlinkuję również notatce do odcinka.

Dobrze, Kuba, no to chciałbym Cię zapytać o te obietnice ze strony Agile, które miały być dowiezione versus to, co zostało dowiezione, bo myślę, że to jest właśnie tą osią różnego podejścia czy różnych zdań na temat Agile w IT, więc jestem ciekaw, jaki tutaj masz ogląd, jakie tutaj masz spojrzenie na ten temat.

 

To jest wielotorowy wątek. Dlaczego? Bo zależy komu, co, kto obiecywał. Teraz powiedziałeś, że Agile już ze 20 lat funkcjonuje. Ja sam z Agilem jestem związany od 2009 roku, więc sam też już mogę sobie kilkanaście lat naliczać działania w tym stylu. Najpierw bezpośrednio w zespołach, potem w firmach, a od jakiegoś czasu już jako konsultant.

I na początku dla mnie był to powiew świeżości, lepsze podejście niż jakieś takie usztywnione zasady pracy. Sam przed Agilem byłem project managerem, działałem jako analityk biznesowy w zespołach, więc sam też poczułem klimaty takie, powiedzmy, klasyczne.

Dzisiaj z perspektywy czasu ich nie neguję, ale zwłaszcza dla zespołów, które przegną ze zbyt sztucznymi zasadami, zbyt dużą ilością procedur, też z jakąś taką separacją ról, że program jest to osobno, potem tester osobno, a zgłaszamy sobie jakieś błędy na ticketach i tak zero współpracy. To w tym klimacie Agile był takim fajnym odświeżeniem, zespołowością, skupieniem się na tym, żeby po prostu zacząć dowozić. I moim zdaniem taka obietnica dalej jest dowożona, jeśli tylko taki styl działania po prostu w danym zespole funkcjonuje.

Ale jest też taki Agile korporacyjny, w którym zwłaszcza duże konsultingi obiecują, że będzie taniej, że będzie szybciej, że będzie oszczędniej dla dowożenia konkretnych projektów. I tutaj już z tym bywa różnie. I teraz to, co mówię, to nie są tylko puste słowa. Rozmawiam obecnie jako konsultant często z zarządzającymi organizacjami. Jeden z członków zarządu, z którym działałem, mnie kiedyś zaskoczył, że powiedział: Przed tobą byli tutaj konsultanci z dużej firmy, ale nie będę mówił której, ale takie topowy konsulting, i oni mówili, okej, wprowadzicie Agile, a będzie 35% taniej, to samo co robicie, tylko taniej.

I on mnie pyta, jak to jest, że będzie taniej. I jakby kruczek jest w tym, że ja wiem skąd jest te 35%, bo to jest zbadany case pewnego banku, który wprowadził Agile, ale po to, żeby bardzo zdigitalizować procesy. I oni poprawili wynik całego banku, bo po prostu pozwalniali mnóstwo ludzi, którzy wykonywali wcześniej czynności ręcznie, a teraz dzięki zwinnym zespołom wprowadzono narzędzia, które zautomatyzowały mnóstwo pracy.

Ale to jest bardzo specyficzny przypadek. Firma, która miała zaszłości, no nie każda organizacja będzie miała taniej. Wręcz ja bym powiedział z mojego doświadczenia, że raczej taniej nie będzie.

I organizacje, które patrzą na to, że będzie taniej, mogą się bardzo ciężko zaskoczyć, bo moje doświadczenie mówi, że często Agile jednak wyciąga pewne zaszłości, właśnie niedoskonałości, i trzeba doinwestować infrastrukturę, środowiska, licencje, być może dotrudnić brakujące kompetencje w zespole, być może trochę dopakować ludzi brakującymi kompetencjami, i nagle się okazuje, że taniej to raczej nie będzie. Będzie szybciej wartość, ale niekoniecznie więcej wytworzonego softu.

I w ogóle najbardziej dramatyczny wymiar to jest niestety taki Agile proceduralny, a to pewnie jeszcze mnie o to podpytasz, więc tutaj się zatrzymam.

 

Z pewnością. Tak tylko sobie pomyślałem, gdy mówiłeś właśnie o tych kosztach, no to faktycznie może być bardzo trudne w oszacowaniu, bo okej, co prawda być może odcinamy takiego trochę organizacyjnego tłuszczyku, ale z drugiej strony no właśnie może się okazać, że mamy pewne braki, które muszą być w jakiś sposób uzupełnione i niekoniecznie ta strata z jednej strony spowoduje, że wychodzimy tak netto, netto na zero, bo jakieś tam zasoby różnego typu szeroko rozumiane muszą być dodane.

Tak samo sobie pomyślałem to wyliczanie właśnie, często robione, tak jak tutaj powiedziałeś, na bazie jakiegoś tam case’u, który może zupełnie odstawać pod różnymi względami od tej konkretnej firmy, w której jesteśmy, też pewnie jest dosyć trudne i w tej dobie AI, gdzie różnego typu wpływ na procesy ze strony AI może następować, to tym bardziej trudno jest uchwycić tak naprawdę ten zysk właśnie z przejścia na Agile albo zastosowania tego podejścia, bo możemy automatyzować, możemy ograniczać koszty, używając różnych narzędzi, nie tylko zwinnego podejścia, prawda?

 

Tak, zwłaszcza bardzo trudne jest takie przyznanie tylko konkretnie Agile’owi pewnych zasług. Do dzisiaj pracuję z organizacjami, które jak chcą policzyć, to próbują to policzyć, i  się okazuje, że np. to nawet jest dosyć świeży case ze w sumie bieżącej współpracy, gdzie uruchomiono pewien zwinny zespół, jeden z wielu w całej organizacji zrobiono taki trochę mocniejszy, trochę lepszy, trochę z mocniejszym też moim wsparciem, i ten zespół post factum, po skończonym takim większym przedsięwzięciu podsumował sobie, jak pracuje.

I się okazało, że np. było przeciętnie połowę mniej błędów, testy trwały w zasadzie na pstryknięcie palca w przeciwieństwie do tego, co pierwotnie było w tej organizacji. Okazało się też, że bardzo szybko zareagowali na pewną zmianę i potrafią wyliczyć konkretne wskaźniki, część z nich wręcz wprost się przekłada też na pieniądz, bo np. skrócone testy to mniej czasu poświęconego przez testerów na przygotowanie wdrożenia tej ekipy. Ale z drugiej strony jakby tak jakby przesadzę z propagandą, to bym powiedział, że Agile w tej organizacji zaoszczędził 8 tygodni pracy całego zespołu.

Ale w drugą stronę to jest też zasługa testerów, którzy się dostosowali i zmienili trochę podejście do pracy. To jest zasługa biznesu, który poszedł na rękę i trochę bliżej współpracował. Więc to jest taki dylemat, zwłaszcza gdyby chcieć być zbyt rzetelnym, zbyt takim szczerym, też takim trochę pokornym, że tak naprawdę wiele korzyści, które Agile sobie jakby przypisuje, to często jest współpraca i takie dokładanie praktyk kolejnych, no mniej bezpośrednio związanych z Agilem.

Bo to często będzie w wielu firmach DevOps, to będzie właśnie uruchomienie praktyk związanych z user experience, podejście produktowe, więc trudno zrobić taki ekstrakt, że Agile to te 3%, a pozostałe 7% to jakieś inne czynności. Ale w wielu organizacjach w zasadzie i tak się nie liczy aż tak dobrze, żeby to miało znaczenie, co oczywiście się czasem mści, bo ktoś powie, że no fajnie, tam się spotykaliście, ale to zasługa kogoś innego, zwłaszcza jeśli w organizacji jest sporo polityki.

 

Pewnie tak samo jak te consultingi, o których tutaj wspomniałeś, które przeceniają ten wkład Agile, tak samo myślę, może to wyglądać w drugą stronę, że zrzucamy na Agile winę i odpowiedzialność za różne rzeczy, które gdzieś tam po drodze nie wyszły z mnóstwa różnych przyczyn.

Może chwilkę porozmawiajmy właśnie na ten temat, co nie działa w przypadku zastosowania tego podejścia i dlaczego.

 

Bardzo kupuję najważniejszy z argumentów, jak myślę o Agile’u, czyli, że nałożenie Agile’a na organizację, która nie ma takiej podstawowej infrastruktury, ale nie w dosłownym znaczeniu, tylko w takim szerszym kontekście. Nie ma architektury, nie ma procesów, nie ma pewnych praktyk inżynierskich, nie ma w ogóle kultury współpracy.

Pewnie mógłbym długo wymieniać taką listę, ale powiem to, co najważniejsze. Organizacja, która jest naprawdę na bardzo niedojrzałym poziomie pod względem, powiedzmy, praktyk pracy nad softwarem, jeśli nałoży na to Agile, to może uzyskać taki efekt trochę placebo, chwilowy efekt świeżości, czyli wyciśniemy z tej organizacji jeszcze przez chwilę coś, a potem się wszystko dramatycznie zapada, bo dogania wszystkich dług technologiczny. 

Albo np. też czasem spotykam takie organizacje, że no Agile tak trochę, trochę jak to powiedzonko o smaganiu martwego konia, że jeszcze z tych ludzi już naprawdę wymęczonych, jeszcze się coś chwilę wycisnęło, ale potem oni już naprawdę mają dosyć, już nie chcą jakby swoją osobistą pracą zastępować niedoskonałości organizacji.

I wracając do Twojego pytania, co nie działa, to Agile jako koncept w zasadzie dosyć prosty, ja sam sprowadzam to do tego, że to jest współdziałanie zespołowe, dowożenie wartości w małych odcinkach czasu, zastanawianie się, co można poprawić i poprawianie tego, tutaj bazuje na modelu Heart of Agile w tej definicji, to ten model niewiele więcej daje na temat tego, jakie praktyki się stosuje, jaką strukturę się buduje, jakie zasady współpracy wprowadzić, czy też nawet to też jest bardzo trudne, jak zarządzać organizacją.

I jeśli Agile trafi do organizacji, która jest podatna, to fajnie siądzie, ale na pewno z tego powodu nie siądzie w organizacjach niepodatnych na to. I pomimo tego, jak długo jestem w Agile, to powiem jedno: to nie jest bardzo uniwersalne narzędzie i taki owczy pęd sprzed paru lat, że absolutnie każda organizacja musi być zwinna, każdy bank, każda ubezpieczalnia, wszystkie te duże firmy, no część z nich po prostu nie ma gotowości na Agile’a, i co gorsza, nawet jeśli sobie coś wprowadzą, to nie ma też gotowości, żeby chociaż dogonić, żeby chociaż coś podnieść. I tutaj, myślę, że są te kłopoty.

Czyli podsumowując tę moją myśl, co nie działa w Agile’u, Agile nie naprawi organizacji sam w sobie i tutaj może być duża niekompatybilność Agile’a do niektórych firm.

Pewnie mógłbym długo wymieniać taką listę, ale powiem to, co najważniejsze. Organizacja, która jest naprawdę na bardzo niedojrzałym poziomie pod względem, powiedzmy, praktyk pracy nad softwarem, jeśli nałoży na to Agile, to może uzyskać taki efekt trochę placebo, chwilowy efekt świeżości, czyli wyciśniemy z tej organizacji jeszcze przez chwilę coś, a potem się wszystko dramatycznie zapada, bo dogania wszystkich dług technologiczny.

 

Tak się zastanawiam, czy to nie jest swego rodzaju błąd w myśleniu albo pewien brak, bo to, o czym powiedziałeś, ta krótka definicja Agile pewnie w bardzo wielu organizacjach ma sens i wnosi wartość, ale później właśnie to wdrożenie, tutaj pewnie to możemy porozmawiać, czy w ogóle można mówić o wdrożeniu Agile, czy w jakiś sposób zaadoptowaniu, powiedzmy, tego podejścia, to tutaj pewnie może się wydarzyć najwięcej złego, co później pozostawia jakieś tam rany, złe wspomnienia i taką niechęć swego rodzaju, żeby ponownie tutaj do tej rzeki wchodzić.

Więc Tobie też się właśnie tak nie wydaje, nie masz takich doświadczeń, że ten proces implementacji, ten proces zaadoptowania Agile w danej organizacji jest najbardziej takim miejscem narażonym, powiedzmy, na problemy, błędy, jakieś wpadki?

 

Absolutnie tak. I tu jest taki trochę cały temat, jak z tymi powiedzeniami, że dobre wrażenie robisz tylko raz, i wiele organizacji wprowadza zwinność, wprowadza jakąś konkretną praktykę, czy konkretny zestaw metod, nie robi tego najszczęśliwiej, być może jeszcze tam coś próbują poprawić, ale nie wychodzi, no i ta łatka już zostaje.

Ja akurat długo byłem na to zjawisko, dosyć ślepy, bo moje pierwsze zetknięcie ze zwinnością było takie bardzo partyzanckie, trochę na przekór wszystkim, po prostu na boku jakiś jeden zespół, zróbmy to trochę inaczej, bo developerzy akurat konkretnie bardzo chcieli spróbować. Więc dla mnie to było naturalne, na zasadzie moi właśni developerzy chcieli tak pracować, ja nie wiedziałem, o co im chodzi, ale w to wszedłem, bo dlaczego nie? No i tak i zaczęliśmy.

Później też w organizacjach, w których byłem, też mieliśmy takie dosyć poważne podejście, że chcemy zrozumieć, że chcemy się wyszkolić, więc długo byłem na to ślepy. I dopiero jak już w kolejnej organizacji po paru latach zacząłem szkolić, konkretnie tam ze Scruma, i m.in. szkoliłem świeżo zatrudnionych programistów, i byłem w szoku, że ja nie muszę ich nauczyć Scruma, tylko muszę ich oduczyć tego, co się dowiedzieli w poprzedniej organizacji, w jakimś tam poprzednim zespole projektowym, by się okazało, to był dla mnie spory szok, jak bardzo kiepsko to wszystko jest wprowadzane i naprawdę nie ma żartów w tym, że czasami tak się mówi, powiedzmy anegdotycznie, że ktoś tam dostał książkę albo od poniedziałku szef zapowiedział, że od teraz działamy ze Scrumem i nikt nie ma pojęcia, o co chodzi, nikt nie ma pojęcia, dlaczego mamy tak działać. Jest to często też takie bardzo sztuczne, bardzo ceremonialne, i ludzie dostałem od tego szału.

I to znowu tak anegdotycznie, ale dosłownie rozmowa z moim sąsiadem bezpośrednim z miejsca, gdzie mieszkam, który jak się dowiedział, że mam coś wspólnego z Agilem, to mówi: łeee, ale ja cię zabiję, coś tam zaczął żartować, to oczywiście był klimat grilla, i tak go podpytywałem, o co chodzi. Wiesz, bo my w moim zespole pracujemy zwinnie. Co to znaczy? No, mamy jednogodzinne daily z szefową, gdzie nasz pięcioosobowy zespół jest przez nią szczegółowo odpytywane, co kto z nas robi, i już. Ja mówię: stary, to w ogóle nie ma nic wspólnego z jakimkolwiek Agilem.

A potem się okazuje, że co jestem na grillu, to ludzie, którzy pracują w korporacji, mają dokładnie taką trzecią, czwartą pochodną z Agile’a, na zasadzie totalnie wypłukane, wszystko do poziomu może właśnie jakiejś codziennej odprawy i to jeszcze kompletnie bez zachowania tego klimatu, chociaż zespołowości, chociaż jakiegoś takiego wzajemnego pomagania sobie. I pod tym względem ja się nie dziwię, jeśli ktoś skrzywi się na widok mojej osoby, jak powiem, że robię Agile’a.

Tutaj mam szczęście w tym, że jednak dostaję pewne zaufanie i mówię: nie, poczekajcie, porządny Agile. Okej, codzienne spotkania, ale w takim stylu. A tak w ogóle to jeszcze dowożenie, jeszcze zespołowość, jeszcze ciągłe doskonalenie, zróbmy fajną sesję usprawnieniową. I wtedy niektórzy mi mówią później: parę lat pracuję Agile’em, a na takim retro jeszcze nie byłem. Albo: łoo, to tak się to robi, to daily? Ale, no nie wszyscy mają to szczęście i niestety w wielu organizacjach Agile’a jest wprowadzane na zasadzie: od dzisiaj tak działamy, nie mamy pojęcia, o co chodzi, nikt nie ma pojęcia.

 

No właśnie, z moich obserwacji wynika, że ta grupa developerów, rozumiana w takim, powiedzmy, ujęciu Scrumowym, czyli zespół ludzi technicznych z kompetencjami technicznymi, to jest ta grupa najbardziej spolaryzowana pod względem patrzenia obecnie na Agile. Tak, są osoby takie chętne, które wręcz nie wyobrażają sobie pracy w inny sposób, być może posiadające właśnie dobre doświadczenia, tak jak tutaj powiedziałeś, albo też skrajny obóz, który gdzieś tutaj bardzo narzeka, być może który się właśnie sparzył na tego typu praktykach zgoła bardzo daleko położonych od Agile.

Czy tutaj też masz takie obserwacje, że coś właśnie nie działa w przypadku developerów szczególnie mocno?

 

Jedna rzecz, która mnie nauczyła pokory od samego początku, to takie pytanie w ankiecie, które podpatrzyliśmy w czasach, gdy pracowałem w Allegro, jeszcze z firmy Yahoo, wtedy jest w miarę funkcjonującej, gdzie oni zadawali członkom zespołów, czyli właśnie wspomnianych developerów, takie proste pytanie: czy jeśli zależałoby to tylko ciebie, czy pracowałbyś w swoim zespole Scrumem?

I oni bardzo mocno podpowiadali, że to pytanie pokazuje jakiś taki sentyment do zwinności w danej organizacji, czy w dużej firmie, w danej części organizacji. I co było ciekawe, ja jestem dumny z tego, jak to funkcjonowało za moich czasów w Allegro, ale nawet wtedy na to pytanie dostawaliśmy pozytywne odpowiedzi w 90%, czyli pomimo tego, że moim zdaniem to wyglądało naprawdę solidnie, to i tak nie wszyscy byli za tym.

To pokazuje, że pewna pula osób pracujących w IT, a zwłaszcza osób, które do tej pory tak nie działały w taki fajny, zespołowy sposób, mogą nie mieć chęci, i tutaj nie ma śladu ironii w tym, co mówię, mogą nie mieć chęci do pracy zespołowej, mogą mieć ochotę na bycie samodzielnym i zależnym wyłącznie od siebie, a nie być na przykład współzależnym i czekać na kogoś, coś komuś przekazywać, coś z kimś współpracować.

Siłą rzeczy też u wielu developerów widzę, czasem jest to nastawienie, czasem niestety bardziej przyzwyczajenie do tego, żeby po prostu już bardziej się skupić na tym, żeby wykonać swój kawałek pracy. I zwłaszcza jeśli ktoś popracuje trochę w takim stylu, że przychodzą wymagania, rozpisane szczegółowe projekty, architektura, jakiś kawałek designu front-endu, który ma być po prostu zakodowany, to taka osoba może niestety właśnie jakby osiąść w tym temacie takiej maksymalizacji, utylizacji kodowania.

To jest straszne i  parę złych słów użyłem jednocześnie, ale takie podejście, że moim zadaniem jest zakodować. Czyli przechodząc na inne profesje, moim zadaniem jest przetestować, ja chcę tylko napieprzać, za przeproszeniem realizację kolejnych scenariuszy testowych. No zwinność mówi, nie, 100% czasu to nie będzie tylko wykonywanie tej czynności profesjonalnej, która jest w Twojej etykiecie, ale to też będzie współpraca, to będzie inspirowanie się, to będzie lepsze zrozumienie tego, co jest do zrobienia.

I tutaj rozumiem tę niechęć, że niektórzy mogą być przyzwyczajeni, a w niektórych organizacjach to nawet działa tak, że po prostu się nie wgrała aktualizacja, że tak naprawdę zmienia się trochę oczekiwanie. Nie oczekuję od developera, że będzie developować, i nawet w rozumieniu Scrumowym, żeby tutaj uogólnić, tylko, że jednak tworzycie produkt, a częścią tworzenia tego produktu mogą być również te czynności, których do tej pory robiliście mniej lub robicie rzadziej, albo które mogą być trochę może niekomfortowe.

Bo to będą np. spotkania, to będzie jakaś analiza, to będą jakieś działania, które są może poza sferą takiej ścisłej profesji. Więc ja rozumiem niechęć, część z tego może wynikać z jakichś tam nastawień, część może być też po prostu związana z preferencjami osobistymi.

Super, jeśli firma nie zmusza ludzi na przekór ich chęciom, czyli zwłaszcza w większej firmie, a w takich funkcjonowałem, zawsze znajdzie się miejsce dla samodzielnego eksperta, może się znajdzie miejsce dla kogoś, kto tam gdzieś będzie coś eksplorował, coś badał, coś tak bardziej inżyniersko, jednoosobowo i nie będzie zmuszany do zespołowości, może nie będzie zmuszany do pracy np. z użytkownikiem, z klientem, z interesariuszami biznesowymi, jeśli nie ma na to ochoty.

Myślę, że w szeroko rozumianej branży są takie stanowiska, w których jest trochę mniej zespołowości potrzebne, a są takie, które jednak będą cenić sobie tę współpracę.

Super, jeśli firma nie zmusza ludzi na przekór ich chęciom, czyli zwłaszcza w większej firmie, a w takich funkcjonowałem, zawsze znajdzie się miejsce dla samodzielnego eksperta, może się znajdzie miejsce dla kogoś, kto tam gdzieś będzie coś eksplorował, coś badał, coś tak bardziej inżyniersko, jednoosobowo i nie będzie zmuszany do zespołowości, może nie będzie zmuszany do pracy np. z użytkownikiem, z klientem, z interesariuszami biznesowymi, jeśli nie ma na to ochoty.

 

Tak, absolutnie. Są również potrzebne osoby, które kodują, które zajmują się tylko tym wąskim technicznym aspektem, wręcz nieraz ich wkład jest niezbędny do sukcesu całego projektu, więc tutaj nie można absolutnie tego odcinać jakoś grubą kreską.

Z moich obserwacji wynika też to, że te takie błędy czy wpadki proceduralne, o których powiedziałeś, czyli takie powiedzmy odbębnianie tych różnych ceremonii, spotkań na siłę, nawet jeśli to nie ma sensu, to jest właśnie często źródłem frustracji dla programistów, developerów, to ich wytrąca często z pracy, po prostu daje takie poczucie zmarnowanego czasu, prawda?

 

Jak trafiam na takie niechętne nastawienie, żeby to powiedzieć bardzo dyplomatycznie, w jakiejś organizacji, bo tak czuję, że tak przychodzę z zewnątrz i ktoś mi mówi w zasadzie to spadaj, po co tu w ogóle jesteś, my nie chcemy w ogóle żadnego tego Agile’a, to coś, co widzę, że najlepiej kupują członkowie zespołów, to ja im mówię: słuchajcie, Agile został wymyślony przez programistów, bo, powiedzmy, taka znaczna, zdecydowana większość osób, które podpisały manifest Agile, ma swoje korzenie w programowaniu, wymyślili to programiści, żeby było lepiej. Róbcie tak i pracujcie tak na tych wspomnianych przez Ciebie ceremoniach, nienawidzę tego słowa, ale rozumiem kontekst użycia. Róbcie tak, żeby było Wam dobrze, żeby było Wam wygodnie.

Ja często próbuję poszukać takich zdroworozsądkowych definicji tych poszczególnych praktyk, więc na przykład Daily to jest miejsce na to, żeby zrobić szybkie sprawdzenie, gdzie jesteśmy i czy ktoś nie potrzebuje pomocy. To może trwać 3 minuty. Nie jestem wielkim fanem, ale kupuję, że niektórzy mówią, my to sobie robimy na Slacku. Wolałbym, żebyśmy to zrobili synchronicznie, ale jak już naprawdę się uprzeć, to może nawet niech będzie asynchronicznie.

Retro to jest zastanowienie się, czy jest coś, co możemy robić lepiej, czy jest coś, co nas wkurzało, coś, co nas denerwowało, coś, co nas spowalniało, zróbmy chwilę zastanowienia się i zobaczmy, czy możemy coś poprawić.

Planowanie, zobaczmy, jaką porcję pracy jesteśmy w stanie zrobić, kto komu w czym może pomóc i jestem w stanie to powiedzieć takim bardzo naturalnym językiem. Mało tego, w wielu zespołach, którym dać pełną swobodę co do wyboru praktyk, ale jednak oczekiwać, że będzie dowiezione, czyli no nie, że tam lenimy się, tylko sami sobie zdecydujcie, jak to będziecie robić, ale oczekujemy, że będziecie dowozić, to w bardzo naturalny sposób wiele takich zespołów, które spotykam, wpada na te praktyki.

I to jest świetne, bo tak naprawdę dokładnie w ten sposób powstały, czy to Scrum, czy to konkretne praktyki, te poszczególne zwinne, że tak naprawdę to nie jest tak, że przysiadł jakiś profesor albo ktoś, wygenerował na nowo pomysł, tylko po prostu w jakimś zespole ktoś pokombinował i stwierdził: słuchajcie, może zamiast ciągle się wszyscy denerwować i dzwonić do siebie, zróbmy sobie tak wspólne spotkanie codziennie rano. I mają daily.

I w wielu firmach wpadają na to sami i później na warsztacie ze mną, na jakimś szkoleniu mówią, kurde, to nie wiedzieliśmy, że to ma nazwę, bo my to robimy. I to spoko, to takiego naturalnego Agile’a bardzo lubię. Ważne, żeby wtedy podchodzić do tego ze świadomością, czyli gdzieś tam, nie, tak na pałę lecieć, zawsze tak robiliśmy, więc też tak robimy, tylko dokonać tej refleksji, zastanowić się, jak to działa, czy to działa, czy czujemy się z tym okej, czy możemy zrobić to ciutkę lepiej, np. bardziej zorganizowanie, może lepiej poprowadzone.

Bo inny wymiar tego, co powiedziałeś, też jest taki wątek, te ceremonie, one często są tak dramatyczne, ja może jestem takim, może mam przypadek lekarza, że lekarz ciągle widzi tylko chorych ludzi, ale jak trafiam do organizacji, w której po prostu jest to wszystko tak źle poprowadzone, to nieraz, mimo że nie takie mam normalnie nastawienie, to mówię: poczekajcie, stop, stop, stop, nie tak to robimy, jeszcze raz, od początku, ale teraz po mojemu.

I się nagle okazuje, że da się rozmawiać, że nawet online nie muszą być nudne, żmudne i bezsensowne i że jakby ta praktyka, powiedzmy, spotykania się może być lepsza, praktyka pracy warsztatowej może być lepsza. Niestety codziennością jest pewnie odwrotność, nie chcę narzekać, więc tutaj postawię kropkę.

 

Jasne. Ja bym jeszcze tutaj podkreślił ten wątek, który powiedziałeś, zaznaczyłeś, że taka, wiesz, osobowość developera może wpływać na to, czy ten stosunek do Agile będzie  pozytywny lub negatywny. Myślę, że też specyfika danej organizacji ma duże znaczenie.

Bo w tym słowie zwinność jest to, że faktycznie zmiany występują częściej niż rzadziej. I znam osoby, które gdzieś niekoniecznie są dobrze do tego nastawione. Preferowałyby, aby jednak ta linia wyznaczona przez kogoś gdzieś tam w managemencie utrzymywała się w wyznaczonym kierunku przez jakiś dłuższy czas, aby te zadania, czy też root mapa bardzo szybko nie fluktuowały, nie zmieniały się.

Potrafię zrozumieć takie podejście i w sytuacji, jeśli trafiam do organizacji, która jednak jest bardzo zwinna pod względem takim biznesowym, pod względem tych feature’ów, które są implementowane, to tutaj może nastąpić rozjazd i chyba takie niepotrzebne obwinianie właśnie Agile jako takiego, bo to akurat tutaj nie ma nic do rzeczy, tylko po prostu całe otoczenie wpływa na ten odbiór finalny.

 

Tak, ja mam trochę problem z takim zasłanianiem się, że skoro jesteśmy Agile, to każda zmiana jest teraz już bezrefleksyjnie wprowadzana. Powiedzmy, przyjmijmy na chwilę założenie, że Scrum jest najpopularniejszą praktyką, czy taką metodą pracy zespołowej, to konkretnie np. Scrum wcale nie jest aż taki zwinny w rozumieniu, że każda zmiana jest super mile widziana i natychmiast wprowadzana, bo jednak np. raczej na czas sprintu jest pewne skupienie, są tam furtki pozostawione, ale jednak taka myśl, że przez najbliższe np. dwa tygodnie będziemy celować w coś, będziemy próbować zrobić to. Będzie okazja do tego, żeby zmienić kurs, ale jak już skończymy to coś, co robimy.

I ten wymiar skupienia jednak uważam, że jest bardzo ważną częścią praktyk, i zmiany tak, ale w jakiś cywilizowany sposób. To, co powiedziałeś o zmianach mi się natychmiast też skojarzyło z takim konceptem zmian, które są zawsze akceptowane, bo nikt nie ma żadnej wizji. I tu jest ból, bo to może być kwestia biznesowa, to może być kwestia w ogóle może braku strategii, czy to firmy całej, czy produktu konkretnego jednego z całej firmy.

I tutaj ja lubię taką definicję product ownera, którą jeden ze znanych mi product ownerów sobie na LinkedIna wpisał jako headline: W 99% przypadków mówię nie. I to naprawdę fajnie mi siada taka myśl, że jednak potrzebujemy też takich osób, które te zmiany w jakiś sposób selekcjonują, przebierają w nich te, które są wartościowe, które trzeba wprowadzić, te, które są obiecujące, ale może najpierw skończmy to, co mieliśmy zaplanowane, wdróżmy to i później zobaczymy, bo może będzie trzeba to zrobić, a może wcale nie, może to jest tylko widzi mi się, i też takie odrzucanie zmian, które jednak np. odciągają nas od osiągnięcia pewnego celu.

Więc tutaj w niektórych organizacjach ta koncepcja, że zmiana jest mile widziana, siada za bardzo i fajnie, jeśli jednak jakiś opór do tych zmian jest. Bo to, co powiedziałeś, w sumie ja bym poszedł dalej. Zmiany potrafią być bardzo frustrujące, nie ma nic gorszego niż takie właśnie napracowanie się, włożenie w serca w jakiś kawałek, który jest w ogóle do zaorania, bo się komuś odwidziało.

Więc tutaj tych emocji związanych ze zmianą jest sporo i nie jestem taki, powiedzmy, stuprocentowym gościem: tak, wszystkie zmiany lubcie, róbcie bez końca zmiany. W najgorszym razie to może być też takie kręcenie się w kółko.

Są takie stare memy, to nawet może były śmieszne obrazki, wtedy jeszcze nie memy, że możemy najpierw dostać zlecenie na kwadrat, później zrobić to z tego trójkąt, potem przerobić to na kółko, a potem w wyniku feedbacku znów wrócić do kwadratu. I niestety ludzie z przekąsem anegdoty tego typu opowiadają, że najpierw mieli dorobić, później mieli usunąć, a potem jeszcze raz dorobić. I to jest słabe, tak być nie powinno.

Ja tu widzę właśnie jakby taki fundamentalny temat, jaka jest strategia firmy, jaka jest strategia produktu, jaka jest wizja, gdzie są cele i czy te zmiany przybliżają nas do celu, wtedy super, wprowadzajmy to, czy nas odciągają, albo są jakimś takim tematem zastępczym, bo w niektórych firmach strasznie to brzmi, ale to jest naprawdę na faktach, np. strona biznesowa jest bodźcowana do wymyślania. Im więcej feature’ów wymyślą, tym lepiej dla nich, i oni później zalewają zespoły, żeby je tam próbować namówić na to, że o, zróbcie jeszcze to.

 

Ciekawe KPI, muszę przyznać. No tak, a z tych powodów, które tutaj wspomniałeś, no to wcale nie znaczy, że gdyby zastosować jakieś inne podejście, inną metodologię, metodykę, jakkolwiek, to byśmy się tego wszystkiego pozbyli, uniknęli, bo nadal ciągniemy ten bagaż różnych tutaj problemów.

I wiesz, tak sobie myślę, że z ust osób, które gdzieś tam narzekają, że Agile nie działa, często bije taka beznadzieja, bo okej, gdzieś tam wiemy, że Waterfall nie działa. No oczywiście z gwiazdką są przypadki, kiedy może to działać, ale w jakimś tam ogólnym ujęciu. Teraz stykamy się w niektórych przypadkach z Agilem, który ma pewne problemy, ma pewne braki, rodzi frustrację. To można byłoby powiedzieć, że jesteśmy już tutaj przegrani, tak? I nie ma dla nas nadziei, nie ma nadziei. Czy są jakieś alternatywy dla Agile? Które rekomendujesz? Które raczej odradzasz?

 

Zabrzmi to strasznie jak na autora Porządny Agile, ale jedną z alternatyw, którą bym rozważył, to jednak ten Waterfall, ale nie tak rozumiany opresyjnie, tylko autentycznie wyobrażam sobie, że jest pewna pula przypadków wykonywanych prac, myślę zwłaszcza trochę mniejszych, trochę w bardziej ustabilizowanych branżach, może w systemach, które mają też już bardzo rozpoznane to, co powinny robić, procesy, które obsługują, są w miarę ustabilizowane, to tam ten powód dla realizowania Agile’a może się okazać bardzo nikły albo w ogóle nieistniejący.

Bo Agile ma sens wtedy, gdy mamy pewną dozę niepewności na temat tego, co jest do zrobienia, i pewną dozę niepewności na temat tego, jak to zrobić. I jeśli naprawdę autentycznie, i tu nie ma żadnych tam złudzeń, tylko autentycznie po prostu trzeba dodać jeszcze jakiś tam przycisk albo zaaplikować jakiś, czy wprowadzić jakiś proces do systemu i tu nie ma zagadek i w dodatku system jest już wygrzany, 20 lat ludzie to robią, wszyscy się na tym znają, to może się okazać, że to trzeba po prostu dobrze zrozumieć, opisać, wprowadzić, zaprojektować i wprowadzić w życie, przetestować, i ta praca będzie miała taki charakter takiego zdrowego, kaskadowego modelu: przeanalizować, zaprojektować, wdrożyć i będzie dobrze.

I tutaj w tym sensie jakby dla mnie pierwszą poważną alternatywą jest właśnie to. Dużo ważnych założeń przyjąłem w tym, bo to musimy wiedzieć co, musimy wiedzieć jak, i myślę, że to musi być nie za duże, bo też większe przedsięwzięcia nawet jeśli są w miarę rozpoznane, to prędzej czy później dogoni je po prostu zmienność w czasie, czyli już nawet takie największe trendy typu wojny, jakieś choroby, epidemie światowe i takie historie, ale nawet jakieś mniejsze rzeczy typu zmiany strategii firmy, zmiany priorytetów, może nawet zmiany zarządzających, jakiś nowy pomysł na tę organizację.

Więc dużych przedsięwzięć nie robiłbym Waterfallem, ale może Waterfolem pociętym na małe kawałki, gdzieś takie rozwiązanie środka, z Agile’a weźmy podejście iteracyjno-przyrostowe, róbmy małe kawałki, jak najmniejsze fazy, jak najmniejsze takie cele cząstkowe, które złożą się na to coś większego, a już realizacja może być taka bardziej waterfallowa.

Bardzo obiecującą alternatywą, zupełnie z innej flanki i myślę, że nabiera ona popularności, w Polsce też się będzie popularyzowała coraz bardziej, to jest koncept pracy produktowej, mocno przez m.in. Marty’ego Cagana propagowany. No, pewnie mogę parę cierpkich słów powiedzieć, ale myślę, że to jest tak bez żadnej ironii, bez żadnego negowania konceptu, jest to kierunek, czyli takie podejście bardzo produktowe, gdzie po prostu tworzymy zespół produktowy, znacznie szerszy niż tylko zespół wytwórczy, bo to też są osoby z marketingu, w zależności oczywiście od specyfiki danego produktu, i to jest zespół, który po prostu ma pod opieką produkt, nad nim pracuje, wykonują to w takim stylu, w jakim chcą, ciągle doskonaląc, tak naprawdę może zanika koncept jakichś sprintów, to bardziej już jest taki ciągły rozwój.

W tym sensie niektórzy powiedzą: trzecia alternatywa oprócz pracy produktowej, no to w jakimś sensie Kanban. Niektórzy powiedzą, że Kanban to też Agile, ale myślę, że taki Kanban czy takie działanie post-Kanbanowe może być też jakąś alternatywą. Skupienie się na flow, skupienie się na ciągłym doskonaleniu, tu są wspólne punkty z Agilem, ale jednak też takie bardzo poluzowanie zasad: róbcie to, co wam pasuje, działajcie tak, żeby było dobrze, doskonalcie to, usprawniajcie cały proces całościowo, patrzcie na mierniki i róbcie, żeby było lepiej.

I w tym sensie to może być ani Agile, ani Waterfall, tylko po prostu takie unikalne podejście specyficzne dla danego zespołu czy może patrzę szczerzej dla danej firmy i takie jakby robienie tego, co najlepsze, a niekoniecznie trzymanie się tej czy tamtej etykiety, tej czy innej praktyki, bo to faktycznie jak się mocno przyjrzeć, to poszczególne praktyki mogą dla danego kontekstu się średnio sprawdzać i nie ma co na siłę ich forsować.

Więc tych alternatyw trochę jest, ale chyba na razie to wybrzmiewa z tego co powiedziałem, że w każdej z nich trzeba to robić dobrze, w tym sensie, że zastanawiać się co działa, mieć tam asertywność w tym, jak się podchodzi do tego co jest przedmiotem pracy, mimo wszystko wierzę w to, że jest tam dalej zespołowość, nawet jeśli np. trend związany z AI poprawi wydajność pracy poszczególnego developera, to ja uważam, że firmy natychmiast wskoczą w temat: dobra to teraz róbmy szersze zespoły, dorzućmy marketing, dorzućmy sprzedaż, dorzućmy ludzi z operacji i te zespoły mogą być szersze, może bardziej wydajne, jeśli chodzi o dostarczanie produktu, ale łapiące się za trudniejsze rzeczy albo próbujące zrobić to jeszcze lepiej.

Więc myślę, że takie poważne alternatywy wiążą się z tym, żeby zastanawiać się, jak pracować i dobierać rozwiązanie do tego co jest adekwatne dla danej sytuacji, może nawet konkretnie dla pojedynczego zespołu, a może tak trochę szerzej dla firmy.

 

A jakie jest Twoje podejście do takiego wybierania selektywnego, takiego cherry pickingu poszczególnych praktyk z różnych tych podejść i konstruowania w naszym przypadku czegoś unikalnego, co często może być takim potworkiem, bo mamy tutaj dwa obozy. Jedni są bardzo tacy konserwatywni i twierdzą, że albo się trzymamy danej metodologii, danego podejścia, albo w ogóle tego nie róbmy. Inni raczej są właśnie tutaj zdania, że powinniśmy wybierać to co w naszym przypadku działa, najlepiej konstruować coś, co w otoczeniu naszej firmy działa najlepiej. Jakie jest Twoje podejście i jakie masz obserwacje właśnie z tego tutaj tytułu?

 

To jest bardzo podchwytliwe pytanie, bo to, co ja myślę o tym, nie powinno być rekomendacją dla szerokiego społeczeństwa. A co ja myślę? Jest taki mem z rozkładem normalnym i skrajnościami, które są przeciwne do tego, co robi większość i mainstream w środku. I ja uważam, że absolutnie trzeba sobie cherry pickować, ale brzmię wtedy tak samo jak ktoś, kto nie ma pojęcia, o co chodzi, i wprowadza tam codzienne, godzinne daily z szefem.

Więc na pewnym poziomie dojrzałości takie dobieranie sobie praktyk, ich mieszanie, takie powiedzmy dopasowywanie, może nawet porzucanie pewnych elementów uważam, że jest bardzo rozsądne i ja to mocno polecam zespołom, które przejdą pewien poziom minimum.

Taka historia, którą miałem, jeden z pierwszych zespołów, pracowałem też między innymi w mBanku i jeden z pierwszych zespołów mBankowych, którym pomagałem wykorzystać Scruma, po paru latach do mnie wrócił, jeszcze byłem wtedy w organizacji i mówią do mnie: Kuba, wiesz co, ten Scrum to nam tak nie do końca pasuje, ale nie wiemy, czy w ogóle możemy tak obrazoburczo łamać zasady, bo firma jednak nadal była taka all in, działajcie w ten sposób. Ci pierwsi to już mieli dwa lata doświadczenia, a taki komunikat, taki podstawowy macie przestrzegać zasad, róbcie to tak, wspierajcie się w następujący sposób, już dla nich nie była wystarczająco dobra, już zrobili, ile, pięćdziesiąt retrospektyw, no już zdążyli się trochę poprawić.

Ja im wtedy tak podpowiedziałem: słuchajcie, dobra, to teraz może nawet nie musicie się publicznie przyznawać do tego, ale zacznijcie kombinować. Przeczytajcie sobie książkę o Kanbanie, zobaczcie, czy może by nie podejść inaczej do tego, jak sobie wizualizujecie pracę, przedyskutujcie z product ownerem, czy na pewno te relacje między Wami a zespołem są takie, jak chcecie, zastanówcie się, gdzie tu jeszcze DevOps do tego wszystkiego wcisnąć.

I sobie powiedzieliśmy: przestańcie robić Scruma, zacznijcie robić dobry zespół, a na zewnątrz wcale nie musicie tak bardzo być inni, tylko to Wy w środku będziecie wiedzieć, że zaczynacie luzować zasady.

I to jest rada, którą mam, ale to wyraźnie podkreślę, to jest jakby jak w tych reklamach leków, to jest rada dla zespołów, które już działają w miarę jakoś, w sensie już się tam zgrali, już się dogrzali, to mówię, pokombinujcie, jakby to było, bez którejś z praktyk.

Mam parę anegdot tego typu, ale jeden z zespołów stwierdził: daily jest bez sensu, nie robimy daily. No to przestańcie robić daily. Jakby róbcie wszystko inne, nie róbcie daily, zobaczycie, jak to będzie. I ten akurat zespół, to nie ja z nimi pracowałem, to jest z drugiej ręki historia, cali dumni, że nie robili daily, ale się codziennie rano spotykali przy kawie i tam przy okazji wymienili, co tam jest i czy jest jakiś ciężki temat, który wymaga jakiejś pomocy.

Więc znam zespoły, które właśnie poluzowują sobie zasady, rezygnując na przykład, no nie będę może wymieniał, rezygnując z poszczególnych praktyk albo wprowadzają w ich miejsce coś, co jest takie, no ewidentnie nie z książki, ewidentnie nie ze szkolenia. Fajnie próbować, fajnie inspirować się, fajnie kombinować, nawet po to tylko, żeby wrócić do tego, czegoś podstawowego, ale lepiej rozumieć, po co to się jednak robi, po co to się dzieje.

Jest trochę problem w tym, że często na bardzo początkującym poziomie zespoły robią praktyki, których nie rozumieją sensu, których nie rozumieją takiej istoty i to nawet nie chodzi o to, że ktoś nie wyjaśnił im tego, tylko po prostu tak przyjmują na wiarę, dobra, musimy robić podsumowanie sprintu, nie za bardzo czujemy, po co to jest, ale będziemy robić i w sumie nie chcemy z tym dyskutować.

A czasami może trzeba przestać to robić albo przeżyć jakąś przygodę z innym podejściem, żeby zrozumieć, że to może jednak ma sens, ma sens skrzyknąć wszystkich, przegadać to, przepracować, może trochę inaczej do tego podejść, więc ja jestem fanem, żeby kombinować, ale to nie jest rada dla wszystkich.

 

Rozumiem. Wobec tego, jaka jest przyszłość Agile, czy to podejście będzie musiało się zmienić, aby wpasować się w całe zmieniające się nasze tutaj otoczenie, czy też może czeka i zagłada właśnie, jakie jest tutaj Twoje przewidywanie?

 

To jest pytanie, które sobie zadaję już od wielu lat, od powiedzmy dwóch, to już tak bardzo mocno. Zresztą tak, jak mnie przedstawiałeś, Agile in the name only to jest taka moja myśl, czekam na dzień, w którym Agile in the name only po prostu padnie. To może oznaczać, że w ogóle cały koncept zostanie też jakby zanegowany, ta etykieta może zaniknąć.

Ja wierzę, że ta istota zwinności, która jest pod spodem, ta esencja, dalej pozostaje adekwatna i firmy będą dalej tak działać, tak się inspirować. Gorzej, jeśli będzie trzeba udawać, że się tego nie robi albo nie nazywać tego w ten sposób, ale dalej tak działać.

Więc tutaj jestem trochę pesymistą. Bardzo obawiam się, że przy tym modelu działania, który jest dzisiaj, ta zła fama wymuszanego Agile’a, który koło tego właściwego nawet nie stał, spowoduje, że się po prostu zatraci ta etykieta. Być może świat znajdzie nową etykietę na to, ale uważam, że dalej taki styl pracy będzie, przynajmniej dla pewnej puli przypadków, dalej będzie adekwatny.

Natomiast ja myślę, że to nas jeszcze czeka. Tu jakby już jest teza w tym odcinku, w niektórych Twoich pytaniach, że jest niechęć, że jest hejt, że jest część na przykład developerów zniechęcona. Myślę, że jeszcze jest dopiero przed nami taki hejt, czy może taka publiczna opinia na temat tego, jak duże organizacje się z Agile’a wycofują.

To może jeszcze potrwać kilka lat, bo kilka lat trwało, żeby duże organizacje w ogóle w Agile’a wchodziły, i na razie są z tego dumne, ale za parę lat organizacje, które nawet może dobrze tego nie robiły, będą z dumą ogłaszały, że przestają to robić (coś, czego nigdy nie robiły). Wtedy może być tak, że otworzysz LinkedIn i codziennie jakiś wpis o tym, zapowiedź, że tam jakiś duży bank zamiast Agile’a robi coś tam, jakiś inny przymiotnik. I może być wtedy takie wrażenie, że już wszyscy ogłosili koniec.

To jest ogólnie taki prosty clickbait o tym, że Agile jest martwy. Pierwszy wpis tego typu mnie  tak oburzył gdzieś w 2011 roku. Jakiś tam kontrowersyjny człowiek stwierdził, że to w ogóle nie ma prawa zadziałać i koniec, już się zamykamy. Oczywiście zawsze tam pod spodem jest jakaś książka, którą ten człowiek sprzedaje albo jakiś kurs albo coś, więc trzeba było przyciągnąć uwagę słuchaczy. Ale fakty są takie, że prawdopodobnie jeszcze czeka nas taki negatywny wydźwięk wycofywania się i niekoniecznie to będzie ten przyjemny moment dla osób, które mocno za Agile są.

Ja z tego powodu sobie temat Agile’a np. na swoim LinkedInie w ogóle wyciszyłem. W sensie przestałem śledzić ludzi, którzy zajmują się Agile’em, bo człowiek może czasami za bardzo uwierzyć w te clickbaity. Po prostu codziennie robię robotę w kolejnych firmach, w kolejnych zespołach i dowożą. Gdzieniegdzie jak się policzy, to widzimy rezultaty pozytywne, w innych bardziej na wiarę to przyjmujemy.

Więc myślę, że będzie takie rozwarstwienie. Ci, co robią tę robotę, po prostu stwierdzą, no nie za bardzo można zrobić coś innego lub się nadbuduje na tym jeszcze kolejne praktyki, które się fajnie rozkręcą. Myślę, że tutaj AI może tak trochę zracjonalizować pewne rzeczy, które dzisiaj są robione bardzo na wiarę, czyli będziemy mieli trochę może mocniejsze racjonalne wsparcie w pewnych pracach procesowych. A w wielu firmach będzie z dumą ogłaszane, że wycofują się z Agile’a. W niektórych organizacjach to nawet może będzie wahadło, czyli już nie robią, od nowa robią, ale jednak nie robią. Będzie zamieszanie.

W tym sensie może bym się mniej przejmował tym, co robią inni, a skupił się na tym, jak to wygląda w moim zespole, w mojej firmie, w moim dziale. Czy to jest Agile, czy to jest nie Agile, czy to jest efektywność zespołu, czy to jest właśnie praca produktowa. Pytanie, czy są rezultaty, czy są efekty, czy są zadowoleni interesariusze, jak dobrze jest klientom, czy jest wynik biznesowy, ale też np. jaka jest jakość produktu, jaki jest proces jego tworzenia, czy jego utrzymania. Na tym bym się skupił, a nie na tym, czy mamy na froncie etykietę na taką, czy inną literkę.

To może jeszcze potrwać kilka lat, bo kilka lat trwało, żeby duże organizacje w ogóle w Agile’a wchodziły, i na razie są z tego dumne, ale za parę lat organizacje, które nawet może dobrze tego nie robiły, będą z dumą ogłaszały, że przestają to robić (coś, czego nigdy nie robiły). Wtedy może być tak, że otworzysz LinkedIn i codziennie jakiś wpis o tym, zapowiedź, że tam jakiś duży bank zamiast Agile’a robi coś tam, jakiś inny przymiotnik. I może być wtedy takie wrażenie, że już wszyscy ogłosili koniec.

Tak dokładnie, przyklejanie etykietek zazwyczaj źle się kończy, jestem absolutnie też tego zdania, że będziemy obserwować ewolucję całego tego podejścia, ale myślę, że gdzieś tam na koniec dnia z korzyścią, jak będzie, to oczywiście zobaczymy.

Dziękuję bardzo. Moim dzisiejszym rozmówcą był Jakub Szczepanik. Rozmawialiśmy o takim dojrzałym i zdroworozsądkowym podejściu do Agile.

Kuba, bardzo Ci dziękuję za spotkanie.

 

Dzięki bardzo.

 

Powiedz, proszę, na koniec, gdzie Cię możemy znaleźć w internecie?

 

Wspomniałem na samym początku, jeśli temat Agile jest interesujący, to mocno polecam podcast Porządny Agile. To w tej chwili, to już nie tylko podcast, bo też w razie czego można znaleźć zapis naszej rozmowy na YouTubie, też na profilu Porządny Agile. Mamy też niektóre nasze rozmowy zamienione na artykuły, więc można też po prostu poczytać pewne tematy.

Drugie miejsce, gdzie można mnie też znaleźć, to mój blog, kubaszczepanik.pl Dawno już nie wpisywałem nic, ale to jest taki zapis, taki mój notatnik na boku, może dzienniczek, z czasów, gdy jeszcze trochę bardziej mi się chciało pisać, to spisywałem różne przemyślenia i tam parę perełek można znaleźć i się doszukać pewnych przemyśleń o zwinnych transformacjach, o Agile’u, o rekrutacjach i paru innych rzeczach, bo też trochę jest przemyśleń o tym, jak zarządzają zespołem, też się tam znajdzie.

 

Super, zatem zapraszamy. Linki oczywiście będą tace do odcinka. Kuba, jeszcze raz wielkie dzięki. Do usłyszenia i cześć. 

 

Cześć! 

 

I to wszystko, co przygotowałem na dzisiaj. Jeśli chcesz więcej takich rozmów, sprawdź poprzednie odcinki, tam też znajdziesz mnóstwo wartościowych treści. Masz pytania, przemyślenia lub po prostu chcesz się przywitać, napisz na krzysztof@porozmawiajmyoit.pl lub odezwij się na socialach. 

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o Agile w IT. 

Do usłyszenia w następnym odcinku.

Cześć!