Bartek Śliwa: Bartek Śliwa, to jest podcast Euvic Talks, w którym łączymy technologię z biznesem.

Dziś odczarujemy troszkę pojęcie zwinności, powiemy sobie czym jest Scrum, a naszym gościem jest Michał Pięciorek. Cześć Michał.

Michał Pięciorek: Dzień dobry, cześć Bartku.

Bartek Śliwa: Michał, standardowe pytanie dla wszystkich. Co cię łączy z biznesem?

Michał Pięciorek: To jest dobre pytanie.

To może tak pokrótce się przedstawię. Michał Pięciorek. Z Euvickiem jestem związany trzy lata. Swoją przygodę tutaj zaczynałem od stanowiska specjalisty do spraw rekrutacji IT. Natomiast ukończyłem Uniwersytet Ekonomiczny.

Myślę, że z perspektywy czasu mogę powiedzieć, że studia był jedynie dodatkiem do tego, co robiłem na co dzień, bo bardzo aktywnie uczestniczyłem, powiedzmy, w życiu studenckim, ale działałem w organizacjach, takich jak parlament studencki, Fundacja Studenckie Form Business Center Club, tam działałem jako koordynator projektu, później przewodniczący regionu, później przez trzy lata w zarządzie ogólnopolskim.

Stąd też moja przygoda zawodowa z Business Center Club w Loży Katowickiej, gdzie to jest Business Center Club, to jest taki klub przedsiębiorców, który zrzesza firmy w całej Polsce. Współorganizowałem 23. i 24. śląską galę BCC.

Także ten kontakt z biznesem był i te problemy, z którymi wtedy przedsiębiorcy się spotykali czy spotykają obecnie, nie są mi obce. Obecnie jestem z Scrum Masterem, współpracuję z zespołami deweloperskimi, współpracujemy z międzynarodowymi klientami i tworzymy produkty cyfrowe najwyższej jakości.

Bartek Śliwa: Zaintrygowało mnie to, co powiedziałeś, że problemy biznesowe nie są Ci obce. Czy możesz zdradzić jakiś z problemów, które podczas działania przy BCC zapadły Ci w pamięć?

Michał Pięciorek: Jeżeli chodzi o takie problemy, to one były bardzo różne i wiadomo, że jedne były bardziej skomplikowane, drugie mniej. Generalnie BCC jako klub też nie tylko zrzesza przedsiębiorców, ale również pomaga im na co dzień. To były problemy, często natury jakichś przekształceń w spółce, czy być może jakieś interpretacje z urzędów skarbowych. Wiadomo, prawo zmienia się dość diametralnie, co utrudnia działanie biznesowi. Więc problem był jeszcze bardziej, że tak, był jeszcze prostszy, ale myślę, że… codzienna praca.

Bartek Śliwa: OK, OK.

No właśnie, jesteś moim kolegą po fachu, bo jesteś Scrum Master’em i zakładam, że niestety rynek mocno zepsuł pojęcie Scruma, Scrum Mastera i często nasi klienci mają taki ambiwalentny stosunek w ogóle do zwinności, więc może powiedz twoimi słowami, jaka jest twoja rola jako Scrum Master? Co w ogóle robi, po co jest?

Michał Pięciorek: Dobre pytanie i często też się z tym spotykam. Czy to powiedzmy, jak tłumaczę, rodzinie gdzieś tam na jakichś urodzinach, “co ty tam właściwie synu robisz?” czy to jak rozmawiam z osobami, które na co dzień nie są związane z IT, no to nie do końca rozumieją tą rolę. Nawet się nie dziwię, bo rola Scrum Mastera jest dość specyficzna. To znaczy, o ile każdy mniej więcej słyszał czym jest scram i no to te odpowiedzialności nie są takie jasne. To znaczy, specyfika tego zawodu polega na tym, że efektów pracy Scrum Mastera nie widać od razu. To znaczy, dopiero po czasie można sprawdzić, czy Scrum Master faktycznie dowozi, czy zespół działa bardziej efektywnie, czy też nie.

No bo Scrum’ie mamy trzy role dla tych, którzy nie spotkali się, żebyśmy mieli to samo zrozumienie. Mamy oczywiście product ownera, czyli to jest ten przedstawiciel biznesowy, który zbiera wymagania, czy to od interesariuszy, czy z rynku, priorytetyzuje te zadania, nadaje pewien kierunek, wskazuje co powinniśmy zrobić w pierwszej kolejności, więc łatwo sklasyfikować i wyobrazić sobie taką osobę.

Mamy deweloperów, bądź ogólnie zespół, który przekształca te wymagania w funkcjonalności. I czy to pisze kod, czy w ogóle tworzy produkt, bo Scrum nie tylko w IT. No i mamy tego nieszczęsnego Scrum Mastera, który siedzi z boku i tak właściwie nie wiadomo co robi, za co go w ogóle rozliczać i tak dalej.

Scrum Master jest odpowiedzialny przede wszystkim za to, żeby Scrum był stosowany zgodnie z tym jak powstał. To znaczy, że w mojej opinii, żeby Scrum przynosił tą wartość taką, wykorzystać w pełni potencjał Scrum’a, no to jednak trzeba zachować te wszystkie zasady, które zostały tam opisane. Ich nie ma wiele, ale trzeba wziąć jako całość, więc dba o to, żeby w procesie tej pracy te wszystkie elementy ze sobą współgrały.

Jest odpowiedzialny też za efektywność zespołu. I jeżeli zespół jest efektywny, osiąga cele sprintu, produkt powstaje inkrementalnie, czyli stopniowo dobudowujemy funkcjonalność, no to to jest dobry sygnał. To znaczy, że zespół działa, więc ten Scrum Master być może tam i pomaga.

Scrum Master również pomaga product ownerowi. Bo ile on jest odpowiedzialny za to, żeby wyznaczyć kierunek, no to nie zawsze będzie wiedział, co jest najbardziej istotne, co ma większy priorytet, więc Scrum Master jest tą osobą, która pomaga znaleźć jakieś techniki priorytetyzacji, jest takim wsparciem i wspólnie gdzieś tam zastanawiamy się, na czym powinniśmy się skupić, więc też jest wsparciem dla product ownera.

Oczywiście Scrum Master powinien szkolić, czy to zespół, czy organizacje, też w tych aspektach miękkich, co również eliminuje marnotrawstwa, które występują dość często w firmach. No i dobry Scrum Master przede wszystkim powinien patrzeć nie tylko na zespół, w którym jest, bo to są często małe zespoły, ale również dobrze, żeby skupił się na całości jako organizacji, żeby, tak jak mówię, eliminować te marnotranstwa, nie tylko na poziomie zespołu, ale całej organizacji, bo to wiadomo efekt skali. Jest to tak w wielkim skrócie, dba o to, żeby ten proces był wykorzystywany należycie.

Bartek Śliwa: No właśnie, bo obserwujemy takie różne wypaczania, czyli Scrum Master jako mikro-manager.

Michał Pięciorek: Tak, albo sekretarz, albo… zaparzacz kawy.

Bartek Śliwa: Czyli nie chodzi o to, żeby kleić kolorowe karteczki.

Michał Pięciorek: Absolutnie nie.

Bartek Śliwa: I jeść ciastka.

Michał Pięciorek: Tak, ja w pełni sobie zdaję sprawę z tego, jak sytuacja wygląda na rynku. Większość Scrum Masterów…, nie wiem czy mogę to powiedzieć, ale jednak rynek jest troszeczkę zepsuty. I słabi Scrum Masterzy robią bardzo złą robotę, bo siedzą na tych spotkaniach, nie pomagają zespołowi, zespół tak właściwie się zastanawia po co on tam jest. No i tworzy to taką aurę, że to w sumie jest sekretarz zespołu i nie wiadomo, co robi, jaki jest jego efekt. A tak jak wspomniałem, efekt pracy Scrum Mastera widać po czasie, po zespole, po tym, czy produkt jest dowożony.

Więc ja sam, muszę się przyznać, wysyłam z zespołami, które współpracuje memy o Scrum Masterach i też się z tego śmieję, bo trzeba mieć dystans. No ale faktycznie jest taka tendencja.

Bartek Śliwa: Zróbmy krok wstecz. Często ludzie stawiają znak równości między pojęciami Scrum i Agile. Czy twoim zdaniem jest to poprawne?

Michał Pięciorek: Nie. Agile jest pojęciem znacznie szerszym. To znaczy Agile jest pewnym sposobem pracy, pewnym sposobem myślenia, być może nawet stylem życia dla niektórych.

Bartek Śliwa: Tak, mindset to jest to słówko, które zawsze lubię używać w stosunku do agile’a.

Michał Pięciorek: Tak, w pełni świetlnym zgodzę, więc to jest tak najprościej tłumacząc, jest to umiejętność dopasowywania się do otaczającej na rzeczywistości, czy to na polu zawodowym, czy na polu prywatnym. Bo wiemy, że możemy sobie coś zaplanować długoterminowo, a później, no, rzeczywistość puka i jest odmienna od tego, co sobie zaplanowaliśmy. Więc taka umiejętność dopasowania się do realiów rynkowych czy też prywatnych. Tak bym sklasyfikował Agile.

Natomiast Scrum jest pojęciem trochę węższym, bo Scrum jest frameworkiem, czyli ramami postępowań, konkretnym sposobem pracy. Wydaje mi się, że może to wynikać to, że ludzie biorą, uważają to jako synonim, może wynikać z tego, że to po prostu Scrum jest najbardziej popularnym, najczęściej stosowanym tym sposobem pracy. Warto pamiętać, że nie jest jedynym, a jakby tych podejść zwinnych jest znacznie, znacznie więcej. Po prostu jest najczęściej stosowany, stąd myślę, że wychodzą tego rodzaju pomyłki.

Gdybym miał to tak zobrazować wizualnie, no to agile porównałbym do oceanu, natomiast Scrum porównałbym do wyspy, być może nawet Australii, bo największa.

Bartek Śliwa: Poetycko.

Michał Pięciorek: Staram się.

Bartek Śliwa: Właśnie, jak już w poetyckie porównania jedziemy, to powiedziałeś, że Scrum to są takie ramy. Kiedyś spodobało mi się porównanie do ramki na zdjęcia. Scrum jest taką ładną ramką na zdjęcia, ale jak wstawimy tam kiepskie zdjęcie, to ładna ramka nic nie zrobi, więc zależy od tego, jak tą implementację Scrum’a przeprowadzimy i wtedy zobaczymy, czy mamy z tego korzyści.

No dobrze. Często widząc oferty pracy na Scrum Mastera, wymagany jest background techniczny. I po co?

Michał Pięciorek: To jest odwieczne…, są dwie szkoły i odwieczna walka się toczy czy ten Scrum Master musi być techniczny czy też nie. I że tak powiem, oba podejścia mają swoje plusy i minusy, bo teraz tak, wiadomo, że jeżeli Scrum Master jest techniczny, to jest osobą dodatkową w zespole, która kuma o co chodzi, jest w stanie gdzieś tam pomóc i jest dodatkową osobą, która rozumie całą tą zawiłość wytwarzania programowania. Więc to jest niebywały plus.

Minusem tej sytuacji jest to, że Scrum Master w tym przypadku musi bardzo być świadomy tego, w jaki roli występuje. To znaczy czy występuje jako developer, bo oczywiście można łączyć tak swoje role, natomiast w przypadku, kiedy ten Scrum Master się wypowiada, on musi ograniczać, czy w tym momencie jest developerem, czy Scrum Masterem. Minusem jest to, że może dochodzić do pewnych nadużyć stanowiska, to znaczy wiadomo, że wszyscy w Scrumie są równi i jesteśmy jednym zespołem, natomiast wiadomo, że jeżeli ktoś ma osobną rolę, no to jego zdanie być może wpływać tak, że te decyzje będą forsowane troszeczkę od góry. Więc tu jest takie zagrożenie, żeby Scrum Master wiedział w jakiej roli wstępuje.

I to jest ta część techniczna. Jeżeli mówimy o Scrum Masterze nietechnicznym, no to odwrotnie. Minusem jest to, że nie pomoże zespołowi, nie powie, słuchajcie, no, robicie to źle i powinniśmy jakieś przyjąć inne założenia. Natomiast plusem jest fakt, że wcale nie musi, bo rola Scrum Mastera jest zupełnie inna. On powinien patrzeć na zespół jako na całość i szukać tych mini-usprawień.

Plusem również jest to, że nie rozumiejąc, co tam w środku jest technicznie, patrzy na produkt okiem użytkownika końcowego. To znaczy, on wcale nie musi wiedzieć, w jakim to jest w frameworku. Tak samo jak użytkownika końcowego nie interesuje technologia. Czy to jest w takim frameworku, czy w takim języku, to ma po prostu działać. Więc nawet próbując się dowiedzieć, jak to działa, to troszeczkę zmusza zespół do przyjęcia takiej perspektywy okiem właśnie użytkownika końcowego, nie? I myślę, że to jest plus.

Wiadomo, że większość firm preferuje, żeby Scrum Master był jednak osobą techniczną. Natomiast osobiście uważam, że dobry Scrum Master nie musi być. Może, ale nie jest to wymóg konieczny, bo jego rola jest nieco inna.

Bartek Śliwa: Jasne. Nawiązałeś też do łączenia tych odpowiedzialności i wspomniałeś przypadek, w którym Scrum Master jest też na przykład developerem. Wydaje mi się, że wtedy musimy mieć mocno dojrzały zespół, a niestety życie pokazuje, a przynajmniej tak z moich obserwacji wynika, że bardzo często organizacje chcą ciąć koszty i przez to wrzucają odpowiedzialność Scrum Mastera na dewelopera, który niekoniecznie wie, jak tą rolę pełnić i dochodzi wtedy do wypaczeń.

Michał Pięciorek: Tak jest. To są te małe odstępstwa. W tych przypadkach Scrum nie daje tej pełnej wartości, którą mógłby dawać. No bo faktycznie jeżeli developer robi to przy okazji, no to to nie jest jego głównym zainteresowaniem, głównymi obowiązkami. Więc dochodzi do jakichś, być może…

W tym momencie ten developer może nie zauważać tych marnotrastw, które się pojawiają po drodze, ale też się zgodzę, że tak to widzę w niektórych przypadkach. Dlatego są te trzy role i każda jest odpowiedzialna za coś innego mimo wszystko.

Bartek Śliwa: No właśnie, ale wszystkie trzy role są odpowiedzialne za to, żeby jednak dostarczać największą wartość. I właśnie czym tu jest ta wartość? Bo ona ma sporo definicji, pewnie każdy ten termin rozumie inaczej i pewnie my możemy sobie teraz wymyślić jakiś nasz termin i ktoś się z nim zgodzi, bądź nie, ale spróbujmy sobie to ubrać w jakiejś ramy. O co chodzi z tym maksymalizowaniem wartości przy użyciu Scruma?

Michał Pięciorek: To znaczy jakie są korzyści co do korzystania, to o to ci chodzi, czy jaka jest definicja wartości, potem byśmy mogli…

Bartek Śliwa: Zintepretuj jak chcesz.

Michał Pięciorek: OK, to wydaje mi się, że przewagą stosowania Scruma jest to, że pozwala bardzo szybko zweryfikować pewne założenia biznesowe. Bo OK, wszystko wygląda pięknie na papierze i w Excelu. Jeżeli firma chce stworzyć jakiś produkt, no to wiadomo, że na etapie prezentacji i ustalenia celów w pokoju wszystko jest świetne. Natomiast może okazać się, że finalnie, no, możemy stworzyć produkt, który nie do końca odpowiada na potrzeby użytkowników.

Teraz jeżeli pracujemy w Scrumie, to wcale nie musimy spędzić całego roku na development i dopiero na samym końcu okaże się, że hej, w sumie tego produktu nikt nie chce. Więc, no to są oszczędności budżetowe również i czasowe i wysiłkowe. Przewagą Scruma jest również to, że nie wymaga tego, aby produkt stworzyć od razu w całość i dostarczać od razu gotowy produkt. Możemy stworzyć część oprogramowania, które działa i mierzyć na bieżąco czy spełnia oczekiwania, czy trafia do klientów, czy nasze założenia były słuszne. Jeżeli są słuszne świetnie idziemy dalej. Po każdym sprintie czyli po każdym etapie dobudowujemy kolejną działającą funkcjonalność i budujemy to oprogramowanie krok po kroku. To troszeczkę tak jakbyśmy budowali zamek z klocków. Mamy klocki, chcemy zbudować zamek, ale nasza wizja może się z czasem zmienić. Jeden element możemy dodać, jeden możemy odmienić i to pozwala jakby dopasować ten produkt czy cokolwiek tworzymy pod potrzeby.

Jeszcze miałem jedną myśl. Zgodzisz się z tezom, że jeśli nie zaangażujemy tych naszych interesariuszy, tego biznesu, to używanie scruma jest bez sensu?

Bartek Śliwa: Myślę, że tak, bo największą wartością jest właśnie ten bliski kontakt, czy to właśnie z interesariuszami, czy przede wszystkim z, no, użytkownikiem końcowym, bo okej, interesariusze są bardzo ważni, ale najważniejszy jest zawsze klient, no bo to dla niego to robimy. A jeżeli klient, jeżeli trafiamy w potrzebę i spełniamy te potrzeby, no to interesariusz również będzie zadowolony. I jeżeli nie mamy tej pętli zwrotnej, tej informacyjnej, słuchajcie, czy idziemy w dobrym kierunku, czy to, co robimy ma sens, no to tracimy jedną z najważniejszych wartości, bo to właśnie o to chodzi, żeby te pętle zwrotne były krótkie, szybkie i treściwe.

Michał Pięciorek: Czyli mówiąc prosto, taki prawilny Scrum niejako powinien wymuszać na nas tą tak zwaną pętlę inspekcji, adaptacji, czyli oglądania tego, co zespół dostarczy przez potencjalnych odbiorców tego produktu. Dokładnie tak.

I no, też trzeba być całkowicie szczerym. Nie zawsze wszelkie decyzje, bo teraz oczywiście zachwalamy Scrum’a, natomiast nie zawsze wszelkie decyzje będą słuszne. No i teraz OK, jeżeli coś okaże się.., popełnimy jakiś błąd, normalna rzecz zdarza się, to w tym momencie nie musimy iść dalej i brnąć w tych błędnych założeniach, tylko od razu ucinamy, “słuchajcie, to nie działa”, wyrzucamy i z każdą pętlą, z każdym sprintem uczymy się coraz bardziej klienta, wymagań, więc ten finalny wynik jest znacznie lepszy i odpowiada na konkretne potrzeby, a nie na to, co sobie wymyśliliśmy w zamkniętym biurze, nie?

Bartek Śliwa: Czyli reagowanie na zmiany ponad podążanie za planem.

Michał Pięciorek: Dokładnie tak. Jak nie wiem, Manifest Agile.

Dobra, Michał, czy Scrum jest odpowiedzią na wszystko? Oczywiście, że nie. Chciałbym, żeby tak było jako Scrum Master. Oczywiście, mógłbym zachwalać, natomiast oczywiście, że nie. Ja też nie jestem takim… tradcjonalistą. Tak, tak, że powiem, że skramy zawsze i wszędzie najważniejsze. Oczywiście, że nie, podejdźmy do tego zdrowo, rozsądkowo. Wszystko zależy jaka jest potrzeba, to znaczy co musimy zrobić, bo jeżeli, na przykład, jeżeli chcemy zbudować dom, budowaliśmy już któryś z kolei dom, to wiemy, co trzeba zrobić, jakie są etapy, co następuje po sobie, jaki jest szacowany koszt. No to w tym momencie, jeżeli mamy tego typu projekty, które są powtarzalne, przewidywalne i już je robiliśmy, to wsadzanie tam Scruma jest totalnie bez sensu i przerost formy nad treścią.

Scrum sprawdza się wtedy, kiedy nie wiemy jaki będzie finalny wynik. Te założenia mogą się zmieniać i dlatego w IT bardzo szybko, że tak powiem, sprawdza się, no bo pewne założenia pierwotne po weryfikacji mogą ukazać się nieakuratne, więc też pozwala dostosować się gdzieś tam wystąpiły po czasie. Być może klient się zmienił albo zupełnie inną strategię chce podjąć, więc tak jak mówię, nie musimy tworzyć całego produktu od razu i się na końcu dowiedzieć, “hej, w sumie to w sensu”, tylko robimy to krok po kroku i tutaj sprawdzamy, czy wszystko gra.

Bartek Śliwa: No właśnie, jakbyśmy mieli w odniesieniu do IT, zastanowić się jakiego typu produkty cyfrowe podchodzą, nadają się do tego, by realizować je w Scrumie, bo zakładam, że jakiś prosty landing page już niekoniecznie.

Michał Pięciorek: Nie, myślę, że to w produktach, może nie że innowacyjnych, ale.. To znaczy na pewno też. Ale w takich produktach, gdzie jest bardzo dużo założeń, to warto…

Bartek Śliwa: Założeń, a nie pewników, to jest chyba ten klucz.

Michał Pięciorek: Tak jest. Kiedy tworzymy jakiś zupełnie nowy system i tak jak wspomniałem, założenia w zamkniętym biurze na prezentacji mogą być świetne. Natomiast później weryfikujemy to z rynkiem, no i tutaj decydujemy czy to jest dobry pomysł czy też nie. Jeżeli nasz pomysł na start-up, który oczywiście zawsze jest świetny, po dwóch, trzech iteracjach okaże się, że jednak może nie do końca trafiliśmy w potrzeby klienta, to lepiej uciąć temat, albo zmienić założenie na samym początku niż brnąć i przepalać ogromne budżety na to i dowiedzieć się o tym po roku. Więc Scrum świetnie sprawdza się w takich projektach niepewnych, gdzie jest dużo zmiennych, dużo założeń.

Bartek Śliwa: No właśnie, z tą niepewnością, bo wiesz, jeśli wykonaliśmy książkę, która jest dokumentacją, pełną założeń, no to taki C-level albo właśnie, panowie dyrektorzy, osoby odpowiedzialne za powstanie danego produktu, oni czują się pewnie, że oni im wiedzą, czego oczekują i że to jest na pewno to. No i właśnie jak ich wytrącić z tego poczucia, z tego przekonania, że faktycznie wszystko pójdzie zgodnie z książką, którą napisali, którą skrupulatnie przez pół roku przygotowywali?

Michał Pięciorek: Myślę, że tutaj takim czynnikiem na pewno będzie aspekt finansowy. To znaczy, jeżeli wyjdziemy z częścią produktu do klientów i okaże się, że nie ma zapotrzebowania i jednak te wyniki nie są tak świetne jak na zielonych grafach. Ale o tym się przekonają dopiero po wydaniu. A development będzie trwał 2 lata.

No właśnie dlatego dobrą praktyką jest wydawanie jak najczęściej, możliwie jak najczęściej, żeby nie dawać gotowego produktu od razu na rynek, tylko dostarczać go inkrementalnie rok po kroku. Bo już może się okazać, że na początku nasze założenia są złe i w tym momencie nie ma sensu przepalać dalszych budżetów. Więc Scrum eliminuje marnotrawstwa, również te finansowe. Tak jak mówię, no, możemy, jeżeli nasze założenia są dobre, możemy w to brnąć dalej i OK, super, tworzymy, dokładamy tą cegiełkę, natomiast jeżeli są złe, no to ten aspekt finansowy dla C-managementu będzie przekonujący.

Ale również… ScrumGate tego nie posiada, natomiast istnieje taki dokument jak Evidence Based Management. To jest taki dokument, który jest uzupełnieniem trochę Scrum’a. Właśnie w tym kontekście takim analitycznym. Może nie będziemy wchodzić w głąb, ten dokument też nie jest duży, ale posiada tam 30, a może więcej, myślę, że więcej, różnych mierników, które pozwalają nam zmierzyć i wyciągnąć te konkretne dane. I tak jak mówię, nie ma sensu wykorzystywać wszystkich mierników, bo to jest mierzenie dla mierzenia. Może nie wszystkie są istotne. Natomiast wybrać te kluczowe, które dadzą nam informacje, które będą nam pomocne i pomogą w podejmowaniu decyzji.

Bartek Śliwa: Wiesz co, ja bym jednak podrążył ten Evidence-Based Management. Też jestem fanem tego frameworku. Mamy tam cztery obszary, w których mierzymy. Pamiętasz?

Michał Pięciorek: Tak, Unrealized Value, czyli wartość niezrealizowana. Ten nasz potencjał do tego, co jeszcze możemy tam dostarczyć.

Bartek Śliwa: Tak jest.

Michał Pięciorek: Mamy Current Value, czyli to, co obecnie dostarczamy i w ogóle w którym miejscu się znajdujemy, czyli to, co dostarczamy w chwili obecnej.

Bartek Śliwa: Mamy również Ability to Innovate, czyli taką umiejętność dopasowania się organizacji do innowacji, do wytwarzania tych pomysłów nowych, oraz mamy również Time to Market, czyli to jest… ona mówi o tym jak szybko jesteśmy w stanie dostarczyć pomysł, ideę, konkretny produkt, w jakim czasie jesteśmy w stanie dostarczyć tą wartość.

I wtedy też możemy sprawdzić, czy ten nasz Scrum działa, czy my faktycznie tą wartość dostarczamy. Tak jak powiedziałeś, istotne jest, żeby nie brać wszystkich mierników, tylko wybrać sobie kilka konkretnych, ale jednak mierzyć się cztery obszary.

Michał Pięciorek: Dokładnie tak. To jest dodatek. Scrum Guide tego nie mówi, natomiast powstały różne uzupełnienia i takie pojęcia. Wyższe levele Scrum’a już o tym traktują troszkę.

Bartek Śliwa: Trochę tak.

Dobrze, Michał. Mam takie pytanie na zakończenie, albo prośbę, żebyś podzielił się czymś, co cię ostatnio zainspirowało. Może być książka, może być film, jakaś aktywność, może jakaś zmiana w życiu.

Michał Pięciorek: Wiesz co, ostatnio, co do aktywności, to przez całe życie myślałem, że nie lubię gór. Na zasadzie zawsze kojarzyło mi się to ze smutnymi rajdami w szkole, gdzie chodziło się cały dzień i po prostu człowiek był zmęczony i żadnej radości z tego nie było.

Natomiast ostatnio odkryłem, że to jest świetne odcięcie się od tej takiej naszej szarej codzienności. Miałem tego pecha, tzn. nie miałem osoby, która by mi to wcześniej pokazała, bo raczej nie chodziłem po górach, jak byłem młodszy, raczej miałem złe skojarzenia. Pokazano mi, że to jest zupełnie coś fascynującego, bardzo polecam. Może nie dla każdego, ale to ostatnio się u mnie zmieniło, że, kurczę, chyba będę częściej jeździł. Zwłaszcza, że tu z południa Polski mamy blisko. Nawet sobie nie zdawałem sprawy i myślę, że to taka ostatnia zmiana, więc bardzo polecam.

Bartek Śliwa: W jakim miejscu byłeś?

Michał Pięciorek: W Karpaczu.

Bartek Śliwa: Ja w Karpaczu też byłem, ale w hotelu. Też się dobrze bawiłem.

Dobrze, Michał. Dzięki za dzisiejszą rozmowę. I zapraszamy na kolejny odcinek podcastu Euvic Talks.