Paulina:
Cześć to Paulina Kacprzak!

Aga:
I Aga Naplocha. W podcaście Design Practice rozmawiamy o praktycznych stronach pracy na styku technologii i designu, zarówno od strony projektowania, jak i zarządzania.

Paulina:
W tym odcinku porozmawiamy o tym, czym jest Agile, jak wpływa na relacje w zespole, na czym polega praca Agile Coacha lub Scrum Mastera i jak realizować się w duchu niezależności i wolności.

Aga:
Naszą gościnią jest Joanna Toboła-Pieńczak - specjalistka od przeprowadzania zmian i wdrażania Agile do codziennego życia. Jest twórczynią Slow Talks i podcasterką. Wcześniej pracowała jako Agile Coach w dużych organizacjach, a obecnie wiedzie życie digital nomadki i przedsiębiorczyni online.

Paulina:
Notatki i linki wymienione w tym odcinku znajdziecie na naszej stronie: designpractice.pl/036. A sponsorem dzisiejszego odcinka jest the:protocol, czyli serwis z konkretnymi ofertami pracy dla branży IT. Sprawdźcie the:protocol.it.

Aga:
Cześć Asia!

Paulina:
Cześć Asia!

Joanna:
Cześć!

Paulina:
Powiedz nam na początek, jaką książkę ostatnio przeczytałaś?

Joanna:
Ja ostatnio zaczęłam słuchać książek, co jest dla mnie nowością, bo wydawało mi się, że to... że nie jestem w stanie tego zrobić, żeby skupić się na słuchaniu i nie wiem, równolegle chociażby spacerować. Ale uczę się tego i słuchałam książki „Slow Sex. Uwolnić miłość” Marty Niedźwieckiej i Hanny Rydlewskiej. Jest tam bardzo dużo wątku dotyczącego świadomości, a to jest coś, co na maksa mnie kręci i w różnych kontekstach lubię to zgłębiać. Uważam, że to jest taka obowiązkowa pozycja dla każdego.

Kim jest Joanna Toboła-Pieńczak?

Aga:
Do odsłuchania. Super, to zalinkujemy! Asia, pewnie wiele osób Cię kojarzy już z Internetu, z Instagrama. Hahaha! Ale nie wszyscy wiedzą jaka jest Twoja przeszłość w IT, więc jakbyś mogła nam opowiedzieć kim jesteś, co robiłaś i co robisz aktualnie.

Joanna:
Dobra, to jest bardzo ciekawe pytanie ze względu na to, że jak ja sobie obserwuję, jak zadaję je innym, to często definiuje nas praca. Ja też w przeszłości tak siebie definiowała, że kiedy ktoś się mnie pytał co robię, czym się zajmuję, to jeszcze tak trochę przekornie mówiłam, że podróżuję, a w wolnych chwilach pracuję w IT. Potem na przestrzeni czasu okazało się, że jak przestałam pracować w tym IT, to trochę zagubiłam swoją świadomość, więc jednak ta praca była mocno definiujące mnie. I teraz jak ja sobie to układam w głowie, to mówię, że zajmuję się takim uważnym i świadomym doświadczaniem życia. I robię to po prostu przez różne role, które pełnię, no bo każdy z nas wchodzi w swoim życiu w różne role. I z jednej strony jestem Joanną kochającą niezależność, życie pod palmami, kawkę speciality, ruch na świeżym powietrzu, ładne wnętrza. Taka ja, która po prostu lubi doświadczać życia, cieszyć się drobnymi przyjemnościami, budować takie bliskie relacje. Jestem żoną, jestem partnerką, jestem przyjaciółką. Określam się też jako digital nomadka, żeby trochę zawężać, bo od trzech lat żyję świecie, mieszkam w różnych miejscach, z tych miejsc pracuję. A zawodowo właśnie te trzy lata temu podjęłam decyzję, żeby spróbować takiego życia po swojemu, zbudować swoją działalność, swój biznes. Chociaż wcale podejmując tą decyzję, tego nie miałam w głowie. Miałam wtedy taką potrzebę wyjechania w świat, pomieszkania gdzieś dłużej, bo jak wspomniałam, były te podróże u mnie bardzo wysoko na liście moich priorytetów, ale zawsze czułam niedosyt, że nawet jak byłam miesiąc w Azji, to czułam, że ja tylko tak sunę po powierzchni, że nie jestem w stanie doświadczyć tych miejsc. No a że kocham słońce, palmy jakoś zawsze od dzieciństwa siedziały mi w głowie, to bardzo chciałam spełnić takie marzenie o zamieszkaniu w ciepłym, egzotycznym miejscu i zobaczeniu, zweryfikowaniu hipotezy czy to jest dla mnie, czy to nie jest tylko wyobrażenie, że to jest fajne na wakacje, na krótki czas, a jednak praca no niekoniecznie sprawdzi się z takiego miejsca.

No ale dobra, jakby co było przed tą moją erą digital nomadki? Ja po studiach dość szybko trafiłam do Allegro i trafiłam tam na staż do centrum Agile, i miałam się uczyć właśnie czym jest Agile, o którym też dzisiaj będziemy rozmawiać. Jak to jest, jak zespoły pracują w Scrumie. I powiem Wam, że ja tam poszłam z takim przekonaniem, że ten Scrum i to zwinne podejście to jest jakiś bullshit z tego co uczyłam się na studiach. I nawet tak na rozmowie tej stażowej powiedziałam, że ja chcę przyjść na ten staż, bo chcę zweryfikować, czy to faktycznie działa. Jak to jest, kiedy nie trzeba planować długoterminowo, bo mam wrażenie, że od zawsze nas uczą, że musisz zaplanować, musisz mieć wszystko gotowe. Takie przekonanie ze szkoły, które zawsze budziło we mnie dyskomfort. Czyli dostajesz zadanie, realizujesz samodzielnie to zadanie. W zasadzie zapytanie o pomoc czy poproszenie o feedback jest nie na miejscu, no bo Ty masz samodzielnie to wykonać, w dodatku wpasować się w klucz, którego Ty nie znasz, ale ktoś go stworzył z jakiś powodów. Oddajesz pracę, a jeżeli popełniłaś błąd na początku w założeniu, no to w zasadzie cała praca jest do kosza i te wszystkie godziny, które spędziło się na tworzeniu tej pracy. I to mnie zawsze uwierało. No i nagle się okazało, że można pracować inaczej. I potrzebowałam zrozumieć, o co chodzi. Przekonałam osoby, które szukały kogoś na stałe, żeby akurat mnie na ten staż wzięli. No i zaczęłam przyglądać się temu, jak pracują w Allegro zespoły scrumowe. Allegro wtedy było taką firmą wiodącą na rynku polskim, jeżeli chodzi o wdrażanie zwinności Agile'a. Po stażu zaproponowano mi, że mogę zostać i ja nie przygotowywałam się do pełnienia konkretnej roli. Wcześniej też skończyłam Informatykę i Ekonometrię na Uniwersytecie Ekonomicznym w Poznaniu, więc ten background techniczny też miałam, aczkolwiek programowanie, no nie czułam go. Fajnie było wiedzieć, jak to wygląda, ale niekoniecznie była to ścieżka, którą chciałam podążać. No i po prostu ścieżka scrum masterska jakoś tak od razu we mnie wzbudziła mocne emocje, bo praca z ludźmi, bo zarządzanie procesem, bo właśnie takie inne podejście do tej pracy, bo stawianie na mądre ruchy, na mądre decyzje, zamiast po prostu wykonywanie ślepo jakiegoś planu, bo ktoś założył go pół roku czy rok wcześniej. No i tak to się zaczęło. Byłam kilka lat w Allegro, właśnie będąc Scrum Masterką, Agile Coachką. Potem zapragnęłam zmienić po prostu miejsce zamieszkania i to w zasadzie był taki impuls po to, żeby mieć większe lotnisko bliżej. Czyli z Poznania przeniosłam się do Warszawy, a wraz z tym stwierdziłam, że no dobra, no, skoro zmieniam miejsce zamieszkania, to czemu by nie zmienić pracy? Bo ten temat pracowy nigdy nie był dla mnie jakiś taki mocno przywiązując. I to chyba była też taka myśl, która mi pomagała fajnie funkcjonować, bo ja sobie zawsze myślałam: „Działaj w zgodzie ze sobą, mów to, co myślisz”, co też jest bardzo ważne w tej roli Scrum Mastera czy Agile Coacha. Pewnie dalej to wyjaśnię dlaczego, ale miałam taką myśl przyświecające, że chcę w pracy działać w zgodzie ze sobą. Chcę tą pracę mieć na takich swoich wartościach, fundamentach. Jeżeli coś jest bardzo wbrew temu, to ja po prostu znajdę inną pracę lub jeżeli mój pracodawca stwierdzi, że to co ja mu oferuję, to jednak nie jest to, czego on chce i postanowi się ze mną pożegnać, to też jest okej. Bo to funkcjonowanie w zgodzie ze sobą to myślę, że po prostu od dzieciństwa patrząc na to jak się szybko buntowałam i jak bardzo chciałam robić rzeczy inaczej, mi przyświecało. No więc trafiłam do drugiej organizacji do Pracuj.pl, no i tam zaczynałam jako właśnie Scrum Masterka. Mogłam tą wiedzę ze wcześniejszego miejsca przenosić na ten grunt nowej organizacji i dosyć szybko też poczułam, że bardzo lubię uczyć innych i gdzieś te kompetencje liderskie, no jak się okazuje test Gallupa też o tym mówi, że u mnie w top 5 jest ten leadership zawarty. Więc to było coś, co też jako kierunek mojego rozwoju mocno mnie ciągnęło. No i dostałam taką szansę. Zostałam liderem zespołu Scrum Masterów, a później Product Development Managerką i pod tą nazwą kryje się to, że po prostu współpracowałam z zespołami. Prowadziłam w takim kulminacyjnym momencie trzy zespoły, których po prostu byłam przełożoną i jakby zawsze mówiłam, że moją misją jest to, żeby budować zaangażowanie wśród ludzi, aby oni jarali się pracą, a dzięki temu mieli motywację wewnętrzną do tego, żeby robić no zajebiste rzeczy, żeby fajnie wytwarzać oprogramowanie i dawać ten wartościowy produkt dla klienta końcowego. No i to robiłam 7 lat, łącznie to moje życie w tym świecie IT. I nie wiem, czy słychać jak o tym mówię, sama się tak wewnętrznie śmieję, bo ja bardzo to lubiłam. Nie jestem z tych case'ów, że miałam wypalenie zawodowe albo moja praca tak mnie przytłaczała, że ja rzuciłam wszystko i wyjechałam mieszkać na Zanzibarze.To zupełnie nie ten case, po prostu ta moja druga strona, te podróże, ta chęć eksplorowania świata, doświadczania, testowania tak mocno zaczęła się odzywać, że postanowiliśmy z moim mężem spróbować. Ten eksperyment był trochę inaczej zaplanowany, bo to jeszcze było przed czasem pandemii i w zasadzie ja planowałam w marcu 2020 złożyć wypowiedzenie i w wakacje mieliśmy wyruszyć spełniać nasze marzenia. No to, co się zdarzyło w 2020 roku, musiało zweryfikować nasz plan. My te marzenia na chwilę odłożyliśmy. No bo skoro nie możemy w zasadzie ruszyć się nawet z domu, to co tu mówić o zamieszkaniu na Bali, Zanzibarze czy jakimś innym egzotycznym miejscu. No ale jak tylko pojawiła się ta luka, że świat jednak się w jakiś sposób otwiera, to dosyć szybko stwierdziliśmy, że ej zaryzykujmy. W najgorszym wypadku po prostu wrócimy.

Życie digital nomadki

Paulina:
Jeszcze się na pewno zapytamy o właśnie o tą podróż, o tą przeprowadzkę i o to jak stosujesz Agile teraz, bo na pewno Twoja praca miała duży wpływ na to, jak teraz funkcjonujesz. Ale właśnie najpierw powiedz, co teraz robisz po tej przeprowadzce i po staniu się digital nomadką?

Joanna:
No właśnie, bo tak jak powiedziałam, moją motywacją nie było „wyjeżdżam i zaczynam szukać swojej nowej ścieżki zawodowej czy właśnie swojej działalności” tylko „dostałam taki prezent w postaci mam czas, żeby w ogóle spojrzeć inaczej trochę na to, jak żyję, co robiłam, co chcę robić”. To była taka, ja uśmiecham zawsze, wymiana, bo kilka lat temu mój mąż poszukiwał swojej ścieżki właśnie, jak się przeprowadziliśmy do Warszawy. Chciał coś zmienić i wtedy umówiliśmy się, że po prostu niech on sobie weźmie pół roku i pobłądzi, i nie skupia się na robieniu rzeczy, na zarabianiu pieniędzy, tylko niech da sobie przestrzeń na właśnie te eksperymenty, poszukanie siebie. No i te pół roku bardzo okazało się cenne patrząc na to, jak dalej się potoczyła jego ścieżka. No i tu się role odwróciły. W sensie on powiedział:  „Dobra, ja już wiem w jakim kierunku chcę iść, ja już mam ugruntowaną pozycję. Teraz ja biorę na siebie ciężar zarabiania pieniędzy, utrzymania naszej rodziny, a Ty po prostu daj sobie ten czas. Daj sobie spojrzeć tak w głąb siebie”. Bo to też jest ciekawe, że wyruszaliśmy z misją podróżowania, a de facto ja po tych trzech latach stwierdzam, że to była taka mocna podróż do środka siebie, żeby zauważyć jakieś swoje przekonania, schematy w jakich funkcjonowaliśmy, to co naprawdę jest dla nas ważne. No i jak dostałam tą przestrzeń, no to faktycznie zaczęły się pojawiać pomysły. Ja nie miałam.. miałam ten backup, wiecie, jakby co, to wrócę do tego, co znałam, może nawet do tej firmy, którą znałam, a może do innej. No możliwości w branży IT jest sporo. Uważam, że jestem bardzo dobra w tym, co robiłam. Dlatego jakoś nie miałam takiego poczucia, że o rany, rezygnuję z pracy, co potem? Więc ten backup z tyłu głowy był, a z drugiej strony miałam dużą potrzebę tworzenia. I tak narodził się właśnie w Zanzibarskim domku na plaży, więc sceneria bardzo sprzyjała temu, żeby mózg zaczął myśleć w inny sposób, narodził się projekt Slow Talks, który jest takim moim autorskim projektem, którego misją jest właśnie budowanie takiej samoświadomości, pokazywanie różnych perspektyw na życie, praca z przekonaniami. No i z jednej strony jest mój podcast, w którym albo nagrywam solówki, albo rozmawiam z gośćmi na przeróżne tematy biznes, podróże, właśnie ta praca z tymi przekonaniami, pokazywanie ścieżki. No bo zazwyczaj w sieci widzimy wierzchołek góry lodowej, a nie widzimy tego wszystkiego, co jest pod spodem. I lubię pokazywać, że za sukcesami, które widzimy, stoi też bardzo dużo pracy. Stoją też jakieś cienie, stoją też jakieś problemy, których no patrząc tylko na kilka sekund podczas przeglądania Instastories, po prostu możemy nie widzieć. Więc prowadzę podcast i to jest takie moje oczko w głowie. Tworzę produkty rozwojowe, które właśnie mają zachęcać do tej pracy nad sobą. I ja bardzo wierzę, że te narzędzia i te rzeczy, których nauczyłam się pracując w IT, można przykładać do codziennego życia. Więc dzielę się tymi narzędziami, pokazuję, jak coś, co pomaga w wytwarzaniu oprogramowania może pomóc w tworzeniu produktu, jakim jesteśmy my sami, jakim jest nasze życie. Żeby tak się trochę zdystansować, spojrzeć z innej perspektywy. To są rzeczy pomagające w porządkowaniu myśli, wyciąganiu wniosków, poszukiwaniu swojej tożsamości. Łączę to właśnie z elementami psychologii, coachingu, które są bardzo mocno w takiej sferze moich zainteresowań i jakiegoś rozwoju, dokształcania się. Prowadzę aktywnie social media, których właśnie tam... to jest taki core zachęcania, pokazywania tego, co się dzieje. No ale jest też druga strona zawodowej części, gdzie myślę mocno te rzeczy projektowe, które wykorzystywałam w świecie IT wybrzmiewają, no to prowadzę właśnie z mężem wspominanym nieraz, zawsze się śmiejemy: „Dobra, mówiłaś o mnie w podcaście? To tak...”.

Aga:
Hahaha! Pozdrawiamy Tomka!

Joanna:
Tak, Tomek jest nieodłączną... jesteśmy partnerami, prowadzimy razem biznes, mieszkamy razem w tych wszystkich miejscach, więc nie da się ukryć, że jest mocną częścią mojego życia. Prowadzimy studio projektowe, ilustracyjne, właśnie bazujące na ilustracjach Tomka, więc ja jestem tą Project Managerą, która zarządza tym wszystkim, a wtedy Tomek może skupić się na tej części artystycznej, kreacji. I to w zasadzie są takie nasze dwa cory działalności. No jeszcze hobbistycznie prowadzimy markę odzieżową, która jakieś realizuje nasze potrzeby spełniania się kreatywnie, jakieś marzenia, które kiedyś powstały. Mamy też swoją kawkę, więc dużo obszarów takich wydawałoby się z różnych dziedzin, aczkolwiek one bardzo mocno spajają po prostu nasze wartości i to, jak żyjemy. Aha, no i ciągle jestem w świecie IT, bo robię też projekty dla firm IT, tak Wy też jestem felietonistą dla the:protocol i to jest to fajne połączenie ze światem IT, że mogę przemycać jakąś moją wizję wykorzystywania tego, co działa w IT w tym codziennym życiu. Tworzę teraz, jestem jedną z twórczyń kursu dla Product Managerów, więc cały czas gdzieś tam w kuluarach w tym świecie IT funkcjonuję.

Interesuje Cię praca Product Managera? Sprawdź 014 odcinek naszego podcastu! 🎧

Aga:
Super, czyli ciągle jeszcze gdzieś tam jedną nogą w tym świecie. Haha...

Joanna:
Tak, bo szkoda. Wiesz, ja w pewnym momencie nawet chciałam się od tego odcinać i takie miałam, że dobra to jest moja przeszłość, ale to jest tak integralna część mnie. Ja w to tak wierzę i tak to lubię, że no w zasadzie projekty, które my prowadzimy, prowadzimy tak, jakbym je prowadziła, pracując w korporacji. Nasza marka odzieżowa, która miała jakby reaktywację w zeszłym roku, właśnie powstawała w duchu MVP. Totalnie opieraliśmy właśnie na zasadach Agile'a naszą współpracę. Prowadziliśmy retrospekcję z naszymi wspólnikami, bo robimy to w cztery osoby. I ja, każdy z nas ma jakieś odpowiedzialności, ja jestem osobą od procesu i zarządzania tym, żeby było efektywnie, zwinnie i żeby skupiało się to na wartości dla klienta.

Co to jest Agile i Scrum?

Paulina:
No właśnie. Zapytamy Cię o to jeszcze, jak wykorzystujesz Agile teraz w swoich aktualnych projektach i w swoim życiu, ale wróćmy jeszcze do wytłumaczenia takich podstaw. Powiedz, co to w ogóle jest ten Agile? Co to jest Scrum? Czy to są tożsame pojęcia? Z czym to się je?

Joanna:
Dobra! Definicji Agile'a, jak sobie wpiszecie, będzie sporo. I ja mam taką swoją, gdzie mówię o tym, że dla mnie to jest taki zwinny sposób myślenia, bazujący na tym, że stawiamy klienta w centrum naszej uwagi i wszystkie ruchy, które robimy, wszystkie decyzje, które podejmujemy skupiają się na dostarczeniu wartości dla tego klienta, na jego zadowoleniu. Tego klienta możemy sobie przeróżnie zdefiniować i takimi fundamentami naszego działania jest proces inspekcji i adaptacji, i to, że zmiana jest nieuniknioną częścią naszych działań. Czyli to reagowanie na zmiany zamiast podążania za planem, jest takim kluczowym elementem działalności. No i żeby tak trochę możne rzucić rys historyczny, skąd w ogóle jakby ten Agile zagościł. No bo on w pierwszej kolejności zagościł w świecie wytwarzania oprogramowania, bo w 2001 roku grupa osób pracujących w ramach wytwarzania oprogramowania spotkała się i wyrzuciła taką frustrację na to, jak wygląda wytwarzanie tych produktów i że tam jest bardzo dużo planowania, bardzo dużo skupiania na dokumentowaniu tego procesu, na właśnie takim procesie, który niekoniecznie stawia w centrum uwagi tego klienta, że gdzieś po drodze przez tą biurokrację, przez to sztywne trzymanie się ram, które się kiedyś założyło, gubi się to zadowolenie klienta. A przecież właśnie po to tworzymy produkty. Ja bardzo lubię to, co mówi Kagan i on mówi o tym, że naszym zadaniem jest tworzenie produktów, które pokochają użytkownicy. A wraz z tą miłością przyjdzie sukces. Ta droga jest oczywiście kręta, nie jest nie jest oczywista, ale mając na uwadze to, co może zadowolić tego klienta końcowego, my jesteśmy w stanie dobrze poznać jego potrzeby. Bo on i ten klient zresztą same wiecie, nie zawsze potrafi wyartykułować, czego potrzebuje. Więc my potrzebujemy to zbadać, zauważyć, przeprowadzić gro eksperymentów, zweryfikować sporo hipotez, żeby właśnie dotrzeć do tego, jak nasz produkt ma rozwiązywać problem, który klient końcowy ma. Więc w tej frustracji, że gdzieś w tym wytwarzanie oprogramowania to się zagubiło i powstała właśnie. Powstał Manifest Agile. Manifest składający się z takich czterech wartości 12 zasad. W jaki sposób te osoby uważają, zauważając to, co działa w ich praktykach, w ich pracy, Jak warto wytwarzać to oprogramowanie i te zasady to pewnie gdzieś tam w dalszej części będą się przejawiać, jak będą opowiadać, nawet jak można w tym codziennym życiu sobie Agile zaimplementować. Ale chciałabym zwrócić uwagę na te cztery wartości, bo one już dużo mówią i te cztery wartości wskazują, co w podejściu Agile jest po prostu cenione bardziej od tej drugiej rzeczy. I tu chciałabym uczulić, bo często jest mówione: „Aha, czyli Agile mówi o tym, a tamto jest niewłaściwe”. Nie, chodzi o to, że Agile mówi, że obie te rzeczy są właściwe, aczkolwiek jeżeli mamy decydować, co jest ważniejsze, to bardziej cenimy tą pierwszą wartość. I jeżeli chodzi o ten manifest, to pierwsza rzecz mówi o tym, że ludzie i interakcje są ponad procesy i narzędzia. I to najprościej wytłumaczyć, że jeżeli masz problem, to idź do tej osoby i z nią porozmawiaj albo zadzwoń do niej, patrząc teraz na funkcjonowanie świata IT niż wpadaj w jakieś procedury, niż korzystaj z jakichś narzędzi, które mogą temu pomóc. No bo po prostu my jesteśmy w stanie rozwiązywać problemy najlepiej, kiedy wejdziemy w interakcję, kiedy wykorzystamy feedback, kiedy będziemy potrafili mówić o sytuacjach, a nie o emocjach. Tego też się trzeba nauczyć. Ale wstawiamy tego człowieka, no bo cały czas jesteśmy ludźmi zaangażowanymi w ten proces wytwarzania oprogramowania, więc skoro jest w nim człowiek, to środowisko wytwarzania oprogramowania komplikuje się, ale traktujmy siebie jak ludzi, patrzmy na siebie jako ludzi, twórzmy te relacje, bo one będą wpływać na to, jaki będzie efekt końcowy naszej pracy. Czyli to jest pierwsza wartość Agile'a. Druga: działające oprogramowanie ponad obszerną dokumentacje. No i owszem, dokumentacja musi pewnie powstawać na poszczególnych etapach, chociażby po to, żeby mógł być obieg wiedzy prowadzony, żeby można było wiedzieć, jak ten system jest skonstruowany. Ale nie poświęcajmy nie wiadomo ile energii w to, żeby to wytwarzać, tylko skupmy się na tym, żeby jak najsprawniej, jak najczęściej wydawać działające fragmenty oprogramowania, na bazie których możemy już zbierać feedback i weryfikować, czy my w ogóle idziemy w dobrym kierunku i czy to zadowolenie klienta faktycznie jest. Trzecia rzecz: współpraca z klientem ponad negocjowanie umów. I to fajnie opowiadać o tym w kontrze do tego tradycyjnego, waterfallowego podejścia do wytwarzania oprogramowania. Bo w tym waterfallu, gdzieś na początku naszego wodospadu pojawiał się klient, z którym ok, rozmawiało się, zbierało się te wymagania i potem przez cały proces wytwarzania oprogramowania w zasadzie go nie było. No bo co mu pokazywać, skoro nic nie mamy? Bo najpierw przez X czasu projektujemy, potem piszemy, potem testujemy. Okazuje się, że jesteśmy w dupie, no bo testujemy na końcu, więc wracamy. Dzieje się, czas mija, no i na końcu przychodzimy do klienta, mówimy mu: „Ta dam, oto nasz super projekt”, a klient mówi: „Ale co to jest?” i duża szansa, że rozwijamy się albo z jego oczekiwaniami, albo z jego potrzebami, albo to, co on potrzebował rok temu, już nie jest teraz aktualne. No bo patrząc na to, jak dużo rzeczy zmienia się w naszej codzienności, te potrzeby mogą się nawet zmieniać każdego dnia. Więc tu, w podejściu zwinnym stawiamy na to, żeby jak najczęściej, w zależności od potrzeb, zbierać ten feedback. A żeby zbierać feedback, wracamy do punktu drugiego, czyli działającego oprogramowania i weryfikowania tych naszych założeń, hipotez, kierunków, w których podążamy, czy one są wciąż spójne z tym, co jest ważne dla naszego klienta końcowego. No i czwarta rzecz, o której już wspominałam w kontekście tego fundamentu, czyli reagowanie na zmiany ponad podążanie za planem. I to jest, uważam, dla każdego z nas taka po prostu, o ile to działające oprogramowanie czy współpraca z klientem, trudno tak intuicyjnie od razu sobie wyobrazić w codziennym życiu takim prywatnym, niezawodowym, o tyle no to reagowanie na zmiany ponad podążanie za planem myślę, że jest najłatwiejsze do zrozumienia. No bo ja żyłam kiedyś w czymś takim, że chociażby w naszych podróżach. Planowałam, no bo dzięki planowi optymalizowałam koszty, mogłam w teorii skupić się na doświadczaniu zamiast myśleniu co dalej, ale de facto ja miałam w sobie tyle stresu, czy ten plan wypali. Albo trafiałam do jakiegoś miejsca, które mi się bardzo podobało, ale okazywało się, no że ja zaplanowałam, że tam nie będzie chyba aż tak fajnie, bo następnego dnia rano mamy wyjeżdżać. I więcej było we mnie takiego żalu, że „Boże, jak bym tu jeszcze została”, no ale całe pozostałe dwa tygodnie są już zaplanowane. W zasadzie wiecie co do takiej minuty, że no tu musimy spać, bo rano będziemy odjeżdżać, tu się będziemy przemieszczać, tu jest samolot, że nagle się stawałam więźniarką? Więźniem tego mojego planu, bo zamiast cieszyć się, doświadczać, być otwarta na to, co zastanę, to ja siedząc w Warszawie w styczniu, kiedy jest taka a nie inna aura, wymyślałam sobie, co będzie dla mnie fajne, ale nie dałam sobie szansy na to, żeby zweryfikować to na miejscu i żeby sprawdzić. Czyli ta czwarta zasada, ten core to mocno bazuje na takiej otwartości na zmiany i na tym, że okej, plan warto mieć, ale nie zawężajmy go, nie wsadzajmy siebie do takiego więzienia tego planu, który sprawi, że zamiast czerpać z tego, co jest, czerpać też takie korzyści, my będziemy się tego sztywno trzymać, no bo skoro już zainwestowaliśmy i czas, i pieniądze, żeby ten plan powstał, no to bez sensu z niego rezygnować. A to będzie powodować, że będziemy niezadowoleni, mimo że plan wydawał się super.

Paulina:
A powiedz, czy to jest tak, że tego planu w takim razie się nie robi w podejściu Agile'owym? I jeszcze też chciałam wrócić do tego trzeciego punktu. No bo jeżeli mówisz, że w tym takim tradycyjnym, waterfallowym ujęciu przez rok pracujemy nad produktem i dopiero wtedy pokazujemy go klientowi, a w podejściu Agile'owym jesteśmy otwarci na jego feedback, to z czym przychodzimy do tego klienta? Właśnie z takim trochę zrobionym produktem czy jak to wygląda?

Joanna:
Dobra, to zacznę od tego. Podstawą jest zdefiniowanie kim jest dla nas klient i bardzo często w organizacjach zarówno klient jest wewnątrz, jak i na zewnątrz. I ten klient to nie jest zazwyczaj pojedyncza osoba, dla której coś realizujemy, tylko grupa ludzi, grupa użytkowników albo jakaś firma, dla której robimy jakąś usługę. I my możemy zacząć nawet od zweryfikowania makiet. Możemy zacząć od zweryfikowania hipotezy. Możemy przyjść do klienta, pokazać mu nasz pomysł i powiem to, żeby nie siedzieć w świecie wytwarzania oprogramowania, tylko wyjść na taki troszeczkę bardziej dostępny, tak może to nazwę poziom, to mogę powiedzieć jak my w studio to wykorzystujemy pracując. Czyli jeżeli my... przychodzi do nas klient i mówi, że potrzebuje zrealizować ilustrację, która ma... on sobie wyobraża, że ma się pojawić na trzech wybranych przez niego nośnikach. No to my najpierw pytamy: „Okej, ale co Ty tą ilustracją chcesz uzyskać? Gdzie ona się ma pojawiać? Jakie emocje ma wywoływać?”. Wiecie, próbujemy zrozumieć, skąd powstała ta potrzeba w ogóle w kliencie, że on tą ilustrację chce. Oczywiście może się pojawić ryzyko, że on powie: „Ej, w sumie to faktycznie po prostu chciałem być fajne i mieć ilustrację, ale te cele, które ja mam do zrealizowania, to zupełnie nie jest to”. No i z punktu widzenia biznesu może to nie jest zbyt dobry ruch, bo właśnie tracimy współpracę, o którą klient się starał. No ale naszym celem jest sprawienie, żeby klient dokonał dobrej decyzji i jeżeli my nie jesteśmy tą dobrą decyzją, to dla nas jakby, to my jesteśmy z tym ok. Bo nie chcemy wyprodukować ilustracji po to, żeby wyprodukować ilustrację. No ale załóżmy, że te jego oczekiwania, okazało się, że ta ilustracja może być tym dobrym sposobem i my zaczynamy od nakreślenia scenariuszy. Czyli nie, że teraz siadamy, mieliśmy jednego calla, on nam powiedział, co chce i siadamy, robimy tą ilustrację, wysyłamy mu po dwóch tygodniach gotowy projekt, tylko najpierw nakreślamy scenariusze, dajemy kilka wariantów tych scenariuszy, że on może sobie wybrać. Zbieramy inspiracje, np. robimy mood board, za pomocą którego on może sobie wyobrazić, jakby to mogło wyglądać. Bo to, że my mamy coś w głowie to jest jedno, ale to co klient myśli, nawet jeżeli rozmawiamy, wiecie o tym samym... Ja kocham taki obrazek, gdzie ludzie niby rozmawiają o tym samym, ale każdy ma inną figurę geometryczną w głowie i potem powstaje projekt i okazuje się, że nawet nie spełnia oczekiwania kogokolwiek, bo po prostu gdzieś te wymagania na początku nie zostały dobrze zdefiniowane. I w momencie, kiedy prezentujemy te szkice, nie szkice,  do szkiców zaraz przejdziemy - te scenariusze, klient już zawęża, czyli mówi: „Dobra, słuchajcie! Ja czuję scenariusz B”. I przechodzimy do kolejnego etapu, czyli zarysowujemy mu szkic. Ta ilustracja jest wtedy tworzona ręcznie, jest takim zarysowaniem, jak ta forma może wyglądać, co tam może się dziać, jak te rzeczy z tego scenariusza wstępnego mogą zostać zrealizowane. No i znowu mamy produkt, który... on już widzi go, on już widzi całość. Nie widzi, wiecie, nie ma tej wizji w głowie, tylko my już ją wysyłamy, on ją feedbackuje, dzięki czemu my zaoszczędzamy czas, znowu, na tworzeniu ilustracji już takiej dopieszczonej, gotowej, a potem się może okazać, że to wstępne założenie jednak, znowu rozminęliśmy się. I w momencie akceptacji tego szkicu przechodzimy po prostu do realizacji pierwszej wersji ilustracji, już skolorowany, już tak, jak może wyglądać. I znowu odbijamy na bieżąco, wprowadzamy poprawki tak, żeby wspólnie wypracować ten efekt, bo wtedy angażując klienta, on też czuje, że jest częścią tego procesu, przez co też ta jego chociażby nawet taka zajawka na to, że jest pomysł na to, jak to dalej może wykorzystać, wraca. My budujemy sobie fajną relację i mamy takie współprace, gdzie klienci po prostu do nas wracają ze względu na to jak ten proces wygląda. Więc dokładnie tak samo może wyglądać to w przypadku tworzenia oprogramowania. My nie musimy pójść już z zakodowanym produktem, tylko możemy pójść chociażby z makietami stworzonymi w Figmie, załóżmy, które będą już klikalne. My możemy pójść z kartkami papieru i z rozrysowanym pierwszym jakimś widokiem, nie wiem, naszego portalu, który załóżmy tworzymy. I po to są researcherzy, badacze, badaczki, żeby w taki sposób przeprowadzić tego klienta przez proces, żeby on poczuł, wyobraził sobie, że już tego produktu używa i dał pierwszy feedback, żebyśmy nie kodowali czegoś... No bo wyobraźcie sobie koszt narysowania czegoś odręcznie, a koszt napisania kodu, który zostanie zweryfikowany, przetestowany, odpowiednio opatrzony jakością techniczną tak, żeby nie kumulować długu technologicznego. Koszt jest niewspółmierny. Więc w tym punkcie w zasadzie chodzi o to, żebyśmy myśleli też o tych kosztach, jak najprościej i jak najtaniej możemy zobaczyć czy to, w którym kierunku idziemy spełnia nasze założenia. Jeżeli klient jest wewnętrzny, no to chociażby pracując w Scrumie mamy takie wydarzenie jak sprint review, czyli pracujemy w iteracjach, dostarczając ten produkt. I po każdej iteracji np. trwającej dwa tygodnie, mamy już jakiś fragment działającego oprogramowania i np. możemy zaprezentować klientowi tzw. happy path, czyli tą pomyślną ścieżkę. Nie mamy jeszcze obsłużonych błędów, które mogą wystąpić. Być może ta warstwa UI nie jest taka jak byśmy chcieli, ale już możemy przetestować pierwsze działanie, dostać feedback i udoskonalać nasz produkt. I to myślę a propos punktu trzeciego. Nie wiem, czy Paulina czujesz się usatysfakcjonowana tym...

Paulina:
Tak, tak! Zdecydowanie.

Joanna:
Dobra. A jeżeli chodzi o ten punkt czwarty, gdybyś mogła przypomnieć, o co zapytałaś, bo się zgubiłam.

Paulina:
Ja już sama zapomniałam. Hahaha!

Aga:
Ja tylko chciałam dorzucić, bo mi się tak super skojarzyło, bo w poprzednim odcinku gościłyśmy Bartka Jurkowskiego, który opowiadał o improwizacji i o tym, że trzeba być otwartym na zmiany i też tego warto się uczyć, bo to jest bardzo trudne, żeby nie trzymać się kurczowo planu, więc to się w ogóle pięknie... jest taka klamra. Spina z tym, że Agile mówi, czwarta zasada o tym, że reagowanie na zmiany jest ważne. Więc tutaj jeszcze, że jak ktoś nie słuchał odcinka z Bartkiem, to polecamy!

Sprawdź 035 odcinek podcastu Design Practice z Bartkiem Jurkowskim! 🎧

Joanna:
Super połączenie. No bo właśnie to pokazuje, że to ta umiejętność może przydawać nam się na każdym... w każdej rzeczy w zasadzie, w której robimy. I ja bym to dorzuciła, bo ja bardzo lubię przeróżne modele, teorie no i zgłębiać właśnie to, jak funkcjonuje nasze ciało na poziomie takim i biochemicznym i tym psychologicznym. I dlaczego te zmiany są dla nas takie trudne? Bo zmiany budzą niepewność. Nasz mózg nie lubi wytrącania z czegoś, czego się już nauczył, z czego coś zna. Przez to on w tym naszym takim gadzim mózgu, który gdzieś tam na początku rozwoju się wytwarza, on ma taki mechanizm obronny na te zmiany. Po prostu kiedy pojawia się opcja, że coś musimy zmienić, to on chce nas pozbawić tego dyskomfortu i siebie pozbawić tego dyskomfortu i po prostu pojawia się ten niepokój, stres, jakieś napięcie. No bo nie wiemy, gdzie ta zmiana nas doprowadzi. Dlatego warto przyglądać się tym emocjom, które do nas docierają, kiedy pojawia się ta zmiana. Ja lubię bardzo pytanie „Co najgorszego może się wydarzyć?” albo taki rachunek zysków i strat, że „Dobra, co zyskam tą zmianą, co stracę tą zmianą? Co stracę, jak nie zmienię? Co zyskam, jak nie zmienię?”, żeby tak zobaczyć taki big picture tego wszystkiego i pracować z tymi emocjami. Bo im więcej zobaczymy, im bardziej sobie wizualizujemy... i znowu wizualizacja - bardzo mocna rzecz w podejściu zwinnym w Scrumie, czyli to się znowu nam wszystko łączy. Jak zrzucimy sobie te myśli z naszej głowy, zobaczymy, to nagle się okaże, że te strachy, które tam towarzyszą, może wcale nie są takimi strachami. Albo ten najgorszy scenariusz - prawdopodobieństwo jego wydarzenia jest tak bardzo małe, że w zasadzie dlaczego my się skupiamy na tym najgorszym scenariuszu? Albo na ten najgorszy scenariusz mamy już opcje A, B i C. I to przyjrzenie się temu powoduje, że oswajamy emocje, oswajamy nasz mózg z tą wizją zmiany i niepewność maleje, no bo zbieramy dane. I znowu, to też się łączy. Współpracując na bieżąco z klientem, zbierając feedback, weryfikując nasze hipotezy, zbieramy dane, które obniżają nam niepewność, zwiększają nasz komfort i pewność naszych decyzji. Przez to ta elastyczność na reagowanie się zwiększa. I wracając do tego pytania. To co powiedziałam na początku, to są wartości Agile'a, ten Manifest Agile, ale to nie znaczy, że ta druga część zdania jest wykluczana, bo jak najbardziej dokonujemy planu, tylko ten plan skupia się na krótkim terminie. Długoterminowo dążymy do jakiejś wizji, a nie do konkretnego planu z listą konkretnych tasków, które mają się wydarzyć w danym momencie. I właśnie w Agile'u pracujemy na poziomie tej inspekcji i adaptacji, w zależności też od metody, którą obierzemy, ale tutaj mogę się zaczepić o Scrum'a, który bazuje na krótkich, maksymalnie miesięcznych iteracjach, w którym zamykamy cały proces wytwarzania produktu. Czyli rozpoczynamy taką iterację od planowania i planujemy, załóżmy, ten miesięczny. Chociaż ja pracowałam w firmach, gdzie zazwyczaj funkcjonowały tygodniowe albo dwutygodniowe tzw. sprinty, czyli te iteracje. Zaczynamy sprint od zaplanowania tego, co chcemy zrealizować i jakby w ramach tego planowania odpowiadamy sobie na pytanie „Jaką wartość chcemy dostarczyć dla klienta, co ten sprint ma dać?”. Odpowiadamy sobie na pytanie „Co chcemy zrobić?” i odpowiadamy sobie na pytanie „Jak to chcemy zrobić?”. Czyli tu mamy takie planowanie już bardziej szczegółowe na poziomie tego planowania sprintu, ale nie mamy zaplanowanego tego, co szczegółowo zrobimy za pół roku. My mamy tą wizję, my mamy etapy, którymi chcemy podążać, ale w związku z tym, że zakładamy, że w każdym sprincie pozyskujemy wiedzę, na podstawie której możemy modyfikować nasz plan, czyli uelastyczniamy się na te zmiany, to za każdym razem na koniec sprintu dostarczamy już jakiś fragment działającego softu, żeby zebrać feedback, żeby odbić nasze hipotezy, które sobie postanowiliśmy i dostosować plan, czyli elastycznie podejść do tego, do jakiej wizji zmierzamy. Więc jak najbardziej planujemy, tylko dajemy sobie ten plan z taką opcją tej elastyczności, bo żeby zapewnić komfort pracy w sprincie, bo tutaj też chciałabym to podkreślić, że to nie jest tak, że zespół zaczyna pracować i w zasadzie każdego dnia może go spotkać coś nieoczekiwanego, nowego i wiecie. No bo to też stres, napięcie, jakieś takie ciągłe bycie na standby'u. Nie, nie o to chodzi. Zespołowi mamy zapewnić komfort, żeby on mógł realizować to, co zostało zaplanowane. W związku z tym niewskazane jest w ramach trwania sprintu zmieniania chociażby jego celów. No chyba, że pojawią się takie wiecie, okoliczności, że załóżmy weźmy sobie na cel naszego dwutygodniowego sprintu, że na koniec sprintu chcemy mieć zaplanowaną podróż do Wietnamu, a właśnie dostajemy informację w trakcie, że Wietnam zamknął się i nie można do niego wlecieć przez następne trzy miesiące, to raczej inwestowanie swojej energii przez kolejny tydzień na to, żeby wciąż planować tą podróż, która w tych okolicznościach się nie wydarzy, no nie jest dobrym pomysłem. Więc może i istnieje ryzyko, ale właśnie przed tym sprintem, który się wydarzy, my musimy włożyć energię w tzw. pielęgnowanie elementów. Kurczę, będę teraz opowiadać o Scrumie i Scrum Guide, ale mamy taką... o może tak - jest coś takiego jak backlog produktu, czyli lista rzeczy, które uważamy z punktu widzenia dostarczania wartości dla klienta, że powinny się wydarzyć. Na górze backlogu mamy najbardziej wartościowe elementy, które chcemy wykonać w najbliższej przyszłości i one są szczegółowo opracowane. Tam mamy już wiedzę, mamy zweryfikowane jakieś hipotezy wstępne, np. z badań z użytkownikami. Mamy doszczegółowione, co konkretnie musi się wydarzyć w ramach tego zadania, żeby to zadanie można było uznać za zrealizowane. A im niżej w tej naszej liście, tym to jest właśnie takie bardziej rozmyte, tym to jest taki luźny plan, bardziej to jest jakaś wizja, co może iść dalej. I jak zespół zaczyna planowanie sprintu, to wcześniej, w poprzednim sprincie zapewnił sobie to, że te elementy z góry backlogu, które będzie chciał realizować, są na tyle przygotowane, że on może skupić się już tylko na realizacji, bo ma wszelkie potrzebne informacje i wiedzę do tego, żeby móc na koniec sprintu dostarczyć działający fragment oprogramowania.

Paulina:
Krótki przerywnik! Zostawiłyśmy dla Was pytanie na Spotify, więc koniecznie tam zajrzyjcie i na nie odpowiedzcie. Czekamy też na Waszą ocenę. Możecie ją zostawić na Spotify albo na Apple Podcasts.

Paulina:
A powiedz jeszcze tak dla uporządkowania pojęć, bo wytłumaczyłaś czym jest Agile, a czym jest Scrum?

Joanna:
To najłatwiej sobie wyobrazić, że Agile to jest taki core, że to jest właśnie ta filozofia, że to jest jakieś podejście, a Scrum czy Extreme Programming, czy Lean, czy Kanban to są takie, że to jest rodzina metod, za pomocą których można realizować tą wizję Agile'a i po prostu każda z tych metod ma swoje ramy postępowania, w ramach których realizuje te wartości i realizuje te założenia zwinności. Czyli mamy matkę Agile, te fundamenty, a poszczególne frameworki tak zwane czerpią po prostu z tych założeń doprecyzowując, ale też nie w jakimś takim bardzo mocnym stopniu, ale doprecyzowując konkretne ramy postępowania, aby móc zapewnić sukces prowadzonemu projektowi. A sukces to: zarobek organizacji, pomyślny launch produktu i po prostu wytwarzanie oprogramowania skupionego na dostarczeniu wartości dla klienta końcowego.

Kim jest Scrum Master i Agile Coach?

Aga:
Powiedziałaś Asia już trochę, jak to się odbywa w praktyce, że są te sprinty, że się planuje, rozpisuję bardziej szczegółowo zadania, jest backlog, ale jakbyś powiedziała jeszcze, jak Twoja rola wyglądała? Jak w ogóle się nazywało to stanowisko? Jak można szukać siebie właśnie w tym obszarze czy realizować się zawodowo? Jak to wiesz, przekłada tak w praktyce na taką rolę?

Joanna:
Jasne. No to w branży, co organizacja, to ta nazwa też się trochę może różnić. Ale w branży jakby ktoś chciał szukać pracy w takim obszarze, to funkcjonuje stanowisko... stanowisko właśnie, a to też z punktu widzenia podejścia do frameworka Scruma to jest odpowiedzialność. No ale powiedzmy, jeżeli szukamy pracy, to zazwyczaj będzie to Scrum Master i ja jako Scrum Masterka właśnie pracowałam i są też Agile Coache. Pracowałam też jako Agile Delivery Agent. To była jakaś taka własna nazwa w organizacji i w zasadzie myślę, że to te dwie - Agile Coach, Scrum Master są takimi najpopularniejszymi pozycjami, z którymi można się spotkać. No i odpowiedzialnością, zadaniem osoby, która wchodzi w taką rolę jest po pierwsze edukowanie, nauczanie o tym, jak tą zwinność wykorzystywać w organizacji. Głównie skupmy się teraz na wytwarzaniu oprogramowania, no bo w tym momencie czy Agile czy Scrum jest tam szeroko wykorzystywany i co ważne też, np. w kontekście Scruma jego autorzy... istnieje coś takiego jak Scrum Guide. To jest bodaj wciąż 16 tylko stron zapisanych tych ram postępowania - jakie wydarzenia funkcjonują, jakie role tam są, jakie są artefakty, jakie wartości, jakie filary. I to jest napisane na tych 16 stronach, czyli teoretycznie nie musicie zgłębiać 200-stronicowej książki, żeby się tego nauczyć. I te ramy są proste, ale trudne w implementacji, dlatego że dochodzi ten czynnik ludzki, dochodzą te emocje, dochodzą korporacyjne, organizacyjne rzeczy, które mówią, jakby zaprzeczają niektórym ramą. Więc rolą Scrum Mastera czy rolą Agile Coacha jest pokazywanie wartości z tego, dlaczego warto tych ram przestrzegać. Zarządzanie tym procesem, bo co ważne, często jest mylone, że ok czyli Scrum Master zarządza ludźmi, jak oni mają pracować, żeby pracować efektywnie, żeby podejmować... Nie lubię tak tego definiować „optymalne”, no bo co znaczy optymalne, ale podejmować najlepsze decyzje, które możemy podjąć w tym czasie. Tylko że Scrum Master nie zarządza zespołem, nie zarządza produktem. Od zarządzania produktem jest Product Owner. A fundamentem Scruma jest samozarządzający się zespół. Czyli to zespół podejmuje decyzje całościowo, tzw. Scrum Team, czym się zajmie, w jaki sposób się zajmie. Scrum Master zarządza procesem. W taki sposób zarządza procesem, żeby on właśnie był efektywny i żeby podlegał ciągłemu doskonaleniu. Bo to co prawda słowo zaczerpnięte z metodyki Lean. Metodyki? Nie metodyki, z metody! Z metody Lean, czyli Kaizen - ciągłe doskonalenie polegające na tym i też w kontekście tej inspekcji i adaptacji, o której mówiliśmy, że my patrzymy, co robimy, przyglądamy się, jakie efekty uzyskujemy, następnie podejmujemy decyzję, czy to jest kierunek, w którym dalej chcemy pracować, czy jednak powinniśmy coś usprawnić, udoskonalić, zmienić, bo np. kategorycznie to nie jest to, co chcemy robić i teraz mówię pod kątem procesu, nie pod kątem produktu. Czyli załóżmy no współpraca w zespole, nie dogadujemy się, no to widzimy, że to jest obszar, którym powinniśmy się zaopiekować. Następnie wypracowujemy np. jakąś akcję, która ma wpłynąć na tą zmianę, adaptujemy ją do naszej pracy. No i znowu mija jakiś czas np. sprint, dokonujemy ponownej inspekcji, czy aby na pewno ta zmiana, którą podjęliśmy przyniosła nam oczekiwany efekt. I to jest tutaj też ważne, że do życia codziennego, dokonywaniu kilku zmian naraz nie da nam odpowiedzi, który nasz ruch przyniósł nam oczekiwany efekt. W związku z tym, żeby ta zmiana aż tak nie przerażała, ja zawsze zalecam taką sztukę małych kroków i po prostu skupienia się na jednej dwóch akcjach na raz, maksymalnie, po to, żeby zobaczyć, czy coś, co wydawało nam się, że o Boże, to jest dopiero początkiem procesu, czy to jednak nie przyniosło nam tego, co potrzebowaliśmy i może nie potrzebujemy więcej energii inwestować w to, żeby osiągnąć coś, na czym nam zależało, tylko możemy pójść dalej. No i właśnie wokół tego krąży się Scrum i moim zadaniem było pokazanie ludziom, dlaczego warto tak robić i dlaczego to jest ważne, jak te ramy, o których mówi Scrum Guide implementować do codziennej pracy. Ja też zawsze mówię o tym, że... I to była taka, bo z jednej strony mamy ten produkt, czyli głównym zadaniem Scrum Mastera jest to, żeby zespoły pracowały efektywnie, wykorzystywały te zwinne zasady postępowania, działały wokół wobec łącznie z... Nie, inaczej - działały w oparciu o konkretne wartości: odwagę, skupienie, odpowiedzialność, zaangażowanie, szacunek wzajemny do siebie, bo to tworzy środowisko, w którym powstają te produkty, które pokochają użytkownicy. I to jest ta jedna część działania Scrum Mastera. A druga - coś, co mnie bardzo w tym wszystkim też jarało i gdzieś się budowało moją ścieżkę rozwoju, którą chciałam podążać, czyli bycie takim lustrem dla osób pracujących, że wiecie, że my czasami tak bardzo jesteśmy w tym procesie tworzenia, że nie widzimy tego przysłowiowego słonia w pokoju, który stoi, który utrudnia nam to nasze działanie. W związku z tym Scrum Master wykorzystuje, może wykorzystać szereg technik do pracy z zespołem, do budowania zespołu, do właśnie budowania tej odpowiedzialności, aby zespół dzielił się feedbackiem, aby właśnie działał w oparciu o ten szacunek, aby razem był w stanie wytwarzać tą najwyższą wartość, którą jest stanie dostarczyć, no bo też coś, co jest bardzo bliskie mojemu sercu, czyli koncepcja mądrości tłumu, która polega na tym, że grupa osób prawdopodobnie będzie uzyskiwała, jakby będzie w stanie wyciągnąć lepszy wniosek, stworzyć lepszy pomysł bądź lepiej oszacować coś niż pojedyncza osoba. I są na to bardzo fajne ćwiczenia do przeprowadzania, żeby po prostu zobaczyć, że załóżmy jeżeli ktoś by miał oszacować mój wzrost, to prawdopodobnie szacunki pojedynczych osób będą na tyle dalekie od tego mojego, ale średnia szacunków sprawi, że to będzie z dużym prawdopodobieństwem wynik najbliższy temu, ile ja mam wzrostu. Więc to jest to, co jakby właśnie pokazywanie takich rzeczy, uczenie, prowadzenie szeregu ćwiczeń, żeby budować tą zespołowość, żeby pokazywać, dlaczego warto, że my jako zespół bierzemy odpowiedzialność i wytwarzamy ten produkt, a nie jako jednostki, które między sobą rywalizują, konkurują i patrzą tylko na swój czubek własnego nosa, no dlaczego warto postępować inaczej. Plus jeszcze cała ta kultura eksperymentowania, weryfikowania hipotez, pracy z przyznawaniem się do błędów. Bo to jest coś, co ja w sumie zaczęłam... Ja sama byłam w tym miejscu, że po tym moim doświadczeniu takim edukacyjnym w szkołach, na studiach, po prostu jak popełniałam pierwszy błąd w pracy, to miałam ochotę zapaść się pod ziemię i w ogóle nikomu o tym nie mówić i jak najszybciej ten błąd odkręcić i w ogóle o nim zapomnieć. I potem jak np. rekrutowałam młodsze osoby i widziałam, jak one przychodzą, to część z nich właśnie miała też takie postępowanie i bardzo bała się tych konsekwencji, bo też je wyolbrzymiała, popełnienia błędu, próbowała je zatuszować czy próbowała jakoś tam odkręcić, przez co jeszcze bardziej np. ten błąd się kumulował, no bo coś zostało wdrożone na produkcji z błędem. I to nie jest wina tej jednej osoby, bo przy wytwarzaniu oprogramowania przechodzimy przez różne etapy. Jedna osoba pisze kod, druga osoba go weryfikuje, trzecia jeszcze testuje. Potem może być jeszcze proces weryfikacji zgodności tego, co powstało z wymaganiami. Więc my jako zespół ponosimy odpowiedzialność za całość procesu, nie pojedyncza jednostka. Więc to też była jakaś taka właśnie w kontekście pracowania w oparciu o te wszystkie wartości Agile Manifestu czy ramy postępowania Scruma, żeby uczyć ludzi, że błędy są spoko, bo... spoko pod kątem takim, że weźmy, zobaczmy, jak to się już wydarzyło, naprawmy ten błąd, a następnie przyjrzyjmy się niemu, wyciągnijmy z niego lekcję, nauczmy się i zastanówmy się, co zrobić, żeby następnym razem ten błąd się nie pojawił. Czyli znowu proces inspekcji i adaptacji, dużo nauki. No praca jeden na jeden z pojedynczymi osobami, praca z emocjami, z przekonaniami. Każdy Scrum Master de facto przez to, że ta rola nie jest wiecie, punkt po punkcie tak bardzo zdefiniowana, może też sobie trochę stworzyć taką własną definicję w oparciu o klienta końcowego. A kim jest klient końcowy? Zespół scrumowy i organizacja. Więc znowu, Scrum Master, jak dla mnie, ja tak pracowałem jako Scrum Master, bazując na założeniach Agile Manifestu, bazując na ramach Scruma, ja skupiałam się na dostarczaniu tej wartości dla zespołu scrumowego i dla całej organizacji, żeby po prostu była zwinna i znowu, na końcu dostarczała produkty, które pokochają ludzie.

Dzień pracy Scrum Mastera i Agile Coacha

Paulina:
Czyli w zasadzie wspomniałaś o tym, że można robić jakieś ćwiczenia, że są też spotkania jeden na jeden. Czy taka codzienna Twoja praca właśnie polegała na tym, że spotykałaś się z konkretnymi osobami czy może robiłaś jakieś warsztaty? Czy możesz obserwowałaś, co się dzieje np. na Slacku, czy są jakieś napięcia? Jak to wyglądało tak w praktyce na co dzień?

Joanna:
Jak rekrutowałam Scrum Masterów, którzy już mieli doświadczenie, to też często zadawałam im pytanie: „Dobra, to powiedz mi, jak wygląda Twój dzień pracy?”. Bo to jest dosyć abstrakcyjne też dlatego, że każdy dzień może być inny w zależności od tego... bo nie powiedziałam czegoś, co też bardzo często wybrzmiewa. I to zdanie tak brzmi, że zadaniem Scrum Mastera jest usuwanie impedimentów na drodze zespołu do osiągnięcia celu, który realizuje. Impedimentów, czyli przeszkód, problemów i te impedimenty mogą być zarówno takie właśnie, nie wiem, relacje w zespole albo niezrozumienie, albo np. zespół ma wykonać pracę, do której nie ma kompetencji, albo właśnie ta potrzeba przekazania feedbacku, bo coś tam nie działa. Z drugiej strony impedimentem może być brak narzędzi, które zespół potrzebuje, żeby wykonać pracę. Albo wiecie, takie prozaiczne rzeczy na zasadzie ciągle wieje klimatyzacja i ten nawiew wieje prosto na ten zespół, a to wprowadza dyskomfort i nie pozwala pracować dobrze, no bo skupiamy się na tych czynnikach zewnętrznych, które wpływają na nasz komfort. Więc moim zadaniem w takiej codziennej pracy było zauważanie właśnie tego, jakie te impedimenty mogą być. I uwaga to nie jest tak, że rolą Scrum Mastera, skoro dwie osoby się nie dogadują, jest wzięcie teraz tych dwóch osób do salki i powiedzenie: „Słuchajcie, widzę, że się nie dogadujecie. Mam na Slacku tutaj screeny z Waszych dwóch konwersacji plus na daily dzisiaj powiedzieliście to i to i teraz słuchajcie, pogodzimy się. Wyciągnij Ty rękę, wyciągnij Ty rękę”. Uścisk dłoni, super, wszystko okej. Załatwiłam, odhaczone, jestem super Scrum Masterką. Niestety w takie pułapki początkujące Scrum Masterzy często wpadają, no bo ogólnie jako ludzie w pracy potrzebujemy widzieć efekty naszej pracy i w tej roli Scrum Mastera o tyle to jest trudne, że efekty potrafią kiełkować miesiącami. I moją rolą nie jest to, żeby powiedzieć zespołowi musicie robić tak, bo dzięki temu będzie efektywnie. Tylko moją rolą jest takie poprowadzenie zespołu, czyli np. tymi warsztatami, ćwiczeniami, codzienną pracą, pokazywaniem właśnie tego, co się dzieje, żeby oni sami de facto doszli do tego wniosku. Jak najbardziej ja mogę im przynieść case study, mogę im pokazać dane, bo to też był taki element mojej pracy, zbieranie danych, np. o tym, jak zespół pracuje, ile zadań jest w stanie realizować w trakcie sprintu albo jaką ma przewidywalność. Jeżeli przewidywalność liczona, uprośćmy, ilość zadań, które zespół zaplanował do ilości zadań, które ukończył. I teraz ja jako Scrum Masterka bazująca na danych, bo to też jest ważne, żeby trochę zejść z tego poziomu emocjonalnego bazującego na przypuszczeniach albo założeniach, schodzić na poziom danych, mogę przyjść do zespołu i powiedzieć: „Słuchajcie! Zobaczcie, od trzech sprintów planujemy na początku 10 zadań, ale w pierwszym sprincie zrealizowaliśmy 6, w drugim 4, a teraz zrealizowaliśmy 3. Jak widzicie nasza przewidywalność jest raczej na poziomie poniżej 50%, która nie jest wskazana”. Bo konsekwencja tak niskiej przewidywalności jest taka, że Product Owner, czyli osoba zarządzająca produktem nie ma pewności, czy to co zespół obieca dzisiaj będzie jutro. A teraz jeżeli np. tworzymy produkt, który ma być częścią wspierającą kampanię reklamową, to tą kampanię reklamową jednak trzeba zaplanować, jednak trzeba ją osadzić w jakimś terminie. Nie wiem, wykupić reklamy w telewizji. Wiecie, że to tutaj te elementy planowania mogą zawężać jakoś ramy tej elastyczności. I jeżeli Product Owner nie ma żadnej pewności, czy to, co zespół obiecał, to faktycznie się wydarzy, no to mamy problem. Więc ja przynoszę dane do zespołu i zaczynam rozmowę: „Słuchajcie, jak myślicie, z czego to wynika? Co takiego się dzieje? Zbierzmy dane”. Jakby zbierzmy dane w sensie nasze wnioski z głowy. Jakby, co się wydarzyło, że tak się zadziało? No i na podstawie tego po prostu procesu, w którym jesteśmy razem, istnieje bardzo duże prawdopodobieństwo, że zidentyfikujemy miejsca tzw. wąskie gardła, które np. wpływają na to i przyczyn tego może być dużo. I znowu jako taki... dobra, bo nie chcę też początkujących Scrum Masterom umniejszać, ale nie mając doświadczenia można wyciągnąć wniosek, że „Okej! Niska przewidywalność zespołu to na pewno zespół planuje za dużo. Musicie zacząć mniej planować i wszystko będzie dobrze”. No i wiecie, zespół zaplanuje mniej, a i tak np. coś się wykrzaczy, bo na zupełnie innym etapie procesu może być z tym problem. I to właśnie było moim zadaniem. Czyli pojawia się coś, na podstawie czego ja powinnam tak zaangażować zespół i tak im pokazać to, co się dzieje, żebyśmy mogli dokonać procesu inspekcji i adaptacji. I to może się dziać np. na sprint retrospective. Czyli może spójrzmy sobie, jak to... myślę, że na Scrumie będzie to najłatwiej tłumaczyć.

Zaczynamy Scrum od wspólnego planowania w zespole. Następnie załóżmy przez ten sprint dwutygodniowy codziennie spotykamy się na daily. To jest takie maksymalnie 15 minutowe spotkanie, podczas którego synchronizuje my pracę w zespole, patrzymy, jak wygląda realizacja celu, rozmawiamy o problemach, które pojawiły się w ciągu ostatnich 24 godzin. To spotkanie jest zawsze w tym samym miejscu, o tej samej porze, żeby minimalizować złożoność, żebym wiecie, nie musiała czekać, czy ktoś do mnie przyjdzie, kiedy mam się synchronizować, kiedy mam pogadać. I np. wtedy ja mogę jako Scrum Master uczestniczyć w tym spotkaniu i facylitować rozmowę. Czyli gdzieś tam, jeżeli zespół jeszcze tej komunikacji nie ma dogranej, pomóc mu poprowadzić tą rozmowę. Jakby najpierw nauczyć zespół, jak to daily może wyglądać, jak można je prowadzić, zadawać pytania pogłębiające, zadawać pytania, które mogą wskazać na to, że gdzieś mamy problem. I znowu jako Scrum Master ja nie muszę być alfą i omegą i wyprzedzać zespół, czyli jak słyszę, że ktoś będzie testować, to sobie myślę:  „Aha, on będzie testować. Tam może pojawić się problem” i mam już założenie, dlatego pytam, tylko w momencie kiedy ktoś mówi: „Dobra, słuchajcie! Ja to biorę dzisiaj do testów. Tyle, że dzisiaj wychodzę wcześniej z pracy, więc no, ale postaram się”. No to ja wtedy mogę powiedzieć: „Okej, czyli będzie mniej czasu, a do testowania wiemy, że jest więcej, to mogę zapytać słuchaj, a jakie jest prawdopodobieństwo, że faktycznie uda Ci się to, jak oceniasz?”. No i wtedy ta osoba może powiedzieć: „Nooo w sumie tak myślę, że kurcze to może być za mało czasu” i wtedy inne osoby z zespołu mogą powiedzieć: „Ej no dobra, no to podzielmy się tym. No jest taka sytuacja!” czyli wiecie, właśnie reagowanie na to, co przychodzi. Jest to daily i w trakcie też sprintu właśnie jest to doskonalenie Product Backlogu, o którym mówiłam, czyli to jest takie, załóżmy, jeżeli cały zespół się spotyka, bo to może mieć różne formy, ale ja jako Scrum Master facylituję takie spotkanie, pomagam zespołowi tak przygotować te zadania, żeby po prostu uzyskać z nich wartość. Ale przy tym po prostu uczę zespół, jak to robić, bo taka myśl, którą kiedyś ktoś mi zasiał i ona przez całą moją pracę przyświecała i ja to zawsze mówiłam: „Moją rolą jak Scrum Mastera albo Agile Coacha jest sprawienie, że ja będę niepotrzebna zespołowi”. Kolejny sabotaż, ale patrząc na moje 10 lat pracy przy projektach, przy rozwijaniu produktów no działa to. W sensie nie chodzi o to, że Scrum Master ma być potrzebny, ma być taką niańką zespołu, ma za niego odpowiadać, kiedy przyjdzie ktoś z trudnym feedbackiem albo kiedy inny zespół robi coś nie tak, to Scrum Master idzie rozwiązać ten problem i zaraz im przemówi do rozsądku. Nie, chodzi o to, żeby właśnie uczyć, pokazywać, zarażać tą zwinnością po to, żeby zespół właśnie bazował na tej samoorganizacji, bazował na autonomii i był w stanie sam rozwiązywać problemy. No bo wyobraźcie sobie sytuację, że idę na L4. Mój zespół ma w tym momencie przeprowadzić daily i co? I oni nie są w stanie przeprowadzić dalej, bo nie ma Scrum Mastera? Czyli ta myśl, że to wszystko co robię ma sprowadzać się do tego, nie żebym ja pompowała swoje ego i pokazywała jak bardzo jestem potrzebna, tylko żeby pokazać ludziom, jak oni mogą to robić, dać im narzędzia.

I właśnie to, co też Paulina pytałaś. Często pojawiały się np. jakieś warsztaty do prowadzenia na poziomie organizacji, bo jedno to jest praca w ramach zespołu, a druga to jest np. praca na poziomie organizacji razem z innymi Scrum Masterami. Niestety często organizacja wymyśla, że chce pracować w Scrumie, ale Scrumem pracują tylko zespoły wytwarzające oprogramowanie, a cała reszta organizacji nie do końca. No i tu mamy zgrzyt. I teraz rolą Scrum Masterów jest zarażanie reszty organizacji tą zwinnością, pokazywanie jak to można wykorzystać i tłumaczenie też dlaczego np. nie zamkniemy się teraz na pół roku i będziemy tworzyć produkt dla marketingu. Tylko jest ważne, żeby te osoby, które są zaangażowane w tworzenie tego produktu były cyklicznie co 2 tygodnie na sprint review, żeby móc dawać właśnie ten feedback, żeby go zbierać. Dlaczego to nie jest tak, że CEO może przyjść do zespołu i powiedzieć: „Ej, słuchajcie, słuchajcie, bo jest ważna sprawa! Ja potrzebuję takiej malutkiej zmiany, 10 minut to tylko musicie w tekście wprowadzić. Wprowadzicie i będzie wszystko okej” i tu pojawia się w zależności też od etapu rozwoju zespołu, bo często zespół może zareagować i powiedzieć: „Hej, idź do Product Ownera. My w taki sposób nie pracujemy. Mamy tutaj to, co jest zaplanowane. Tylko Product Owner może podjąć decyzję”. No i teraz znowu pojawia się Product Owner. Musi mieć szacunek w organizacji, musi mieć decyzyjność. Musi też mieć w sobie wypracowane coś takiego, żeby wiecie, wejść ze swoim pracodawcą jakby nie patrzeć w dyskusję, że: „Słuchaj, to tak nie wygląda. Jeżeli to jest tak krytyczne i ważne, możemy to... przedyskutujmy dlaczego, ale też pamiętaj o tym, że to nie jest, że ktoś podmieni literki w kodzie, tylko ze względu na potrzebę zachowania jakości tego, co tworzymy, potrzebuje to przejść przez cały proces. W związku z tym to nie będzie zmiana na 10 minut, tylko np. zespół będzie potrzebować godziny żeby to zrobić. I czy Ty chcesz, żeby właśnie on zrezygnował z rzeczy, którą robi, która też jest tak bardzo ważna na rzecz rzeczy, którą właśnie wymyśliłeś, że warto zrobić?”. I wiecie co? W takich dyskusjach bardzo często wynikało, dobra, to może poczekać faktycznie. Nie mówię o błędach, które wyskakiwały i trzeba było na nie reagować, ale o takich trochę zachciankach albo takich wiecie, genialnych pomysłach, w których autor się zakochał, a ze względu na hierarchię ma teoretycznie większą moc. No i znowu tutaj pojawia się Scrum Master, który uczy Product Ownera, w jaki sposób pracować. Pomaga mu. Często Scrum Masterzy i Product Ownerzy pracują w duecie, wspólnie, razem rozwiązując jakieś rzeczy. Bo ja jak tak wiecie, 3 lata nie pracuję już w takim środowisku, to nasz mózg ma tendencję do pamiętania tych dobrych wspomnień i tych dobrych momentów, ale czasami robię sobie taki check, przypominając, że dużo jest tam rozmów, dużo jest pokazywania, dużo jest właśnie tej edukacji, dlaczego tak robimy, a nie inaczej.

I nie powiem konkretnej listy zadań, z którą przychodzi Scrum Master do pracy i ją wykonuje, bo to jest reagowanie na to wszystko, co przychodzi, zbieranie danych, właśnie to bycie lustrem, o którym wspominałam, praca czy z osobami indywidualnymi, jak Product Owner, czy poszczególni deweloperzy. To jest wdrażanie nowych osób. To jest praca ze Scrum Masterami na poziomie organizacji, żeby nie wiem, też zbierać dane, też implementować jakąś ideę, np. w obu organizacjach wprowadzaliśmy coś takiego jak taki feedback, który nie odbywa się, wiecie, raz do roku, a po nim dostajesz ocenę roczną, a następnie na podstawie tego Twoją podwyżkę czy premię. Bo trochę to się mija z ideą zwinności, gdzie na bieżąco weryfikujemy to, co się dzieje. No i jednak pamiętamy jakieś ostatnie 3 tygodnie, miesiąc z tego co się działo. To też jest trochę słabe, dając komuś feedback na podstawie jakiś ostatnich wydarzeń. W związku z tym np. w organizacjach wprowadzałam z innymi Scrum Masterami coś takiego jak kwartalne feedbacki, gdzie gromadziliśmy się razem w zespole i za pomocą jakiś technik, które wypracowaliśmy, budowaliśmy przestrzeń na to, żeby ten feedback mógł zajść. Dzięki temu to wpływało na motywację ludzi, bo dostawali naprawdę fajne rzeczy, które mogły im pokazać. Wiecie, to jest trochę tak, że my nie widzimy czasem, w czym jesteśmy dobrzy, to to jest nasz standard, ale inne osoby z zewnątrz potrafią nam to powiedzieć i to mocno wpływa na to, jak się czujemy w pracy. Z drugiej strony możemy też nie dostrzegać tego, co moglibyśmy robić lepiej, a ten feedback od współpracowników, jeżeli zostanie w odpowiedni sposób, i znowu tutaj wracamy do tej roli edukatora, to może wpłynąć na to, że my się będziemy po prostu rozwijać jako ludzie, że to nam wskaże ten nasz kierunek. I to są też fajne materiały do pracy z naszym przełożonym, nad naszym rozwojem, nad tą oceną, jeżeli istnieje, bo ja nie jestem fanką ocen, jeżeli chodzi o takie pozycjonowanie, kto jest piątką, a kto jest trójką. Ale to też wpływa na to, jak jesteśmy postrzegani przez naszego przełożonego. No i jest jakąś też kartą przetargową do rozmowy o podwyżce czy do rozmowy o zmianie jakiegoś naszego miejsca, że jeżeli mamy osobę np. dewelopera, który męczy się już nad produktem, który pracuje, no to chyba lepiej zauważać to w takich odstępach krótszych niż tkwić rok w tym miejscu, bo np. ten deweloper nie czuje się na siłach, żeby móc powiedzieć głośno o tym, że chciałby to miejsce zmienić. I my się po roku dowiadujemy, że on w styczniu w zasadzie to już chciał rzucić papierami, a coś tam się poprawiło. Albo mamy sytuację, że ktoś przychodzi i mówi zwalniam się, a okazuje się, że naprawienie rzeczy, które dla tej osoby są niekorzystne i nawet dla zespołu nie jest dużym problemem tylko przez to, że nie stwarzamy przestrzeni do rozmowy, te rzeczy nie wychodzą na wierzch. Myślę, że mogłabym jeszcze z dwie albo trzy godziny opowiadać o tym, co to może być, więc chyba bym tutaj ucięła.

Aga:
Super, super! Jest to szalenie ciekawe i myślę, że to jest taka wielowarstwowa rola, dużo rzeczy się dzieje. I tak jak są zasady Agile'u, trzeba reagować na zmiany, to też Agile Coach czy Scrum Master, Masterka muszą gdzieś tam reagować bardzo i taką uważność mieć, myślę, sporą.

Joanna:
Uważność. To są moje rzeczy. Jakby to nie jest uniwersalna lista, którą spotkacie w artykułach, ale z tego co ja zaobserwowałam: uważność, pokorę, właśnie taka mocna praca z ego, mocna praca ze swoimi przekonaniami i z tym właśnie... jakby ja to tak zawsze wizualizowała, że załóżmy deweloper kończąc dzień pracy, deweloper, designer, że wiecie wchodzi do pracy i załóżmy ma stworzyć makiety czy napisać fragment kodu i on na koniec pracy może przyjść z takim prezentem do kogoś i powiedzieć: „Proszę, to jest to co zrobiłem!”, że to jest to. A ja, bywały takie dni, w których mogłam to zrobić, ale bywały takie dni, gdzie to była właśnie ta praca na tych emocjach, relacjach, na rozmowach, na biciu się z koniem, kopaniu się z koniem i de facto na początku miałam z tym problem, że no dobra, no i ja wychodzę z tej pracy i co ja mogę dać w tym prezencie? Co mam powiedzieć? Że rozmawiałam z ludźmi? I to też jest rzecz do przepracowania i do takiego właśnie na poziomie też inspekcji, adaptacji swojej pracy największa satysfakcja, kiedy np. przychodził deweloper, ja tak mówię deweloper, ale to mam na myśli w duchu Scruma, że to może być właśnie i UX, i UI, i badacz, wszystkie osoby, które tworzą produkt, jakby składają się na ten finalny efekt produktu i przychodził deweloper zagubiony, niepewny, bojący się mówić i poprzez pracę z nim okazuje się, że np. po 2 miesiącach zupełnie inaczej to wygląda, że on wziął jakieś techniki, o których mu powiedziałam, któremu pokazałam i zaczął je implementować, że ta współpraca w zespole zaczęła inaczej działać, że na początku zespół na tym sprint retrospective na koniec, w którym podsumowujemy proces i rozmawiamy o tym, jak nam się pracowało, co możemy robić lepiej, że był zespół, który no nie potrafił ze sobą za bardzo rozmawiać, nie wiem, w większości milczał albo pływał po powierzchni, a nagle potrafimy zajść głęboko. No i widzę, że to, nad czym pracowaliśmy, przychodzi i przynosi efekt. Więc też tej roli Scrum Mastera zawsze warto sobie, ja tak robiłam, wyznaczać takie cele dla siebie, że jeżeli widzę, że ten mój klient, czyli powiedzmy ten Scrum Team, boryka się z tym, z tym i z tym. Pokazuję to zespołowi, że to widzę, zespół mówi: „Tak, my też to widzimy, chcemy nad tym pracować”, no to, że ja też tworzę jakąś wizję, do czego chcę dojść, w jaki sposób chcę to robić, że przychodząc do pracy mówię sobie: „Okej, jeżeli teraz pracujemy nad poprawieniem komunikacji w zespole, to w jaki sposób ja w tym tygodniu chcę sprawić, żeby ta komunikacja w zespole poprawiła się chociaż o 1%?”. No i znowu czerpiemy z Agile'a, czerpiemy z tego podejścia zwinnego. To nie jest coś takiego, że przychodzę i sobie myślę: „Hmmm, co tu dzisiaj by zrobić”, tylko też dobrze pracować na tej wizji, planie, na celach, żeby właśnie móc sobie potem sprawdzić, na ile moje działania wpływają na to, jak funkcjonuje zespół czy organizacja.

Kto może korzystać z metodologii Agile?

Paulina:
A powiedz, czy Agile jest tylko dla deweloperów? Czy mogą z niego korzystać też designerzy czy chociażby marketingowcy?

Joanna:
Ja uważam, że Agile jest dla wszystkich. W sensie, ja naprawdę i to robię w zasadzie w moich social mediach, robi to w podcaście, robię to też teraz, namawiam ludzi do tego, żeby po prostu spojrzeć na pewne rzeczy, które w nas tkwią właśnie przez system edukacji, przez jakieś przekonania, przez wychowanie naszych rodziców, którzy mieli jednak zupełnie inny dostęp do narzędzi, zupełnie inaczej rozmawiało się w kontekście jakiegoś takiego samorozwoju, kwestii psychologicznych, zupełnie inne były tematy tabu niż te, które są teraz, że po prostu to, co daje Agile, pozwala nam przyjrzeć się też tak po prostu jako jednostkom, przyjrzeć się naszej pracy i zweryfikować, czy aby na pewno to, co robimy daje tą wartość i jest najlepszym sposobem funkcjonowania. Jak wspomniałam, w Scrumie są trzy odpowiedzialności. Product Owner, który mówi co zrobimy, czyli zarządza tym produktem. Deweloperzy, którzy mówią jak to zrobimy i w skład deweloperów wchodzą wszystkie osoby, które mają wkład do stworzenia ostatecznej wersji produktu. I znowu to się będzie różnić w zależności od organizacji, bo w niektórych organizacjach, w tym naszym Scrum Teamie, czyli zlepku tych wszystkich ról, będziemy mieli same osoby piszące kod i testujące. Czyli to może być, mogą być programiści, mogą być testerzy, testerzy automatycznymi, no wszystko zależy od organizacji. Ale pracowałam też w zespołach, w których w ramach Scrum Teamu funkcjonowali po prostu też np. UX albo były dedykowane osoby odpowiadające za tę warstwę wizualną. Zdarzało się, że też byli badacze zaangażowani w to, no bo przecież bazujemy na tym, żeby wymiana informacji pomiędzy tymi wszystkimi osobami była jak najczęstsza. Czyli jeżeli nawet już jesteśmy na etapie, że mieliśmy badania, mieliśmy makietę jakiegoś fragmentu oprogramowania, który tworzymy i programiści to kodują, to przecież super opcją jest powrót z tym do tego naszego UX'a czy specjalisty od UI'a i powiedzenie: „Patrz, to jest to co zakodowałem”, bo oni już mogą dać feedback, oni już mogą spojrzeć, oni też mogą w ten sposób zweryfikować swoje założenia, że załóżmy ktoś wyobraża, jakby wiecie, stworzył i wersję responsywną i wersję desktopową, ale okazuje się, że jednak po zakodowaniu są jakieś ograniczenia w tej wersji responsywnej i trzeba zmienić wykorzystany font, bo on niekorzystnie wygląda. Więc jeżeli te osoby ze sobą ściśle współpracują, szybciej reagujemy na zmianę, mamy sprawniejszą wymianę informacji, przez co sprawniej dostarczamy ten ostateczny efekt dla tego naszego klienta i on może już z tego zacząć korzystać i dawać nam dodatkową informację zwrotną. Więc z jednej strony to jest to, z drugiej strony pracowałam w organizacji, byłam właśnie taką Scrum Masterką, a może bardziej Agile Coachem dla zespołu, który się utworzył tylko z UX'ów, specjalistów od UI i tam nie było żadnych... i pojedynczych deweloperów, którzy mogli po prostu te rzeczy z warstwy wizualnej od razu implementować, żeby tworzyć po prostu takiego play booka dla innych zespołów, jak ta warstwa wizualna ma wyglądać i funkcjonować czy tworzyć komponenty, które no nie będzie musiał zespół solowo implementować za każdym razem, tylko to będą gotowe komponenty w kodzie do wykorzystania w produktach po to, żeby uspójniać wielkość, wygląd produktu. No bo jeżeli jesteśmy małą firmą, wiecie, zatrudniającą jeden zespół, kilku programistów, specjalistę od UX'a - okej. No ale jeżeli budujemy taki portal jak Allegro czy Pracuj.pl, to mamy zaangażowane w to kilka zespołów. Ja nie wiem, jak to teraz wygląda w Allegro, ale jak tam pracowałam, to ok. 70 zespołów scrumowych było zaangażowanych w tworzenie oprogramowania. 70 razy no 8, 10 osób, bo zazwyczaj tyle liczyły zespoły, no to widzimy jaka to jest skala. No i teraz jak sprawić, żeby ten portal wyglądał spójnie, jeżeli mamy 70 osób pracujących nad tym portalem? No i właśnie po to był tworzony tamten zespół i tworzyliśmy go w duchu zwinnym. Właśnie w taki sposób, żeby oni nie zamknęli się teraz na pół roku, pracując nad tym, jak to ma wyglądać, a potem po pół roku przyjdą do zespołów scrumowych i powiedzą: „Proszę bardzo, to jest wasz play book! Teraz możecie z niego korzystać. Enjoy!”. No jakby wiecie, znowu - brakuje tego feedbacku, brakuje wymiany informacji, brakuje już implementowania tego na żywym organizmie. Więc my przyjęliśmy pracę w iteracjach. Przyjęliśmy ten proces planowania, codziennego spotykania się, weryfikowania efektów swojej pracy. Na koniec iteracji sprint review, bo o nim też tak wprost nie powiedziałam. Czyli zaprezentowanie efektów tej swojej pracy, zebranie feedbacku, bo wtedy interesariuszami, czyli tymi klientami, były wszystkie zespoły scrumowe z wewnątrz organizacji i one mogły już dawać feedback, już mogły mówić, jak to wszystko wygląda. Plus na koniec też mieliśmy sprint restrospective, które pomagało nam w wypracowaniu tej lepszej współpracy, bo nagle stworzyliśmy zespół od zero. Spotkały się.. tam były naprawdę mocne indywidualności, więc to trzeba było wszystko pokleić. Tam byli eksperci, każdy ze swojej dziedziny, więc wiecie, no jak się spotykają eksperci, każdy ze swojej dziedziny, to też te emocje, właśnie to ego też często dochodzi do głosu. Trzeba było to wszystko poukładać, więc tu odpowiadając na Twoje pytanie nawet w organizacjach, w których mamy to wytwarzanie oprogramowania, znaczy w sensie inaczej - w świecie IT może to funkcjonować nawet poza zespołami, które wprost wytwarzają oprogramowanie dla klienta, może to pracować w zespołach, nie wiem, marketingowych. Ja pracowałam z moją przyjaciółką, która prowadzi swoją agencję interaktywną. Pracowałyśmy właśnie w takich konsultacjach jeden na jeden, bo też takie usługi świadczę. Kiedy ona zaczynała i jak jej o tym wszystkim opowiadałam, ona mówi: „Boże! Ja chcę część z tych rzeczy zaimplementować u siebie w ogóle”. I wiecie, i oni mają klientów, z którymi pracują, bazując na na iteracjach, właśnie na przygotowywania tego Product Backlogu, na reagowanie na zmiany. Mają te sesje feedbackowe, mają retrospektywy, mają podsumowania. Jakby jest ten ciągły feedback, że ona po prostu no nie zaimplementowała całości Scruma, bo faktycznie też w Scrum Guide, jeżeli chodzi o wytwarzanie oprogramowania, jest wprost powiedziane, że zacznij zaimplementowaniem całości, bo to całość daje tą wartość. Potem, ja tak uważam, możesz eksperymentować w zwinności, jak się nauczysz tych podstaw. Ona w swoim wzięła po prostu jakieś elementy, które zaczęły jej fajnie pracować, a jest totalnie oderwana od wytwarzania oprogramowania.

Najczęstsze błędy w zespołach scrumowych

Aga:
Super! To też jest odpowiedzią na to, że można wykorzystywać Agile'a nie tylko w IT. Można wykorzystywać tak na co dzień. To jeszcze Asia jakbyś mogła powiedzieć, jakie są najczęstsze błędy, które Ty napotykałaś na swojej drodze w zespołach scrumowych? Możemy, nie wiem, to zawęzić albo do retrospektywy, albo może daily, jakby jakieś takie przy okazji jakbyś mogła też dać jakieś takie wskazówki, jak udoskonalać siebie w tym setupie scrumowym.

Joanna:
Wiesz co? No pierwszą rzeczą to było niedanie sobie przestrzeni na takie zrozumienie tego procesu i poeksperymentowanie z nim. No bo to dla mnie, tak jak mówiłam, na początku tego stażu wydawało się abstrakcyjne, że grupa osób nie zarządzana przez managera pracuje w dwutygodniowej iteracji i na koniec ma już dostarczyć działający fragment oprogramowania. No jak? Jak może być zespół w stanie napisać w dwa tygodnie kod, który będzie działać i jeszcze przejść przez ten etap testowania, weryfikacji i jeszcze to ma w jakiś sposób wyglądać. I w momencie, kiedy jeszcze niedostatecznie rozumiemy ten proces i rozumiemy, jak każdy z jego elementów przynosi wartość, to bardzo często jest tak, że zespół mówi: „Dobra, nie róbmy daily! Przecież wiemy, co mamy robić. Mamy plan” i pomija pewne elementy. Tylko daily służy synchronizacji i ja bardzo, jakby dosyć szybko zrozumiałam, że moją rolą jako Scrum Mastera nie jest teraz wychodzenie na piedestał i mówienie: „Słuchajcie, nie! Daily jest w Scrum Guide najważniejszą rzeczą... blablabla” i wiecie, takie karanie, traktowanie ten zespół, znowu i tu wchodzi aspekt analizy transakcyjnej, która też jest bardzo ciekawym zagadnieniem i ja z nią też pracowałam z zespołami scrumowymi, prowadziłam warsztaty, uświadamiałam o co chodzi, żebyśmy lepiej rozumieli siebie, swoje interakcje. Więc nie z pozycji rodzica, który karci, tej Scrum mamy, o której mówiłam, tylko z pozycji dorosłego, który podchodzi do tego zwinnie. Czyli jeżeli zespół mi mówił: „Nie chcemy robić daily”, ja mówię: „Dobra, mamy teraz sprint dwa tygodnie, to zróbmy eksperyment. Przez dwa tygodnie nie robimy daily? Spoko, co chcecie tym uzyskać?”,  „Nooo więcej czasu, bo wiadomo, co robimy. Jakby zawsze 15 minut to wybija z rytmu jakiejś pracy”. Mówię:  „Nie ma sprawy, zapiszmy!”. I za każdym razem, kiedy zespół rezygnował z daily, wracał do niego po kilku dniach trwania sprintu. No bo brakowało tego miejsca na tą synchronizację, bo nagle okazywało się, że coś się rozjeżdżało, bo nagle okazywało się, że ktoś coś zrobił, ale komuś nie powiedział. Albo ktoś wchodził i mówił: „Ej słuchajcie, muszę z Wami pogadać!” czyli było to rozpraszanie z pracy. Jeżeli daily ma ramę, że maksymalnie 15 minut, bo te time boxy w Scrumie też są bardzo istotne, czyli ten maksymalny czas do trwania jakiegoś wydarzenia, żeby efektywnie, żeby tego nie przeciągać, żeby nie robić z tego nie wiadomo jakich rozmemłanych rzeczy, to wiecie, nagle ktoś mówił: „Ej, pogadajmy” i robiła się godzina gadania o wszystkim, tylko nie o tym, co było celem. Więc jakby taka pierwsza rzecz, czyli rezygnowanie, szczególnie na początku, z tych filarów wydarzeń czy z tych ról, które powoduje, że nie mamy zaopiekowanego odpowiednio tego procesu, więc najprawdopodobniej zaczną się pojawiać ipedimenty, przeszkody, które by nie występowały, kiedy te elementy by były.

Druga rzecz to, w organizacjach, które też nie do końca rozumieją, łączenie roli, czyli np. Scrum Master i Product Owner w jednym. No kurczę, to jest trudne, bo jeden zarządza procesem, drugi zarządza produktem. W jaki sposób Product Owner ma wiedzieć, jak się rozwijać, jak udoskonalać, co robi nie tak, skoro równocześnie jest Scrum Masterem, które w jakiś sposób obserwuje i wspiera tą pracę? Albo wykluczanie roli Scrum Mastera ze względu na budżet, no bo w sumie żeby powstał produkt to potrzebujemy kogoś kto da wizję i kogoś kto to wytworzy. No i co ten Scrum Master robi? Wiecie jakby, no i co, rozmawiasz z ludźmi? Okej, super! No ale ludzie są dorośli, przecież porozmawiają. I jakby pozbywanie się tej roli, która jest taką... pokazuje inną perspektywę. Może być taką kamerą, którą po prostu czasami można włączyć, odtworzyć i pokazać, co się dzieje, no bo nie jest zaangażowana w ten proces, przez co może się w jakiś sposób zdystansować. No bardzo częstą rzeczą, chociażby podczas sprint retrospective jest sunięcie po tej powierzchni. Czyli zespół gada o problemach, które wydaje mu się, że są... no inaczej albo inaczej - po pierwsze, zrzucanie odpowiedzialności na kogoś innego, czyli zaprzeczanie działania zgodnie z tymi wartościami Scruma, zaangażowania i brania odpowiedzialności na siebie, jakiejś odwagi, czyli dopatrywanie się swoich niepowodzeń w czynnikach zewnętrznych. To przez inny zespół, to przez dział marketingu, to przez to, że ktoś nam czegoś nie dał. I wtedy jakby rozwiązujemy problem, nad którym nie mamy sprawczości, zrzucamy z siebie odpowiedzialność. A tu jest super rzecz, i to znowu też w takim prywatnym życiu, że jak coś nam się nie uda, to też mamy tą skłonność „A ja nie napisałam maila, bo on mnie rozproszył” albo nie wiem „Zapomniałem o tym, bo przyszłaś do mnie i do mnie zaczęłaś mówić”. No, no nie? Jakby tak, zdarzyło się coś takiego, ale to Twoją odpowiedzialnością było pamiętanie o tym, więc zamiast zrzucać na mnie tą winę, to zastanów się, jak możesz zaopiekować sprawę niezapominania o rzeczach. Czyli ja uważam, że wszystko o czym mamy pamiętać jest tym, co z dużym prawdopodobieństwem zapomnimy, dlatego wszystko sobie zrzucam na, akurat ja najprościej używam notatnika, aplikacji notatnik na telefonie czy na komputerze, która jest współdzielona razem z moim mężem i jakby w takiej naszej codziennej pracy, jeżeli pojawia się jakiś temat do zaopiekowania, to od razu wrzucam go sobie na listę zadań, żeby raz - o tym nie myśleć, dwa - nie odrywać mojego męża od tego, co on właśnie w tym momencie robi. No i trzy, żeby nie zapomnieć. Więc jeżeli o czymś zapomnę, to pierwsze co patrzę na siebie co ja mogę zrobić lepiej, a nie na świat zewnętrzny, który jest przecież taki straszny i beznadziejny i na pewno tylko mi nie sprzyja, a wszystkim innym sprzyja. Więc to takie obwinianie na zewnątrz, to takie dotykanie problemów, które wydają nam się problemami, czyli... tak spróbuję jakoś z codziennego życia o tym pomyśleć. Hmmm o, że np. spóźniłem się, to trochę z tym obwinianiem jest. Przypomnijcie sobie jak w szkole brzmiały uzasadnienia spóźnienia - przepraszam za spóźnienie, autobus mi uciekł.

Aga:
Hahaha! Taak, klasyka!

Joanna:
Okej, okej! Dobra nie, nie no to autobus Ci uciekł... a może Ty wyszłaś za późno? Albo Ty nie dopilnowałaś czegoś? Nie? I to jest jedno. I teraz, jeżeli ktoś się często spóźnia, to my możemy zacząć np. myśleć „on się spóźnia, bo wychodzi za wcześnie, znaczy za późno”, nie? I to może nam się wydawać, że rozwiązaniem naszego problemu jest wychodzenie wcześniej z domu i wtedy na pewno się nie będę spóźniać. Ta osoba zaczyna wychodzić wcześniej z domu, no ale wciąż się spóźnia. No i wiecie, jakby dotknęliśmy ten problem. Nie zadaliśmy sobie, to jest super technika, którą polecam każdemu, 5 razy why, czyli 5 razy dlaczego, żeby dochodzić do realnego, jakby do tego źródła naszego problemu. Bo może się okazać, że ta osoba wychodząc z domu zawsze jeszcze pogada z sąsiadką, która co rano jest w ogródku albo zawsze jeszcze wchodzi do sklepu kupić kanapkę, no bo musi mieć śniadanie do pracy, a w tym sklepie jednego dnia nie ma kolejki, ale drugiego dnia jest kolejka, jednego dnia kasa nie działa, drugiego nie działa, trzeciego dnia nie ma kanapki, więc musi iść do innego sklepu. Więc co z tego, że ta osoba wyjdzie wcześniej, jak problem leży gdzieś indziej. I oto i to jest też częsta pułapka, nie? Że jakby nie dochodzimy do źródła i z tym 5 razy why, to może powiem krótko taką historię, bo ona jest uświadamiająca, bo ja też zawsze lubię zasiać to ziarno, dlaczego warto coś robić, a nie mówić tylko, że warto. I była taka historia w Waszyngtonie. No tam przepiękne te budynki administracji publicznej i wiecie, z takiego one są często białego kamienia, tak jak Biały Dom. No i wszystkie budynki w jakiejś tam okolicy wyglądały dobrze, ale był jeden, który był w opłakanym stanie. No i zatrudniono gościa, który miał sprawdzić, o co w ogóle chodzi, no bo oni robią wszystko, czyszczą ten budynek, stosują nie wiadomo jakie preparaty, ale de facto to tylko pogorsza sprawę. No i on przyszedł pod ten budynek, no i zadał pierwsze pytanie: „Słuchajcie, dlaczego ten budynek wygląda w taki sposób?”. No i mu powiedzieli, że no: „Musimy bardzo często ten budynek myć, używamy mocnych chemikaliów, no i niestety na ten kamień te chemikalia działają w taki sposób, że on tylko traci na jakości”. „No dobra, czyli musicie go myć, no ale dlaczego musicie go myć?”,  „No bo na tym budynku gromadzą się gołębie, które wydalają się na ten budynek. W związku z tym my musimy te kupy sprzątać, używając tych trudnych chemikaliów”. On mówi: „No dobra, no spoko. No ale jest tyle budynków w okolicy, to dlaczego gołębie siadają akurat na tym. Skąd są te gołębie?”. Zaczęli drążyć i się okazało, że na tym budynku są pająki. Pająki, które czy tam jakieś robaczki, które przyciągają te gołębie, bo one te robaczki sobie zjadają. No więc ok, poszliśmy dalej, czyli już mamy te, mamy te robactwo. No ale skąd się bierze to robactwo, skoro nie jest na innych budynkach? I okazało się, że na ten budynek było zwrócone światło, które powodowało, że te pająki lgnęły do tego światła. Jak były pająki, pojawiały się gołębie, jak pojawiały się gołębie, no to tam ciągle siedziały, srały i budynek trzeba było czyścić chemikaliami. Wystarczyło lampę przekręcić na inną stronę. Zniknęły pająki wraz z nimi gołębie, wraz z nimi odchody gołębi. Budynku nie trzeba było już czyścić. I to był ten proces dochodzenia, bo moglibyśmy ciągle myśleć, jakie inne środki chemiczne użyć, jak przeganiać te gołębie. One i tak by wracały, bo nie mielibyśmy rozwiązanego tego źródła problemu. Więc to też jest taka rzecz, na którą warto zwracać uwagę, nad którą warto pracować, znowu i w pracy zespołowej, i w życiu prywatnym, żeby dochodzić do tego źródła. No tak myślę, że to są takie core'owe rzeczy, no bo to, że relacje, to jako praca jak z ludźmi właśnie, to myślenie, ten mindset w ogóle agile'owy, bo to jest cały mindset, że my jako zespół dostarczamy wartość, że my razem mamy największą moc, że naszym celem nie jest konkurowanie, udowadnianie sobie, właśnie łechtanie tego ego, o którym już nieraz wspomniałam, tylko naszym celem jest wypracowanie takiego fajnego środowiska pracy, w którym funkcjonujemy, dzięki któremu pracuje nam się przyjemnie, jesteśmy zaangażowani.

No tu jeszcze w takim podejściu, tym agile'owym dochodzi ten aspekt, który często jest pytaniem „No dobra, gadasz o tym Scrum Masterze, który tu może z tymi ludźmi. Gadasz o samoorganizującym, autonomicznym zespole, który ma wpływ na swoją pracę i decyzje. No a menadżerowie, a szefowie? A przecież tymi ludźmi ktoś musi zarządzać?”. No i właśnie tymi ludźmi, nie chodzi o to, żeby zarządzać ludźmi. Chodzi o to, żeby zarządzać ich zaangażowaniem. O to, żeby tworzyć takie środowisko pracy, w którym ludzie będą chcieli pracować, w którym będą chcieli, wiecie, będą przychodzić i będą czuli, że mają wpływ na ten produkt. No bo znowu, przechodząc do kolejnych teorii Daniel Pink i jego teoria drive'a trzech rzeczy, które nas motywują w pracy: cel, autonomia, mistrzostwo. I właśnie na tym też bazuje podejście zwinne. Jeżeli pozbawisz ludzi celu, ich zaangażowanie będzie spadać i motywacji wewnętrznej w zasadzie tym nie będzie, a pieniądze są krótko motywującym czynnikiem. Jeżeli pozbawiasz ludzi autonomii, no jakby myślę, że wy sobie równie jak ja nie wyobrażacie pracy, że ktoś przychodzi do was i mówi: „To konkretnie zadanie i pracujcie tak dzień w dzień”. Będą osoby, które lubią więcej tego sterowania, kierowania, ale nie pozostawiając sobie ani procenta wpływu na to, co robimy, to jest niszczące. To jest po prostu budzące frustrację, budzące zniechęcenie i na pewno niepobudzające tego, że chcesz jeszcze więcej dać z siebie w pracy. Więc menadżerowie, bo ja byłam w tej roli, muszą pamiętać o tych trzech rzeczach i oczywiście reagują na to, co się dzieje w zespole. Mogą pomagać, pracują z osobami jeden na jeden, ale po to, żeby budować ich zaangażowanie, żeby rozwijać ich skille, żeby pomagać budować tą ścieżkę rozwoju, dostarczać narzędzia, dostarczać takie środowisko w pracy, w którym po prostu ja przychodzę i wiem, że mam ochotę to robić. Mam ochotę dać z siebie jeszcze więcej i zależy mi na tym produkcie. I to jest, i to jest takie clue. No i właśnie co? Błąd - menadżerowie, którzy znowu, potrzebują, nie rozumieją, potrzebują się zaangażować, ingerują w pracę zespołu albo chcą kierować tą pracą, albo działają za pomocą Managementu 1.0 czy 2.0 czyli Command i Control zamiast tego co gdzieś bardzo mocno znowu spina się z Agilem, czyli nowe pojęcie Managementu 3.0 opartego właśnie na tym podejściu zwinnym, na autonomii i na interakcji, na częstym feedbacku, na pracowaniu nad mistrzostwem, czyli rozwijaniu tych kompetencji, które są w nas dobre, zamiast skupiania się na tym, że w czymś jesteśmy beznadziejni i tam pompowania tej energii. No, myślę, że na tym skończę ten wątek.

„Umiem inwestować i inwestuję”

Aga:
Joanna, bardzo dużo opowiadałaś o tym, jak właśnie jako Agile Coachka rozwijasz tak naprawdę rozwój innych, znaczy nie - rozwijasz inne osoby w zespole. To teraz ostatnie pytanie do Ciebie. Na rozwoju jakich umiejętności Ty no chciałabyś się skupić w najbliższym czasie? I to absolutnie nie muszą być zawodowe rzeczy.

Joanna:
Tak, pierwsze co mi przyszło do głowy, jak zobaczyłam wcześniej to pytanie, to było, że teraz mocno w moim obszarze zainteresowań jest inwestowanie. I nawet mam taką swoją afirmację, ponieważ sobie prowadzę journaling, żeby właśnie dla siebie prywatnie zrzucać te różne z głowy, obserwować sobie swoje emocje, to co się we mnie dzieje. Plus też zapisuję takie zdania, które dają mi taki kierunek mój, gdzie ja chcę być, gdzie się rozwijać. I właśnie od jakiegoś miesiąca wybrzmiewa tam zdanie „umiem inwestować i inwestuję”, więc nawet już zainwestowałam w kurs dotyczący tego. Ja gdzieś przy tym inwestowaniu już od kilku lat jestem, ale chciałabym wejść na inny poziom, bo czuję, że ta moja wiedza i moje sposoby na to, jak pozyskiwałam na ten temat informacje, trochę się wyczerpały. Plus bardzo mocno jestem fanką tego, że jeżeli ja mam przeznaczyć X czasu na to, żeby zdobyć jakąś wiedzę, która już gdzieś istnieje, żeby ją przyswoić, zweryfikować czy jest cenna, to jak sobie policzę koszt tego kontra zainwestować w kogoś produkt, gdzie ta wiedza już jest zebrana, gdzie to już zostało zweryfikowane i gdzie ktoś jest w tym ekspertem, to ja bardzo chętnie też z taką myślą rozwoju dla tej osoby, docenienia jej pracy, wolę przekierować tam te pieniądze. Więc w kurs też zainwestowałam i to. No na tym będę chciała się skupić.

Aga:
Super, to trzymam kciuki za pomyślne wiatry w inwestycjach.

Joanna:
Dzięki!

Aga:
To jeszcze na sam koniec powiedz Joanna, gdzie można Cię znaleźć w Internecie?

Joanna:
Dobrze. No to zapraszam na slowtalks.pl, które spaja te wszystkie rzeczy, które robię. Tam zawsze pojawiają się informacje o podcaście. Podcast też jest w Slow Talks, na Spotify, iTunes i YouTubie. Ja też co dwa tygodnie wysyłam tzw. slowletter, czyli newsletter  z treściami rozwojowymi, z jakimiś tematami zaczepnymi, rozkminkami, inspiracjami, które zbieram, książki, podcasty, filmy, artykuły. Więc to wszystko dzieje się na portalu Slow Talks. Tam jest jedno miejsce, z którego można sobie wychodzić. No i zapraszam na mój Instagram - joanna.tobola. Bo tam również wszystko na bieżąco się dzieje. Można poobserwować to, jak właśnie to moje digital nomadzkie życie też wygląda. W tym momencie akurat jestem na wakacjach w Polsce, bo ten okres wakacji w Polsce zawsze jest tym cennym czasem, w którym lubię czerpać z tego, co daje polskie lato. Więc teraz moje życie w Polsce, w Warszawie lub w innych miejscach, ale myślę, że na jesieni znowu w jakimś miejscu mnie zobaczycie. Jeszcze nie zdradzam gdzie, bo w duchu właśnie tego zwinnego podejścia kiedyś naprawdę potrzebowałabym już wiedzieć, mieć plan, najlepiej zarezerwowaną miejscówkę, ale też te trzy lata tego takiego życia trochę w niepewności nauczyły mnie to, że ta niepewność może być też fajna i dużo rzeczy po drodze może być różnych. W związku z tym nie potrzebuję już teraz wiedzieć. Mam jakiś cel, mam jakiś kierunek, ale jeżeli po drodze wydarzą się rzeczy, które mnie zaskoczą, to po prostu wybiorę coś innego.

Paulina:
Super! No mamy nadzieję, że jeszcze będziemy miały okazję się spotkać, żeby pogadać właśnie o tych trzech latach, które minęły już w życiu digital nomadzkim, bo to też jest super ciekawy temat, więc mam nadzieję, że to nie jest nasze ostatnie spotkanie. A już teraz bardzo Ci dziękujemy i do zobaczenia niebawem!

Joanna:
Ja też Wam bardzo dziękuję i przyznam, że jeszcze w żadnym podcaście nie mogłam tyle poopowiadać o Agile'u. A jak słyszycie moje beztroskie dziecko aż całe skacze, bo po prostu ja tym żyję, lubię to i serio to nie jest tylko dla osób tworzących oprogramowanie, tylko dla programistów, tylko każdy z nas może czerpać coś z tego podejścia do tego, żeby życie stawało się lżejsze, łatwiejsze i żeby właśnie gdzieś tam słuchać siebie, żyć w zgodzie ze sobą. To jest moja misja, więc dzięki, że mogłam też u Was o niej poopowiadać.

Aga:
Super! Bardzo się cieszymy i do zobaczenia. Dzięki Asia!

Joanna:
Do zobaczenia!

Paulina:
Bardzo dziękujemy Wam za to, że byliście z nami. Jeśli szukacie pracy, koniecznie sprawdźcie stronę sponsora tego odcinka, czyli the:protocol.it - serwis z konkretnymi ofertami pracy dla branży właśnie IT. Notatki i linki do tego podcastu znajdziecie na naszej stronie: designpractice.pl/036.

Aga:
A jeśli podoba Wam się nasz podcast, koniecznie zasubskrybujcie go w swojej platformie podcastowej lub na YouTube. Śmiało zostawcie swoje wrażenia w komentarzach. Będziemy na nie bardzo czekać i oczywiście za wszystkie jesteśmy bardzo, bardzo wdzięczne!

Paulina:
A na nowe odcinki możecie liczyć w każdy pierwszy i 15. dzień miesiąca. Pamiętajcie też o zapisaniu się do naszego newslettera, żeby nie przegapić żadnego nowego odcinka. Wystarczy wejść na: designpractice.pl. Do usłyszenia za 2 tygodnie!

‍