Wprowadzenie do wprowadzenia AGILE – Dariusz Klupi

Podcast Leaders Island Z Warsztatu LiDERA – transkrypt
ODCINEK 2

Leaders Island Podcast 2
WPROWADZENIE DO WPROWADZENIA AGILE
Dariusz Klupi

Józef: Dzień dobry, to jest podcast Z warsztatu menedżera. Nazywam się Józef Kącki i razem z moimi gośćmi dzielę się praktyczną wiedzą i umiejętnościami na temat zarządzania. Jeśli jesteś menedżerem, który chce się rozwijać, czerpać z praktycznych doświadczeń mentorów i w ten sposób szlifować swoje umiejętności, tan podcast jest dla ciebie. To jest drugi odcinek podcastu Z warsztatu menedżera. Dzisiaj w audycji będziemy rozmawiali o Agile, a dokładniej mówiąc o tym, jakie kroki powinien wykonać menedżer, który chce zaimplementować Zwinne praktyki zarządzania projektem w swoim zespole. W studiu moim i waszym gościem jest Darek Klupi, który ma bardzo duże doświadczenie w tym obszarze zdobyte, nie tylko w kilku krajach, ale także na różnych kontynentach. Cześć Darek, witam cię bardzo serdecznie.

Darek: Cześć Józef. Witam wszystkich.

Józef: Zanim zaczniemy, przedstaw się proszę słuchaczom. Powiedz kim jesteś, co robisz i skąd się wziąłeś.

Darek: Dariusz Klupi, jak wspomniałeś. Kim jestem? To jest pytanie, na które cały czas szukam odpowiedzi. Natomiast: skąd się wziąłem? Urodziłem się w Krakowie, studiowałem informatykę. Już w szkole średniej było to moje hobby – budowanie systemów informatycznych. Przez pierwszą część mojej kariery byłem programistą, czyli tworzyłem oprogramowanie. Później, gdy pojawiały się coraz większe wyzwania informatyczne, zauważyłem, że jedna osoba źle się skaluje i potrzebny jest zespół, aby stworzyć coś większego. Praca w zespole nie jest łatwa i zaczęło mnie fascynować, jak to się dzieje, że banda inteligentnych, dobrze wykształconych ludzi nie jest w stanie stworzyć razem fajnego rozwiązania. Tak się zainteresowałem tym tematem, że straciłem zainteresowanie technologią i zacząłem interesować się dynamiką międzyludzką, psychologią, komunikacją. W zasadzie nastąpiło takie przepięcie, automatycznie wskoczył temat przywództwa. Podejrzewam, że to zainteresowanie nas łączy. To wszystko ujęte w przede wszystkim dostarczaniu w sposobach zwinnych.

Józef: Gdzie pierwszy raz się spotkałeś z podejściem zwinnym?

Darek: Pierwszy raz spotkałem się z tym sposobem, nie wiedząc o tym. Pracowałem agilowo już od samego początku. Pierwsze oprogramowanie tworzyłem, można powiedzieć profesjonalnie, w Telekomunikacji Polskiej z nudów. Po prostu nudziło mi się i tworzyłem oprogramowanie, które ułatwia pracę. Najpierw mnie, a później moim kolegom. Później w Comarchu przez to, że mieliśmy dużo ograniczenie, jeśli chodzi o czas i bardzo wielką swobodę, jak pracować. Z perspektywy czasu widzę, jak dużo zwinnego podejścia było i nazywaliśmy to zdrowym rozsądkiem. Wiele osób jak poznaje Agile’a, to często dziwi się, że to jest po prostu zdrowy rozsądek, to nie jest żadna metoda. Takie były początki. Ze słowem Agile spotkałem się po przeczytaniu kultowej książkki dla programistów Pragmatic programmer. Wtedy dowiedziałem się o manifeście agilowym. Przeczytałem go i stwierdziłem, że nie da się inaczej dobrze tworzyć oprgoramowania. Manifest podpisałem i tak zaczęła się wieloletnia przygoda z tym podejściem.

Józef: Wiem, że miałeś długi epizod pracy programisty w Szwajcarii. Kiedy przeniosłeś się tam, czy od razu zanurzyłeś się w zwinnym produkowaniu oprogramowania? Czy tam też jeszcze były jakieś resztki wodospadowego podejścia?

Darek: Szczerze mówiąc, z waterfallem spotkałem się dopiero w firmie Creditt Suisse, dlatego że przez pierwsze lata pracowałem w małych albo średnich firmach i po prostu tam bardzo często nie ma miejsca, pieniędzy ani czasu, żeby stosować naukowe metody tworzenia oprogramowania. Mam na myśli dzielenie na różne fazy, po specjalizacji. Bardzo często nie ma osobnych ludzi, którzy zajmują się bardzo wąską dziedziną, jednym zagadnieniem, czyli na przykład tylko analizą biznesową czy testowaniem. W małych firmach po prostu nie ma na to czasu i ludzie muszą być dużo bardziej uniwersalni. W momencie, kiedy pracowałem w Szwajcarii, w firmie rodzinnej prawie sześć lat, zajmowałem się wszystkim. Od rozmowy z klientem poprzez analizę biznesową, wyobrażanie sobie rozwiązania, tworzenie architektury, kodowaniem, poprawianie swoich błędów. Miałem bezpośrednią styczność z konsekwencjami błędów, które popełniałem we wcześniejszych fazach, co było taką bardzo fajną pętlą zwrotną, która pozwalała mi bardzo szybko się uczyć. Przez sześć lat nie byłem w stanie zrozumieć, jak to jest, że projekty informatyczne się nie udają. Nasza skuteczność, w tej małej firmie rodzinnej, wynosiła ponad dziewięćdziesiąt procent. Klient, który przychodził i mówił o swoich potrzebach, w dziewięćdziesięciu procentach przypadków odchodził z rozwiązaniem, z którego był zadowolony. Czytałem w prasie fachowej, że ponad połowa projektów się nie udaje i nie byłem w stanie zrozumieć, jak to się dzieje. Głodny wyzwań i większej złożoności dołączyłem do firmy Credit Suisse i to był pierwszy moment, kiedy zetknąłem się z Waterfallem i to w brutalny sposób. Z tego całego zakresu, którym zajmowałem się w małych firmach, otrzymłem tylko i wyłącznie jeden, wąski etap. Czyli dostałem specyfikację od świetnie opłacanych specjalistów. To świetne opłacanie jest ważne, dlatego że w jakiś sposób powoduje, że czujemy się mali i daje wrażenie, że nasze zdanie jest nieważne. Wiemy, że tutaj właśnie przyjechał spcjalista z City of London, jest bardzo znanym i szanowanym ekspertem. W momencie, kiedy dostajemy jakieś papiery, specyfikacje, nawet jeżeli nie mają one dla nas sensu, akceptujemy je, bo wierzymy, że ten ekspert po prostu się nie myli. Moja sytuacja w tej firmie była taka, że mniej więcej przez rok próbowałem się dowiedzieć, kto będzie używać tego oprogramowania, (8:20 – przejęzyczenie) jaka będzie interakcja z tym systemem. Wszyscy eksperci mówili: „Dariusz to nie jest twoje zadanie, twoim zadaniem jest napisanie kodu. My już wszystkie decyzje podjęliśmy, to jest wszystko przemyślane i nie musisz się w ogóle tym przejmować. Po prostu zakoduj to”. W momencie, kiedy przyszło w grudniu do przekazania rozwiązania klientom, wszyscy eksperci zniknęli. Efekt był taki, że w banku inwestycyjnym jeden z traderów zaczął na mnie krzyczeć, że jestem idiotą, że zmarnowałem masę pieniędzy na projekt, że produkt jest w ogóle nieadekwatny do ich sytuacji, nie są w stanie go używać i po prostu poczułem się bardzo źle.

Józef: Sama radość, z tego co mówisz.

Darek: Był to dla mnie szok, dlatego że wszystkie przeczucia, które miałem, czytając specyfikacje, wszystkie pytania, jakie zadawałem: po co, dlaczego, jak to, to dla mnie nie ma sensu, nagle zyskały na ważności. Wiedziałem, że to były właściwe pytania, na które, jeśli nie dostaję odpowiedzi, to bardzo możliwe, że jest coś nie tak. To był brutalny sposób, ale zacząłem trochę bardziej wierzyć w siebie i w swoją intuicję, która podpowiadała mi, że coś chyba jest nie tak.

Józef: Później po tym doświadczeniu w Szwajcarii przyszedł czas na pracę w Azji, tak? Do której zapewne wrócimy. Powiedz w skrócie, czym się zajmujesz teraz. Co Ciebie teraz zawodowo zajmuje?

Darek: W tym momencie powiedziałbym, że staram się stworzyć warunki w dużej korporacji po to, żeby firma miała korzyści biznesowe z metod zwinnych. Pomijając modę na to, aby dostarczać oprogramowania Agilem, tym właściwym powodem, dla którego my chcemy dostarczać to metodą zwinną jest zyskanie przewagi konkurencyjnej. Czyli mówimy tutaj o korzyściach biznesowych.

Józef: To jest ciekawe, co powiedziałeś, bo rzeczywiście z jednej strony Agile jest już bardzo popularny. Niektórzy złośliwie mówią, że wystarczy na książce kucharskiej napisać Agile i będzie się sprzedawała dużo lepiej. Mam wrażenie, że jest coś w tym jest z prawdy. Już powoli dochodzimy do obłędu, w którym za chwilę właściciele kotów będą od swojego kota wymagali większej zwinności niż jego naturlna, bo wszyscy muszą być Agile. Przejdźmy więc od razu do bardzo brutalnego pytania. Po co menedżer miałby wdrożyć Agile’a? Nawiązuję tutaj do takiej ogólnej narracji, która panuje przynajmniej w branży IT, z której Agile wyszedł, że mamy świat dobrych programistów, deweloperów którzy chcieliby zwinnie i elastycznie pracować i mamy też opracawców menedżerów, którzy absolutnie są blokadą każdej zmiany. Po co menedżer miałby wdrażać Agile?

Darek: Chyba najprostszą metodą jest obniżenie ryzyka projektu. Metody zwinne są tak skonstruowane, że odkrywa większość ryzyk, jakie projekt ma, bardzo szybko. W tym momencie możemy korygować wszystko, co tyczy się produktu, dostawcy, zespołu bardzo szybko. Wtedy kiedy mamy jeszcze cały budżet i cały czas do deadlinu.

Józef: Bardzo cieszę się, że o tym wspomniałeś mówiąc o ryzykach w projekcie. Mam wrażenie, że panuje się wśród nas taka narracja, że jeśli przejdziemy na tą cudowną, zwinną metodę, czy to będzie Scrum czy coś innego, to nagle nie będziemy mieli ryzyk, nie będziemy mieli problemów, a świat będzie piękny i będziemy chodzili w miękkich trampkach, fajnych podkoszulach i będziemy mieli zawsze uśmiech na twarzy, bo problemy nie wystąpią. A tymczasem, odzierając takie podejście z fikcji, mam przed sobą raport z 2012 roku, który porównuje projekty realizowanie agilowo i projekty realizowanie waterfallowo. Widać tutaj bardzo dużą różnicę na korzyść projektów, które się udają w Agilu – to jest 42%. Podlinkujemy źródło tego raportu pod audycją. W metodzie waterfallowej to jest 14%. Czyli mamy 42% udanych projektów do 14%. To jest trzy razy więcej. Natomiast, to co jest ciekawe i co mnie od razu bardziej interesuje: „no dobra, czyli w Agilu jest 42%, które się udaje, ale jest cała reszta tortu”. Jak popatrzymy na liczbę projektów, które w obu metodykach są problematyczne, są challangem, jak to jest w raporcie pokazane, to mamy relację: Agile 49%, Waterfall 57%. Ta różnica nie jest już taka wielka, co oznacza, że to jest wciąż rzeczywistość, która nie jest kolorowa. Mimo wszystko, w obu podejściach trzeba walczyć i rozwiązywać kreatywnie problemy.

Darek: Bardzo często w swojej karierze jestem proszony o to, żeby zrobić ocenę dojrzałości zwinności zespołów. Muszę ci powiedzieć, że w ponad połowie przypadków ludziom tylko wydaje się, że pracują w sposób zwinny. Bardzo często używają i języka, który zapożycza słowa kluczowe z tego podejścia, natomiast tak naprawdę nie ma to nic współnego z Agilem.

Józef: Czyli nie wystarczy robić codziennie standup-y, działać w dwutygodniowych sprintach, żeby uznać się za super zwinną agilową organizację.

Darek: No niestety, jest to niewystarczające. Przede wszystkim dlatego, że musimy pamiętać, że metody zwinne mają minimalizować ryzyko, więc mają wykazać wszystkie ryzyka, jakie są w projekcie. A w projekcie mamy ryzyko chociażby tego, że podjęliśmy błędną decyzję, rozwiązujemy zły problem. To jest pierwsze ryzyko, takie na samym początku. Ryzyko związane z dostawcami, technologią, dynamiką zespołową. W momencie, kiedy my tych ryzyk faktycznie nie sprawdzamy, tylko pozwalamy, żeby były one sobie na półce i nie robimy żadnych eksperymentów, które mają nam pokazać, czy założenia, które zrobiliśmy, są prawdziwe, czy rozwiąujemy dobry problem. Czy użytkownicy końcowi faktycznie będą chcieli stosować to rozwiązanie. Jeżeli nie będziemy robili nic w tym kierunku, tylko czekamy aż mamy wszystkie standyp-y, releasy, ale nie konfrontujemy tych półproduktów, kolejnych – jak to mówimy w Agilu – inkrementów jakiegoś produktu. Jeśli faktycznie nie idziemy do jakiegoś użytkownika, nie próbujemy powiedzieć: „Słuchaj, czy możesz spróbować tego użyć? Czy to jest faktycznie to, co sprawi, że twoje życie będzie lepsze?”. Jeżeli tego nie robimy i czekamy do końca, to ryzyko cały czas mamy w projekcie. I nieważne czy efekt będzie taki sam w momencie, gdy zrobimy rollout, czy wydamy oprogramowanie i damy dostęp użytkownikom. Gdy oni po raz pierwszy w swoim życiu zobaczą to oprogramowanie i powiedzą: „No nie, to nie jest to rozwiązanie”, to nieważne czy było robione Waterfallem, czy metodami zwinnymi, po prostu klient nie będzie chciał za to zapłacić. Nie będziemy mieć korzyści biznesowych.

Józef: Czyli wracając do tego pytania, po co menedżer miałby wdrażać Agile, parafrazując to, co zostało powiedziane, udzieliłbym odpowiedzi, że jego życie stanie się łatwiejsze, nie łatwe. To nie jest, że będzie teraz mlekiem płynące, bezproblemowe. Będzie łatwiejsze, ta liczba możliwych zasadzek i projektów, które się nie udają jest relatywnie trzy razy wyższa. 17 20 – tu chyba miało być, że niższa.

Darek: Ja bym powiedział, że zmienia się charakterystyka albo rozkład problemów. Jeżeli weźmiemy sobie jakiś projekt na jakiś czas, to bardzo często w standardowych podejściach jest bardzo dużo problemów na początku, później jest środek, kiedy wydaje nam się, że wszystko jest pod kontrolą, bo przecież wszystko zaplanowaliśmy, eksperci klepnęli projekt. Wydaje się, że wszystko idzie w dobrym kierunku i jest bardzo dużo problemów na końcu, kiedy mamy ten prawdziwy test, czy to, co stworzyliśmy, jest tym właściwym rozwiązaniem. Charakterystyka prezentuje się tak, że jest dużo problemów na początku, mniej w środku i bardzo dużo na końcu. Wszyscy wiedzą, że ten okres UAT, czyli User Acceptance Testing, to jest bardzo stresujący okres w życiu każdego project menagera. Agile zmienia tę charakterystykę, która zaczyna być troszeczkę płaska, natomiast podniesiona troszkę wyżej. Problemy wystepują z większą częstotliwością, ale mamy więcej czasu na to, żeby je rozwiązywać. Mamy bardziej komfortowe warunki, żeby te problemy rozwiązywać i dobrze prowadzony projekt agilowy w zasadzie nie zaskakuje na końcu. Jeżeli na końcu mamy wielką niespodziankę, kiedy klient albo sponsor jest niezadowolony z rozwiązania, to znaczy, że coś zrobiliśmy źle w trakcie całego procesu.

Józef: Czyli nie należy traktować Agila jako podcinania gałęzi, na której siedzi menedżer, bo też często słyszałem o tym, że jest duży opór, jeśli chodzo o wdrażanie zwinnych metodyk w warstwie zarządzającej. Dzisiaj jestem project menedżerem, czyli właściwie mam władzę nad wszystkimi, mogę zajechać każdego, mówiąc kolokwialnie, Wykresem Gantta udowodnić mu, że powinieć być w innym miejscu niż jest, a teraz wprowadzimy zwinne metody i kim ja mam zostać. Scrummasterem? Przecież to jest w ogóle miękka funkcja coucha, czy product ownerem? Nie mniej, jak rozumiem, z punktu widzenia menedżera jest to 19 49 – przejęzyczenia do uzasadnienia takimi twardymi liczbami, bo oczywiście ilość problemów przekłada się na czas i produkcję oprogramowania, a więc koszta. Wspomniałeś o tym, że sprawdzasz dojrzałość zespołu do pracy zwinnej. Bardzo mi się to spodobało, ponieważ kilka razy spotkałem się z sytuacją, kiedy właśnie menedżer chciał wdrożyć metody zwinne w zespole, a programiści deweloperzy byli tą siłą, która generowała opór. Z jakiegoś powodu nie chcieli. To mnie zastanawia, bo gdzieś za rogiem stoi przecież obietnica czegoś wspaniałego, a jednak opór był po stronie zespołu.

Darek: Praca w metodologiach zwinnych tak naprawdę jest dosyć ciężką pracą. Dlatego że wymaga utrzymania bardzo wysokiego skupienia na tym, co się robi. Jest cały czas wzmagana presja czasu, czyli mamy cały czas te dwutygodniowe okresy i co dwa tygodnie faktycznie musimy dokończyć 20 07 przejęzyczenie jakiś fragment oprogramowania. Nie ma miejsca na to, żeby sobie odpuścić i powiedzieć „Projekt trwa pół roku, powiedzmy, że jest lato, więc możemy sobie pracować troszkę lżej”. Potem mamy jesień i wiemy, że deadline jest doopiero na grudzień, więc przyspieszymy na jesień i powinno być okej. W Agilu bardzo często jest Sense of urgency, które jest wzmacniane systematycznie i praca metodami zwinnymi jest po prostu trudna. To po piwersze. Po drugie, spotkałem się z zespołami, które nie chcą pracować w Agilu. Bardzo często były to zespoły, które w jakiś sposób znalazły sobie strefę komfortu, gdzie w dużej mierze kontrolują środowisko. Są to bardzo często seniorzy, w sensie bardzo doświadczeni programiści, którzy są odpowiedzialni za jakieś oprogramowania od, powiedzmy, dziesięciu lat. Cała firma się liczy z ich wiedzą i bardzo często role są odwrócone: to nie jest tak, że menedżer przewodzi grupie programistów, tylko programiści przez to, że mają bardzo mocny atut w ręku w postaci np. strategicznego systemu, który oni napisali i oni go znają, odawracają role i to oni zarządzają.

Józef: Oni są właścicielem, że tak powiem, największego królestwa, które może runąć. Nie menedżer.

Darek: Dokładnie. Agile, wprowadzanie metod zwinnych, z powrotem odwraca tę rolę. Dobrze wprowadzony Agile przekazuje sterowanie klientowi, który płaci za programowanie, komuś, kto finansuje to przedsięwzięcie. To jest to oddawanie tych przysłowiowych lejców.

Józef: Ja się zastanawiam, czy wpływ na to, że część zespołów nie chce, czy czuje opór przy przejściu na techniki zwinne, nie jest związany z umiejętnością współpracy i pewną otwartością i zaufaniem, jakie mamy do siebie jako ludzie. W Agile jest wpisana pewna, a nawet większa niż pewna, ekspozycja społeczna. Mamy sprint, mamy standup-y codziennie, musimy się skonfrontować. Coś wczoraj powiedzieliśmy, musimy dzisiaj się z tego „wyspowiadać” oraz zaufać drugiej osobie, że ona zrobi to, co ustaliliśmy. W tym kontekście bardzo intrygujący jest raport CEBOSU z 2016 roku, który pokazuje zaufanie społeczne. Co ciekawe, na jedno z dwóch pytań, które zostały zadane ludziom, pierwsze brzmiało: ogólnie rzecz biorąc, większości ludzi można ufać, a drugie: w stosunku z innymi trzeba być bardzo ostrożnym, trudno powiedzieć. W 2016 roku 23% Polaków odpowiedziało na pierwsze pytanie twierdząco – większości ludzi można ufać, a 74% odpowiedziało, że większości ludzi nie można ufać. Nie mówiąc o jakich ludzi chodzi. Chodziło o generalnie nastawienie. Ten trend rośnie, bo w 2002 roku było 19%. Po 14 latach mamy 4% więcej po tej dobrej stronie mocy. Zadano też pytanie odnoszące się do tego, jakim grupom ufamy. Czy ogólnie rzecz biorąc ma pan/i zaufanie, czy też nie ma pan/i zaufania do: (..) i wymienione też grupę „osoby, z którymi pani pracuje”. 18% powiedziało, że zdecydowanie ma zaufanie. 63% – raczej ma zuafnie, cała reszta – nie, zdecydowanie nie ma zaufania do osób, z którymi na co dzień pracuje, czyli właściwie spędza większość swojego świadomego życia, zakładając, że praca to jest 8, czasem 10 godzin.

Darek: Metody zwinne stwarzają warunki, gdzie zaufanie jest cały czas testowane. W zasadzie, trzy filary metod zwinnych to: radykalna przejrzystość, ciągła inspekcja i adaptacja do wszystkiego, co odkrywa inpekcja. Gdy odkrywamy, że nie możemy komuś ufać, natychmiast należy zaadaptować się do nowej sytuacji. Co robimy w takim razie? Wiele zespołów, w których mamy pewne rzeczy do ukrycia, nie będzie chciało prawdziwych metod zwinnych, dlatego że po prostu nie chcą, aby pewne rzeczy zostały dojrzane. Nie chcą się ujawnić, być przejrzanymi, dlatego że będą musieli coś oddać. To, co sobie ugrali i w jaki sposób się zafortyfikowali. Te mury muszą runąć i na pewno coś się zmieni. Ludzie nie chcą zmian.

Józef: W tych badaniach mamy oczywiście odniesienie do Polaków. Jestem bardzo ciekawy, czy mając doświadczenie z Polski, Szwajcarii i Azji widzisz jakieś różnice kulturowe po stronie zespołu i po stronie menedźerów? Jeśli tak, to jakie?

Darek: Mogę oczywiście mówić tylko o trzech krajach, gdzie żyłem i zdobyłem jakieś doświadczenia z pierwszej ręki. Powiem tak. Wprowadzanie Agila w każdym kraju stawia inne wyzwania. W Hongkongu wielkim wyzwaniem było poddawanie się autorytetom, czyli ludzie w Hongkongu, podejrzewam, że jeszcze bardziej w Chinach, od samego początku są uwarunkowywani, żeby nigdy nie kwestionować nauczyciela, menedżera. Jest takie pojęcie jak zachowanie twarzy. Nie wolno pracownikowi stawiać menedżera w złym świetle. Wszyscy są wyuczeni, że jest to bardzo ważne i nie należy tego robić, więc w momencie kiedy ja jako nauczyciel Agila mówię ludziom: „Słuchajcie, jeśli widzicie, że popełniam błąd, to waszym obowiązkiem jest jak najszybsze poinformowanie mnie o tym”. A oni pytają: „Ale przecież tego nie wolno robić, prawda?”.

Józef: Potrafię sobie wyobrazić, że dla nich musi to być jakieś rocket science. Kiedyś miałem dużą przyjemność współpracy z Chińczykami, kiedy wprowadzaliśmy na polski rynek markę Huawei i było dla mnie wielkim szokiem kulturowym, że na spotkaniach na poziomie zarządu, jeśli najważniejszy rangą menedżer nie wykonał gestu udzielającego głosu, to cała reszta jego kolegów, którzy byli bardzo merytoryczni, ale jednak niżej w hierarchii, nawet się nie odezwała. Znaczy, oni nie mieli prawa w ogole ruszyć powieką, dopóki nie dostali pozwolenia z góry. Czysto formalnego.

Darek: Tak. Inczaej wprowadza się Agila w Szwajcarii, a inaczej w Polsce, gdzie jest dosyć łatwo na początku, dlatego że u nas kwestinowanie autorytetów nie stanowi problemu.

Jozef: Nawet jesteśmy w tym, myślę, przodownikami.

Darek: Myślę, że nawet jesteśmy w tym dobrzy. Podejrzewam, że podobnie jest w Stanach Zjednoczonych. W Szwajcarii 29:29 pauzy są przede wszystkim problemy, to znaczy dla mnie to były problemy jako coucha, że dla ludzi są bardzo ważne bezpieczeństwo i przewidywalność. Metody zwinne opierają się na innym paradygmacie – naprawdę nie znamy tej najlepszej drogi, która prowadzi do najlepszego rozwiązania, jakie można w skończonym czasie wykonać, ale na bieżąco przyglądamy się drodze, którą idziemy i czy przypadkiem tej drogi nie zmienić. W Szwajcarii ludzie wierzą ekspertom i wierzą, że da się przewidzieć najlepszą drogę już na samym początku i w momencie, kiedy tą drogę już przewidzimy, to nie chcemy już robić żadnych odstępstw, bo przecież najelpsza droga jest znana. Jeżeli w to wierzymy, to metoda agilowa wydaje się być stratą czasu.

Józef: To wróćmy w takim razie na polskie podwórko i przejdźmy do trudnego pytania. Jakie pierwsze kroki powinien wykonać menedżer, który chce wprowadzić zwinne praktyki w swoim zespole, do którego argumenty finansowe związane ze skutecznością i z większą optymalizacją procesów działają, który ma tyle odwagi, żeby też nie bronić swojego królestwa?

Darek: Dla mnie pierwszym najważniejszym krokiem jest uproszczenie sposobu działania i współpracy zespołu ze stroną zamawiającą. Uproszczenie i przybliżenie tych dwóch zespołów do siebie. W Agilu wykonuje się to przez taki artefakt, który nazywa się Peglogiem. Peglog to jest po prostu taka bardzo długa lista przyszłych interakcji z rozwiązaniem. Ta lista jest zawsze spriorytetyzowana pod względem interakcji, które dają najwięcej wartości. Jeżeli pewne interakcje będą możliwe, to one natychmiast przyniosą bardzo dużą wartość wymierną. Albo coś stanie się możliwe albo niemożliwe lub też będzie zajmowało dużo mniej czasu. Albo zautomatyzujemy jakiś pracochłonny fragment, który tak naprawdę nie wnosi dużo wartości dodanej, natomiast trzeba go wykonywać. Dostajemy coś co natychmiast sprawia, że jakość naszego życia się poprawia. Na górze tej listy mamy rzeczy, które dają tej wartości więcej, mają bardziej pozytywny wpływ na nasze życie. Na dole mamy te rzeczy, które je 32 34 pauza trochę usprawniają, ale dużo mniej. Jest to pierwsze rzecz, od której zaczynamy, jest to część po stronie zamawiającego. Czyli biznes jest tak naprawdę odpowiedzialny za to, żeby tę listę mieć. Żebyśmy wiedzieli, co tak naprawdę jest wartościowe.

Józef: Przy czym jak pójdziemy do zamawiającego i namówimy go na taką zmianę w naszej interakcji, to co z zespołem? Z tą drugą, naszą stroną? Tu mamy wielu interesariuszy, którzy mogą być niezadowoleni zarówno w górę, jak i w dół albo w bok. To, o czym mówiliśmy.

Darek: Dlatego w Agilu mamy rolę. Product owner, który jest odpowiedzialny za przeprowadzenie negocjacji i po prostu zalecane jest, aby była to jedna osoba, która może mieć pomocników i może stworzyć małą hierarchię po to, żeby ogarnąć wielki temat. Natomiast jest to jedna osoba odpowiedzialna za to, żeby po prostu uzgodnić ten interes pomiędzy wieloma akcjonariuszami.

Józef: Patrząc oczami wyobraźni widzę takiego menedżera, który, załóżmy, że są jeszcze takie obszary, gdzie nie pracuje się jeszcze agilowo, naczytał się wielu artykułów i pomyśli sobie: „No dobra, od jutra będziemy pracowali agilowo. Pójdę do swojego zespołu i powiem im, że od poniedziałku zaczynami dzień od standup-u”. Śmiem twierdzić, że to może się nie udać.

Darek: Tak, 34 22 przejęzyczenia mam taką check-listę kilku rzeczy, które muszą się wydarzyć, zanim jest sens zacząć ten pierwszy sprint, ten pierwszy dzień, kiedy zaczynamy pracować w sposób zwinny. Jedną z takich rzeczy jest stworzenie odpowiedniego zespołu, efektywne przekazanie odpowiedzialności za tworzenie produktu na zespół. Czyli to nie project manager jest odpowiedzialny, ale zespół. Mówię efektywne przekazanie, czyli oni naprwdę rozumieją, że mają wpływ na to, jak ten produkt będzie robiony. Mogą podejmować decyzje. Zadaniem menedżera jest ustawienie wszystkich ograniczeń, których zespół nie może przekroczyć, czyli jak najbardziej ilości pieniędzy, które mogą wydać, czasu, który mogą przekroczyć. Mogą to być jakieś rozwiązania technologiczne, czyli np. mówimy: „Możecie robić, co chcecie, ale nie możecie wchodzić w technologię Oracle, dlatego że mamy taką umowe strategiczną z Microsoftem i nawet jeżeli jako zespół uważacie, że to jest lepsze, niestety to jest techniczne ograniczenie, którego nie możecie przekroczyć”. Takich ograniczeń jest więcej i w zasadzie jak zaczynasz analizować, skąd się te metody zwinne wzięły, gdzie są ich korzenie, to właśnie jednym z takich korzeni jest inny paradygmat zarządzania. Jest zarządzanie nie przepisowe, tylko przez wyznaczania ograniczeń. Takich ograniczeń, po angielsku nazywa się to constraint, w Agilu jest pełno. Chociażby timeboxy, czyli mamy jakiś ograniczony wycinek czasu, w którym coś musi się wydarzyć i jest to nieprzekraczalne. Są inne ograniczenia, np. jak długa może być specyfikacja. Jest to jedno z ograniczeń, które czasami stosuję. Na przykład, że specyfikacja do jednego zadania nie może być dłuższa niż dwa ekrany. W momencie kiedy jest dłuższa należy ją rozbić na podzadania. Pełno jest takich ograniczeń, które są po to, żeby wymusić przewartościowanie, co jest najważniejsze. Bardzo często w czasie szkoleń zadaję pytanie: „Jeżeli poproszę cię teraz o to, żebyś mi opowiedział historię swojego życia, to jak myślisz, ile czasu ci to zajmie?”. 37 18 pauza

Józef: Wiele tygodni. Przynajmniej kilka godzin.

Darek: Dobrze. Chodzi o to, żebyś opowiedział mi historię swojego życia, natomiast masz na to pięć minut. Jak będzie różniła się ta historia?

Józef: Oczywiście, wspomnę o rzeczach najważniejszych.

Darek: Dokładnie. Czyli te ograniczenia w Agilu, które są w wielu miejscach, ciągle wymuszają, żebyśmy swoją ograniczoną uwagę skupili na tym zadaniu, problemie, który w danym momencie jest najważniejszy. W zasadzie to jest największy trik metod zwinnych. Utrzymywanie skupienia na najważniejszych rzeczach i w ten sposób wygrywamy, bo w ten sposób jest mniejsze prawdopodobieństwo, że stracimy czas na nieistotne rzeczy.

Józef: Czyli z jednej strony menedżer musi sobie przygotować pole w zespole do tego, żeby wdrożyć Agile. Do tego służy ci lista. Czy możesz się nią podzielić z naszymi słuchaczami tak, żebyśmy ją podlinkowali pod ten odcinek?

Darek: Tak, wydaje mi się, że jak najbardziej. Mogę się podzielić.

Józef: Świetnie. Mamy takie przygotowanie pola na poziomie, na którym ja jako menedżer funkcjonuję. Przypuszczam, że trzeba też przygotować grunt wyżej. To, co powiedziałeś. Dzisiaj zajmujesz się w dużej organizacji właściwie przygotowaniem otoczenia do tego, żeby Agile mógł zaistnieć. Jeśli potrafię sobie wyobrazić, że przychodzi jakiś młody, zapalony teamleader lub menedżer z wypiekami na twarzy i swojemu szefowi mówi: „Od jutra jedziemy z Agile. Będzie pan zadowolony”. Widzę tymi samymi oczami wyobraźni, jak tętnica zaczyna mu pulsować i mówi: „Synu, wróć na miejsce, na openspace i ochłoń”. Więc, jak może się do tego taki ktoś przygotować? Jakimi argumentami może przekonać górę, że warto zacząć tworzyć środowisko do tej zwinnej metody?

Darek: Ja mam taki jeden trik, który stosuję w czasie rozmowy. Jednym z punktów listy, jak stworzyć te warunki, jest potwierdzenie, czy strona zamawiająca zdaje sobie sprawę z konsekwencji prowadzenia czy dostarczania produktu w sposób zwinny. Dlatego, że te konsekwencje są inne niż w przypadku tradycyjnego podejścia wodospadowego. W momencie, kiedy mam klienta, który np. jest nieprzyzwyczajony do tego, żeby oglądać niekompletne fazy jakiegoś produktu, to pierwszy moment, kiedy on przyjdzie i zobaczy, to tak jakbyśmy remontowali łazienkę. Przychodzimy do architekta, który robi piękną wizualizację, pokazuje nam, jak będzie wyglądała skończona łazienka. Po miesiącu pracy zapraszamy klienta, aby zrobił inspekcję. Jak on wchodzi do tej łazienki i patrzy się, a tutaj wystają jakieś rury, tutaj jest mokry tynk, tutaj nie ma jeszcze kafelek. Wszystko wygląda w sposób totalnie odległy od tego, co klient widział na wizualizacji. W momencie kiedy ten człowiek nie jest gotowy i nie rozumie, po co on się tam w ogóle znalazł, to dla niego to będzie strata czasu. Mówi: „Ale po co mnie tutaj zaprosiłeś? Zaproś mnie wtedy, kiedy będzie to to, co pokazałeś mi na wizualizacji. Wtedy przyjdę i powiem ci, czy zapłacę za wykonaną pracę, czy jakość jest odpowiednia, czy wszystko jest tak, jak się spodziewałem czy nie”. Problem polega na tym, że to jest z późno. W momencie kiedy dajemy zamawiającemy dostęp do tego, żeby kontrolował pewne fazy, to kiedy widzi, co się dzieje, może interweniować. Dlatego że bardzo często wizualizacja robi bardzo wiele założeń. Kiedy widzimy kolejną fazę, może się okazać, „ale chwileczkę, prysznic powinien być w innym miejscu”. Kiedy ja jestem w pomieszczeniu, to już nie jest wizualizacja, to widzę, że jednak jak ta szafka się otworzy, to nie będę mógł przejść do innej części łazienki. Od razu to widzę. To już nie jest wizualizacja. Czym innym jest rzeczywistość, a czym innym plan. Jeżeli ktoś nie rozumie tej wartośći, to nie będzie chciał uczestniczyć. Bardzo często jednym z sygnałów, że Agile nie działa tak dobrze jak powinien, jest, że zespół przygotowuje demonstrację kolejnego kawałka rozwiązania, a ze strony zamawiającego nie pojawia się nikt. To jest moment, kiedy zaczynamy tracić wartości biznesowe, czy korzyści biznesowe z Agila, dlatego że nie nastepuje inspekcja jakiegoś fragmentu i nie nastąpi po niej ewentualna interwencja. Po to to pokazujemy, żeby klient w tym momencie, kiedy widzi, zorientował się, że może coś jednak się nie dogadaliśmy i to niekoniecznie idzie w tym kierunku, w którym chce. Tworzymy szansę na to, żeby interweniować i poprawić. Bardzo, bardzo wcześnie. Jeżeli strona zamawiająca nie jest na to przygotowana i nie zorganizuje sobie czasu na to, żeby uczestniczyć i współtworzyć ten produkt, to wtedy nawet dobrze zarządzany produkt po stronie zespołu, który dostarcza, zamienia się mimowolnie w projekt waterfallowy, dlatego że ma tę samą chrakterystykę. Jest spokój w środku, a potem wielka niespodzianka i rozczarowanie na końcu.

Józef: Ja tak myślę sobie, że w obu kierunkach jeśli chodzi o zespół i ten kierunek komunikacji wewnątrznej, jak i na zewnątrz, w stosunku do klietna, mówimy o pewnej zmianie. Często pokazujemy menedżerom, że przy jakiejkolwiek zmianie warto jest zachować takie trzy podstawowe płaszczyzny komunikacji: warstwę informacyjną, czyli że coś się wydarzy i jak będzie to wyglądało. Nastepna istotna warstwa to warstwa edukacyjna, czyli jak to będziemy robić i po co to robimy i warstwa motywacyjna, czyli jakie będą z tego korzyści. To, od czego zaczęliśmy nasza rozmowę. Korzyści nie będą polegały na tym, że znikną wszystkie problemy. Być może nawet z punktu widzenia klienta w tej metodologii jest więcej interakcji, musi się bardziej zaangażować, musi przyjść do tej łazienki co tydzień zobaczyć, odebrać ogrzewanie podłogowe, zamontowaną kabinę itd., ale robimy to w imię tego, żeby rzeczywiście szybciej i bardziej efektywnie skończyć ten produkt, projekt, a więc ma to już bezpośrednie przełożenie na koszty. Zachowanie tych trzech warstw bardzo prostych, komunikacyjnych powoduje, że naturalny opór, który jest przy zmianie można przekuć na stronę pewnej szansy, która stoi przed nami.

Darek: Dokładnie. Dwa duże projekty w korporacjach prowadzone w sposób zwinny zakończyły się zanim zdążyliśmy zatrudnić programistów. W fazie przygotowania projektu weryfikacja zrozumienia, jaki problem próbujemy rozwiązać z biznesem, biznes zorientował się, że nie jest w tym momenicie w stanie z powodu pewnych ograniczeń tego rozwiązania dostać i projekt zakończył się tak naprawdę, zanim odbył się pierwszy sprint. Drugi taki projekt zakończył się po pierwszym sprincie. W momencie kiedy klient zobaczył pierwsze przybliżenie, pierwsza odsłonę rozwiązania, zorientował się, że popelnił błąd i zamówił złą rzecz. Według mniejest to bardzo dobre zakończenie projektu. Zanim wydaliśmy budżet przeznaczony na to i zanim zmarnowaliśmy czas kalendarzowy, zaczynamy zajmować się czymś innym, w co wierzymy, że ma większą wartość.

Józef: Tak, myślę, że dla klienta jest też dużą wartością, że ma świadomość, iż po drugiej stronie jest partner, który go wspiera. Często jest tak, ze klient nie jest w stanie, to też było moje doświadczenie, będąc po stronie klienta, zamawiałem oprogramowanie, nie byłem w stanie zadać sobie wszystkich pytań związanych z wszystkimi możliwymi ryzykami. Pamiętam, jak wdrażaliśmy system CRM to mimo, że potem powstała specyfikacja trzydziestu stron i tak w procesie dwuletniej produkcji weszliśmy na różne rafy, czasem bardzo płytkie, których nie byliśmy w stanie przewidzieć, choć bardzo sobie ceniłem, że po drugiej stronie miałem partnera, który cały czas zadawał pytania i właściwie współtworzył ze mną jako zamawiającym ten produkt 46 48 przejęzyczenie

Darek: Powiedziałbym nawet, że to jest skutek, może nie uboczny, ale pomiędzy dobrze funkcjonującymi zespołami zwinnymi 46 59 przejęzyczenie a zamawiającymi po jakimś czasie wytwarza się zaufanie. 47 04 (ja to bardzo często symbolizuje – przejęzyczenie Standardowym podejściem jest, że zamawiający jest stroną dominującą i po prostu ma władzą nad dostawcą, dlatego że płaci. Ten, kto płaci – rządzi. Nawet jeżeli zamawiajacy zamówi coś głupiego, to dostawca to dostarczy dlatego że po prostu nie sprzeciwiamy się. Po jakimś czasie stajemy się partnerami. Między stroną zamawiającą i dostawcą pojawia się zaufanie i po prostu jest z tej współpracy dużo większa wartość.

Józef: Mówiąc o Agilu na początku wspomniałeś, że to jest po prostu zestaw praktyk powiązanych z rozsądkiem. Bardzo często mam dokładnie tę samą refleksję, bo oczywiście mówimy o produkcji oprogramowania, czegoś bardzo skomplikowanego, ale wróćmy do tej łazienki, o której mówiłeś. Ile razy choćby wśród naszych znajomych przerabialiśmy przypadki, że przychodzi ktoś odebrać już tę łazienkę i mówi: „Panie, no przecież gdzie ten prysznic tutaj. W ogóle miał być po drugiej stronie. Przecież ja tu nie przejdę – Ale pan tak mi narysował”. I wtedy jest potężna frustracja po stronie zamawiającego „To pan powinien wiedzieć, że tutaj się nie da przejść”.

Darek: Wtedy dostwca mówi: „Panie, ludzie mają takie pomysły i ja je wszystkie realizuję. Jak ktoś chce, to ja mu to robię”.

Józef: Dokładnie, „Ja myśłałem, że pan będzie przeskakiwał”. Tu dochodzimy do kolejnej wartości z punktu widzenia menedżera. Ona może nie jest krótkotrwała, bo nie przyjmujemy każdego zamówienia od klienta. Natomiast taką formą współpracy budujemy dużo lepszą relację z klientem. Bez względu na to, czy to jest klient wewnętrzny, bo ktoś pracuje w bardzo wielkiej organizacji, czy to jest klient zewnętrzny. Moim zdaniem powoli kończy się już czas na to, żeby mieć bezwolne, bezrefleksyjne warzywa po drugiej stronie, które zakodują wszystko, co moja głowa wymyśliła.

Darek: To po prostu jest za drogie.

Józef: Dobrze. To w takim razie, dążąc do konkluzji, 49 27 – przerwa. Podsumujmy. Z jednej strony, jeśli chodzi o Agile, to przede wszystkim stoją za tym bardzo konkretne merytoryczne i mierzalne benefity. W postaci czasu projektu, liczby projektów, które kończymy.

Darek: Utrzymanie wiedzy, dlatego że najczęściej dobrze funkcjonujące zwinne zespoły po prostu trwają dłużej i wiedza, którą gromadzą, jest do dyspozycji organizacji dłużej. Każda wymiana zespołu to jest kolosalna utrata wiedzy i doswiadczeń. Bardzo często biznesmeni nie zdają sobie sprawy jak duża. Tak naprawdę będą musieli zapłacić za to wszystko jeszcze raz. Kiedy wymieniamy zespół, wymienaimy ludzi, ludzie są niezadowoleni, odchodzą, przychodzą nowi. Tak naprawdę musimy zapłacić jeszcze raz za to, żeby odbudować tą masę krytyczną wiedzy, która pozwala zbudować jakieś rozwiązanie i je utrzymywać.

Józef: Z punktu widzenia menedżera warto przygotować sobie taką listę argumentów, czy benefitów, które 50 53 – przejęzyczenie są korzyściami zarówno dla mojego zespołu, jak i dla klienta, jak i dla interesariuszy wyżej w organizacji, czyli mojego szefa.

Darek: Czyli pytanie, co w tym jest dla nich? Dla zamawiających, którzy decydują, co będzie możliwe w czasie realizacji.

Józef: Potem, w kolejnym kroku warto zachować tę informację przynajmniej w tych trzech warstwach, żeby oswoić ludzi z lękiem związanym ze zmianą. Zawsze jest to jakaś zmiana. Mówiliśmy też o przygotowaniu sobie zespołu. O tym, żeby to była przestrzeń, która jest na tyle dojrzała, żeby była w stanie zaadaptować te nowe metody i ta większą ekspozycję społeczną, pewną presję. W niektórych wypadkach większy rytm.

Darek: Tutaj jest też wielki temat, jakie zadania dajemy zespołowi. Są takie dwie strategie: zespoły, które zajmują się komponentami i zespoły, które zajmują się pewnymi funkcjonalnościami rozwiązania. Dwie sztuki jak dzielić zadania. Czy dzielić pionowo czy poziomo, ale to może kiedy indziej. Są zupełnie inne konsekwencje tego, jak dzielimy potrzebę biznesową i w jaki sposób przydzielamy ją do zespołu.

Józef: Tak jak powiedziałeś, myślę, że to jest ciekawy temat na następny odcinek, jak to robić w praktyce. To jest już dylemat, który mamy po tym, jak już przekonaliśmy klienta albo naszych deweloperów albo swojego menedżera, że warto zacząć adaptować zwinne metodyki, co nie oznaczać będzie, że nasza firma się przewróci, zniszczy, straci i będzie jeden wielki bałagan.

Darek: Dla mnie, jakby to krótko powiedzieć, zarządzanie zwinne powoduje lepsze warunki do tego, żeby ludzie mogli troszczyć się o rozwiązanie. Po prostu tej troski o rezultat końcowy może być więcej. Metody inne bardzo często cierpią na to, że ludzie po prostu nie dbają o to, jak projekt/ produkt zostanie odebrany. Wiele osób słyszało o projektach, które się udały i np. zostały odrzucone przez użytkowników. Użytkownicy po prostu nie kupowali tych rozwiązań albo wręcz w jednej korporacji wszyscy sprzedawcy odmówili używania pewnego rozwiązania, za które firma zapłaciła dziesiątki milionów dolarów.

Józef: Aby nie iść w takim razie taką drogą warto zainteresować się, czy zaadaptować metody zwinne do swojego zespołu, do czego zachęcamy słuchających nas menedżerów. Dobrze! To jest podcast Z warsztatu menedżera. Dzisiaj moim i Waszym gościem był Datek Klupi. Zachęcam was do komentowania treści tego odcinka i zadawania pytań, na które z przyjemnością odpowiemy. Darek, bardzo dziękuję za udział w audycji.

Darek: Dziękuję bardzo i mam nadzieję, że do usłyszenia.

Józef: Do usłyszenia.