Obniżanie ryzyka w agile

Jakie zachowania intuicyjne kojarzą się z obniżaniem ryzyka w agile, a jak to wygląda w praktyce? W odcinku rozmawiamy o pułapkach intuicji i podpowiadamy konkretne wskazówki, skupiając się na praktycznym, a nie książkowym podejściu do zarządzania ryzykiem. Każdą pułapkę próbujemy zrozumieć, ocenić kryjące się za nią niebezpieczeństwo oraz proponujemy sprawdzone sposoby radzenia sobie w takich sytuacjach.

Zobacz wersję wideo:

Sprawdź nasz webinar o dzieleniu elementów Backlogu Produktu na mniejsze elementy.

Transkrypcja podcastu „Obniżanie ryzyka w agile”

Jacek: Jakiś czas temu facylitowałem spotkanie z Klientem, podczas którego rozmawialiśmy o pułapkach intuicji. Czyli zaczęliśmy rozważać, które rzeczy myślimy, że działają, a które rzeczy działają naprawdę. Ta myśl, którą obrobiliśmy wspólnie na warsztatach, stała się dla nas pomysłem dla nas na dzisiejszy odcinek.

Kuba: Jest to interesujący wątek i rzadziej poruszany w takim tutaj środowisku tworzonych treści wokół zwinności. Niedawno też mieliśmy takie pytanie od jednej z naszych słuchaczek, którą teraz pozdrawiamy, która pytała właśnie, jakie paradoksy wiążą się z agilem. Na temat tego odcinka wybieramy wątek obniżania ryzyka w agile. Więc porozmawiamy o tym, jakie zachowania intuicyjnie mogą się kojarzyć z tym, co obniża ryzyko. No i niestety, to będą rzeczy, które mogą być mocną pułapką, więc zaproponujemy swoje kontrpropozycje sprzeczne z taką prostą intuicję, ale faktycznie obniżające ryzyko w agile. Co bardzo istotne, poruszymy te wątki praktycznie. Czyli nie chcemy tutaj w ogóle wchodzić w wątek książkowej definicji ryzyka, zarządzania ryzyka, klasyfikację ryzyka. Po prostu, od razu przejdziemy do wątku, jak to w praktyce widzimy, że się realizuje w zespołach zwinnych. Książki, parę za moimi plecami widać, na filmie na YouTube, można sobie zobaczyć. Warto czytać, natomiast my się skupimy tutaj stricte na praktyce.

Jacek: No dobrze Kuba, to gdybyś miał podać pierwszy przykład. Co podpowiada nam intuicja, a co z kolei naszym zdaniem, faktycznie pomaga obniżyć ryzyko w pracy zwinnej?

Kuba: Te intuicje wprowadzimy w postaci cytatów. Więc ja tutaj tak spróbuję się wczuć w osobę, która ze mną dyskutuje. No i czasami słyszę taki głos. „Jak dobrze przeanalizujemy wszystko na początku, to niczego nie pominiemy”. Potrafię zrozumieć osobę, która używa takiego argumentu. Powołuje się ona na chęć niepominięcia niczego, takiego dogłębnego przeanalizowania, zastanowienia się. Sprawdzenia wszystkich możliwych tutaj założeń. I jeśli zrobimy to porządnie, jeśli zrobimy to dobrze, jeśli zrobimy to na początku projektu, no to już wszystko pójdzie prosto. Tylko niestety z tą prostą intuicją, z którą do jakiegoś stopnia empatyzuję, jest spore założenie, czy spory problem. Mamy tutaj taki problem, czy pułapkę myślenia deterministycznego, że faktycznie wystarczy naprawdę dobrze pomyśleć, wystarczy naprawdę dobrze popytać, poszukać, sprawdzać. No i będziemy mieli opanowany cały zakres. Będziemy mieli to wszystko prawdopodobnie również spisane, zaplanowane, porozkładane na części pierwsze. Ja się bardzo obawiam, że takie założenie daje złudne poczucie panowania nad zakresem, które jest niestety tylko złudzeniem.

Jacek: No i to co byśmy chcieli tutaj zaproponować w zamian, to zamiast takiej próby uchwycenia wszystkiego perfekcyjnie od samego początku, raczej rekomendowalibyśmy takie iteracyjne odkrywanie produktu. Czyli taką symultaniczną czynność w stosunku do samego procesu wytwarzania, w której, zanim podejmiemy się realizacji jakiegoś konkretnego zadania, zdobywamy dowody z rynku od naszych Użytkowników, od naszych Interesariuszy, że te pomysły faktycznie mają sens. To jest jakby jedna rzecz. Z drugiej strony, że nasz pomysł na ich implementację również jest właściwy.

Kuba: I, żebyśmy się dobrze zrozumieli. Broń Boże nie sugerujemy, że należy natychmiast rzucić się do pracy. Nie zastanowić się na początku co robimy, jaki jest tego cel, dla kogo to robimy? Natomiast, no tutaj sugerujemy po prostu to, żeby wykonać jakieś czynności związane z odkrywaniem produktu od początku, ale być po pierwsze OK, z tym że nie uda się wszystkiego przewidzieć, wszystkiego przemyśleć, wszystkiego zebrać. I co ważne, nawet jeśli mamy wrażenie, że już w miarę czujemy, o co chodzi, to nie zgubić tego momentu. Że być może na początku byliśmy w błędzie. Być może się myliliśmy? Albo zmieniły się realia, na przykład rynkowe, albo konkurenci coś wprowadzili, albo Klienci zaczęli trochę inne rzeczy preferować. Stąd mocne założenie, robimy odkrywanie produktu na początku prac, ale nie porzucamy tej koncepcji odkrywania produktu również w trakcie dalszego wytwarzania kolejnych wersji, kolejnych przyrostów. Wracamy do tych koncepcji. Być może tylko po to, żeby się utwierdzić, że wszystko jest w porządku. Dobrze to przemyśleliśmy, ale mimo wszystko tutaj czai się ryzyko, o którym jest ten odcinek. Czai się ryzyko, że źle zinterpretowaliśmy rzeczywistość i produkt, który wytwarzamy, będzie po prostu błędny. Będzie niedopasowany. Stąd wykonujmy dodatkowe czynności związane z tym, żeby to ryzyko obniżyć i po prostu powracajmy do konceptu wszystkich tych technik, które używamy, albo nawet zmieniania tych technik, żeby być bardziej spokojnym, że realizujemy właściwy produkt.

Jacek: Kolejną pułapką, którą chcemy przedstawić, to pułapka, w której proponowane jest przygotowanie gotowej, skończonej architektury, zanim rozpoczniemy pracę. Jest to taki przykład, pewnie najbardziej właściwy dla organizacji, które rozwijają własne produkty cyfrowe, gdzie taka pokusa przygotowania architektury na początku, może się pojawić. Z jednej strony, znów empatyzując, pewne decyzje architektoniczne, mogą się okazać trudne do zmiany. Stąd jakby rozumiem potrzebę tego, żeby mieć jakiś, nazwijmy to fundament, który pozwoli nam w sposób elastyczny, lekki, rozbudowywać dalej nasz produkt. Natomiast pułapką tego założenia jest to, że de facto usztywnimy architekturę, tworząc ją na samym początku prac, na bazie wiedzy z tego jednego, konkretnego momentu. Czyli trochę nawiązując do tego pierwszego punktu, jeżeli nasze podejście jest adaptacyjne, czyli będziemy zdobywać wiedzę w trakcie prac, no to zarówno to zrozumienie, czego potrzebuje Klient, zrozumienie tego, jak my te potrzeby zaadresujemy, one mają wpływ na to, jak będzie wyglądać architektura.

Kuba: Tu rozwiązaniem jest taka koncepcja, która jest wyszukiwalna, czy sformułowana, jako koncepcja wyłaniającej się architektury. Owszem, wykonujemy jakieś czynności na początku prac. Mamy jakiś szkic tej architektury, albo pierwszy jej pomysł, ale w toku kolejnych prac, doszczegóławiamy nasze podejście. Ciągle wracamy do przemyślenia tego, jakie nasze rozwiązanie jest na tej warstwie architektonicznej, a nie tylko ślepo podążamy temu, za tym, co zostało już wcześniej ustalone.

Jacek: No i tutaj, żeby uspokoić osoby, które nie czują się komfortowo z tą rekomendacją, żeby ta architektura się wyłoniła, to oczywiście nie oznacza, że my zostawiamy tę architekturę samej sobie i ona przypadkowo, na bazie naszych działań, po prostu się wyłoni. To nie tak funkcjonuje. Raczej tutaj mamy na myśli coś takiego, że pewna koncepcja architektury, pewien zarys, ona powinna się narodzić w głowie, bądź w głowach osób, które mają odpowiednie kompetencje, żeby taką architekturę przygotować. Jednak warto zwrócić uwagę na to, żeby ta architektura była taka wystarczająco dobra na ten konkretny moment, żeby rozpocząć pracę, no i żebyśmy powstrzymali tę pokusę. A może zaplanujmy ją też na wariant X, Y i Z. Żaden z tych wariantów może się nie wydarzyć w przyszłości. To jest jedna rzecz. Z drugiej strony, spójrzmy na to z takiej perspektywy, że im dłużej będziemy przygotowywać architekturę i oczekiwać, że możemy wystartować dopiero, jak architektura będzie gotowa, no tym później, de facto, wystartujemy z naszą inicjatywą.

Kuba: Następna pułapka intuicji, to taki tekst „Efektywnie kosztowo będzie zintegrować się na końcu”. Nie zawsze usłyszymy dokładnie te słowa, ale no czasami są argumenty, takie powiedzmy, parafrazując, jak my się będziemy ciągle integrować, to przecież to będzie drogie. To już lepiej róbmy to rzadko, może zupełnie na końcu projektu. I faktycznie potrafię zrozumieć tę perspektywę i w niektórych zespołach to faktycznie tak to wygląda, że integracja sama w sobie jest bardzo kosztowna. Na przykład, zwłaszcza jeśli nie mamy automatyzacji, automatyzacji testów, automatyzacji procesów wdrożenia w realiach procesów cyfrowych. No i wtedy faktycznie każdy kolejny pomysł integracyjny wiąże się z tym, żeby wykonać jakiś szereg czynności manualnych, dosyć żmudnych. Mało przyjemnych. Tylko jaki tu jest problem? To, że to, co zostanie przygotowane w projekcie, nie da się zintegrować, albo wyskoczą w trakcie integracji jakieś dodatkowe nieprzewidziane sytuacje. Niekompatybilność poszczególnych modułów, albo jakieś takie szare strefy niedogadane. Błędy wydajności. W ogóle błędy, które niewyłapane były w poszczególnych elementach składowych, tylko pokazały się dopiero po zintegrowaniu całości. To może być również niebezpieczne zjawisko i kosztowne z perspektywy, na przykład projektu i zarządzania ryzykiem. Więc tutaj integrowanie się jest kosztowne, ale brak tej integracji, może się okazać dla projektu jeszcze bardziej kosztowny.

Jacek: No i tutaj generalnie to, co byśmy rekomendowali, no to na pewno jakaś forma ciągłej integracji. Czyli raczej zaszycie integracji w trakcie procesu wytwórczego, niż pozostawienie tego na samym końcu. Tutaj, chociażby, jeżeli mówimy o produktach cyfrowych, to można się śmiało inspirować extreme programmingiem, który do takich częstych buildów i do częstej integracji zachęca. Im bardziej mamy ten proces zautomatyzowany, tym ta informacja zwrotna, że popełniliśmy jakiś błąd, jest szybsza i tańsza. No i oczywiście tutaj znów należy potraktować to jako pewnego rodzaju inwestycję. Czasem mamy już te mechanizmy w organizacji wytworzone, przetestowane i po prostu do tworzenia nowych produktów, nowych inicjatyw, po prostu po nie sięgamy. Natomiast czasem jest to kwestia tego, że musimy sobie te narzędzia, procesy, wytworzyć, przetestować, jakby uruchomić. No natomiast z perspektywy programisty, a mówię to jako osoba, która dobre siedem, osiem lat programowała, no to taka informacja zwrotna na wczesnym etapie, że coś zrobiłem źle, albo czegoś nie zrozumiałem, albo się minęliśmy w rozumieniu, jako zespół, no to jakby bardzo wartościowe z takiej perspektywy, że podnosi pewność tego, że to, co wytwarzane, po prostu jest dobrej jakości.

Kuba: I myślę, że nieprzypadkowo padło słowo inwestycja. Bo to też może być po prostu pewien wydatek, który poniesie albo projekt, albo po prostu jest to pewien koszt organizacji. No i nie sprowadzajmy tego, tylko i wyłącznie do narzędzi, do budowania buildów, bo to mogą być też tematy związane ze środowiskami. Doinwestowanie infrastruktury, doinwestowanie również narzędzi dla całego zespołu wytwórczego. No i to wszystko powoduje, że są pewne koszty, ale są one po prostu sposobem na ominięcie wielkiej pułapki, czy wielkiego możliwego kryzysu w projekcie, wynikającego z tego, że integrujemy się tak rzadko, że przeoczamy jakieś spore problemy, które się czają tuż za rogiem.

Jacek: Kolejnym przykładem błędu intuicyjnego myślenia jest taki pomysł, z którym się często spotykam, czyli „Nie pytajmy Klienta o feedback, tak w trakcie prac, no bo ciągle będziemy musieli poprawiać”. Czyli mówimy tutaj o sytuacji takiej, gdzie ktoś obawia się pytać o feedback, no bo po prostu boi się, że ten Klient będzie nam coś dokładał, zmieniał. No i gdybym miał tak empatycznie spojrzeć na osobę, która konstruuje taką wypowiedź, no to rozumiem, że chciałaby zapewnić takie poczucie progresu pracy. Zapewnić skupienie i na pewno nie chciałaby ta osoba, żeby konkretny developer, czy zespół kręcił się w kółko. Na zasadzie tylko zmieniam, zmieniam i zmieniam, a postępu prac nie ma. No i oczywiście tak, jak się zgadzam z pomysłem, żeby tworzyć zespołom odpowiednie warunki, w których mogą się skupić, no tak jestem bardzo nie po drodze z tematem niesprawdzania, czy idziemy w dobrą stronę. Tak więc jakby mówimy dzisiaj o ryzyku w odcinku, więc z mojej perspektywy ryzyko, że wytworzymy coś niewłaściwego, jeżeli zrezygnujemy z tej informacji od Klienta na bieżąco, z mojej perspektywy jest spore. Bo zarówno my możemy coś źle zrozumieć. Klient mógł nam coś źle przekazać. Jakby tutaj tych pułapek, żeby złudnie myśleć o kwadracie, a na koniec okaże się, że to jest prostokąt, albo jakiś romb, no jest całkiem sporo.

Kuba: I rozwiązanie jest tutaj zupełnie nieodkrywcze. Przynajmniej my to tak czujemy. Podejście zwinne, jego cechą jest między innymi bliska współpraca z Klientem. Niezależnie od tego, czy czujemy, że Klient będzie miał jakiś feedback do nas, czy być może będziemy się kręcili przez chwilę w kółko. Takie problemy da się rozwiązać. To jest kwestia rozmowy. Ale ja mam tutaj mocne poczucie, że im bliżej jesteśmy z tym współpracującym z nami Klientem, im bardziej zawiązaną mamy relację, tym łatwiej będzie też wyjaśnić, że być może czas już skończyć wybrzydzać, albo ewentualnie wymyślać. Jakkolwiek nawet taki skrajny przypadek mógłby się zdarzyć. Tylko po prostu zacznijmy realizować działania. Wyjaśnijmy sobie, jakie są konsekwencje. Może też wyjaśnijmy sobie, że te zmiany założeń, czy zmiany zdania, no po prostu oddalają nas od realizacji pewnej całości, czy od daty wdrożenia kolejnej wersji. I to wszystko nawet w tym scenariuszu, że faktycznie Klient ma taki charakter wybrzydzania. Natomiast o wiele częściej widzę, że i Klient i wykonawca po obu stronach, każdy chce osiągnąć pewien rezultat, więc te zlecone uwagi, czy przekazane informacje zwrotne, naprawdę są ważne. To nie są chciejki. To nie są jakieś wymyślania, tylko naprawdę są sprawy, które powodują, że ten produkt nie wygląda tak, jak sobie to wyobraża ten odbiorca.

Jacek: I tutaj w tej poradzie czai się mikropułapka. Taka, że ktoś może powiedzieć, „No przecież pokazujemy Klientowi produkt. Raz na miesiąc. Raz na dwa tygodnie. No to przecież, jak będzie coś nie tak, no to powie”.

Kuba: Robimy Demo.

Jacek: Robimy Demo. Tak. Bardzo często słyszymy to z Kubą w różnych organizacjach. Natomiast bardziej tutaj mamy na myśli taką faktycznie bliską współpracę z Klientem. Czyli sytuację, w której tak dając taki namacalny przykład. Osoba, która reprezentuje Klienta, bądź Klient, jest z naszym zespołem w kontakcie kilka razy dziennie. W realiach pracy przedpandemicznej, w jednym budynku, to oznacza kursowanie między piętrami, jeżeli te osoby są na różnych piętrach. Jeśli mówimy o Kliencie wewnętrznym. Jeśli mówimy o Kliencie zewnętrznym, to oznacza kilka razy w ciągu dnia zdzwonienie sie, dosłownie na chwilę. Na chwilę udostępnienie ekranu, pokazanie, tak, żeby po prostu nie czekać, nie kumulować tego potencjalnego błędu, który możemy zebrać w trakcie tych dni niepokazywania progresu. No i po prostu korzystać z tego feedbacku na bieżąco. No bo po prostu, na bazie naszych doświadczeń, zwykle prowadzi to do lepszych rozwiązań.

Kuba: Następną pułapką intuicji, podobną do tematu współpracy z Klientem, jest taki tekst „Zróbmy Klientowi dokładnie to, czego chce”. Tutaj mocny akcent na „dokładnie to, czego chce”. Czyli tutaj jest czające się założenie, że może będzie prościej, może będzie łatwiej, gdy nie będziemy dyskutować. Nie będziemy zadawać tych trudnych pytań. Nie będziemy tutaj dywagować, wątpić. Jakoś tutaj stosować jakichkolwiek zaawansowanych technik. Tylko po prostu, jak Klient mówi, że chce zielony przycisk, to dostaje zielony przycisk. Tylko no, jakie tutaj jest wielkie zagrożenie? Że znowu jest to ryzyko produktowe, takie bardzo biznesowe. Klient może nie umie wyrazić tego, czego potrzebuje. Może nie do końca to wie, tylko przed nami udaje bardziej pewniaka, niż jest to w rzeczywistości. Jest spore zagrożenie, że po prostu zbudujemy niepotrzebny produkt. Jak mówię o zielonym przycisku, to to jest taki banalny przykład. Ale już bliższy o wiele bardziej realnego przykładu, który gdzieś tam powiedzmy, spotkałem w pewnych zespołach z przeszłości. No to budowanie na przykład zaawansowanej wyszukiwarki w naszym systemie, w czasie, gdy tak naprawdę Klient potrzebował inteligentnych, we właściwym miejscu pokazujących się rekomendacji tego produktu, który potrzebuje dokładnie w tej chwili. Widziałem na własne oczy zespoły, które kupę czasu, energii i wysiłku intelektualnego poświęciły na realizację produktu, który zupełnie nie rozwiązywał potrzeby Klienta.

Jacek: To, co mówisz o tym, że zróbmy dokładnie to, co Klient chce, to często to wygląda w ten sposób, że zespół ma jakieś wątpliwości dotyczące tego, co słyszy od Klienta. No ale dla mnie to jest taka postawa, co tam my będziemy się odzywać, co tam będziemy się wychylać. No to chce, no to trzeba to robić. Z mojej perspektywy to jest kompletnie nieprofesjonalne zachowanie, powiedziałbym wręcz nieetyczne. Jeżeli mamy cień wątpliwości, jako partnerzy technologiczni, że jest jakiś rozjazd, że coś może pójść nie tak. No to po prostu, z mojej perspektywy, należy jakby skonfrontować ten temat u po prostu upewnić się bądź zweryfikować to, co chcemy wytworzyć. Więc na pewno tutaj taką praktyką, którą rekomendujemy, to jest „Dążenie do zrozumienia prawdziwej potrzeby Klienta”. Nie jest to jakaś taka zaawansowana technika. To jest po prostu umiejętność prowadzenia dialogu. Umiejętność zadawania właściwych pytań. Rozróżnienia kiedy należy zadać pytanie otwarte, kiedy należy zadać pytanie zamknięte? Kiedy sparafrazować? Kiedy coś dodatkowo narysować? Pokazać wizualnie. Tak, żeby użyć wszelkich możliwych sposobów, które przybliżą nas do sytuacji, gdzie mamy bardzo wysokie prawdopodobieństwo, że jesteśmy na tej samej stronie, jeśli chodzi o to, co mamy zrealizować.

Kuba: I może się tak zdarzyć, że zespół zwinny, który dla danego Klienta po raz pierwszy raz w życiu wykazuje taką postawę, właśnie aktywną. Dąży do głębokiego zrozumienia. No to ten zespół może się wydawać trudny we współpracy. No bo teraz jakby kwestionuje, jakby zadaje pytania, o co tu w ogóle chodzi. Mieli to zrobić. Jak murarzowi karzę wybudować mi kawałek muru w moim domu, no to po prostu on to robi, a nie zadaje pytania, po co? No i to jest taki żart, który akurat dla obu z Jackiem ma większe znaczenie, ale dosyć tych insiderskich historii. Po prostu praca projektowa, kreatywna, nad innowacyjnymi produktami, nie ma charakteru takich prostych zleceń, które trzeba ślepo wykonać tak, jak zlecający mówi. A nawet i budowlańcy lubią też wejść w dyskusję, gdy z nimi współpracujemy. Czemu tak? A czemu nie inaczej? No i ja prywatnie sobie cenię, jak mi dobry fachowiec powie – „Panie, to bez sensu. Zrób to pół metra w lewo, albo w prawo. Wyżej, niżej”. I się okazuje, ta osoba się na tym zna. Ja zaufam i wręcz wzbudza moje zaufanie, gdy dostaję serię pytań drążących, po co to jest mi i jak chcę tego użyć? I również dywagacje, jak ta osoba po drugiej stronie by to zrobiła. Więc tutaj dążmy do zrozumienia tej potrzeby i być może też, jeśli napotykamy pewien opór po stronie naszego rozmówcy, to spokojnie miejmy naszą wersję odpowiedzi, z czego wynika, że chcemy tutaj trochę podrążyć. Bądźmy tutaj bardzo też partnerscy i asertywni. W takim rozumieniu, że my jesteśmy OK i tamta strona jest OK. Nasze drążenie to nie jest jakieś dopiekanie, albo jakieś takie nieprzyjemne interakcje. Tylko to jest autentyczna współpraca. Chęć kreatywnego zrozumienia, co tak naprawdę chodzi? Jaka jest ta prawdziwa potrzeba?

Jacek: Kolejnym przykładem tego, co może podpowiadać nam intuicja, jest chęć dobrego podzielenia się zadaniami na początku i spotkania się na koniec projektu, czy inicjatywy. Czyli tutaj zakładamy, że albo dzielimy się pewnymi zadaniami wewnątrz zespołu, albo gorszy wariant, moim zdaniem, dzielimy się zadaniami pomiędzy zespołami. Czyli mówimy już tutaj o skalowaniu. No i po prostu, jak każdy zrobi swoje, no to się zintegrujemy, spotkamy się i będzie, na pewno będzie działać. No i oczywiście tak, empatycznie patrząc, no ktoś może mieć ochotę na mniejsze zamieszanie. No bo oczywiście odwrotny scenariusz tego, co powiedziałem, no to jest na pewno konieczność synchronizacji, sprawdzania, upewniania się. No co może być odebrane jako zamieszanie, no i na pewno nie jest to czas spędzony przed klawiaturą, no więc jest to czas nieefektywny. To oczywiście żart. Natomiast no to, co się faktycznie dzieje, no to pozbawiamy bądź zespół, bądź zespoły przestrzeni do współpracy i do zespołowości. Co z mojej perspektywy jest bardzo niebezpieczne, bo przybliża nas do tego, że w kontekście zespołu mamy bardziej grupę osób, niż zespół. Co często obserwuję i brak tego fundamentu z mojej perspektywy zamyka całą masę ścieżek rozwojowych dla zespołu. Z drugiej strony możemy wpaść w taką silosowatość na poziomie zespołów. Czyli każdy zespół robi swoje. My robimy dobrze. Nieważne, co robią oni, inni. No i to też z tych wyrazów, które używam, no słychać, że to jest bardziej okopywanie się, niż tworzenie czegoś wspólnie.

Kuba: I tu akurat nasza praktyka może nie być aż tak oczywista. Rekomendujemy w tym miejscu, jednak takie nastawienie się, czy podejście na uwzględnianie różnych perspektyw, jakie mamy w zespole. W praktyce to na przykład może oznaczać dążenie do pracy, co najmniej w parach, a najlepiej może i całym zespołem. I tutaj jest szereg takich praktyk, jak właśnie programowanie w parach, sworming, mop programming. Warto sobie takie praktyki zobaczyć, jako inspirację. Ale nawet jeśli nie utrzymamy konkretnie zdyscyplinowanego podejścia w tym stylu, to ja, chociaż apeluję o to, żeby nie zamykać się w swoich wycinkowych fragmentach zadania, tylko właśnie próbować atakować problemy z perspektywy kilku osób. Nawet jeśli to jest dwóch specjalistów o podobnych kompetencjach, to mimo wszystko, będziemy świat widzieć trochę inaczej i na trochę inne rzeczy zwrócimy uwagę. Dzięki czemu to rozwiązanie będzie lepsze jakościowo, ale też my między ludzko będziemy dobrze ze sobą współpracować. A już w ogóle magia się otwiera, jeśli zaczniemy pracować właśnie też na styku między różnymi kompetencjami. Dla mnie klasykiem w tym miejscu jest bliska współpraca pomiędzy osobą zapewniającą jakość, nazwijmy go testerem, a programistą. I te osoby ramię w ramię współpracujące, a nie czekające, aż jedna skończy, żeby ta druga mogła rozpocząć swój wycinek pracy. O wiele częściej i o wiele efektywniejsze zespoły widuję, które po prostu zacieśniają tę współpracę. Mniej widać granice pomiędzy moją pracą a Twoją pracą. Być może to gorzej wygląda w raportach czasu pracy, albo w jakimś systemie elektronicznym do raportowania zadań, gdzie te zadania po kilka osób jednocześnie realizuje jedno zadanie. Ale jak nie patrzymy na tę wygodę obserwatora, tylko skupimy się na jakości i też na obniżeniu ryzyka, no to lepsza współpraca jest w takich zespołach, które po prostu dążą do tego, żeby w zespołowy sposób atakować te problemy, z którymi dany zespół się mierzy.

Jacek: Tu generalnie, ja tak rozumiem zespół. Ja też do takiej pracy jestem przyzwyczajony. Jeżeli pracujemy zespołowo, to znaczy, że tych szans na interakcję mamy sporo. No i teraz, jeżeli patrzymy na pracę w zespole przez tę perspektywę, o której wspomniałeś, czyli ja bym powiedział, że to jest taka perspektywa Excela, utylizacji. Nie spodziewajmy się, że zadzieje się magia. Z mojej perspektywy to skupienie należy położyć bardziej w okolicach produktu i osiągania celów biznesowych. Natomiast to, jak to sobie zespół zrealizuje, to ma tutaj powiem, drugorzędne znaczenie. No bo tak naprawdę chodzi o to, żeby przesuwać się w stronę realizacji biznesu. A to, jak to zrobimy, w parze, w trójce, ktoś komuś pomoże, to jest tak naprawdę drugorzędne.

Kuba: Jak wspomniałeś Excela, to mamy następną pułapkę intuicji, mocno skojarzoną z Excelem. „Jak dobrze to wszystko zaplanujemy, to realizacja już pójdzie gładko”. I taka perspektywa, może właśnie związana z zarządzaniem, jakimś takim dzieleniem zadań, że jeśli zrobimy dobry plan – temat bardzo podobny do tego, jak myślimy o analizie albo architekturze. Że jeśli tak zadziałamy planistycznie, zbudujemy ten plan, przygotujemy go, upewnimy się, że jest dobry. Może dwa razy zweryfikujemy, czy nie ma jakichś luk, to potem już wszystko będzie dobrze. Już pójdzie naprawdę, jak z płatka, jak z górki. Jak już plan mamy, to nic, tylko go wykonać. I trochę ironizuję, bo nie mogę się powstrzymać. Natomiast rozumiem też postawę taką. Być może z doświadczenia wynikającą, że odwrotność tego też jest zupełnie bez sensu. Czyli takie działanie zupełnie bez planu, bez pomyślunku, bez żadnej koordynacji, bez żadnego uzgodnienia. Czym się zajmujemy? W jakiej kolejności? Być może, jakie są jakieś krytyczne momenty, które naprawdę muszą być dobrze dograne. No, ale nie popadajmy w żadną ze skrajności. Ani działanie bez planu nie ma sensu, ani też takie założenie, czy złudzenie, że dzięki temu, że mamy super plan, to już wszystko pójdzie dobrze, też jest pułapką. Tutaj zagrożenie jest proste. Dla niektórych osób plan staje się taką wytyczną, ale jest to jednocześnie iluzja posiadania kontroli. Czyli tutaj mówimy o ryzyku, to jest takie ryzyko, że realizując pierwotnie zbudowany plan, nie dostrzegamy dużych pułapek. Pojawia się jakaś nowa okoliczność. Pojawia się coś, co jednak przeoczyliśmy, ale ślepo podążamy z góry określonym planem, będąc właśnie zupełnie nieczułym, albo nie zauważając tego, że coś się zmieniło, że coś nowego wyskoczyło i trzeba po prostu się zaadaptować.

Jacek: No i tutaj rozwiązanie, które jest nam bliższe. Jest dosyć proste. Mianowicie, chcielibyśmy ten plan na bieżąco aktualizować i uszczegóławiać. I teraz, co to znaczy? Aktualizacja planu, no to w sumie jest odpowiedź na to wszystko, co Kuba powiedziałeś. Czyli zmienia się rzeczywistość, no to my reagujemy. No i ten nasz plan jakoś przebudowujemy, po to, żeby on, no po prostu był lepszy w kontekście najlepszego odczytu rzeczywistości. To jest jedna rzecz. Natomiast uszczegóławianie planu, to jest bardziej kierunek taki, w którym mamy pewną bazę, natomiast ta baza nie pokrywa nam wszystkich przypadków. Nie jest szczegółowa, nie jest taka zrobiona do atomu. Tylko to, co się wydarzy w najbliższej przyszłości, mamy dosyć dobrze zaplanowane. Jutro mamy bardzo dobrze zaplanowane, ale to, co będziemy robić za trzy miesiące mamy tylko w pewnej ogólności. Być może nawet na poziomie haseł. Trochę tak generalnie, jak byśmy opisywali dobrze przygotowany Backlog Produktu, jeżeli mówilibyśmy o Scrumie. Tak więc ten plan będziemy uszczegóławiać dopiero wtedy, kiedy będzie właściwy moment. Trochę takie bym powiedział „just in time”, czyli wtedy, kiedy jest potrzeba już wiedzieć większy poziom detali, wtedy te detale przygotowujemy. Posiadanie planu na dużym poziomie detali, pół roku w przód, z mojej perspektywy, to jest kompletne marnotrawstwo, strata czasu. Ten plan i tak się zmieni. I to nie za trzy miesiące, on się zmieni za tydzień. Przynajmniej jeżeli jesteśmy oczywiście w domenie, powiedzmy sobie złożonej.

Kuba: Ja tutaj dorzucę taką myśl, że dla mnie obecnie, według mojego stanu wiedzy i tej teoretycznej i takiej też praktycznej, dobry plan to jest plan prosty i modułowy. Prosty, czyli jest łatwy do zrozumienia, ogarnialny, nieprzeładowany szczegółami, o których mówiłeś Ty Jacek. A modułowy, czyli taki, który po prostu na początku zawiera pewne kawałki takie skończone, większe uogólnienia, które gdy przyjdzie czas, będziemy doszczegóławiać, ale też moduł może być zastępowalny. Niektóre plany dobre, mają po prostu opcję. Jeśli się wydarzy A, to zrobimy to. Jeśli B, to to. Więc z góry znamy, powiedzmy, zarys scenariusza postępowania, ale nie poświęcamy za dużo energii na to planowanie, póki nie przyjdzie właściwy moment.

Jacek: Kolejna pułapka, to taka pułapka, w której wychodzimy z perspektywy, że po co cokolwiek sprawdzać. Po co to sprawdzać, co robimy, skoro bardzo dobrze wiemy, jak powinniśmy to zrobić. No i można tutaj próbować zrozumieć osobę, która proponuje nam takie podejście, że obawia się straty czasu. W sensie, mamy pewne bardzo dobrze już wydeptane ścieżki. Kurczowo trzymamy się poznanych sposobów. No więc po co mamy eksperymentować? Przecież już dobrze to wiemy. Ja bardzo często słyszę „Po co wymyślać koło na nowo?”. No dobrze, tylko niestety tutaj jesteśmy de facto w szczególności w złożonych domenach o krok od ignorancji. W takim sensie, że przez taką nazwijmy to, czasami pychę, jesteśmy w stanie bardzo łatwo przeoczyć, że nasza rzeczywistość się zmienia. Czyli jesteśmy liderem na rynku. Co tam będziemy się dokształcać, co tam będziemy czytać. Dajcie spokój. No i właściwie pół roku później, że ten start-upik, z którego tak się śmialiśmy, który tak trochę bardziej był otwarty na to, żeby eksperymentować, no to właśnie zaczyna nam zjadać nasz Marketplace. Tak więc spore niebezpieczeństwo. No i tutaj w szczególności ta taka ignorancja. Takie poczucie nieomylności. Ono może nas zaprowadzić w błędną uliczkę.

Kuba: I tutaj propozycja, którą mamy jako rozwiązanie tej pułapki myślenia, zaczerpnęliśmy od Alistaira Cockburna, który w ramach koncepcji Heart of Agile sugeruję taką myśl „Deliver for learning”. Trudno nam przyszło z tłumaczeniem tej koncepcji, więc opowiem ją opisowo. Chodzi o to, żeby wytwarzanie, które realizujemy w ramach pracy zwinnej, traktować też jako okazję do ciągłej nauki. Czyli nie maksymalizujmy samego wytwarzania dla dostarczonych kolejnych produktów, czy kolejnych elementów tego produktu. Ale niech to wytwarzanie będzie też ciągłą okazją do nauki, refleksji i pewnego odkrywania. I to ma dwie warstwy. Bo to jest nauka i odkrywanie tego, co wiemy o rynku, o Kliencie, o biznesie, czyli tak trochę mocniej na zewnątrz. Ale to też „Deliver for learning” do środka, czyli ciągle się uczymy, ciągle próbujemy pewne rzeczy na nowo. Bo to, co Jacek mówił o tym zagrożeniu, tej pysze, czy ignorancji, może oznaczać też prosty patent, który niestety widuję w niektórych zespołach. Realizujemy nasze rozwiązania, jak pięć lat temu, albo dziesięć lat temu. Więc kto by tam używał clouda. Po co automatyzacja. Jakieś rozwiązania architektoniczne, czy wzorce są jedyne słuszne. Technologie, no przecież stary dobry PH. I nagle się okazuje, że coś, co jeszcze parę lat temu było może sensowne, a dziesięć lat temu było nowinką, no dzisiaj jest już dla dinozaurów. Sposobem na to, żeby właśnie dokładnie wpaść w tę pułapkę, jest ciągłe powtarzanie realizacji naszych rozwiązań dokładnie tak, jak zawsze to robiliśmy. Ciągłe zakładanie, że rynek się nie zmienił. Ciągłe zakładanie, że technologia się nie zmienia.

Jacek: Jest oczywiście mały haczyk. Tak, żebyśmy mogli uczyć się poprzez wytwarzanie, no to musimy pracować w krótkich iteracjach. To jest jedna rzecz. Druga rzecz jest taka, na koniec tych iteracji, no musi się pojawiać coś namacalnego. Czyli podzielenie sobie wielkiej pracy na kawałki, gdzie na koniec etapów nie mamy nic, co moglibyśmy pokazać Klientowi. Nic, co moglibyśmy zwalidować. Nie jest dobrym pomysłem, no bo de facto nie otworzy nam furtki do tego, żeby się czegokolwiek nauczyć. Tak więc niezmiennie rekomendujemy, żeby szlifować swoje umiejętności w zespole. Jak dzielić produkt? Jak wyciągać esencję z potencjalnie dużych kawałków? Jak też wychodzić z tej pułapki myślenia, że tego się nie da podzielić? Najczęściej się da podzielić. Czasem trzeba po prostu pomyśleć trochę inny sposób. No i to otwiera nam furtkę do tego, żeby w regularny i w, żeby częsty sposób pobierać lekcje.

Kuba: Ostatnia pułapka intuicji reprezentowana jest przez cytat „Nasi Klienci woleliby, żeby produkt był zmieniany rzadko”. I autentycznie słyszę takie głosy. Jakieś dramatyczne historie, cytaty z jakichś komentarzy, czy to w sklepie w apkami, czy to w jakichś forach, albo na Twitterze, że tu Klienci bardzo niezadowoleni. Lepiej byłoby robić te zmiany najrzadziej, jak to możliwe, bo każda zmiana spotyka się z ostrą, negatywną reakcją. Oddzielna kwestia, że faktycznie trochę tak jest, że Klienci bywają niezadowoleni ze zmiany. Natomiast ja myślę, że skupmy się na tym, z czego wynika, że te zmiany są tak źle odbierane? Zwłaszcza takie argumenty typu, no bo przestał działać system. Bo zupełnie pełna rewolucja i Klienci się czuli kompletnie zagubieni. To nie są argumenty za tym, żeby zmieniać rozwiązania rzadko. To są raczej argumenty, żeby zmiany robić dobrze, w szerokim znaczeniu tego słowa. Natomiast jesteśmy w kontekście ryzyk. No niestety ta taka kolejna argumentacja za tym, żeby robić zmiany rzadko, no ona już się przewijała przez inne mity, wcześniej wymienione. Wszystkie te argumenty razem do kupy powodują, że mamy argumenty za robieniem rzadkich zmian. Rzadkie zmiany powodują, że każde kolejne dostarczenie wersji, która jest bardzo duża, to też jest bardzo wielkie wydarzenie. I to jest bardzo wielkie wydarzenie z perspektywy rynku. Czyli robimy rzadkie wdrożenie bardzo dużej rewolucji dla Klienta. To też jest wielkie wydarzenie z perspektywy technologicznej. To jest mnóstwo na przykład kodu do przetestowania. Mnóstwo integracji. Całe wielkie procesy wokół tego, żeby to wielkie wdrożenie się udało, żebyśmy mieli je pod kontrolą. Niestety również wielkie ryzyko, że jak mamy wielkie wdrożenie, o wielkim zakresie robione rzadko, to niezwykle prosto też, żeby to wielkie wdrożenie się opóźniło. Przesunęło datę. To jest regularna historia, którą ciągle słyszę w różnych firmach.

Jacek: Rozwiązanie jest proste. Przez odwrotność, czyli nie duże, rzadkie wdrożenia, tylko małe, częste wdrożenia. No i oczywiście one muszą mieć sens. Z takiego punktu widzenia funkcjonalnego, czyli oczywiście nie chodzi o to, żeby za wszelką cenę dostarczać coś, no co nie przynosi wartości dla Użytkownika. Raczej tutaj mam na myśli takie sensowne biznesowe zmiany. No i ta częstotliwość wdrożeń, no to też jest coś, co warto sobie jakoś empirycznie wyregulować. Bo to też nie chodzi o to, żebyśmy cały czas zmieniali dla zmieniania. No ale chodzi o to też, tak jak Kuba wspomniałeś, żeby wdrożenie nie było wydarzeniem. Rutynowo jest to może trochę takie niebezpieczne słowo, ale powiedzmy, że zaryzykuję jego użycie. Wdrożenie to jest po prostu zwykła czynność. Robimy ją wielokrotnie, często. Tak więc, no po prostu nie jest to nic, co by nas przerażało. No i to też może świadczyć o tym, że przez to, że zrobiliśmy to wielokrotnie, no to większość błędów już wykryliśmy. Tak więc przestaje to dla nas być wyzwaniem.

Kuba: Z małymi i częstymi wdrożeniami mam taką małą, lubianą przeze mnie historyjkę, czy metaforę. Szczególnie zasadna jest ona dla tych z Was, którzy byli może w Warszawie i jechali metrem, jedną z całych dwóch linii. Metro ma tę charakterystykę, że jeździ często. W zasadzie nie ma żadnego znaczenia, jaki jest rozkład jazdy metra. Bo po prostu, jak jeden pociąg nam odjedzie, jak schodzimy po tych schodach, to za chwilę podjedzie najpóźniej w ciągu paru minut kolejny. Nie musimy się przejmować, że się spóźniliśmy. Nie musimy się przejmować, że wszyscy się zmieścili. W godzinach szczytu niektórzy zostają na peronie i wsiadają do kolejnego pociągu i to jest w porządku. Dla porównania pociąg między Warszawą, a Poznaniem jeździ co godzinę w godzinach szczytu, ale to i tak już jest rzadko. A w którymś momencie jest ten moment, że odjeżdża ostatni, a potem następny będzie za trzy godziny i jest wielka afera i wielka tragedia, jeśli się spóźnimy pięć minut. Trzeba się narastać, pociągi potrafią też być strasznie zajęte. Więc tutaj niech mają ten charakter takiego właśnie często odjeżdżającego metra. Czasem trochę pustsze, czasem trochę większe. Ta rutyna, o której powiedziałeś i tak się trochę krygowałeś, ja nie mam żadnego problemu z nią. Po prostu OK. Przychodzi najbliższa okazja do wdrożenia. Za chwilę będzie następna, a potem jeszcze kolejna. Ewentualne spóźnienie się nie ma żadnych tutaj jakichś wielkich konsekwencji. Każda z tych zmian jest niewielka. Łatwo nad tym wszystkim zapanować. A nawet w tym negatywnym scenariuszu, że coś poszło nie tak, to też łatwo będzie wyizolować ten problem. Jeśli faktycznie zepsuliśmy coś Klientom, no to ta jedna konkretna, pojedyncza, drobna zmiana, może być bardzo łatwa do cofnięcia. Być może do wyjaśnienia, co tutaj nie zagrało? Albo jakościowo, albo biznesowo.

Jacek: Podsumowując odcinek, jako całość, chciałbym, żebyśmy podkreślili kilka praktyk, które z naszej perspektywy pomagają obniżać ryzyko w agile. Przede wszystkim rekomendujemy iteracyjne odkrywanie produktu. Wyłaniającą się architekturę. Ciągłą integrację. Bliską współpracę z Klientem. Dążenie też do zrozumienia prawdziwej potrzeby Klienta. Uwzględnianie różnych perspektyw w zespole w procesie wytwarzania. Bieżącą aktualizację i uszczegóławianie planu. Ciągłą naukę poprzez wytwarzanie oraz małe i częste wdrożenia.

Kuba: Notatki do tego odcinka z linkami do materiałów, między innymi reklamowaliśmy ten odcinek taką poręczną kartą do Bingo z cytatami, na które się powoływaliśmy, ale również transkrypcję, zapis wideo, najdziesz na stronie porzadnyagile.pl/52.

Jacek: Kończąc dzisiejszy odcinek, chcielibyśmy zaprosić Cię na kolejne Q&A na Facebooku, które będziemy organizować z Kubą 7 grudnia o godzinie 20:00. Jak zawsze możesz liczyć na nieco luźniejszą atmosferę, niż w podcaście. Trochę szerszą tematykę, niż podejście zwinne. No i oczywiście naszą perspektywę na Twoje pytania. Pytania, jak zawsze możesz zostawić nam w formie komentarza pod tym odcinkiem w odpowiednich Social Mediach lub wysłać nam anonimowo, jeżeli preferujesz bardziej taką formę, formularzem, do którego link załączamy do notatek tego odcinka. Tak więc zapraszamy wszystkich 7 grudnia o godzinie 20:00 na Facebooka.

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

Jacek: Dzięki Kuba.

Kuba: I do usłyszenia wkrótce.