Czym jest, jak rozpoznać i naprawić Scrum w wersji zombie?

W dwudziestym szóstym odcinku podcastu „Zwinne organizacje” Paweł Tomkiel rozmawia z Sebastianem Żebrowskim, LeSS Scrum Masterem z UPC Polska, o tym, jak Scrum jest używany w organizacjach oraz jak często jest zatracana jego istota.

Transkrypcja podcastu

Paweł: Cześć, jestem Paweł Tomkiel.

Sebastian: Cześć, jestem Sebastian Żebrowski.

Paweł: W dzisiejszym odcinku będziemy rozmawiać o tym, jak Scrum jest używany na rynku, jak jest używany w firmach, ale jednocześnie jak często jest zatracana sama jego istota. Sebastian, znam cię jako osobę, która jest powiązana z różnymi środowiskami, głównie warszawskimi, ale również polskimi, szczególnie teraz, gdy przeszliśmy do online, Liberating Structures, The Liberators, LeSS. Gdybyś miał powiedzieć kilku słowach o sobie to kim jesteś i co robisz?

Sebastian: Nigdy nie jestem w stanie odpowiedzieć na to pytanie w sposób zadowalający. Obecnie prowadzę onboarding, gdzie robimy wstęp dla nowych osób z agile, o co chodzi w ogóle z tym agile - takie nasionko ciekawości sadzimy w tych nowych ludziach. Z jednej strony mogę powiedzieć, że jestem Scrum Masterem. Z drugiej strony mogę powiedzieć, że jestem Agile Coachem, który specjalizuje się w Scrumie. Z trzeciej strony jestem wielkim fanem uprawiania tej roli w sposób, nie jako człowiek od zespołu, tylko też działań na poziomie całej organizacji, czyli jestem agentem zmiany. Też nie samym Scrumem człowiek żyje, tam wchodzi wiele rzeczy na pograniczu różnych tematów, Leadership, Management, Product Management. Jest wiele rzeczy, które interesują w domenie agilowej, które bardzo często zamieniają się takie proaktywne hobby, gdzie próbuję coś dać od siebie społeczności.

Paweł: Dzisiaj skupimy się na kwestii samego Scruma. Użyliśmy już tego słowa na początku odcinka - Scrum w wersji zombie. Ten zwrot jest często używany w naszym środowisku agile. Jak ty byś zdefiniował Scruma w wersji zombie?

Sebastian: Można powiedzieć, że Zombie Scrum nie jest nowym pojęciem. To pojęcie już było, tylko teraz wielu osobom przypadło do gustu, wcześniej nazywaliśmy to teatrem agile, maskaradą agile. Zdefiniowałbym to po prostu, jako ślepe wierzenie, że wprowadzając jakieś narzędzie, proces, cokolwiek takiego, co myślimy, że nam rozwiąże problem, to w magiczny sposób zmieni nam się zachowanie i kultura firmy. Ile razy opowiadałeś sobie taką bajeczkę, że jak znajdę odpowiednie narzędzie, "to-do apkę", to w magiczny sposób zaczniesz się lepiej organizować. Poświęcasz wtedy całą energię na szukanie tego narzędzia, tej idealnej apki. Nie ma takiej danej apki, bo żadna apka nie jest w stanie przewidzieć wszystkich tych kombinacji. Cała energia na to idzie, a problemem nie jest apka, problemem jest zachowanie.

Nawet Einstein kiedyś powiedział, że jeżeli miałby godzinę na rozwiązanie jakiegoś problemu to 55 minut poświęciłby na zrozumienie tego problemu, a 5 minut na rozwiązanie. My jako ludzie mamy tendencję do tego, żeby iść od razu w te rozwiązania bez przemyślenia jaki jest faktyczny problem.

Rzadko kiedy myślimy o zachowaniach, a często myślimy od razu o rozwiązaniach, np. jak ktoś wie co to są Impact Mapy to wie, że są proste, ale nie są łatwe, bo ludzie mają tendencję do pójścia w te rozwiązania. Podobnie jest z agile. Większość osób, myślę, że też sporo osób na wysokich szczeblach myśli, że agile to jest po prostu "procesik"- masz 5 wydarzeń, 3 role i mamy agile. Ile firm w ogóle nawet nie wie po co tego agile’a wprowadza. Po prostu wprowadza, bo reszta też wprowadza. Ile razy słyszymy, że mamy Scruma, a sprowdza się on do tego, że jest narzędziem tortur IT. Później słyszę, Scrum nie uwzględnia Customer Experience. To jest zrozumiałe, jeżeli ktoś traktuje Scrum jako taki procesik z wydarzeniami, który jest po stronie tylko IT to wiadomo, że nie uwzględnia wtedy Customer Experience, tylko to jest kwestia implementacji, a nie kwestia samego Scruma.

Oczywiście łatwo wykazać, że to nie jest prawda, że Scrum nie uwzględnia Customer Experience. Wystarczy spojrzeć sobie do choćby agile manifestu. Problemem organizacji jest spłycanie tego tematu, podchodzenie do niego, jak właśnie do kolejnego narzędzia, które trzeba po prostu wdrożyć. Jak często mówi się o transformacjach organizacji. Samo pojęcie sugeruje, że coś wprowadzamy w takim skończonym czasie, zrobił pstryk i przełączymy jakiś włącznik w magiczny sposób - jesteśmy agile, jesteśmy po transformacji. To jest bzdura, bo co najwyżej możemy adaptować ten agile, tego Scruma. Jest to proces ciągły. Jeżeli przez wiele lat tworzyliśmy taki supeł organizacyjny to nie możemy teraz założyć, że w skończonym czasie jesteśmy w stanie ten supeł rozwiązać. Nie możemy też zakładać, że wiemy do końca jak to zrobić, z jednej choćby przyczyny: budując na ludziach, budujemy na błocie, cytując jedną książkę, czyli jako ludzie jesteśmy nieprzewidywalni, mamy swoje indywidualne zachowania, cele, zrozumienia, komunikacja jest prosta do wytłumaczenia jako koncept, ale jest też jest prosta, ale nie jest łatwa do zrealizowania. Nie jesteśmy w stanie budując na ludziach próbować przewidzieć, jak się zachowają, jak się zachowa złożony system, jakim jest organizacja, nie jesteśmy w stanie przewidzieć, ile może to potrwać. Nie możemy też przewidzieć, że nawet mając cel wprowadzenia tego agile’a, to ten cel nie zmieni się w czasie, jak będziemy lepiej rozumieć problem.

Zombie Scrum jest ślepym wierzeniem w to, że wprowadzając jakieś narzędzie lub proces dokonamy zmiany kultury czy zachowań osób w organizacji.

Paweł: Ciekawe, że powiedziałeś o kulcie Cargo. Dla tych, którzy nie słyszeli o tym, to kult Cargo to właściwie jest ruch religijny, który się rozwijał na Wyspach Oceanu Spokojnego i zaczął się od tego, że przyjeżdżali tam kolonizatorzy, budowali pasy startowe dla swoich samolotów, samoloty lądowały i za każdym razem, kiedy taki samolot lądował, przywoził jakieś dary, jakieś dobra. Ludy, które obserwowały samoloty, ten pas startowy, uczyły się, że jeżeli będą budować pasy startowe, to będą do nich przylatywać takie samoloty i będą zostawiać dary. Ślepo wierzyły, że wdrożenie pasa startowego zmieni ich życie.

Sebastian: Możecie zobaczyć, że tam nawet oprócz pasów startowych były samoloty ze słomy, stacje radiowe, tak samo zbudowane ze słomy, w kształcie tej technologii. Podobnie jest ze Scrumem czy Agilem, gdzie wprowadzając ten "procesik" myślimy, że w magiczny sposób odczarujemy wszystkie problemy, które mamy w firmie.

Paweł: Wdrażamy te procesy, wdrażamy te gotowe narzędzia, oczekujemy jakiejś zmiany. Zanim pójdziemy dalej, chciałbym cię zapytać, czy to właśnie jest tak, że po to, powstają takie Frameworki, jak Scrum, jakieś metodyki, jakieś sprawdzone sposoby działania, żeby je wdrożyć i właśnie one mają sprawić, że zaczniemy działać inaczej, że nasza praca przyniesie inne efekty.

Sebastian: Kiedyś, jak byłem młodym Scrum Masterem, chociaż pewnie tak patrząc na staż kolegów to można powiedzieć, że nadal jestem młodym Scrum Maserem, to, jeżeli ktoś w organizacji zaczął mówić, że Scrum nie działa to wpadałem w panikę. Myślałem, że to jest moja wina, że robię coś źle. Z czasem doszedłem do takiego wniosku, że to nie jest tak, że Scrum nie działa i trzeba z tym coś zrobić - on ma nie działać tak naprawdę, bo jeżeli by działał od razu, to znaczyłoby, że już jesteście agile, już jesteście w stanie maksymalizować zwrot z inwestycji w krótkich cyklach, więc już ten agile wam działa. Można powiedzieć, że Scrum jest jak linijka czy waga. My, używając tego narzędzia, patrzymy na to, jak daleko jesteśmy od tego celu doskonałościowego, tak od tego, jak daleko jesteśmy, żeby w krótkich cyklach maksymalizować wzrost z inwestycji, więc sam Scrum nie rozwiąże nam niczego, pokaże tylko, jak bardzo odbiegamy od tego, gdzie chcemy być. Poprawiając Scruma, to tak, jakbyś myślał o tym, że potrzebujesz schudnąć i stajesz na wagę i widzisz, że ten wynik nie jest tak jak trzeba. I teraz, co zrobić, aby był taki jak trzeba - to stanę jedną nogą. Oczywiście waga zmieni, pokaże mniejszą liczbę, która bardziej ci się podoba. Pytanie, czy uwaga teraz działa, czy pokazujecie stan faktyczny. Tak samo jest ze Scrumem, zwiększy po prostu transparencję problemów i tego jak daleko jesteś od tego celu doskonałościowego.

Paweł: Ciekawe jest to, co powiedziałeś, że scrum ma nie działać z zasady tuż przy wdrożeniu, ale postawiliśmy taką tezę na początku tego odcinka, że on w większości firm nie działa. Rozmawiamy dzisiaj o takim stanie, ja tak to rozumiem, że zombie Scrum to jest ta sytuacja, kiedy on nie działa albo działa w jakiś sposób, który się wyklarował w danej firmie, ale de facto nie wpływa właśnie na szybkość, nie przynosi efektów, to znaczy może działać, może być tak, że wszyscy są świetnie nauczeni, zdefiniowane są wszystkie role, ale tak naprawdę nie przynosi żadnych efektów. I chyba ten stan, o którym dzisiaj rozmawiamy to jest ten stan braku zmiany w takich organizacjach.

Sebastian: To jest tak naprawdę to zombie. Nawet ostatnio myślałem o tym, że często taki Scrum i nawet to widziałem wielokrotnie, może tak naprawdę pogarszać sytuację. Jeżeli firma nie chce żaden sposób się zmienić, zmienić swojego podejścia, tylko chce wprowadzić ten "procesik". Mówię to ironicznie, z perspektywy osoby, która z góry na to patrzy i podchodzi bardzo szyderczo do tego. Mamy jakieś narzędzie, chcemy je wprowadzić, myślimy, że ono coś zmieni, a jednocześnie nie chcemy zmienić tego, jak działamy, jak działa firma, jaka jest struktura firmy.

Paweł: To jest klucz, to co powiedziałeś, że wdrażamy, ale tak naprawdę nic nie chcemy zmienić. Chcemy nadal mieć zespoły funkcyjne.

Sebastian: Tak, chcemy nadal mieć zespoły funkcyjne, chcemy nadal mieć długie szczeble hierarchii, chcemy nadal mówić ludziom "jak", zamiast "co i po co", chcemy nadal podejmować za nich decyzje, nigdy nie stwarzać im okazji do samoorganizacji. Generalnie wszystko jest samo, po prostu robisz mapowanie. Teraz nie masz już zespołów - masz składy, nie masz departamentów - masz triby. Masz Spotify model, wiele firm wdraża Spotify model, gdzie samo Spotify mówi o tym, że nie ma czegoś takiego jak Spotify model, jest to migawka z tego, do czego oni próbowali dążyć w 2012 czy 2014 roku. Nie ma czegoś takiego, a ile firm to wprowadza, bawi się w te swoje triby, składziki, mówi, że mają agile, przy czym tak naprawdę nic się zmieniło, po prostu jest większy chaos, jest zmapowanie ról, a tak naprawdę zachowanie, o którym mówiliśmy na początku, zostaje takie samo, kultura zostaje taka sama. Czy dostarczamy coś szybciej? Może jestem w stanie uwierzyć, coś tam się może poprawić, jeżeli podeszliśmy do tych tribów w ten sposób, że one są cross-funkcjonalne, że nie są już takie stricte funkcyjne departamenty, tylko faktycznie są one bardziej samowystarczalne. Zakładam, że wtedy coś się poprawi, ale, budulcem takiego Scruma są samoorganizujące się zespoły. Wiele razy słyszę coś takiego, że my nie jesteśmy start-upem i to ma tłumaczyć dlaczego mamy taką złożoność organizacyjną, złożoność tych procesów. To jakby się zastanowić nad tym to tak naprawdę, im mamy bardziej złożoną organizację, to musimy bardziej upraszczać strukturę i te procesy, bo im większa organizacja, tym więcej ponosimy globalnie strat wynikających z tej biurokracji, tej wyuczonej niezaradności naszych ludzi, takiego braku pro aktywności. Im mamy większą organizację, tym bardziej na tym tracimy.

Paweł: Powiedzieliśmy, że czasem firma robi transformację agile, ale tak naprawdę nie chce się zmienić. Tylko kiedy o tym teraz myślę, to chyba nie jest tak, że firma nie chce się zmienić, decydenci na samej górze, zarząd, CEO, oni chcą, żeby ich organizacja się zmieniła, chcą, żeby firma przynosiła więcej biznesowej wartości, chcą, żeby firma dostarczała coś szybciej do klienta końcowego, więc tak naprawdę ktoś, kto decyduje o rozpoczęciu transformacji, chce, żeby coś się zmieniło, więc właściwe pytanie, które powinniśmy postawić, to jak te osoby, którym rzeczywiście zależy na zmianie organizacji, mogą rozpoznać, że ta transformacja się dzieje, ale nie przyniesie żadnych efektów, jak rozpoznać zombie Scruma?

Sebastian: Jeżeli ktoś obiecuje konkretny termin na wprowadzenie transformacji agile to albo cię oszukuje, albo nie rozumie, na czym to polega, albo mówimy o jakiejś mikro firmie. Jeżeli mówimy o dużych organizacjach, to nie da się tych rzeczy przewidzieć. Jeśli ktoś mówi, że jest w stanie to przewidzieć, to mówimy najprawdopodobniej nie o transformacji agile, tylko o wprowadzeniu Zombie Scruma. Wprowadzenie tych ról, udawanie, że robimy agile, że mamy tego Scruma, możemy sobie wrzucić na LinkedIn, że coś tam się odbyło, jak my idziemy do przodu, a pod spodem jest w sumie tak jak zawsze. Jak to poznać i czym się to charakteryzuje? Pierwszą rzeczą to jest odejście od takiej pułapki utylizacji zasobów, użycia zasobów, czyli, jeżeli mamy pracę kreatywną i złożoną to nie możemy wrzucać modelu fabrycznego i mówić, że ten fabryczny model zadziała, to jest oszukiwanie siebie. W samym Scrumie czy agile nie chodzi o to, żeby ludzie byli jak najbardziej zajęci, nam chodzi o to, żeby maksymalizować zwrot z inwestycji w tego Scruma w krótkich cyklach, cały czas, weryfikując, czy to, co nam się wydaje, czy te nasze hipotezy, które trzymamy w backlogu faktycznie idą w tę stronę, w którą my chcemy, żeby one szły. Jest takie powiedzenie, że żeby wejść w buty klienta, trzeba najpierw wyjść ze swoich butów, czyli my nie możemy zakładać, że my wiemy czego potrzebuje klient. Musimy poprzez szereg eksperymentów dojść do tego, czy to, co nam się wydaje jest faktycznie tym, czego potrzebuje klient. Jeżeli podchodzimy do tego jak do fabrycznej pracy, gdzie każdy trybik ma swoją specjalizację, robi swój kawałeczek roboty, to wtedy w prosty sposób wydłużamy tę pętlę uczenia się. Jeżeli mamy cross-funkcjonalny zespół, w tym zespole mamy kompetencje programistyczne, analityczne, testerskie.  Jeżeli podchodzimy do tej pracy w ten sposób, że np. mamy nadwyżkę testowania i zamiast pomóc z tym testowaniem w zespole, analityk zamiast pomóc z testowaniem, to robi analizę na przyszłość, która niekoniecznie nam się przyda, bo zmienią nam się priorytety i pójdzie do kosza. To właśnie zamiast podchodzić do tego w ten sposób, to analityk powinien zakasać rękawy, pomóc z testowaniem, skrócić pętlę uczenia się tak, żeby ta inwestycja w tym sprincie wyszła jak najszybciej do klienta, żebyśmy byli w stanie zweryfikować czy to, co nam się wydaje, to jest faktycznie to, czego potrzebuje klient. To jest właśnie takie podejście, gdzie mówimy o tym, że chcemy skracać pętle uczenia się. To tak samo oznacza, że musimy angażować zespoły to, żeby one pracowały z ekspertami domenowymi, z użytkownikami, z klientami i żeby bezpośrednio z nimi rozmawiali. Jeżeli robi to u was Analityk, Product Owner czy inny pośrednik wydłużający pętlę uczenia się i wprowadzający głuchy telefon to nie jest to agile. To jest właśnie to myślenie fabryczne, gdzie wprowadzamy agile do takiej fabryki softu, gdzie mówimy, że nasi eksperci nie są w stanie zrozumieć domeny, nie są w stanie zaproponować rozwiązań biznesowych i musi to za nich zrobić ktoś bardziej doświadczony, kto lepiej to rozumie.

Jeżeli ktoś obiecuje konkretny termin na wprowadzenie transformacji agile to albo cię oszukuje, albo nie rozumie, na czym to polega. Jeżeli mówimy o dużych organizacjach, to nie da się tych rzeczy przewidzieć. Jeśli ktoś mówi, że jest w stanie to przewidzieć, to mówimy najprawdopodobniej nie transformacji agile, tylko o wprowadzeniu Zombie Scruma.

Paweł: Chciałbym chyba z tobą wejść w polemikę, bo to, co powiedziałeś, to jest prawda, to znaczy, że np. programista jest w stanie porozmawiać z klientem, albo jest w stanie stworzyć jakiś diagram, albo jakiś zalążek dokumentacji, ale czas programistów jest na tyle drogi, albo na tyle nie chcą tego robić, chcieliby się tylko zajmować kodowaniem, że po to się bierze analityka, który jest pewnie tańszy niż sam programista.

Sebastian: W przyszłości, zakładam, że za 10 lat, firmy w końcu zrozumieją, że nie opłaca nam się używać programistów i zrobić z nich takie biologiczne translatory wymagań na kod, bo to kompletnie nie bierze pod uwagę czegoś takiego, jak Total Cost of Ownership, czyli całkowity koszt posiadania. Można zacytować DDD, gdzie mówi się to, co znajdzie się w kodzie jest tym, co zrozumiał programista Software Developer, osoba pisząca ten soft. Im więcej mamy niezrozumienia, tym gorszy powstaje kod, tym więcej nam to generuje ponownej pracy, tym więcej generuje np. długu technicznego. Więc jeżeli myślisz o tym fabrycznie, jeżeli myślisz o tym z perspektywy utylizacji zasobów, to faktycznie nie opłaca się, ale jeżeli myślisz z perspektywy tego, że mamy rozwiązać problem klienta, to wielokrotnie spotykałem się z tym, że Software Developer wychodził z bardzo dobrym pomysłem, albo np. patrzył na metryki i ekscytował się, że nam skacze sprzedaż. To jest bardziej ludzkie podejście, gdzie nie zakładamy, że jesteś człowiekiem, który robi jedną sztuczkę, że jesteś trybikiem o jednej specjalizacji, tylko każdy z nas ma wiele specjalizacji, ma wiele talentów. Jest takie powiedzenie popularne środowisku, że specjalizacja jest dobra dla insektów, bo insekty się specjalizują. My jako ludzie mamy jakieś predyspozycje, jakiś talent, ale to nie jest tak, że później robimy jedną rzecz. To jest też prosta droga do tego, żeby się wypalić, albo też zwiększyć marnotrawstwo niewykorzystanych talentów.

Tak naprawdę, nie da się dokonać zmiany, nie da się uciec przed zombie Scrumem, jeżeli nie jesteśmy gotowi na to, żeby zmienić strukturę organizacyjną. Jest takie powiedzenie Larmana "Culture follows structure". Zarówno struktura, jak i tak naprawdę rekrutacja mocno wpływają później na kulturę, a co za tym idzie na zachowanie. I dla mnie to się wiąże mocno z prawem Conway’a. Jeżeli mamy tu organizację ustrukturyzowaną w sposób funkcyjny, matrycowy, gdzie skupiamy poszczególne specjalizacje w jednym miejscu i optymalizujemy raportowanie i rozliczanie to, to powoduje, że mamy zależności. A jak mamy zależności to nie jesteśmy w stanie jako ten zespół Scrumowy dostarczyć czegoś w jednym sprincie. Wskutek tego wydłuża nam się pętla uczenia się i zwrot z inwestycji w ten sprint, albo w ten zespół Scrumowy. Ile razy byliście w takiej sytuacji, gdzie zamiast skończyć, to zaczynacie coś nowego, bo musicie na coś czekać, na jakiś inny zespół gdzieś indziej w organizacji. Bez zmiany struktury nie da się tego zmienić, nie da się zlikwidować tych zależności. Dużo firm myśli, że powoła sobie projekt Scrumowy i w magiczny sposób wszystkie problemy, choćby właśnie z prawem Conway’a znikną i w dwa tygodnie coś zostanie zrobione i dostarczone, od razu zderzone z klientem i będziemy w stanie dowiedzieć się czy idziemy w dobrą stronę czy nie.

Pamiętam jeden projekt, gdzie właśnie był taki kult optymalizacji wizerunku i robienia czegoś na 100%. Mówi się w środowisku, że jeżeli pokazujesz coś i nie wstydzisz się tego, co znaczy, że pokazujesz to za późno. Tutaj jest podkreślenie tego, że ta pętla uczenia się musi być krótka, muśmy ciągle pozyskiwać ten feedback i właśnie w tym projekcie akurat była taka sytuacja, gdzie, zanim coś trafiło do klienta, to był kwartał na stabilizację łaty i coś, co trafiało do tych użytkowników miało opóźnienie półroczne względem tego, co robiliśmy. To powodowało, że te zespoły, które rozwijały produkt, tak naprawdę dowiadywały się o tym, czy i robią coś dobrze czy nie z półrocznym opóźnieniem, a po pół roku okazywało się, że nie o to chodzi i trzeba iść w zupełnie inną stronę. Można powiedzieć, że całe pół roku szło w jakimś stopniu do kosza. Teraz zapytasz się mnie co się stało z projektem, a ja Ci odpowiem - nic, ubili go. Mogę się założyć, że na koniec dnia ktoś powiedział, że wszystko dlatego, że Scrum nie działa.

Paweł: Jeżeli projekt jest ubijany właśnie po takiej pierwszej nawet półrocznej pętli feedbacku, to jeszcze nie jest źle. Widziałem projekty, które trwają lata i nie są wypuszczane nigdy i jest ciągle work in progress, czyli de facto jeszcze nie jest to stratą, jeszcze nie jest żaden zwrot, ale trwa, bo zostało zaplanowane. Ma nawet 5-letnie opóźnienie, ale wykonujemy plan.

Sebastian: Jak często masz takie sytuacje, gdzie z prostego MVP, czy czegoś podobnego, robi się jakaś wielka kobyła, bo jest taka kultura w organizacji, gdzie każdy menadżer, np. chce się wykazać, coś dorzuca do tego projektu. Był taki film na faktach o budowaniu czołgu, gdzie co iterację znajdował się jakiś nowy generał, który mówił, że musimy jeszcze coś dodać i z tego pierwotnego celu tego czołgu zrobił się taki Frankenstein, który żadnego z tych celi nie spełniał, gdy był kontakt już z klientem, czyli na froncie.

Paweł: Pociągnę trochę ten temat. Pracujesz w dużej organizacji, ja też pracuję w dużej organizacji. Czy sądzisz, że tak duże organizacje, które właśnie dbają o swój wizerunek, dbają o to, co wypuszczają na rynek, czy mogą pozwolić na wypuszczenie czegoś niedokończonego do klienta?

Sebastian: Jest to też kwestia tego, o czym mówimy. Bo z jednej strony możemy pokazywać użytkownikowi, klientowi coś, co jest nieskończone, co jest nawet makietą, na takich testach z użytkownikami, gdzie minimalizujemy impakt tej naszej nieskończoności. Jednocześnie coś, co w jakimś stopniu zmniejsza ryzyko, poprzez właśnie narzędzia UX-owe. Inny aspekt jest taki, że zmiana zmianie nie jest równa. Jedna zmiana to może być wysłanie głupiego SMS-a. Z drugiej strony możemy mieć np. nieidealny kolorek na produkcji w interfejsie albo przycisk w złym miejscu. To może czasami w niektórych domenach źle wyglądać i klient zaczyna podważać jakość, ale jednocześnie nie jest to coś, co sprawia, że mamy wyciek danych, albo jest jakiś faktyczny ból z tym związany. Trzeci aspekt, to za bardzo bycie pewnym tego, że wiemy, co klient chce. Czyli zamiast pokazać taki szkielet, coś, co z punktu widzenia klienta jest logicznie całością to my próbujemy zrobić z tego kombajn, nawet nie weryfikując, czy te funkcjonalności będą przydatne, czy ktokolwiek będzie z tego korzystał. Byłem też w takiej sytuacji, gdzie robiliśmy niby Scruma, ale wszystko działo się etapowo, czyli była taka sekwencja "przyczajony Scrum, ukryty Waterfall", gdzie było 5 takich kolumn i zanim zaczęliśmy następną kolumnę to musieliśmy skończyć tę pierwszą. Dochodziło do takich chorych absurdów, gdzie zamiast skończyć ten proces, powiedzmy proces sprzedaży czegokolwiek end to end, nawet z tym tzw. Happy Pathem, z tą szczęśliwą ścieżką, to my zajmowaliśmy się dopieszczeniem wizualnym jakiegoś elementu tej apki, a po roku nadal nie działał process and threads. W pewnym momencie trochę nie wytrzymałem, zacząłem po prostu utransparentniać ten absurd. Udało mi się na szczęście dotrzeć do odpowiedniej osoby i udało mi się to sprzedać, wtedy dopiero nam ta praca ruszyła. Już wyszliśmy na produkcję, nawet nikt nie wspominał tych zmianach wizualnych. Jak często się skupiamy na takich pierdołach wizualnych, które tak naprawdę, kogo byś nie zapytał, to byś dostał inną odpowiedź. Często jest też tak, że ludzie nie chcą rozmawiać o trudnych rzeczach, o procesach, które może trzeba na nowo zdefiniować w firmie, tylko wolą się przyczepić do przycisku nie w tym miejscu, do koloru. O tym jest dużo prościej rozmawiać. Na pewno dużo osób czuje się z tym komfortowo, bo nie można się pomylić albo powiedzieć czegoś głupiego w tym kontekście, jest bezpieczny.

Paweł: Na zakończenie chciałbym zapytać, co w takim razie można poradzić na ten Zombie Scrum, który jest wdrażany w organizacjach, ale który nie przynosi tej realnej zmiany?

Sebastian: To jest trudne pytanie, żeby tak odpowiedzieć uczciwie. Z tego względu, że budując na ludziach, budujesz na błocie. Każdy kontekst jest mocno indywidualny i tak samo nie dość, że każda firma składa się z unikalnej kompozycji ludzi, tak samo każda firma ma inny kontekst i takie powiedzenie jednoznacznie zróbcie to i to, jest na poziomie transformacji, że jestem w stanie przewidzieć jak długo będzie trwała i co trzeba dokładnie zrobić. Tak wysoko poziomowo i mówiąc bardzo ogólnie potrzebujemy zwiększać widoczność problemów, jakie mamy w organizacji. Musimy odważnie chcieć je rozwiązywać. Musimy wiedzieć w ogóle po co robimy tego Scruma, po co robimy agile. Potrzebuję mieć osoby, które widziały jak ten Scrum może działać, które nam pomogą po prostu uniknąć tego zombie Scruma i zrobienia z tego fabryki, albo czegoś innego do torturowania ludzi.

Paweł: Dodałbym do tego to, co powiedziałeś, żeby mieć cel określony. Dlaczego właściwie chcemy robić transformację zwinną, dlaczego chcemy wdrażać Scruma? Dodałbym to, że powinniśmy mierzyć, powinniśmy utransparentniać, powinniśmy uwidaczniać efekty tego, co się działo przed wdrożeniem i co się dzieje po wdrożeniu, czyli określić te kluczowe metryki, nie produktywności, nie KPI, ale to, co się faktycznie dzieje, takie KVI- Key Value Indicator.

Sebastian: Nawet Scrum Work ma coś takiego, jak Evidence Based Management, tam jest podział na te metryki output-owe i outcome-owe. Tylko to też jest kwestia taka, wiem z własnego podwórka, nie, żeby u mnie było idealnie, ale pewne metryki outcome-owe jest ciężko wyciągnąć i mierzyć. Tak jak mówiłem, że ten supeł organizacyjny jakby zasupla przez wiele lat, podobnie to wygląda z tym mierzeniem, gdzie np. mamy Call Center i to Call Center, po rozmowie ma do wyboru jakiś formularz. I teraz, jeżeli nie przemyślimy tego procesu, tego zaznaczania w jakiej sprawie klient do nas zadzwonił to może być tak, że np. taki system będzie kierował konsultantów, żeby klikali byle jaką opcję, żeby jak najszybciej zamknąć okienko, żeby obsłużyć kolejny call. Chcesz zmierzyć tego KVI, ale osoby, które budują tego KVI, tak naprawdę mają KPI-e ilościowe. Wtedy możesz mieć np. metrykę, metryka jest outcome-owa, jesteś zadowolony z siebie, ale pod spodem ta metryka nie jest prawdziwa, nie daje ci tej rzeczywistości. Istota jest taka, żeby właśnie wyłapywać takie miejsca i wyłapywać to, gdzie sami siebie oszukujemy, albo mamy dług techniczny, dług organizacyjny, gdzie coś nam zmniejsza tę transparencję, tę widoczność problemów.

Paweł: Poruszyliśmy dzisiaj dużo wartościowych wątków. Gdybym miał zapytać, jakie 3 najważniejsze rzeczy z naszej rozmowy chciałbyś, żeby nasi słuchacze zapamiętali to, co by to było?

Sebastian: Pierwsza rzecz - bez zmiany struktury, bez takiego pochylenia się faktycznie nad tą strukturą i co za tym idzie rekrutacją nie jesteśmy w stanie dokonywać zmian, które będą miały duży impakt. Nie jesteśmy w stanie tego zrobić. Druga rzecz - jeżeli robimy wiele rzeczy naraz, to wydłużamy tę pętlę uczenia się, więc te rzeczy, które mogłyby być za miesiąc, będą za ileś miesięcy. Dodatkowo obciążymy naszych ludzi, kortyzolem, wypaleniem itd. Tak samo, to też z mojego doświadczenia, nie trzymajcie zespołów Scrumowych w piwnicy, bez wsparcia organizacji. Jeżeli jesteście np. menedżerami to waszym zadaniem jest, by pomóc tym zespołom, żeby one były w stanie osiągnąć tę samoorganizację, żeby byli w stanie dokonywać faktycznie tej zmiany, dostarczać faktycznie ten skończony inkrement produktu co sprint. Sami Scrum Mastrerzy nie rozwiążą problemów organizacyjnych, oni potrzebują wsparcia góry, potrzebują wsparcia menadżerów, potrzebujemy stworzyć warunki, żeby ten Scrum mógł zakwitnąć.

Paweł: Bardzo dziękuję za podsumowanie, dziękuję też za rozmowę. Myślę, że może być bardzo wartościowa dla naszych słuchaczy. Dajcie nam znać, co myślicie na naszych mediach społecznościowych. Jeżeli nasi słuchacze chcieliby dowiedzieć się więcej o tobie to, gdzie byś ich odesłał?

Sebastian: Myślę, że na LinkedIn. Tam najczęściej działam. Tam też promuję swoje inicjatywy, np. meetupy The Liberators, gdzie właśnie staramy się rozprawiać za pomocą warsztatów z Zombie Scrumem, budować świadomość społeczności. Dodatkowo też robimy warsztaty z Large-Scale Scrum, czyli z tego skalowania Scruma. Wbrew pozorom to jest mocno powiązane ze sobą. Wiele takich dynamik, które są na poziomie zespołu, często później są na poziomie organizacji, więc te tematy mi się wiążą zawsze. Stąd też moje zainteresowanie. Jestem zawsze chętne do tego, żeby pogadać o właśnie takich tematach Scrumowych i Agilowych.

Paweł: Drodzy słuchacze, odsyłam również do naszego bloga "Zwinne organizacje" na stronie Deloitte.com, a także do naszych odcinków, w których poruszaliśmy podobne zagadnienia: „Spotify nie używa modelu Spotify. Twoja firma też nie powinna” oraz „Pracownicy dostarczą to, co mierzysz”. Dziękujemy i do usłyszenia.