Marcin Aks Grochowina – o zwinności w Organizacji

PS: Paweł Sala
MG: Marcin Grochowina

PS: Cześć. Ja nazywam się Paweł Sala, a to jest podcast Email i Marketing, odcinek osiemnasty. Podcast Email i Marketing to audycja, z której dowiesz się jak lepiej realizować swoje działania marketingowe i nie tylko. Dzisiaj pierwszy odcinek z serii poświęconej kulturze organizacji, zarządzaniu organizacją. Podczas tej rozmowy poruszamy tematy, związane przede wszystkim ze Scrumem, zwinnymi metodami zarządzania i o tym jak staramy się to wprowadzić do FreshMaila.

PS: Witam Cię w kolejnym odcinku videocastu E-mail i Marketing. Dzisiaj moim gościem jest Marcin Grochowina z Scrum Master FreshMaila i będziemy rozmawiać o, no właśnie, o Agile, o Scrumie, o bardzo zwinnym podejściu do zarządzania produktem, projektami, generalnie o zwinności w organizacji. Zapraszam Cię bardzo gorąco do obejrzenia całego odcinka.

PS: Marcin, zaczynałeś swoją przygodę z szeroko rozumianą branżą interaktywną jako project manager, z taką też rolą zostałeś zrekrutowany, zwerbowany do Fresh Maila. Powiedz mi proszę, bo to było już kilka lat temu, pięć?

MG: Pięć.

PS: Pięć lat temu. Na czym wtedy ta praca polegała? Dla Ciebie tak jako project managera?

MG: Hm, to znaczy ja zanim dołączyłem do Fresh Maila bardzo dużo pracowałem w systemie takim typowo projektowym. To znaczy projekty dla klientów, które miały jakiś określony budżet, określony deadline, określony zespół do realizacji tych projektów. Natomiast w zasadzie od samego początku jak zaczynałem pracę bardzo mocno stawiałem nacisk na to, żeby… na rozmowę z zespołem deweloperskim. W zasadzie jak zacząłem swoją pracę jako junior project manager, pamiętam pierwszą rozmowę z zespołem deweloperskim, który był zaskoczony tym, że przychodzi ktoś do nich zapytać ich, ile im to zajmie, bo zazwyczaj wcześniej wyglądało to tak, że ktoś z góry sobie estymował bez konsultacji z nimi złożoności projektu i następnie oni zostawali postawieni przed faktem dokonanym, musicie zrobić coś w określonym czasie, zazwyczaj w czasie nierealnym. Później gdzieś na przestrzeni lat jeszcze pracując w branży interaktywnej miałem styczność z takim około rocznym projektem, gdzie rozwijaliśmy czy tworzyliśmy w zasadzie grę na iOS-a i to był taki moment, kiedy stwierdziłem, że te wszystkie rzeczy, którymi się interesowałem, które próbowałem wdrażać w różnych zespołach przy krótkich projektach związane ze Scrumem, przy jakimś większym projekcie mają nie chcę powiedzieć, że sens, mają na pewno, są dużo bardziej użyteczne.

PS: Okej.

MG: Nie chcę, żeby to zabrzmiało, że to jest herezja, że nie można robić Scruma w małych projektach, bo jak najbardziej go można robić, natomiast ja stwierdziłem, że najlepiej się czuję rozwijając dłuższy projekt, jakiś produkt i gdzieś się zdzwoniliśmy wspólnie. Okazało się, że jest możliwość dołączenia do zespołu FreshMaila i tak też się stało te pięć lat temu. No i na początku byłem w zasadzie project managerem, przy czym od początku mieliśmy taki układ, że będziemy tego Scruma wprowadzać. Ja jeszcze wtedy pracowałem bardzo mocno narzędziowo, to znaczy traktowałem Scruma jako zestaw pewnych reguł, z których nie do końca wszystkie stosowałem i wydaje mi się, że rozmawiając teraz po latach z wieloma Scrum Masterami czy z wieloma zespołami deweloperskimi to jednak nadal jest taka praktyka, że nie wszystkie reguły gry scrumowej są wykorzystywane w różnych zespołach. No i w trakcie tej naszej pracy gdzieś tam sobie różne etapy testowaliśmy, różne sposoby testowaliśmy, aż przyszedł czas, żeby powiedzieć spróbujmy zrobić Scruma zgodnego ze Scrum Guidem i tak go robimy od ponad dwóch lat, prawie trzech lat.

PS: I przestałeś być project managerem, stałeś się Scrum Masterem.

MG: Tak. Też nie od razu.

PS: Też nie od razu, wiem.

MG: Też nie od razu to się stało, to znaczy w momencie, kiedy postanowiliśmy zrobić dużą kreskę i zacząć korzystać…

PS: Może nawet grubszą, grubą nie, już dużą, ale okej.

MG: Tak. Kiedy stwierdziliśmy robimy restart naszego Scruma, zaczynamy postępować z regułami opisanymi w Scrum Guidzie, wtedy w organizacji było dwóch project managerów, no ale tak naprawdę w Scrumie i w Scrum Guidzie nie ma roli project managera, jest rola product ownera, jest rola scrum mastera, no i tak się podzieliliśmy, że w zasadzie ja jako osoba, która miała dłuższe doświadczenie w produkcie FreshMaila, większe doświadczenie w tym jak on powstawał, przez jakąś chwilę pełniłem rolę product ownera. Natomiast po roku bardzo się cieszę, że mogliśmy odbyć szczerą rozmowę i nie ukrywam, że zawsze dla mnie, ja nigdy nie byłem osobą produktową, to był bardzo ciekawy eksperyment, natomiast zawsze byłem bardziej osobą od tworzenia zespołów, od budowania relacji między członkami zespołów i moment, w którym wspólnie doszliśmy do wniosku, że mógłbym zająć się rolą Scrum Mastera. To był moment w ogóle, w którym chyba najbardziej w życiu rozwinąłem skrzydła. Ja bardzo się cieszę, że mogłem to zrobić.

PS: Okej. Tak, natomiast o ile project manager, kierownik projektu jest czymś, co większość widzów może zrozumieć bez większego problemu, natomiast, no scrum master to można tłumaczyć na… przetłumaczyć dosłownie, natomiast z czym to się w praktyce, na czym Twoja praca w praktyce polega?

MG: Najłatwiej jest ją przetłumaczyć dosłownie.

PS: Okej.

MG: To znaczy Scrum Master jest mistrzem Scrum’a.

PS: A Scrum znaczy?

MG: Scrum to jest sposób organizowania pracy zespołu, niekoniecznie deweloperskiego. W zasadzie wywodzi się ze sposobów zarządzania czy organizowania pracy zespołów deweloperskich, natomiast w tym momencie to już bardzo mocno ewoluowało również w naszej organizacji i to jest taki zestaw dobrych praktyk, w jaki sposób organizować swoją pracę, żeby móc w sposób szybki weryfikować pewne hipotezy, pewne eksperymenty, przede wszystkim w określonych odstępach równych czasu dostarczać pewne ukończone… w Scrumie to się nazywa incrumy, czyli ukończone działające funkcjonalności, elementy produktu. Tak, to jest w zasadzie Scrum, czyli taki sposób organizacji swojej pracy, żeby co określony czas dostarczać coś naszym klientom czy naszym użytkownikom, natomiast Scrum Master jest osobą, która ma sprawiać, żeby ten Scrum się dział, to znaczy jest takie pojęcie, tłumaczy się bycie Scrum Masterem jako servant liderem, jako takim liderem służalczym i jest pełna pułapka w tym.

PS: Służalczym czy służącym?

MG: Służ…

PS: Okej, potato, potato.

MG: Nie stosujmy, zostańmy przy angielskiej nazwie servant lider. Służebnie, o.

PS: Służebnie, okej.

MG: Służebnie. Lider służebny, tak. I to się sprowadza do tego, że w zasadzie Scrum Master ma wspomagać zespół w dążeniu do samoorganizacji. Przez samoorganizację rozumiemy dążenie do tego, żeby zespół mógł samodzielnie podejmować decyzje i brać odpowiedzialność za to, co wytwarza. I w zasadzie ta rola ma pomagać zespołowi w takiej codziennej pracy, żeby dążyć do osiągnięcia tego sposobu pracy.

PS: Okej, natomiast, no bo mówisz, że zespół sam się organizuje, to jest coś nowego, czego zazwyczaj nie ma, jeżeli mówimy o zwykłym project managemencie, gdzie mamy normalnie water falla i ten system nakazowo-rozdzielczy, więc powiedzmy mamy zespół, który sam próbuje oszacować, co zrobi, kiedy zrobi i jak zrobi, natomiast bardziej mnie jakby zainteresowało to, co powiedziałeś, weźmie odpowiedzialność za to, co robi. No bo teoretycznie jak ktoś pracuje w firmie, pracuje w jakimś zespole, bierze odpowiedzialność za fragment kodu, za fragment roboty, którą wykonał, natomiast czy Ty widzisz tutaj jakąś subtelną różnicę pomiędzy tym, że mam wykonać swoją pracę dobrze, a tym jak mam ją wykonać i wziąć odpowiedzialność w Scrumie czy generalnie szerzej nazwijmy to, w Agile, w podejściu agile’owym. Bo ja tak zastanawiam, ja jak patrzę jak my podeszliśmy do tego, miałeś zrobić robotę, zrobione. Coś jest nie okej, no to jest nie okej, no i w tym momencie jakby jest tłumaczenie się do przełożonego, a tutaj nam się nagle pojawia, że nie ma tłumaczenia do przełożonego, a przynajmniej powinno być.

MG: Znaczy bardzo ważnym elementem Scrum’a jest w ogóle zrozumienie, co znaczy, że coś jest zakończone. Jest coś takiego jak definition of done, definicja ukończenia zadania czy w zasadzie tego nad czym pracujemy i można powiedzieć, że to jest pewnego rodzaju kontrakt, który jest ustalany przez zespoły i w tworzeniu takiego kontraktu chodzi o to, żeby każdy z członków zespołu w ten sam sposób rozumiał, co to znaczy zakończona praca. To znaczy bardzo często spotykałem się z takim podejściem, że deweloper, który miał wykonać jakieś zadanie, kończył je na etapie, na którym uważał, że to jest już, że on już zakodził wszystko, co miał do zakodzenia, kropka. Natomiast jest jeszcze etap testowania, jest jeszcze etap jakichś modyfikacji, jakichś poprawek, jest etap tak naprawdę dostarczania tego użytkownikowi. No i to, w jaki sposób pracujemy, to budujemy taką świadomość, że kod, który tworzymy to nie jest po prostu linijka kody, czyli jakiś tam ciąg znaków, który powstaje, tylko to jest wszystko, co tworzymy, to jest tak naprawdę coś, z czego będą korzystali nasi klienci, nasi użytkownicy, w związku z czym każdy siadając do tworzenia czegokolwiek tak naprawdę w tym, w jaki sposób pracujemy we FreshMailu, dążymy do tego, żeby brał odpowiedzialność za to, jaką wartość przyniesie to naszym użytkownikom, a nie było to po prostu sztuką dla sztuki.

PS: Okej. U nas w Scrumie jak zaczęliśmy go wprowadzać to, może nie jak zaczęliśmy, po tej grubej kresce, która gdzieś tam się pojawiła dwa lata temu, z kawałkiem nawet.

MG: No ze trzy lata.

PS: Trzy lata temu. Nagle pojawiły się pewne eventy w organizacji, tak? W sensie pojawiły nam się retrospektywy, pojawiły nam się stand up’y, pojawiły nam się dema. Tego wcześniej nie było albo było to w sposób taki trochę kadłubkowy zrobione. Jakbyś spróbował przez chwilę zastanowić się jak zwłaszcza retrospektywy, czyli coś, czego absolutnie wcześniej nie robiliśmy, wpłynęło nie na samą pracę nad produktem, nie na samą pracę projektową, którą realizowaliśmy, ale generalnie na może górnolotnie, kulturę organizacji albo pewien main set w organizacji, bo tu myślę, że to jest coś, czego książki zazwyczaj nie opowiadają. Generalnie wszyscy mówią Scrum jest fajny, bo dowozi fajne rzeczy, a tutaj nagle obok dowożenia fajnych rzeczy pojawia nam się coś zupełnie, jakaś pochodna, natomiast pochodna, która zmienia wszystko albo zaczyna zmieniać.

MG: Okej, to jest tak, że tak jak wcześniej wspomniałem albo nie wspomniałem, ja przez bardzo długi czas podchodziłem do Scruma bardzo wybiórczo, to znaczy zespoły, z którymi pracowaliśmy, pracowały w sprintach, mieliśmy planowania, czyli taki etap, gdzie na początku sprintu, czyli tego okresu, w którym powstaje ten wspomniany wcześniej inclement, zastanawialiśmy się, co w tym okresie jesteśmy w stanie stworzyć. Mieliśmy daily scrumy czy też stand up’y, czyli takie codzienne spotkania, na których spotykaliśmy się całym zespołem i omawialiśmy bieżący stan prac, natomiast jedną z rzeczy i tu myślę, że to był mój największy błąd na przestrzeni lat mojej pracy ze Scrumem. Pierwsza rzecz, którą wyrzucałem w każdym zespole z naszego Scruma to były retrospektywy. Myślę, że dlatego, że nie wiedziałem w ogóle czym są, po co one są, do czego one służą. Jasne, czytałem o nich bardzo dużo, nigdy nie przetestowałem ich w praktyce i wydawały mi się wtedy, że w zasadzie tyle tych spotkań w tym Scrumie jest, że po co dokładać zespołowi kolejne spotkanie, na którym będą rozmawiać o tym jak pracuję. Aż pojawił się w naszej organizacji Wojciech Ptak, którego muszę tu wspomnieć, bo w zasadzie ja…

PS: Znaczy…

MG: Ze Scrumem pracuję od dziesięciu lat.

PS: Wojtek nam narysował grubą kreskę.

MG: Tak.

PS: I pokazał jak pewne rzeczy trzeba robić, po prostu.

MG: Tak, to jest śmieszna sprawa, bo Wojtek się pojawił, przez jakiś czas się przyglądał temu, w jaki sposób pracujemy. My jeszcze wtedy planowaliśmy w godzinach czy wróżyliśmy z fusów wydając nam się, że planujemy. I Wojtek kiedyś zainicjował spotkanie, na którym wziął ówczesnych project managerów, czyli mnie i Tomka, z którym wówczas pracowaliśmy i stwierdził chciałbym wam opowiedzieć o planowaniu w story pointach, w punktach. Bo tak naprawdę przyglądając się z boku wydaje mi się, że to planowanie na godziny jest nie do końca efektywne.

PS: Nawet może nie efektywne, tylko prawdziwe.

MG: Prawdziwe, chyba to jest właściwe słowo. No i w zasadzie z tej prezentacji na temat różnicy między godzinami a story pointami zrodziła się prezentacja na temat Scrum Guide’a i pamiętam, że Wojtek był taki trochę, zastanawiał się, co z tego dalej wyniknie, to znaczy czy zaczniemy to wdrażać stopniowo, w jaki sposób w ogóle do tego podejdziemy, a my wróciliśmy po weekendzie i stwierdziliśmy albo grubo, albo wcale, zresztą to był taki moment, kiedy było też sporo frustracji w zespole, że ten Scrum, z którego korzystamy ma się nijak w ogóle do tej rzeczywistości, do tej utopii, która jest opisywana w książkach na temat zwinnych sposobów podejścia do programowania. No i zaczęliśmy robić go zgodnie ze Scrum Guidem, gdzie jednym z elementów jest właśnie retrospektywa, strasznie długi wstęp, ale dochodząc do odpowiedzi na Twoje pytanie.

PS: To ja tylko tak, zrobię jedno wtrącenie, bo to tak dziś jakby ktoś wygooglał Wojtka, Wojtek jest naszym CTO.

MG: Tak.

PS: Natomiast w tamtym czasie Wojtek Ptak był znajomym naszym, to znaczy moim znajomym i bardziej mojego wspólnika Krzysia, i wtedy go poprosiliśmy, żeby nam pomógł, skonsultował z nami czy w roli konsultanta się pojawił jako ktoś, kto się zna na big data, na analizie danych, na wszystkim, co nie było związane z zarządzaniem IT jako takim, tylko na pewnym bardzo technicznym podejściu do jednego problemu, a jakby wyszło przy okazji z tego, że w sumie pokaże, potrafi nam pokazać troszkę inny sposób pracy i troszkę mniej, znaczy nie troszkę, odmienił to jak ta…

MG: To znowu jeszcze zanim dojdę do retrospektyw dodam.

PS: Dobra, dobra.

MG: Że tak, no jakby pojawienie się…

PS: Będzie laurka dla Wojtka.

MG: Dokładnie. Pojawienie się Wojtka w tej organizacji było dla mnie bardzo znaczącym momentem w ogóle na mojej drodze do rozumienia, czym jest zwinność, czym jest Agile, czym jest w ogóle kultura organizacyjna i to był taki moment, taki aha, moment, kiedy stwierdziłem okej, wszystkie klocki zaczynają wskakiwać na swoje miejsce. To było nawet bardzo ciekawe, bo w tamtym czasie czy w zasadzie bardzo często chodzę na różnego rodzaju meet up’y, konferencje, spotykam się z różnymi członkami zespołów deweloperskich czy scrumowych i jak słucham sobie na tych spotkaniach problemów, z jakimi przychodzą ci ludzie, to ja w tamtym momencie zacząłem rozumieć, że my w zasadzie mamy wszystkie puzzle w ręku, mamy wszystkie puzzle odwrócone nawet frontami do góry. Mało tego, nawet mamy w zasadzie całą ramkę już ułożoną, tylko trzeba zacząć pozostałe elementy układać do…

PS: Okej.

MG: Tworzyć ten obrazek. I wtedy zaczął się ten cały proces naszej transformacji, już tak wydaje mi się, że ruszył, zaczął ruszać z kopyta, żebyśmy byli fair ze słuchaczami.

PS: Lub widzami.

MG: Lub widzami. Nadal tego obrazka nie ułożyliśmy.

PS: Absolutnie tak.

MG: Natomiast na przestrzeni tych lat myślę, że udało nam się parę elementów ze sobą sparować i fajnie patrzeć, że ten obrazek zaczyna nabierać jakiegoś konkretnego kształtu. Wracając do retrospektyw, tak ta rozmowa będzie wyglądać, bo ja jestem gadułą. Tak, no retrospektywy to jest takie specyficzne spotkanie, na którym zespół scrumowy rozmawia na temat tego, w jaki sposób im się pracowało. To znaczy to nie jest spotkanie, na którym omawiamy szczegóły implementacyjne jakichś konkretnych rozwiązań technicznych, którymi się zajmujemy, tylko rozmawiamy o wyzwaniach, z którymi się spotkaliśmy w trakcie danego sprintu, co nam przeszkadzało, co moglibyśmy czy oczekiwalibyśmy od siebie, jakich zmian, żeby mogło nam się pracować lepiej, produktywniej, zwinniej. I to, co jest dla mnie bardzo ważne, to jest przestrzeń całkowicie bezpieczna, to znaczy wszyscy członkowie, którzy siedzą na tej sali mają prawo powiedzieć, co ich boli, z czym mają problem, ale też co ważne, bardzo mocno trzeba podkreślić, że to nie jest przestrzeń do narzekania, tylko bardzo ważne jest, żeby w trakcie takiego spotkania zdefiniować najważniejsze wyzwania i wspólnie zastanowić się jak tym zespołem, który siedzi, uczestniczy w danej retrospektywie, te wyzwania możemy zaadresować, w jaki sposób możemy je rozwiązać. To nie oznacza, że zespół, którego problem dotyczy, czy jeżeli jest na przykład problem nie wiem, na poziomie organizacji albo na poziomie współpracy z jakimś innym zespołem, czy w obrębie działu, czy z zewnątrz, to nie znaczy, że my musimy za wszelką cenę te problemy starać się samemu rozwiązać, ale to znaczy, że ktoś z zespołu musi wziąć odpowiedzialność za podjęcie rozmowy w ogóle z…

PS: Okej.

MG: Czy doprowadzenia do tego, żeby ta rozmowa gdzieś wyszła poza ten pokój. I to było niesamowite zobaczyć, że zespół, któremu dano szansę porozmawiania na takie tematy, ustalając pewne jakby ramy tej rozmowy, to znaczy, że nie spotykamy się tylko po to, żeby się wypłakać w ramię i wrócić do rzeczywistości, tylko spotykamy się po to, żeby zdefiniować, nazwać na głos nasze problemy i zastanowić się jak je rozwiązać. No to był dla mnie taki moment kurczę, spoko, mamy naprawdę fajnych ludzi na pokładzie, z którymi fajne rzeczy można robić, wystarczyło dać im szansę wypowiedzi, żeby zaczęli działać. To był taki chyba jeden z największych momentów zwrotnych dla mnie.

PS: Znaczy ja Ci powiem, że ja mam takie poczucie, że po pierwszych retrospektywach, może nie po pierwszych, ale po jakimś czasie, gdy te retrospektywy się u nas pojawiły, nagle coś, czego mogłeś nie zauważyć na etapie, na poziomie zespołu IT, pojawiło się to nagle to, że użyję bardzo brzydkiego sformułowania, szeregowy deweloper potrafił podejść do członka zarządu czy nie wiem, spotkać się ze mną, ja pamiętam jak Sebastian, który jeszcze wtedy nie był team leaderem, siedzieliśmy w kolanku, przyszedł i mówi słuchaj Paweł, bo ja nie rozumiem, czemu my pewne rzeczy robimy w taki, a nie inny sposób, to wydaje mi się trochę bez sensu, weź wytłumacz. Nie pamiętam nawet, czego to dotyczyło, bo to jakby nie ma znaczenia, to była jakaś pierdoła, natomiast sama świadomość tego, że przyszedł, powiedział bardzo głośno, że coś mu się wydaje nie okej i nie na zasadzie pokrytykujmy, tylko na zasadzie zastanówmy się czemu to jest nie okej i czy być może ja coś źle rozumiem, czy być może rzeczywiście coś jest nie okej i trzeba się nad tym pochylić, więc to nagle pokazuje, że to wychodzi już poza zespół czy w niektórych wypadkach wyszło poza zespół scrumowy i nagle ta otwartość pojawiła się i odwaga troszkę szerzej, więc myślę, że to taki miało większy impakt, nie tylko na ten zespół.

MG: No.

PS: Tak trochę.

MG: Ludzie i interakcje ponad procesy i narzędzia to jest…

PS: Tak.

MG: Pierwszy, no jeden z elementów manifestu Agile i no dla mnie chyba najważniejszy. Myślę, że nie jest to jakoś wyjątkowo kontrowersyjne, bo nawet Martin Fowler, jeden z sygnatariuszy tegoż manifestu Agile, ostatnio zwrócił na to uwagę, że z tych wszystkich czterech elementów tego manifestu Agile nie bez przyczyny ludzie i interakcje ponad procesy i narzędzia są na początku, bo jest to bardzo ważne, żeby współpracować ze sobą, żeby rozmawiać, żeby tworzyć zespoły, które potrafią się komunikować, potrafią zadawać pytania i jest to dla nich ważniejsze w osiąganiu celów niż tworzenie jakichś wielkich procesów, które powodują, że formalizujemy całą naszą współpracę, co jakby trzeba też zaznaczyć, że…

PS: Taki złoty środek.

MG: Elementy Agile, manifestu, nie mówią, że my stawiamy ludzi i interakcje na piedestale, a pozostała, ta druga część, nie jest ważna, natomiast przedkładamy tą, te pierwsze elementy nad te drugie, bo to prowadzi do celu.

PS: Okej. Dla tych wszystkich, którzy nie zapoznali się, jeszcze nie mieli okazji poznać manifestu, będzie w linku do tego materiału. A zresztą myślę, że trochę więcej linków pojawi się, bo dużo merytoryki takiej technicznej. Natomiast wspominałeś o tym obrazku, co jest myślę piękną metaforą, o tych puzzlach, gdzie ramka jest ułożona, gdzie połączyliśmy pewne fragmenty puzzli, natomiast całego obrazka nie mamy, no i to też szczerze trzeba powiedzieć, że jesteśmy organizacją w transformacji, trwa to dwa lata i to jeszcze pewnie chwilę potrwa. I to nie jest tak, że to się dzieje just like that i nagle wszystko dobrze funkcjonuje. Powiedz mi, bo mamy zespół IT, który bardzo szybko powiedzmy, szybko, za szybko, mówimy o dwóch latach, tak?

MG: Tak.

PS: Ale to jest szybko.

MG: Tak, to też był proces.

PS: Tak. Doszedł do tego, że ta zwinność, Scrum jest bardzo jakby stawiany na… zwinny.

MG: Trzeba przyznać, że jakby dla nas to jest w pewnym sensie środowisko naturalne, bo w tym momencie już bardzo rzadko spotyka się doświadczone zespoły, które nie pracują zwinnie.

PS: Okej.

MG: Więc dla nas jakby jest to… dla ludzi wywodzących się ze świata IT ten temat Agile czy Scruma, czy Kanbana, jest naturalny, więc myślę, że po prostu tam trzeba byłoby pewne procesy…

PS: Pewne rzeczy.

MG: Interakcje, procesy i narzędzia trzeba by pewne procesy, nie, no jakby trzeba było pewne rzeczy uporządkować.

PS: Uporządkować i zainicjować.

MG: Nazwać, zainicjować i to na pewno pomogło jakby, to kliknęło po prostu.

PS: Kliknęło. Natomiast, no mamy inne obrazki, czyli resztę organizacji, gdzie nie tylko we FreshMailu, ale w każdej innej organizacji mamy biuro obsługi klienta, mamy dział sprzedaży, mamy dział marketingu, eventy, finanse, jakąś administrację, no i to są jakby te inne składowe, te inne puzzle, które gdzieś są i to są też stay holderzy.

MG: Interesariusze.

PS: Interesariusze.

MG: Osoby zainteresowane.

PS: Produktem.

MG: Produktem.

PS: Firmą. I teraz czy masz jakieś spostrzeżenia, bo my sobie gdzieś to wewnętrznie w organizacji próbujemy poukładać i mam wrażenie, że nam całkiem fajnie, użyję znowu słowa, którego nie lubię, to agilowanie, ale zmienianie kultury organizacji idzie, ono idzie sobie swoim tempem, w jednych zespołach szybciej, w innych wolniej, natomiast nie chciałbym odnosić się do FreshMaila, tylko do porad dla osób, które być może pracują w innych organizacjach i też te zwinne podejście chciałyby zacząć adoptować, tylko nie na etapie IT, tylko być może tak szerzej organizacyjnie, jakieś dobre rady, spostrzeżenia. Ha, wiedziałem, że to będzie trudne pytanie.

MG: Podobały Ci się analogie to mogłeś się kolejnymi posłużyć.

PS: Dajesz. Wiesz, że ja jestem człowiekiem metafor.

MG: Ja mam w zasadzie dwie takie metafory związane z tym jak to się u nas zadziało. Z jednej strony dla mnie, jeżeli chcemy pracować zwinnie, jeżeli pasuje nam ta filozofia, bo dla mnie Agile jest filozofią, jeżeli taki sposób pracy nam pasuje wszystkim i chcemy jakby w ten sposób postępować, to dla mnie to jest w pewnym sensie, organizacja jest wtedy systemem naczyń połączonych. To znaczy nie ma czegoś takiego, że jeden zespół pracuje zwinnie, do pewnego miejsca w biurze te zespoły pracują zwinnie, a pozostałe nie, bo to jest, jakby ma wpływ na całą organizację, no to są pewne reguły gry, które warto by było, żeby rozumieli wszyscy. A druga taka analogia tego, co działo się u nas w organizacji. Ja mam takie spostrzeżenie, że proces wdrażania naszego Agile’a wyglądał trochę tak jakbyśmy postawili kilka filiżanek na stole i przykleili do nich karteczki IT, marketing, claim servis, sprzedaż i w tej pierwszej, do tej pierwszej filiżanki z napisem IT sypali różne mieszanki herbat zalewając je wrzątkiem, testując jak smakują i w pewnym momencie doszliśmy do miejsca, w którym stwierdziliśmy ten smak jest super, więc weźmy tą mieszankę i nasypmy do pozostałych filiżanek i to będzie nasz Agile. I to bardzo szybko się okazało, że to się nie sprawdziło, bo tak naprawdę każdy zespół jest inny, każdy zespół pracuje w trochę inny sposób, nawet w obrębie zespołu IT tak naprawdę nie ma jednego zestawu reguł, który można zastosować do zespołu, który rozwija projekt A i przenieść go na zespół, który rozwija projekt B oczekując, że odniesie się ten sam efekt, tak? Dlatego bardziej w tym kontekście ten, ta analogia naczyń połączonych. Wszyscy na siebie wpływamy. Wszyscy, zmiana w jednym miejscu ma wpływ na zmianę w pozostałej części organizacji. Dla mnie najważniejsze jest tak naprawdę wspólne zrozumienie nad czym pracujemy, to znaczy wspólne ustalanie priorytetów na poziomie organizacji, które są zrozumiałe przez każdy z zespołów. Mieliśmy tu małe problemy techniczne i wypadłem z rytmu. Wspólne ustalanie priorytetów.

PS: Priorytetów.

MG: To było moje ostatnie zdanie i… tak, no jakby największym problemem wydaje mi się w takiej sytuacji jest to, że każdy z zespołów ma jakieś oczekiwania, każdy z zespołów ma jakieś potrzeby i dopóki myślimy klientem tak naprawdę, jeżeli wytwarzamy produkt, z którego korzystają klienci, to tak naprawdę głos naszego klienta jest dla nas najważniejszy. I fajnie byłoby jakby ustalając kolejne kierunku rozwoju myśleć przede wszystkim właśnie tym, jaką wartość w rozwoju naszego produktu przyniesie to naszym klientom. I wspólnie tak naprawdę rozmawiać o tym, w jakim kierunku się rozwijamy, bo tych potrzeb jest bardzo dużo, ale nawet w zespole, nawet w firmie produktowej, IT-owej, zespół IT zawsze ma jakąś, no nie jesteśmy w stanie realizować wszystkich potrzeb równocześnie w tym samym momencie.

PS: Nie da się.

MG: Nie da się. I dopóki nie ma tej przejrzystości, tej transparentności miejsca, w którym rozmawiamy wspólnie, co jest ważne w tym momencie dla firmy i nie rozumiemy tego wszyscy, to zaczyna się rozsypywać, tak? Bo nagle zaczyna się przerzucanie…

PS: Moje jest mojsze.

MG: Moje jest mojsze albo czekam na coś od X czasu i dalej tego nie mam, a prawda jest taka, że to nie jest tak, że jak czekasz i nie masz to znaczy, że ktoś tego nie zrobił, bo nie chciał.

PS: Bo mu się nie chciało, tak.

MG: Albo, bo nie robił nic w tym czasie, tylko te zespoły zazwyczaj zajmują się czym innym i dopóki nie ma tej, tego miejsca na wspólną rozmowę, na rozumienie tych zasad, tych priorytetów, to zazwyczaj to powoduje frustrację i to jakby zaciemnia cały obraz.

PS: Znaczy ja Ci powiem, że może jest jeszcze jedna rzecz, bym dopowiedział, chociaż Tobie pewnie nie wypada powiedzieć, przynajmniej nie mi, może na jakimś meet up’ie. Ja prawdę powiedziawszy myślę, że poza tą płaszczyzną wspólnego ustalania celów, rozumienia tego, co jest ważne i pilne, i kiedy to jest ważne, i kiedy to jest pilne, i wspólnego main setu, tak naprawdę chyba największym wyzwaniem, które rodzi się zwłaszcza na poziomie małego start up’u, któremu się wydaje, że jest super innowacyjne, co robi, to jest rola założycieli, tego top managementu, piję wprost do siebie i do mojego szanownego wspólnika, gdzie nagle, no na początku Cię kusi bardzo, żeby być… może inaczej, gdy zakładasz firmę, to na początku jesteś everything managerem, zarządzasz wszystkim i masz na wszystko wpływ. Wszyscy się Ciebie o wszystko pytają, więc czujesz się taki ważny, potrzebny i tu jest jeszcze problem gdzieś do przepracowania w głowie pod tytułem okej, być może wiem jak to dobrze zrobić, ale skoro mamy mieć zespół samoorganizujący się, samouczący się, bo to jest jakby nietożsame, ale to wynika stąd, to nagle trzeba odpuścić i pozwolić gdzieś popełniać pewne drobne błędy. I niektórzy łapią to szybciej, inni troszkę wolniej, tak. Ja dołożę, że to jest jeszcze ta część, którą powinni też słuchacze czy widzowie poznać, bo to jest tak, z jednej strony jak jest dwa i pół roku drogi FreshMaila to jest jakby jako organizacji to jest jakby jedna droga, ale gdzieś obok myślę, że trochę inną drogę w innym tempie przebywam ja, trochę inną przebywa Krzysiek. Pewnie jeszcze inną Wojtek jako nasz CTO, ale tak naprawdę to jest jeszcze wewnętrzna droga, którą każdy musi gdzieś przejść.

MG: Pawle, ja Ci zawsze wszystko powiem. Natomiast tak, no jakby był kiedyś taki Pan, nazywał się Taylor, który ułożył sposób, zrewolucjonizował w pewnym momencie sposób produkcji w fabrykach i jego podejście zakładało, że ludziom pracującym na taśmie należy stworzyć bardzo dokładne instrukcje stanowiskowe, algorytmy, według których mają postępować, a to, w jaki sposób będą pracować, będzie określane przez w ogóle zupełnie inne zespoły, doświadczonych planistów, którzy będą, jakby mają większą wiedzę. Ja wychodzę z założenia, że tworząc cokolwiek, tworząc produkty, projekty, jeżeli nie jesteś jednoosobową działalnością, tylko dochodzisz do momentu, w którym zaczynasz zatrudniać ludzi, to zatrudniasz tych ludzi dlatego, że oni są specjalistami w tym, do czego ich zatrudniasz. I teraz tworzenie zespołów, których z jednej strony zbieram ludzi, którzy mają doświadczenie i są ekspertami w tym, w danej dziedzinie, a następnie mówienie im dokładnie jak mają pracować jest totalnie bez sensu, bo to ci ludzie mają największe doświadczenie, to ci ludzie mają największą wiedzę, to oni wiedzą, jaką drogą dojść do celu, który Ty jako założyciel, CEO, członek zarządu, masz w swojej głowie, tak? Bo dla mnie top management to jest tak naprawdę taki drogowskaz, to są ludzie, którzy mają inspirować kierunkiem gdzie, pokazywać dokąd dążymy, natomiast, no jakby to wyszukiwanie drogi fajnie by było, żeby to zespół do tego dochodził, bo to zespół jest tak naprawdę, ma komplet wiedzy i często komplet narzędzi do tego, żeby ten, tą drogę przebyć.

PS: Znaczy mi się tak jak… kurczę, będzie tak refleksyjnie, ale niech będzie. Ja nie pamiętam, którą książkę akurat czytałem, czy to była [00:37:35], czy któraś inna, natomiast generalnie leanowych i tam była opisana historia jak managerowie z General Motors wybrali się do chyba Toyoty i na koniec oglądali taśmę, no to wiadomo, tam były jeszcze ambony, czyli tam te przyciski do wstrzymywania linii i tak dalej, natomiast na koniec podchodzą do managera, lidera, cholera wie jak on się nazywa, do gościa, który odpowiadał za daną linię produkcyjną, pytają, a gdzie macie stanowisko z młotkiem gumowym. I koleś pyta, o jaki kuźwa ci młotek gumowy chodzi. No bo u nas jak idzie taśma, to jak wkładamy drzwi, to one zazwyczaj są niedopasowane, więc na koniec gość tam młotkiem gumowym jakby sztukuje, żeby ten samochód dobrze działał. No i oni mówią, no ale u nas drzwi pasują, a jak nie pasują, to wciskamy przycisk i robimy stop, zastanawiamy się, co się chwilę wcześniej stało, no że było nie okej. Ja to trochę traktowałem jako taką…

MG: Simon Sinek „Start with why”.

PS: Pewnie tak. Za dużo książek, w sensie nigdy za dużo, natomiast zaczynają się tytuły mieszać. Natomiast ja troch traktowałem jako taką fajną historyjkę z rynku japońskiego na zasadzie opowiadałem taki urban legend. Natomiast potem sobie przypomniałem jedną historię, gdy moja żona wysyłała produkty swojej firmy do… właśnie na rynki japońskie i nagle dostawała zwrotki, że pudełko było lekko zakrzywione, które doszło tam albo opakowanie jest jakieś nie takie. Normalnie było naklejone na kartce papieru, sfotografowane i wysłane. I to nie chodziło o to hej, coś zepsuliście, tylko hej poprawcie, bo dostarczacie nieidealny produkt i mówimy o pudełku nie produktowym, nie jakby zapakowaną serię produktów, tylko o tym pudełku, które było jakby na koniec tej wielkiej palety, czyli coś, czego właściwie nikt nie widzi, bo ktoś to rozcina nożem i tyle, a tam było lekko zagięty róg. Wysłali, bo tak dbają o szczegóły i o cały proces, żeby to, co dostarczasz na koniec, miało, no było dobre po prostu, bez jakichkolwiek wad czy idealne jak może jak tylko się da to zrobić, więc to jest coś, żeby tego gumowego młotka pozbyć się z głowy.

MG: Ja jestem wielkim fanem kultury eksperymentów i to też jakby bezpośrednio wywodzi się z samego Scrum’a, z filozofii agile’owej, bo Scrum jest oparty o empiryzm, zakłada tak naprawdę, że każdy…

PS: Że doświadczasz.

MG: Że doświadczasz.

PS: Po prostu.

MG: Tak, że wyciągasz, że planujesz swoją drogę bazując na doświadczeniach, które zdobywasz. Jest taka pętla scrumowa wymyślona przez start up w [00:40:38], więc to jest taki producent motywacyjnych plakatów agile’owych. Co ciekawe, jakby na marginesie ja bardzo długo traktowałem te plakaty jako takie PRL-owskie hasła „kobiety na traktory” i parę innych. Natomiast moment, w którym faktycznie miałem ten, to kliknęło mi z Agile’m to wszystko, co trafia w moje ręce stamtąd to jest w ogóle…

PS: Wow.

MG: Wow i w ogóle. Boże, jakie to oczywiste, hasło typu „ideas over titles” czy właśnie pętla scrumowa „experiment fail learn repeat” i to jest coś, do czego bardzo często zachęcam też zespoły, z którymi pracuję, żeby każde wyzwania, z którymi się mierzą, do każdych wyzwań podchodzić na zasadzie eksperymentu. Umawiamy się na jakieś ramy czasowe jak długo ten eksperyment będzie trwał. Po dojechaniu do time boxa wyciągamy wnioski z tego, czego się nauczyliśmy, co możemy zmodyfikować, w jaki sposób możemy, jakie wnioski możemy z tego wyciągnąć i startujemy z kolejną interakcją tego eksperymentu i to jest jakby mega fajne, bo pozwala się dużo szybciej uczyć, natomiast też bardzo ważne jest, żeby nie wpadać w takie pułapki „experiment fail repeat”, co jest bardzo częste albo robić eksperymenty, które trwają dwa lata i nie ma żadnej refleksji przez ten czas.

PS: Ja Ci powiem, że z tym jest jeden problem, bo to nawet nie jest wyzwanie związane. Zobacz, że ja nie pamiętam, na jakimś evencie start up’owym byłem i ktoś miał piękną prezentację jacy to jesteśmy kreatywni i jak to odpalamy X kreatywnych projektów rocznie i de facto ten sam X dowozimy na koniec projektów kreatywnych.

MG: Sto procent?

PS: No blisko sto procent.

MG: Szacun.

PS: Pytanie, co znaczy dowozimy, no nie? Więc mówię kurde…

MG: Jaka jest definicja ukończenia.

PS: Ukończenia i co znaczy kreatywne, więc mówię come on, no jak coś ma być kreatywne, to musi być jakieś pole do tego, że mamy pewną niewiadomą. Natomiast największe wyzwanie czy problem sprowadza się do jednej, prostej rzeczy. Jeśli podchodzisz do tych eksperymentów naprawdę sensownie, to znaczy dajesz ramy czasowe, dajesz pewne metryki, które Ci sprawdzają czy coś jest okej.

MG: Oczywiście, że tak.

PS: To zobacz jak potem czasami trudno jest powiedzieć, bo to my w zespole czy we FreshMailu jesteśmy w stanie zrozumieć okej, to nam nie wyszło, nie wyszło, ponieważ i zastanawiamy się czy dalej jest sens powtarzać i próbować to osiągnąć, czy być może tego na ten moment nie jesteśmy w stanie osiągnąć, bo takie wnioski też się czasem pojawiają. Problem jest troszkę inny, że żyjemy w świecie, gdzie tak naprawdę klienci, konsumenci, nie do końca czasami pojmują jak im mówisz hej, nie zrobimy danej funkcjonalności, bo nie umiemy, bo nam nie wyszło, bo myślimy, że mamy inne, ważniejsze priorytety, bo nie musimy być produktem dla wszystkich i nagle jak zaczynasz taką komunikację części klientom przynajmniej pokazywać, to okazuje się, że oni zaczynają tracić dobre zdanie o Tobie, no nie? To znaczy ja miałem przynajmniej kilka takich rozmów z naszymi klientami, gdzie powiedziałem hej, nie dowieziemy tego, a nie dowieziemy, ponieważ wiemy, że jak dowieziemy to dzisiaj, to to będzie po prostu złe. To znaczy będziemy udawać, tak? Będzie take it time, take it make it, natomiast to nie o to chodzi, bo chcesz dowozić dobry produkt, który spełnia oczekiwania i potrzeby klientów. Nie wszyscy jakby tą filozofię trzymają u siebie, po stronie rynku. Jakby historia chyba na inną rozmowę.

MG: Znasz jakikolwiek produkt, który jest dopasowany do oczekiwań wszystkich mieszkańców świata, poza wodą? Produkt wymyślony przez kogoś i sprzedany tak, żeby wszyscy z niego korzystali? Jakby piję do tego, że nie da się wymyśleć…

PS: Znam jedną firmę z Krakowa, która robi jeden produkt, który teoretycznie powinien być do każdego biznesu dopasowany i dobra, pomidor. Nie będziemy tego wycinać, ale tak, pomidor.

MG: Moje ulubione powiedzenie.

PS: Pomidor.

MG: Tak.

PS: Pomidor, tak.

MG: Nie, jakby to… piję do tego, to jest tak samo jak ze zwinnością. Jak rozpoczynasz ten proces i chcesz iść w tym kierunku, to musisz liczyć się z ryzykiem, że zaczną, z ryzykiem wykruszenia się niektórych osób z organizacji, bo to nie jest sposób pracy dla każdego, to nie jest coś, co… są ludzie, którzy po prostu lubią pracować w sposób…

PS: Mam check listę.

MG: Mam check listę, tak. Albo panicznie boję się brania odpowiedzialności i za wszelką cenę nie będę tego robić. Więc, no to jest jakby koszt tej transformacji i to tak naprawdę do organizacji należy zrobienie tego rachunku zysków i strat. Ja uważam, że tak naprawdę nawiązując do tych kreatywnego przemysłu czy w ogóle organizacji, które wytwarzają cokolwiek, no nie ma w tym w XXI wieku już miejsca na tayloryzm i nawet jest co roku takie badanie Info Q, robi stan projektów IT czy w zasadzie organizacji wytwarzających produkty IT i z tego raportu wynika, że już w organizacjach z obszaru technologicznego nie ma już rozmowy czy my chcemy być zwinni. To już po prostu tak się dzieje. To jest standard, bo nie ma innej drogi tak naprawdę. Jeżeli żyjemy w świecie, w którym między prototypem a dostarczeniem nawet beta produktu, time to market wynosi dziesięć lat, no to come on.

PS: No tak, jasne.

MG: Ten rynek się zmienia po prostu i to nie ma sensu, tak? Więc water fall w tym momencie już nie ma żadnego sensu. Pewnie zostanę zlinczowany przez niektórych za takie stwierdzenie. Natomiast nie, no jakby w firmach, które chcą być innowacyjne, no już nie ma miejsca na to, nie wiem ile czasu jeszcze mamy, bo mam kolejną anegdotę.

PS: Powoli pewnie będziemy kończyć, natomiast jedziemy na razie. Znaczy ja Ci powiem tak, jak o tym wykruszaniu, bo tam mówisz, że niektórzy się wykruszają, bo nie chcą brać odpowiedzialności, to ja tak, taka mi myśl przyszła, ostatnio po raz kolejny miałem okazję spotkać się z Jackiem Walkiewiczem. W ogóle gość jakby na, może kiedyś uda się go zaprosić do podcastu, który zmienił moje życie jak jeszcze nie był znany, w sensie miałem dwadzieścia lat to go pierwszy raz spotkałem i on kiedyś coś takiego powiedział, nie pamiętam przy której okazji, ale jak go ostatnio spotkałem mi się przypomniało, że tak naprawdę odpowiedzialność, jeżeli bierzemy za coś odpowiedzialność, w sensie zawodowym, prywatnym, zawsze odpowiedzialność rodzi zaangażowanie, to zaangażowanie, które naprawdę jest tu w głębi serca, rodzi perfekcjonizm. A dzisiaj chcę… czy perfekcję, nie perfekcjonizm, perfekcję. I teraz, jeżeli bierzemy odpowiedzialność, będziemy zaangażowani, stworzymy coś perfekcyjnego, a przynajmniej perfekcyjnego w tym obszarze, w którym próbujemy nad tym pracować, czy to będzie usługa, czy to będzie produkt, czy to będzie funkcjonalność, reklama, czy związek w życiu, to dalej będzie jakby dążyło, będzie ten limes do perfekcji, więc myślę, że to nie jest nawet kwestia, że wszystkie organizacje, tak jak mówisz, że organizacje IT wiedzą, że to pozwala bardzo szybko działać. Ja myślę, że tak naprawdę ten rynek nie dość, że bardzo szybko się zmienia, to teraz ta ilość produktów, która jest w stanie przetrwać na rynku, w dłuższym horyzoncie, nie dziesięcioletnim, ale kilkuletnim, niestety bardzo szybko jest walidowana i zostają tylko te produkty, które są naprawdę wyjątkowo niezwykłe. Na swój sposób one, każde mają trochę inny zakres funkcjonalny czy zakres użyteczności. Mi się bardzo podoba, ja pamiętam, nie wiem, no z piętnaście lat temu bardzo interesowałem się zarządzaniem czasem i wtedy byłem fanem różnego rodzaju narzędzi do zarządzania sobą w czasie, potem pojawiły się smartfony, pojawił się wysyp, autentyczny wysyp aplikacji do zarządzania swoimi taskami szeroko rozumianymi, natomiast jak popatrzysz dzisiaj na market place to mamy, mówimy o produktach Apple’owskich czy na urządzenie z iOS-em, masz Omni Focusa, masz Think Sell, przez Culture Code robione, masz Nozbe jako nasz polski produkt i swoją drogą super start up, bo w Polsce prawie nieznany, na świecie jedna z topowych marek. No masz jeszcze nie wiem, Trello, ToDoIst’a, WunderLista i to jest tyle. A cała reszta gdzieś pojawia się, chwilę jest i za dwie sekundy nie ma, a te produkty, one nie są, one rozwiązują podobne problemy, tylko na inne sposoby. I nagle okazuje się, że doszły do perfekcji tam, gdzie mogą być.

MG: Znaczy ja myślę, że w tym momencie użytkownicy już bardziej szukają experience niż… liczy się doświadczenie, a nie…

PS: No pewnie też, no.

MG: Tak naprawdę znów jakby odnosząc się do słuchania potrzeb użytkowników, ten time to market jest bardzo ważny chociażby po to, żeby zwalidować swoją hipotezę, tak? Ja kiedyś doszedłem do takiego wniosku, że każdy pomysł już został kiedyś wymyślony, a nawet jeżeli Tobie wydaje się, że masz coś bardzo innowacyjnego, to istnieje bardzo duże prawdopodobieństwo, że w tym samym momencie ktoś na drugim końcu świata wpadł dokładnie na ten sam pomysł i teraz…

PS: Jakby badania, które to udowadniały sprzed dwudziestu lat.

MG: To jest ta naprawdę wyścig z czasem i znów wracając do start up [00:51:20] better than perfect, bardzo ważne jest też takie podejście good enough. Adam Kawa, który w tym momencie, jeden z najlepszych specjalistów w Polsce od big data, gość, który tworzył klastry big data’owe w Spotify, zapytany, gdyby miał wybrać jedną rzecz, którą wyniósł z tego jako doświadczenie, z tego, z tej pracy w Spotify, powiedział, że to było podejście good enough, że tak naprawdę każdy z nas chce, aby to, co wytwarzamy było perfekcyjne, ale trzeba znaleźć tą relację między to już jest funkcjonalne i możemy zacząć to weryfikować z użytkownikami, jakby znaleźć ten złoty środek, właśnie ten moment, kiedy możemy dostarczyć to, zweryfikować, dostarczyć coś, zweryfikować czy to nasze podejście, założenie jest właściwe i słuchając feedbacku naszych użytkowników rozwijać to dalej, tak? I to, no to jest dla mnie w tym momencie dosyć ważne dla biznesów innowacyjnych.

PS: Myślę, że to jest też ładna puenta. Przynajmniej na dziś. Nic, dzięki bardzo za przyjęcie zaproszenia.

MG: Dziękuję bardzo.

PS: Piąteczka.

MG: Dzięki.

PS: Dzięki.