Czym jest Water Scrum Fall? Ten popularny w wielu organizacjach antywzorzec wszczepia elementy zwinności w klasyczny, kaskadowy proces wytwarzania produktów. W odcinku tłumaczymy zagrożenia związane z tym antywzorcem, jak zawsze na bazie praktycznych przykładów z naszego doświadczenia. Dowiesz się, jak poradzić sobie z Water Scrum Fall’em, zarówno z poziomu zespół, jak i osób zarządzających organizacją.
Zobacz wersję wideo:
Dodatkowe materiały
TRANSKRYPCJA
Jacek: W dzisiejszym odcinku opowiemy czym jest Water Scrum Fall i dlaczego ten antywzorzec jest pewną pułapką? Opowiemy na początku czym jest Water Scrum Fall? Dlaczego uważamy, że jest niebezpiecznym antywzorcem? A następnie podzielimy się swoim praktycznym doświadczeniem, jak radzić sobie z Water Scrum Fallem, zarówno w pojedynczym zespole oraz jak zmienić organizację systemowo, żeby wyjść z tej pułapki.
Kuba: Water Scrum Fall jest tutaj pewnym hasłem, czy nazwą wzorca, który zbiera pewną grupę rozwiązań organizacyjnych. Rozwiązań, w których w procesie wytwarzania produktu, czy wytwarzania oprogramowania, czy przygotowywania jakichś produktów szerzej rozumianych, stosowane są techniki zwinne, ale są one wyłącznie środkową częścią kaskadowego procesu. Czyli jakiegoś takiego procesu bardzo przypominającego rozwiązania klasyczne związane z zarządzaniem portfelem, na przykład inicjatyw projektowych, gdzie jest jakiś etap inicjowania, wymyślania, selekcjonowania, priorytetyzowania, być może projektowania, wyceniania i te wszystkie etapy przed rozpoczęciem wytwarzania. Samo wytwarzanie może nawet jest na przykład z użyciem Scruma. Istnieje zespół zwinny, który iteracyjnie i przyrostowo przygotowuje zleconą inicjatywę. Potem być może jest jeszcze etap po wytworzeniu. Czyli jakieś przygotowanie wdrożenia, może jakieś osobne testy przed wdrożeniowe. Szereg czynności, które dzieją się zgodnie z istniejącymi procedurami. Są dalekie od tego, co kojarzy się ze stylem współpracy w sposób zwinny. Termin ten, czyli Water Scrum Fall, rozpowszechniła firma Forester. Firma badawcza, która w swoim raporcie stwierdziła w którymś momencie, że jest to popularny wzorzec stosowania podejścia zwinnego, czy takiego zaadaptowania filozofii zwinnej w firmach na całym świecie.
Jacek: Kilka pułapek, na które chcielibyśmy zwrócić uwagę. Przede wszystkim można powiedzieć, że cementuje pewien determinizm, w którym na bardzo wczesnym etapie trwania inicjatyw projektów, czy ogólnie rzeczy, którymi się zajmujemy, na bardzo wczesnym etapie podejmujemy pewne decyzje. I to często wynika z takiego podejścia, że czujemy, co trzeba zrobić. To jest dokładnie to, co powoduje, że szereg rzeczy usztywnia się na samym początku pracy z konkretną inicjatywą. Na bazie tych z czasem starzejących się założeń, a czasem wręcz można powiedzieć nieaktualnych, wykonujemy pracę – można powiedzieć, z rozpędu. No co powoduje, że już na etapie wytwarzania operujemy na niewłaściwych danych.
Kuba: Kolejna pułapka, też wynikająca z takiego podejścia – ktoś decyduje na dosyć wczesnym etapie. To jest pułapka tego, że oddzielamy tych, którzy wymyślają. Tych, którzy decydują. Tych, którzy myślą strategicznie, którzy posiadają informację i swobodę decyzji, od tych, którzy już potem są tylko wykonawcami. A może nawet nazwalibyśmy ich podwykonawcami, czyli brak kontekstu, oderwanie od tych przyczyn, nieświadomość, jakie istniały inne opcje, które zostały w ramach tego wzorca Water Scrum Fall sprowadzone do zróbcie dokładnie to. Jak to wykonacie, to będzie wszystko w porządku.
Jacek: Kolejna pułapka, to dosyć długi czas wynikający z rozbudowanego procesu. W takim sensie, że od momentu pojawienia się pomysłu, do momentu, kiedy ten konkretny pomysł jest zrealizowany, upływa masa czasu i wcale to nie wynika z tego, że jest dużo pracy do zrobienia, tylko z tego, że ten cały proces jest dosyć taki obudowany i biurokratyczny.
Kuba: I tutaj mamy bardzo prosty przykład z pewnej organizacji, w której funkcjonowałem przez parę lat w swojej przeszłości, gdzie w którymś momencie w ramach refleksji na temat procesu projektowego, jaki funkcjonował w tej organizacji, policzyliśmy czas, który zająłby projekt o zerowej zawartości. Taka powiedzmy hipotetyczna zabawa. Projekt nie ma w sobie nic do wykonania. Nie ma żadnej pracy, żadnych testów, żadnej analizy. Tylko po prostu przepuszczamy przez nasz system taki projekt zerowy. No i projekt zerowy trwałby kilka miesięcy, bo trzeba czekać kilka tygodni na decyzję komitetu zatwierdzającego inicjatywę. Trzeba czekać w kolejce po tak zwane zasoby. Trzeba czekać w kolejkach na jakieś okienka. Trzeba czekać, aż ktoś wykona testy. On sobie gwarantuje w procedurze minimalny czas na to. Procedura wdrożeniowa również gwarantuje minimalne czasy. W wielu takich wzorcach okazuje się, że zwinność fajnie w środku zespołu, ale przed i po zespole kilka miesięcy dodatkowych, po prostu sama ta biurokracja, czy uporządkowanie procesu zjadają i wydłużają ten lead time, o którym Jacek przed chwilą wspomniał. Kolejną pułapką, którą też wymienimy, to jest taka pułapka opisywania metaforą „przerzucania przez płot”. Powiązana z tym tych, co wymyślają, ale wewnątrz Scrum Water Falla może być kilka grup wykonawczych. Taki, chociażby wzorzec, który czasami słyszymy, rzadziej spotykamy, na przykład Scrum Analityków i Scrum Testerów. Osobne zespoły, które mają osobne Sprinty. Okazuje się, że te grupy między sobą jakieś swoje półprodukty przerzucają. Oddziela się kontekst. Nie ma za bardzo współpracy. Po prostu wszyscy pracujemy fazowo. Nawet jeśli teoretycznie nazywamy to, co robimy na przykład Scrumem, albo nazywamy te odcinki czasowe, w których pracujemy – Sprintami, ale mimo wszystko, to oddzielenie i takie przerzucanie przez płot” bez martwienia się, czy to jest właściwe, czy to jest poprawne, czy możemy coś usprawnić na punktach styku. Czy po prostu możemy tak prawdziwie współpracować ze sobą?
Jacek: I ostatnia pułapka, na którą chcemy zwrócić uwagę, to pułapka, która polega na tym, że mamy taką pewną wrodzoną tendencję do generowania opóźnień, które są wbudowane w proces. Kuba wspomniał o okienku. Ja rozwinę ten pomysł. Ten przykład, to jest taka sytuacja, w której mamy już wyprodukowane rzeczy. Jeżeli mówimy na przykład o wytwarzaniu oprogramowania. One są wydevelopowane. Natomiast teraz zewnętrzny jakiś zespół, zewnętrzny departament będzie testował i zapewniał jakość i wystawiał nam zielone lub czerwone światełko, w zależności od tego, czy te testy przeszły poprawnie, czy nie. No to sam ten czas oczekiwania na to okno testowe, kiedy inne projekty są w trakcie testów, może nam bardzo mocno wydłużyć czas oczekiwania na finalny produkt, pomimo iż można mieć wrażenie, że wszystko już jest napisane i wystarczy tylko przetestować. Więc ani nie tylko przetestować, no bo, żeby w ogóle wejść na testy, to trzeba poczekać. Potem ten czas testów, plus no jak to bywa z testami, one najprawdopodobniej zwrócą jakieś błędy. Efektem testowania będą błędny, które wrócą w postaci developmentu do wykonania i znów trzeba będzie wrócić na testy. Tak więc w najgorszym przypadku kilka takich rund, może nam w dramatyczny sposób wydłużyć czas, kiedy będziemy mieć produkt gotowy do oddania na środowisko produkcyjne.
Kuba: Wymieniamy kilka pułapek Water Scrum Falla. Jest ich o wiele więcej. Niektóre z nich się same nakręcają. Znaczy, niektóre z tych rzeczy łącznie jeszcze potęgują problem. Natomiast po pierwsze. Na pewno nie chcemy ironizować z takich sytuacji. To jest po prostu szara codzienność wielu organizacji. I wcale, żebyśmy się dobrze zrozumieli, wcale nie sugerujemy braku uporządkowania, czy spójnych priorytetów dla organizacji, czy jakichś inicjatyw, kierunków, strategii. Te wszystkie rzeczy są potrzebne w wielu organizacjach, też takie powiedzmy regulacje związane z na przykład zarządzaniem zmianą w systemach IT, na przykład w branży finansowej, po prostu wynikają z prawa. Procedury są potrzebne. Tam, gdzie muszą istnieć, to będą istnieć. Natomiast dla nas problemem jest i o tym będzie reszta tego odcinka, jest to, że takie procedury Water Scrum Fallowe, mogą być w sytuacji, gdy pojawiają się okazje. Coś korzystnego, a nie możemy tego zrobić, bo procedura nakazuje nam realizację pewnej z góry określonej sprawy. No i te powiedzmy procedury, bardzo kiepsko bronią się w sytuacjach kryzysowych, gdy ustalona z góry lista priorytetów znienacka przestaje być aktualna, bo pojawia się coś nowego, istotnego i na przykład roczna Road Mapa ląduje w koszu, no bo nie możemy jej realizować, bo te priorytety aktualne są zupełnie inne.
Jacek: No dobrze, to jak sobie będziemy radzić z tym antywzorcem, czyli z Water Scrum Fallem, na poziomie pojedynczego zespołu?
Kuba: Zacznę od takiej rady zerowej. Przede wszystkim uświadomić sobie, że w ogóle istnieje taka sytuacja. W wielu sytuacjach takich społecznych, czy to na jakiejś konferencji, czy to na jakimś spotkaniu społeczności zwinnej, dosyć nieprzyjemny jest moment, gdy powiedzmy, w podobnym w stylu rozmowie dochodzimy do tego, że ktoś się orientuje – „Kurcze. Myślałem, że pracuję Scumem, ale tak naprawdę pracuję Water Scrum Fallem. Czy może moja organizacja pracuje Water Scrum Fallem?”. Więc tutaj zwłaszcza rada dla osób, które tak na razie mocno patrzą optyką pojedynczego zespołu, żeby się rozejrzeć i popatrzeć trochę szerzej. Zamapować sobie, jak wygląda proces pracy w zespole moim, ale też jak wygląda proces pracy z tym wszystkim, co się dzieje przed moim zespołem. Skąd Product Owner bierze pomysły? Czy je generuje, czy może ktoś mu je zleca? Czy są jakieś procedury związane z tym? Jakieś standardy? No i też to samo w drugą stronę. Co się dzieje z tymi rozwiązaniami, które my wydevelopowaliśmy? Oddaliśmy na jakąś kolejkę, albo jakieś środowisko i czekamy aż to zostanie wdrożone. Zwłaszcza z perspektywy na przykład Scrum Mastera, ale też osoby zainteresowanej swoim procesem w swoim zespole, czy to lidera zespołu, czy developera. Zamapowałbym. Poznałbym ten proces. Spróbowałbym go zrozumieć. Zrozumieć też intencje stojące za tym procesem. Przede wszystkim, żeby w ogóle wiedzieć, że coś takie jest i żeby sobie to uświadomić, ale też może, żeby poznać pewne reguły. W wielu tego typu procesach wcale nie jest aż tak źle, jak może łatwo zironizować i na przykład są metody zarządzania zmianą. Jakieś procedury związane ze zmianą zakresu, czy zmianą jakichś zasad projektu. Może są procedury odstępstwa od reguł. To są wszystko, powiedzmy, myki biurokratyczne, które warto znać. Warto sobie zdawać z nich sprawę. No i postępować według reguł gry, ale też czasami sobie samemu za wąsko tego poletka nie dookreślać.
Jacek: Drugi pomysł, jakim chcemy się podzielić, to jest pomysł, w którym pokazujemy, że można pracować w inny sposób. Czyli możemy tutaj pokazać jakieś konkretne dane. Pokazać jakieś dowody na to, że nasz pomysł na jakąś zmianę w inicjatywie ma sens. Podzielić się pomysłami, jakimiś hipotezami i pokazać, jaki to może mieć wpływ na to, czym się aktualnie zajmujemy. O tyle ta porada wydaje nam się sensowna, no raz, że pracowaliśmy z tą poradą w praktyce. Z drugiej strony to jest taki głos rozsądku z zespołu. Jeżeli jako osoby pracujące w zespole, czy gdzieś w otoczeniu zespołu, widzimy, że można zrobić pewne rzeczy lepiej, optymalniej, będą miały większy sens. No to naszym zdaniem, po prostu warto, chociażby spróbować. Tutaj w tej poradzie abstrahujemy od tego, czy ta nasza rekomendacja, czy ta nasza opcja, czy propozycja zostanie rozpatrzona. Natomiast chodzi o to, żeby w ogóle uruchomić taki proces myślenia, czy w zespole, czy w organizacji i pokazać, tak dosyć mocno oddolnie, że w ogóle można tak pracować. Że jest inny sposób pracy, niż mocno taki, predefiniowany zakres, definiowany na początku pracy z konkretną inicjatywą, czy z konkretnym produktem.
Kuba: Spróbuję to sformułować jeszcze innymi słowami, tę radę. Mamy tu na myśli taki przypadek, żeby nie iść w ślepo w to, co zostało gdzieś tam przyniesione do zespołu. Na przykład w postaci zdefiniowanej inicjatywy projektowej, która jest do wykonania w pewnych konkretnych ramach. No tylko mimo wszystko podejść do niej, z bardzo otwartą głową. Rozszerzyć sobie tę perspektywę. Dążyć do tego, jaka jest w ogóle intencja, jaki jest sens. Jakie są różne opcje? Być może ci, którzy gdzieś tam od nas wcześniej decydowali, być może z udziałem Product Ownera, być może bez udziału Product Ownera, no po prostu nie mieli takiego obrazu sytuacji, jaki my mamy w obie strony. Może oni coś wiedzą, czego my nie wiemy i my się dowiedzmy tego, ale może też my znamy jakieś fajne rozwiązania, które mogą to coś tutaj usprawnić. No i myślę, że w każdej organizacji, nawet najbardziej sformalizowanej i sproceduryzowanej, takie zwłaszcza sytuacje, gdzie mamy lepszy, tańszy pomysł na osiągnięcie tego samego, albo lepszego rezultatu, są mile widziane. Czyli nie zamknijmy się w takiej perspektywie ślepego wykonawcy poleceń, bo tak wynika z takiej właśnie procedury, czy mechaniki biurokratycznej. Następna porada, to taka rada już takiego trochę rebelianta korporacyjnego – „Wychodź ponad reguły”. Wychodź ponad reguły, czyli podchodź do procedur na zasadzie takiej prawniczej, jeśli coś nie jest zabronione, to znaczy, że jest dozwolone. Czyli procedura może brzmieć tak bardzo, wykonaj projekt, tak jak jest zlecony. Wykonaj go w jakiś sposób kaskadowy, czy taki fazowy. No, ale jeśli procedura wprost nie mówi, że możemy wykonać Product Discovery w trakcie developmentu, to dlaczego go w równoległym trybie nie wykonywać? Albo poszczególnych, chociaż takich technik, albo wręcz całego tutaj arsenału. No i tak samo rzeczy związane ze wdrożeniami. Pewnie najprościej interpretować wiele takich Water Scrum Fallowych procedur, że wdrożenie fajnie, iteracyjnie, przyrostowo, na test A, a potem wdrożymy całość dopiero po zakończonym projekcie. Jeśli procedura tego nie zabrania, to dlaczego nie wdrażać co Sprint, albo nawet w środku kilka razy. Jeśli wiemy, że to jest korzystne, to zrozumiemy, o co walczymy i być może naginajmy te zasady, przełamujmy te bariery. Interpretujmy na swoją korzyść. Nie na zasadzie, żeby łamać zasady i robić coś głupiego, tylko żeby przewyższać zasady. Czy to właśnie wychodzić ponad reguły, a nie poza reguły?
Jacek: Jeżeli Kuby głos Was nie przekonuje, to ja tutaj przywołam słowa Arnolda Schwarzennegera, który powiedział „Breake the rule but not the law”. Czyli właściwie to samo, co Kuba powiedział, tylko po angielsku. Natomiast mówiąc tak poważnie trochę, z procedurami często jest tak, że wydaje nam się, że procedura jest jakaś i pewne luźne interpretacje, co wolno, a nie wolno, są powtarzane na korytarzach, kuchniach i w pokojach zespołowych. W sensie były w czasach przed pandemicznych. Dzisiaj to pewnie na jakimś Slacku, czy Teemsach. No i bardzo często, kiedy się spojrzy w tę procedurę, no to jest tak, że te rzeczy, które mówimy, że nie można, one nie są wprost wskazane. Tak więc warto kwestionować takie rzeczy. Zaglądać w te miejsca, gdzie ta procedura faktycznie jest, no i dobrze się zastanowić, czy faktycznie wyklucza pewne zachowania, czy tylko istnieje pewne takie zrozumienie tej procedury w organizacji, która na przykład powoduje, że nie możemy się kontaktować ze Stakeholderami, bo mamy jakieś pojedynczy punkt kontaktu ustalony. Być może wcale to nie jest prawda, a nawet jeśli jest, no to z mojej perspektywy warto spróbować zrobić to inaczej. Popróbować. To nie są rzeczy, które w jakiś taki drastyczny sposób zagrażają pracy, czy produktowej, czy projektowej, więc warto tutaj eksperymentować. W znaczeniu szukać furtek. Może to brzmi pejoratywnie, ale przestrzeń na to, żeby pewne rzeczy zrobić, po prostu w inny sposób. Kolejnym pomysłem, jakim chcemy się podzielić, jeśli chodzi o radzenie sobie z Water Scrum Fallem na poziomie pojedynczego zespołu, jest policzenie marnotrawstwa, które generuje proces, w którym jesteśmy jakby opakowani. Na czym to polega? Polega to na tym, żeby spróbować wychwycić wszystkie te elementy procesu, które z naszej perspektywy, ze względu na to, że są poukładane, tak jak są, po prostu są marnotrawstwem. Czyli wszelkiego rodzaju oczekiwanie. Wszelkiego rodzaju procesowanie pewnych decyzji. Czasy oczekiwania, zależności zewnętrzne. Wszystkie takie rzeczy, które niby muszą być. No bo tak sobie wszystko poukładaliśmy. Ale gdyby spojrzeć na liczby, no to okazuje się, że tego czasu robi się całkiem sporo i możemy dojść do sytuacji, w której tak naprawdę więcej czekamy, niż wykonujemy pracę. Więc jakby uważność na to. Taka świadomość, wypatrywanie takich miejsc oraz ich ewidencja, może być bardzo fajnym i mocnym argumentem do rozmowy z osobami decyzyjnymi, żeby przekonać je do tego, że być może warto się przyjrzeć, czy aby na pewno musimy funkcjonować w taki konkretny sposób, jaki sobie rozpisaliśmy.
Kuba: W takim policzeniu wyszedłbym trochę ponad tylko zwykłe policzenie minut, czy godzin. Pewnie w wielu firmach, wielu zespołach, może nawet i dni, które po prostu zmarnowaliśmy na taką, a nie inną usztywniającą strukturę, czy proces projektowy. Ale też nie zapomnijmy policzyć strat, jakie firma ponosi w takim koszcie alternatywnym. Tutaj takie pojęcie „Cost of delay” – ile firma zyskałaby, gdyby ten projekt, czy produkt, który wprowadzaliśmy na rynek, wyszedł na przykład tydzień wcześniej. To jest wielkie zagadnienie, jak to liczyć, ale nawet takie uproszczone myślenie, ile więcej zysku w tym roku mielibyśmy, w tym roku budżetowym, gdybyśmy nie ponosili tych zbędnych kosztów, a produkt szybciej, czy wcześniej pracowałby na rynku. Może się okazać, że będzie bardzo ważnym argumentem. Bo tutaj przy założeniu, jeżeli mówimy o racjonalnej dyskusji, to prawdopodobnie znajdą się obrońcy procesów w obecnym kształcie. Będą to na pewno osoby nastawione na jakąś tam zgodność z regułami, wytycznymi. Jakieś osoby o silnych nawykach. Być może o silnej pozycji w organizacji. Od tych osób usłyszymy, że tak właśnie musi być. Inaczej się nie da. To są koszty funkcjonowania w naszej branży. Zwykłe strony to tak można robić, ale nasz system jest trochę bardziej skomplikowany. Tutaj faktycznie takimi zwykłymi, prostymi argumentami albo i sumą, że spędziliśmy nad tym pięć dni roboczych niepotrzebnie, bo coś poszło do kosza, to może nie być aż tak istotne. Natomiast argument, taki powiedziałbym bardziej bazowy, podstawowy, fundamentalny w firmach generuje zyski, albo zyski większe, albo mniejsze, przez to, że funkcjonuje w tym, a nie innym modelu. To może być o wiele istotniejszy argument, niż to, że spędziliśmy właśnie chwilkę za długo na trochę bardziej proceduralnym podejściu. No dobra, to ta porcja porad była na taką perspektywę jednego zespołu, różnego typu. Wiem, że nas słuchają osoby również zarządzające organizacjami? Jakie rady mamy tutaj? Jak zmienić organizację systemowo, żeby wyjść z pułapki Water Scrum Falla?
Jacek: Pierwsza porada jest podobna do porady, którą mieliśmy na poziomie zespołu. Czyli uświadomić sobie, że to w ogóle jest problem na poziomie całej organizacji. Czyli nie tylko ta świadomość, że można to zrobić inaczej, jest istotna na poziomie zespołu, ale warto byłoby dotrzeć do osób z innych działów, z innych departamentów. Z tej drugiej strony, czyli na przykład będąc z perspektywy IT, to być może z biznes będąc w biznesie, być może to jest IT. No i wywołać ten temat, tak trochę bardziej bym powiedział przekrojowo, na poziomie całej organizacji. To może nie być proste. Tutaj mówię ze swoich doświadczeń, ponieważ nie każdemu zależy na zmianie. To oczywiście jest głęboki i duży temat, ale upraszczając to trochę, niektórym osobom może być dobrze na tych stanowiskach, na których są. W tych strukturach, z tak dużą grupą osób pod sobą. Pracując w jakiś, jakby taki wygrzany, sprawdzony sposób. Najzwyczajniej w świecie mogą nie być zainteresowane tym, żeby zmieniać coś. No bo być może okaże się, że to jest też jakieś zagrożenie dla ich stanowiska, dla headcountu, który mają pod sobą. Tak więc zdecydowanie chcielibyśmy przestrzec przed przesadnym ufaniem, że się nie da, bo tych głosów, co zresztą Kuba przed chwilą wspomniałeś, może w organizacji może być sporo. No i strategia, chyba nawet Bas Vodde, tę strategię proponował. To jest po prostu omijanie maruderów. Nie traćmy energii na osoby, które próbują nam udowodnić, że się nie da. No tylko pracujmy z ludźmi, którzy widzą przestrzeń na to, że można pracować inaczej, że można pracować lepiej.
Kuba: Jak mówisz o omijaniu maruderów, to ja znam taką radę szczegółową do tej rady, którą powiedziałeś. Odróżnijmy dwa typy maruderów. Tych, którzy są, powiedzmy merytorycznie krytyczni i wskazują kilka przyczyn, dla których ten proces musi wyglądać, jak wygląda i wsłuchajmy się w te przyczyny. Może przepracujmy wokół tych przyczyn temat. Typu – musimy mieć jakieś formalne potwierdzenie, no to znajdźmy lepsze formalne potwierdzenie, niż jakaś długaśna faza testów. Albo lepiej zorganizujmy proces wdrożeniowy. Natomiast są też osoby, które będą po prostu z automatu na „Nie” dla zmiany i nie za bardzo mają jakiekolwiek inne argumenty, niż już od lat tak robimy, albo wszyscy u nas w branży tak robią. To faktycznie tych bym nie słuchał. Te osoby, które mają jakieś argumenty merytoryczne, być może niech wygenerują listę rzeczy, które ich zdaniem muszą być uwzględnione i może jest miejsce na to, żeby merytorycznie podyskutować. Dobra, ale zawsze jest tak, bo zaczęliśmy od takiego poziomu, że wiele da się zmienić, nawet jeśli Jacek tak lekko zaznaczył, że to jest na pewno politycznie często trudna rozmowa i wielostronna. Czasami jesteśmy w takiej organizacji, być może nawet w skali globalnej, gdzie wpływu na to, jak cały proces nie mamy, ale mamy wpływ na funkcjonowanie naszego większego obszaru. Tutaj pierwsza rzecz, która mi przychodzi do głowy jako taka rada, jak z tego sobie Water Scrum Falla trochę wyjść, jednocześnie będąc trochę w niewygodnych regułach, to takie coś, co ja bym nazwał „projektem na pakiet zmian”. Czyli zastanówmy się, jak nasze procedury, jak nasz właśnie ten proces pracy zachowa się w sytuacji, gdy przepuścimy przez tę proceduralną maszynkę jakiś taki adapter. To jest słowo, które Jacek mi tutaj podpowiedział, na po prostu procedurę. Czyli przepuszczamy jakiś pakiet zmian, na przykład w naszym produkcie, z perspektywy formalnej jest to jeden projekt. Jakoś tak wystarczająco ogólnie nazwany, żeby dawał swobodę później w realizacji. Natomiast sam zespół, jakby pod tym pakietem realizuje wszystko to, co jest potrzebne, ważne i ma o wiele więcej miejsca dla takiej zwinnej pracy. Ma miejsce na to, żeby eksperymentować. Być może manewrować trochę. Jest miejsce, żeby w środku pewnego okresu rozliczeniowego też zmieniać pewne kierunki rozwojowe, czy taką taktykę pracy. Jednocześnie być zgodnym, z tym że dążymy do tego, żeby zrealizować pewien wyższy cel. Osiągnąć jakiś wynik biznesowy i ten wynik biznesowy jest tutaj jakby niezmienny i to on jest wykazany na tym poziomie, powiedziałbym proceduralnym.
Jacek: To jest o tyle ciekawe, że właściwie żadna procedura z mojej perspektywy nie musi tutaj ulec zmianie. Właściwie wszystko, że tak powiem kolokwialnie, poleci po staremu. Jedyne co się zmieni, z perspektywy osoby z zewnątrz, no to, że faktycznie ten zakres jest trochę luźniejszy, albo mniej ze sobą powiązany. Natomiast jakby cała magia zadzieje się wewnątrz. Czyli dla obserwatora z organizacji kolejny projekt, natomiast osoby, które są zaangażowane w ten projekt wiedzą, że pracujemy w ramach tej inicjatywy w trochę inny sposób. W takim sensie, że na przykład ten zakres, on będzie nam ewoluował i wyłaniał się wraz z rozwojem prac na bazie, czy testowania hipotez, czy jakiegoś rozbudowanego funkcjonowania Product Discovery. Tak więc spore możliwości, a jednocześnie pozostajemy, że tak powiem niewidoczni dla radarów.
Kuba: To ja dopowiem, że jak powiedziałem ten „pakiet zmian”, to miało to być opisowe. Nie rekomenduję, żeby nazywać projekt pakietem zmian, bo to czasami jednak ten radar gdzieś tam zamigoce na czerwono i może ten projekt mieć problem. To być może trzeba jednak nazwać bardziej cwanie, ale o tę intencję pakietowości mi tutaj chodzi.
Jacek: Kolejna powiązana porada, to jest umówienie się na pilota. Czyli na taki projekt, inicjatywę, która idzie poza regułami. Czyli jest realizowana wyraźnie w inny sposób. Niekoniecznie musi być kompatybilna z procedurami, tak jak w przypadku tej poprzedniej porady na „pakiet zmian”, tylko wyraźnie tutaj – to jest zupełnie inaczej realizowana inicjatywa. Dobrze, żeby to zostało zakomunikowane do organizacji. Tę inicjatywę będziemy robić w inny sposób i ta inność tutaj, ona może przybrać różne formy. Mamy tutaj z Kubą wspólne doświadczenia, że czasem to jest stworzenie kompletnie oddzielnego produktu. Czasem to może być w ogóle fizyczna relokacja osób. Być może w czasach pandemicznych szczególnie, to jest zebranie osób do jednego pokoju. No i tak moglibyśmy wyliczać. Czyli robimy pewną inicjatywę zupełnie inaczej, niż robiliśmy dotychczas. To jest jasne. To jest dogadane, omówione. Nikt nie powinien być zdziwiony. Natomiast, w szczególności wewnątrz tego działania tam powinna dziać się magia, czyli powinniśmy pracować dokładnie, tak jakbyśmy chcieli pracować. Mówię to po to, żeby uniknąć takiej pułapki, że pomimo iż teoretycznie jesteśmy tacy super na świeżo, no to jednak stare nawyki powodują, że zamiast wykorzystać ten potencjał, to idziemy starą ścieżką.
Kuba: I tutaj więcej charakterystyk zebrane jest, chociażby w takim wzorcu organizacyjnym, który nazywa się Scrum Studio. Bo to mniej więcej jest to rozwiązanie. Czyli tworzymy pewne specjalne warunki. Taką może bańkę kulturową. Dbamy naprawdę mocno o to, żeby skoro już mamy przyzwolenie – najlepiej jak najwyższej góry możliwej w naszej organizacji, żeby pracować inaczej, to też faktycznie eksploatujemy na maxa to, żeby to było coś innego i czerpiemy też korzyści z tej inności. Taka może przestroga tutaj, też z praktyki, że z takimi pilotami jest czasami problem, że one mogą się ciężko propagować z powrotem do organizacji. Czyli, jeśli zrobiliśmy takiego pilota też trochę po to, żeby może pokazać organizacji, trochę rozbujać łódkę i pokazać wszystkim, że można inaczej, że rezultaty są fajne, że ludzie są kreatywni. To może być, im bardziej dziwni jesteśmy, tym może być trudniej to z powrotem przenieść do organizacji, no bo Wy tam mieliście specjalne warunki. Normalnie u nas w firmie tak się nie robi. I to w zasadzie obie te dotychczasowe porady wymienione przez nas, czy zarówno ten „pakiet zmian”, jak i ten „pilot” mogą czasami mieć problem, żeby stać się nowym status quo, czy taką nową codziennością. Tutaj osobny poziom samozaparcia takiego lidera, takiej inicjatywy lub najbardziej światłych managerów na topie, potrzebne jest, żeby to propagować, żeby chociaż zebrać minimalne lekcje i je gdzieś przenieść z powrotem do takiej zwykłej codzienności projektowej. Następna porada też na takim poziomie systemowym. Pewnie bardziej leanowa i taka bardziej spokojna, niż hackowanie systemu, albo robienie jakichś baniek kulturowych, no to po prostu zastanów się, jak swój proces kształtujesz w swoim obszarze? Jak kształtują Twoi koledzy na Twoim poziomie zarządzania? Poddawaj ten proces refleksji i usprawnieniom. Wiele takich procedur projektowych cierpi też między innymi na tym, że to są takie instrukcje, czy procedury „półkowniki”. Czyli gdzieś tam, ktoś coś ogłosił. Jakieś procedury wprowadził. Zaszył je może w jakichś narzędziach elektronicznych i one tak tkwią niezmiennie od lat. Wiele razy już słyszałem takie mikro anegdoty, ale one są bardzo znamienne. W tym polu to wpisz tam cokolwiek, bo i tak tego nikt nie sprawdza, albo w tym polu zawsze wybierz B01, bo inaczej Cię nie przepuści system. I to jest taki bardzo wyraźny sygnał, że nikt nie sprawdza tego procesu. Nikt nie usprawnia narzędzi. One się dezaktualizują i nikt nad tym nie pracuje. Więc tutaj zdrowe, proste BHP systemowe. Raz na jakiś czas, najlepiej pewnie w cyklu wrócić do uczestników procesu, do aktorów, do też nazwijmy ich beneficjentów, pewnie sponsorów projektów. No i taką przekrojową analizę zróbmy, czy funkcjonuje proces? Jak dobrze funkcjonuje? W jakich miejscach mógłby być usprawniony? To pewnie nie jest wyjście z pułapki Water Scrum Falla, że porzucenie tych wszystkich otoczek, ale i tak uważam, że jest dużo do zrobienia, żeby na przykład zostawić, czy podmienić te wytyczne tak, żeby zostawiały bardziej zwinnym zespołom więcej miejsca. Być może uprościć pewne zasady. Być może dać pewne ścieżki alternatywne, na przykład dla zwinnych zespołów umożliwić trochę lepszy styl pracy, niż taki klasyczny, tradycyjny styl – nazwijmy go waterfallowy.
Jacek: Tutaj bym dwie rzeczy dwie rzeczy zaakcentował. Po pierwsze to, żeby faktycznie zaprosić wszystkich, być może reprezentację, jeśli osób jest dużo, ale żeby maksymalnie szeroko pokryć działy, departamenty organizacji. Czyli, żeby to nie było takie jednostronne spojrzenie na proces. Z drugiej strony, żeby z tego nie wynikły takie Lessons Leaarned, które wylądują w szufladzie, nawet jeśli zostaną zatwierdzone jako najlepsze. Tylko raczej chodzi o to, żeby faktycznie przekuć to w konkretne aktywności. No i co ważne doprowadzić te aktywności do wykonania. Kuba, powiedziałeś to wprost. Chodzi o refleksję nad procesem i usprawnianie go. No, ale znów tu moje doświadczenie z pola bitwy pokazuje, że często takie inicjatywy mają miejsce. Rozmawiamy o problemach. Nawet powstają jakieś konkretne plany, no ale później bieżączka, życie projektowe, rzeczywistość covidowa powoduje, że nikt tego nie archiwizuje, no i w konsekwencji proces po prostu zostaje taki, jaki był i tylko zmarnowaliśmy czas z tej perspektywy na spotkanie, no, które no do niczego się nie przyczyni. Takim kolejnym pomysłem, którym chcemy się podzielić, to jest pomysł, żeby szukać inspiracji zewnętrznych. Czyli może być tak, że pracując w konkretnej organizacji, w szczególności, jeśli pracujemy dłuższy okres czasu, może się okazać, że trochę zaakceptujemy, czy przyzwyczaimy się do tego, że pracujemy w jakiś tam konkretny sposób. Jest sporo opcji, które można wykonać, żeby zainspirować się i zobaczyć, że można wykonywać pracę w inny sposób. Kilka przykładowych pomysłów. To mogą być, chociażby konferencje. W dzisiejszych czasach pewnie bardziej online. Wszelkiego rodzaju wizyty referencyjne, gdzie firmy zwykle niekonkurujące ze sobą zapraszają do siebie reprezentację z drugiej firmy, żeby pokazać, jak pracują, jak funkcjonują. Jest też tam przestrzeń trochę na wymianę myśli, na wymianę praktyk. No czy taki staroszkolny sposób zdobywania wiedzy, czyli na przykład można przeczytać jakąś książkę, w której autor dzieli się koncepcją, która dla naszej organizacji może okazać się interesująca.
Kuba: Ale tu mogą też służyć takie osoby, jak my z Jackiem. Czyli konsultanci, którzy pracowali w różnych organizacjach. Pracują równolegle z różnymi branżami. Widzą różne konteksty. Po prostu znają różne opcje. Nie zamykajmy się na to, że jeśli pracujemy, jak pracujemy, a nawet jeśli pracujemy tak, jak pracuje cała nasza branża, to jeszcze nie znaczy, że to jest już taki koniec historii i nie można pracować lepiej. Zwłaszcza w tych teoriach zarządzania. Czułość na kontekst branży jest potrzebna. To się zgodzę, ale to też nie jest powiedziane, że firma z branży X nie może się zainspirować podobnymi, bardziej nowoczesnymi rozwiązaniami, jednak z sąsiedniej branży, gdzie gdzieś tam pewne rzeczy zostały trochę zanegowane, czy trochę gdzieś granice zostały przesunięte. I na koniec taka rada, bo mam takie poczucie, że te poprzednie były mimo wszystko takie grzeczne. No to tak na koniec dowalmy do pieca. Zastanówmy się też, czy czasami nie jest potrzebna rewolucja? Zwłaszcza jeśli ten nasz Water Scrum Fall ma ewidentne wady i nie za bardzo jakiekolwiek zalety. Nie za bardzo istnieją jakieś przyczyny, dla których ten proces tak właśnie musi wyglądać. Może trzeba się zdecydować na bardziej radykalne środki. Zaorać istniejący proces. Być może wejść w jakiś taki eksperyment zwinnej pracy, stworzenia jakichś zespołów zwinnych, które po prostu działają poza regułami. Tworzą sobie te reguły od nowa. Skupiamy się na takim wypracowaniu procesu razem też z jego uczestnikami, ale to nie jest krok ewolucyjny, że punkt 7.1 zamieniamy na nowe brzmienie, tylko po prostu nie ma żadnego punktu. Wylatują one prawie wszystkie. Trzymamy się jakiegoś bardziej zwinnego podejścia, również na tym poziomie proceduralnym.
Jacek: Mamy z Kubą wspólne doświadczenia. Widzieliśmy takie zmiany. Tak z jednej strony oboje wierzymy w ewolucyjny proces usprawniania, tak paradoksalnie z drugiej strony są sytuacje, w których bardziej zdrowe będzie jednak rozpoczęcie od zera. Czyli poukładanie w sposób inny. Przychodzi dzień zero, od którego zaczynamy funkcjonować w inny sposób. Nie ma moim zdaniem dobrej odpowiedzi na to pytanie, z którego podejścia skorzystać. Jest to decyzja mocno kontekstowa, ale zależało nam z Kubą, żeby ta opcja trochę bardziej rewolucyjna, żeby ona też wybrzmiała.
Kuba: Żeby była jasność, co to znaczy rewolucja? Ona oznacza absolutne zanegowanie wszystkich istniejących zasad, ale też być może całkowita odnowa, powołanie osób decyzyjnych, wyznaczenie osób odpowiedzialnych za produkt, za decyzje strategiczne, czy taktyczne w ramach naszego obszaru. Być może w ogóle też po prostu ustalenie nowych granic, czy nowych definicji tego, co to dla nas jest zespół? Czym jest produkt, którym się dany zespół opiekuje? Bo często firmy tkwią w takim jednocześnie proceduralnym układzie i układzie takim strukturalnym, czy organizacyjnym. Tutaj nie ma co ewoluować. Jednocześnie kilka czynników jest źle poukładanych i to będzie bardzo trudne do zmiany taką metodą małymi krokami. Podsumowując ten odcinek. Zdefiniowaliśmy, jak rozumiemy wzorzec Water Scrum Fall i podzieliliśmy się w sumie dziesięcioma radami. Cztery z perspektywy zespołu, czy danej grupy produktowej i sześcioma poradami z perspektywy osób odpowiedzialnych już na poziomie całej organizacji za system, jak to zrobić, żeby albo sobie lepiej radzić w takim świecie, albo po prostu go usprawnić, żeby wyjść z pułapki Water Scrum Falla.
Jacek: Od kilku lat z Kubą pracujemy jako niezależni konsultanci z różnymi organizacjami. Pomagamy rozwiązywać problemy takie, jak opisaliśmy w dzisiejszym odcinku. Tak więc, jeżeli czujesz, że możemy dać wartość naszym spojrzeniem z boku, naszą ekspertyzą, naszym doświadczeniem i moglibyśmy w usprawnieniu Twojego procesu w Twojej firmie i towarzyszyć Ci w procesie tej zmiany, to śmiało skontaktuj się z nami przez formularz kontaktowy na stronie porzadnyagile.pl/kontakt. Warto też na koniec tego odcinka wspomnieć, że jest on dla nas z Kubą w pewnym sensie wyjątkowy. Mianowicie dokonaliśmy sporej aktualizacji, jeżeli chodzi o podcast od strony, nazwijmy to takiej kuchennej.
Kuba: Nie zmarnowaliśmy czasu około świątecznego.
Jacek: Tak. Przegryzaliśmy karpiem i sałatką pewne spore zmiany. Osoby, które słuchają, a właściwie oglądają podcast na YouTube, myślę, że zauważyły, że pracujemy na nowych mikrofonach po to, żeby z Kubą brzmieć w ten sam sposób i jednocześnie, żeby podnieść jakość dźwięku, który dociera właśnie do Twoich uszu. Tak więc jeżeli czuliście, że jesteśmy zestresowani, no to najprawdopodobniej dlatego, że pracujemy na nowym sprzęcie.
Kuba: Nowy sprzęt lepiej zbiera stres.
Jacek: Tak. Zdecydowanie. Jestem cały usztywniony. Natomiast druga rzecz, która się wydarzyła i która też jest dla nas istotna, to po dwóch latach zdecydowaliśmy się zmienić też oprawę graficzną podcastu, która od samego początku, od powstania była stworzona z myślą, że będzie tymczasowa. Ta tymczasowość trwała z nami przez dwa lata. Uznaliśmy, że przyszedł moment, kiedy mamy dowód na to, że podcast jest dla nas ważny. To już pięćdziesiąty któryś odcinek, który nagrywamy i nie zamierzamy przestawać. Dojrzeliśmy do decyzji, żeby oddać w ręce profesjonalistów to, jak się prezentuje podcast. Logotyp i cała oprawa, kolory, czy grafiki, które wykorzystujemy w Social Mediach dostały nowy wygląd i jakby to też jest coś, co z naszej perspektywy daje nam sporo radości.
Kuba: Daj nam sygnał, jeśli widzisz zmianę na lepsze. Jeśli nie widzisz zmiany na lepsze, to tym bardziej daj nam ten sygnał, bo tutaj trochę zainwestowaliśmy czasu i emocji. Na koniec przypomnę, że notatki do tego odcinka z linkami do materiałów, które wspomnieliśmy w czasie nagrania, transkrypcję, zapis wideo znajdziesz na stronie porządnyagile.pl/54.
Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.
Kuba: Dzięki Jacek.
Jacek: I do usłyszenia wkrótce.
Water Scrum Fail*