FO 063 Scrum nie tylko w IT – rozmowa z Mariuszem Chrapko

W każdej firmie realizujemy jakieś projekty, które dostarczają naszym klientom wartościowe produkty i usługi. Wiele jest sposobów na zarządzanie projektami i organizację pracy zespołów, które je wykonują. W IT popularne jest podejście zwinne, zwane Scrum.
I o tym całym scrumie rozmawiam z Mariuszem Chrapko, który szkoli ze scruma, prowadzi blog i podcast Menedżer plus o zwinnym zarządzaniu, a także pomaga we wdrażaniu i adaptacji zwinnych metod pracy.
Co ważne, mówimy o Scrum nie tylko w IT!
Podcast w formie wideo:
Przeczytaj transkrypcję naszej rozmowy
Jeszcze nim przejdziemy do rozmowy to chciałam coś dodać, bo wiem, że mało kto słucha gadania podcastera po zakończeniu rozmowy z gościem 😉 Mariusz odpalił teraz sprzedaż swojego szkolenia o tym jak być Zwinnym Liderem, na które można zarejestrować się jedynie do tej niedzieli 12 kwietnia 2020 r (rok podaję, bo może ktoś słucha w 2021 ;)).
Mówię o szkoleniu nie dlatego, że mam w tym biznes, po prostu Mariusza śledzę od kilku lat i wiem jak ogromną ilością wiedzy się dzieli. Więc jeśli zainteresuje CIę rozmowa to odwiedź stronę ze szkoleniem 🙂 Szkolenie rzecz jasna w formie online!
Zapis na kurs Agile Leadership
W odcinku “Scrum nie tylko w IT” poruszamy takie tematy jak:
- Czym jest scrum?
- Czym jest podejście zwinne? Czy scrum i podejście zwinne to to samo?
- Czym jest Agile?
- O co chodzi w samoorganizujących się zespołach?
- Kto powinien wchodzić w zespół scrumowy?
- Jakie problemy w zespołach rozwiązuje scrum?
- Czy scrum sprawdzi się w marketingu?
- Czym się cechuje zespół scrumowy?
- Czym jest sprint?
- Jakie obowiązki ma scrum master?
- Co począć z osobami, które nie chcą pracować w scrumie?
- Na czym polega retrospektywa?
- Jaka jest rola mediatora?
- Do ilu zespołów może być przydzielony Scrum master?
- Czym jest zwinność w zarządzaniu projektami?
- Jak długo powinien trwać sprint?
- Jak wygląda prowadzenia projektów dla klientów?
- Od czego zacząć wdrażanie scrum?
- Do czego można wykorzystać scrum?
- Co jest niezbędne w Scrumie?
- Czy Product Owner może być także Scrum Masterem?
- Czy można wdrożyć Scrum tylko częściowo?
[spreaker type=player resource=”episode_id=24918685″ width=”100%” height=”350px” theme=”light” playlist=”show” playlist-continuous=”false” autoplay=”false” live-autoplay=”false” chapters-image=”true” episode-image-position=”right” hide-logo=”false” hide-likes=”false” hide-comments=”false” hide-sharing=”false” hide-download=”true”]
Ten scrum to z jednej strony bardzo mnie ciekawi, a z drugiej wydaje się taki trudny przez te swoje nazwy. Sprinty, iteracje, retrospektywy. Ja dzięki pracy w nowych technologiach część tych pojęć trochę znam, ale przyznaję, że nie miałam nigdy możliwości brania udziału w tym od A do Z. A chciałabym!
Jestem ciekawa jak to u Ciebie jest? Czy w Twojej firmie wdrożono Scrum?
I jeszcze raz przypominam o szkoleniu Mariusza – klik
Bardzo Ci dziękuję, że słuchasz podcastu FIRMA ON-LINE. Będzie mi miło jak podzielisz się linkiem do tego odcinka z osobami, których mogą zainteresować tematy jakie tu poruszam.
Mariusz w sieci:
Podcast Menedżer plus
Strona internetowa Mariusza
Szkolenie Zwinny Lider Agile Leadership
Skąd możesz pobrać podcast Firma On-line?
Podcast dostępny jest :
- na blogu – lista wszystkich podcastów
- w Spotify
- w Google Podcasts
- w iTunes
- na Youtube
- w serwisie Spreaker – pobierz aplikację Spreaker dla Androida i iPhone
- w serwisie Stitcher – pobierz aplikację Stitcher dla Androida i iPhone
- pobierając aplikację do słuchania podcastów na Androida, np. Podcast Addict, Podcasts Go, Google Podcasts, The Podcast App
- pobierając aplikację do słuchania podcastów na iPhone, np. Overcast, Pocket Casts, Castro, The Podcast App
- Pobierz plik mp3
- Poprzez specjalny RSS
Zapisz się także na mój newsletter by być na bieżąco, a przy okazji otrzymać fajne prezenty.
A jeśli spodobał Ci się ten odcinek będę wdzięczna za komentarz i podzielenie się tym odcinkiem z innymi osobami, którym jego treść może być przydatna. Będzie mi też miło jeśli poświęcisz chwile i zostawisz krótką ocenę podcastu w iTunes – dzięki temu inne osoby łatwiej dotrą do tego podcastu.
Oceń podcast Firma On-line >>
- użytkownicy systemu IOS – iPhone, iPad i komputery Mac – wejdź do iTunes i kliknij w sklep, tam wyszukaj FiRMA ON-LINE. Możesz ocenić dodając gwiazdki, a także zostawiając komentarz. Dziękuje!
- użytkownicy systemu Windows – zainstaluj na swoim urządzeniu aplikację iTunes, kliknij w niej w sklep, tam wyszukaj FiRMA ON-LINE. Możesz ocenić dodając gwiazdki, a także zostawiając komentarz. Dziękuje!
- użytkownicy systemu Android – wejdź do Google Play, pobierz aplikację Apple Music i kliknij w niej w sklep, tam wyszukaj FiRMA ON-LINE. Możesz ocenić dodając gwiazdki, a także zostawiając komentarz. Dziękuje!
Trzymaj się ciepło i do usłyszenia niebawem 🙂
Podcast o wykorzystaniu Scruma poza IT
Agata: Cześć, ja nazywam się Agata Chmielewska, a w tym podkaście dowiesz się, jak wykorzystać Internet do rozwoju biznesu i samego siebie.
W każdej firmie realizujemy jakieś projekty, które dostarczają naszym klientom wartościowe produkty i usługi. Wiele jest sposobów na zarządzanie takimi projektami i organizację pracy zespołów, które te projekty wykonują.
W IT popularne jest podejście zwinne, zwane Scrum. I o tym całym Scrumie rozmawiam z Mariuszem Chrapko, który szkoli ze Scruma, prowadzi blog i podkast Manager Plus o zwinnym zarządzaniu, a także pomaga we wdrażaniu i adaptacji zwinnych metod pracy, w tym właśnie Scruma.
No i nie przedłużając już, zapraszam cię serdecznie do posłuchania naszej rozmowy.
Cześć, co dobrego u ciebie słychać?
Mariusz: Cześć, witam cię. Miło mi bardzo tutaj być. No co u mnie słychać.
Ostatnie dwa tygodnie mam takie mocno nagraniowe, dużo nagrywam. Jako podkasterka mnie rozumiesz pewnie i też dużo czytam w związku z tym. Także nawet na Facebooku pisałem ostatnio, że to taki mój prywatny domowy uniwersytet trochę jest, bo do tych wywiadów staram się solidnie przygotowywać.
Czasami trzeba przeczytać jakąś książkę, posłuchać różnych rozmów i to jest takie bardzo fajne, odświeżające. A dużo nagrań, bo przygotowuje się do remontu studia powoli. Za sobie zrobić wreszcie takie profesjonalne lektorskie studio.
Agata: Wow.
Mariusz: Projekt już mam, także czekam na ekipę jak to zwykle bywa.
Agata: Fajnie. Żeby pokój przygotować pod kątem nagrań już tak bardziej profesjonalnie, żeby tylko siąść i jechać z koksem.
Mariusz: Tak, no tak, wiesz, zwłaszcza to będzie też przydatne do kursów online. I tak w ogóle, jeżeli byś tam jeszcze chciał jakieś, może audiobooki, nie wiem, ale to na pewno jest fajne. Kurs mam jeden, ale powiem ci, że mam takie doświadczenie, ponieważ ty działasz dużo tak online. No bo zresztą ja też, ale jakoś te kursy online kiedyś rozmawiałem, zaprosił mnie Piotr Peszko do swojego podkastu i mówiłem mu, że mi trochę brakuje twarzy w tych kursach online, bo niby jest kontakt z uczestnikiem takiego kursu, ale mimo wszystko to jest taki kontakt mailowy, facebookowy, a jednak na szkoleniach, na warsztatach można zobaczyć twarz, porozmawiać, są relacje i to jest coś, co mnie bardzo kręci też, więc jakoś tak się nie mogę przekonać jeszcze do tych kursów.
Aczkolwiek jeden kurs Scrum Assistance jest, były już dwie edycje i trzecia tak wisi wisi i zastanawiam się kiedy ją odpalę, ale jest tam już sporo osób zebranych jako lista rezerwowa, więc może się coś wyklaruje niebawem. Ciągle brakuje czasu albo priorytetów bardziej.
Agata: Tak, wiesz co, to też zależy od osoby i właśnie tak jak ty, niektórzy lubią kontakt taki faktycznie face to face, fizyczny w realu tak zwanym, a to też z drugiej strony takie online kursy mają tą zaletę, że to jest oszczędność czasu i też wiele osób uczestników woli kursy online, więc jak masz chętnych to ruszaj.
Dobrze, wiesz co, ja chciałam ciebie podpytać o modny przynajmniej w moim środowisku Scrum, z którego szkolisz i piszesz i tak naprawdę, co to jest ten Scrum, podejście zwinne, o co w tym wszystkim chodzi, tak jakbyś miał babci wytłumaczyć albo nie wiem, dziecku, albo mi.
Mariusz: No tak jakbyśmy pomyśleli o dzieciaku faktycznie to bym powiedział chyba, że jest to taki sposób organizacji pracy, zabawy może lepiej, wszystkich dzieci w piaskownicy po to, żeby zbudować coś fajnego, tak bym chyba powiedział, aczkolwiek te definicje takie uproszczone to jest moja pięta Achillesa, muszę ci się przyznać, bo do tej pory zauważyłem, że mam problem z upraszczaniem dość duży i od jakiegoś czasu jestem też trenerem takiego modelu Fris i wykorzystuję go bardzo mocno w pracy z zespołami, to jest takie narzędzie diagnostyczno-rozwojowe polskie, bardzo rzetelne i tam zrobiłem sobie badanie, jak się w ogóle obwąchiwałem z tym narzędziem i wyszło mi, że mam bardzo dużą złożoność poznawczą.
To jest w psychologii taki wymiar, zjawisko, które określa właśnie jak bardzo potrafisz tak z pozycji drona spojrzeć na rzeczywistość i jak bardzo jesteś w stanie tak w prostych żołnierskich słowach komuś wyłożyć jakąś mądrość życiową czy jakąś prawdę i zauważyłem, że mam z tym duży problem zawsze, bo widzę mnóstwo różnych ścieżek, różnych takich przypadków, które trzeba rozważyć i o których trzeba powiedzieć.
Ale kilka lat temu, już trzy lata będzie, jak wystartowałem z takim projektem Scrum dla Zielonych, to taka moja życiowa misja, żeby mówić o tej metodzie, która jakby nie było przyszła ze świata IT, ciągle jest najbardziej popularna w tej branży informatycznej, ale żeby o niej mówić też poza IT do różnych organizacji, do różnych zespołów, które niekoniecznie pracują w taki informatyczny sposób.
No i tam to była dla mnie duża taka szkoła, żeby się trochę przełączyć, żeby sobie tą złożoność poznawczą zmniejszyć i odejść od takiego żargonu, też od przykładów takich typowo informatycznych, no i żeby mówić do ludzi po prostu o Scrumie.
Czyli tak podsumowując można powiedzieć, że jest to sposób organizacji pracy zespołu, który rozwija jakiś produkt. To tak jakbyśmy faktycznie babci albo sąsiadowi w windzie, który wychodzi z jamnikiem na spacer, mieli powiedzieć, to bym takiego jednego zdania użył. Sposób organizacji pracy zespołu, który rozwija jakiś produkt.
Agata: Ok. I czy to jest tożsame Scrum, nazwa z podejściem z winnym, czy to jest coś innego, dwie różne rzeczy, bo to mi się też tak przewija często.
Mariusz: Tak, to wiele osób o to pyta, bo jest takie słowo magiczne, które gdzieś tam można spotkać, też nie tylko w internetach, ale na konferencjach, gdzieś tam w artykułach różnych, agile.
No i co sobie można, właśnie jest to zwinność po polsku. To można sobie wytłumaczyć w ten sposób, że agile to jest bardziej taka filozofia pracy, coś co określa różne metody zwinne. Scrum jest jedną z takich metod. Ja często używam takiej metafory parasola, czyli masz parasol, ten parasol to jest agile, pod parasolką masz różne metody.
I Scrum jest taką metodą, która jako jedyna faktycznie jest metodą niezwiązaną z całym tym światem informatycznym. Faktycznie jest to metoda, sposób bardziej, mówi się framework, o którym za chwilę powiemy, organizacji pracy.
Możesz stosować tę metodę, ten sposób pracy w bardzo różnych obszarach, aczkolwiek tak jak mówiłem przyjęło się bardzo mocno, że teraz to jest bardzo trendy w IT, ale nie chciałbym się ograniczać tylko i wyłącznie do tej branży informatycznej. Pod tą parasolką są też inne metody, jest programowanie ekstremalne, jest dynamic system development method, podciągnęło się tam też taką metodę liniową Kanban, która jest też mocno popularna dzisiaj, ale agile to jest bardziej pewna filozofia pracy, która stawia mocno na zespół, na pracę zespołową, stawia mocno na komunikację, na pracę w takich krótkich cyklach zwanych iteracjami.
Na koniec każdej takiej iteracji powstaje coś, co jest potencjalnie gotowe, wartościowe dla klienta. Zespół jest bardzo takim mocnym tutaj wyznacznikiem metod zwinnych. Zespół, który jest interdyscyplinarny, sam organizuje swoją pracę, więc ten agile to jest kilka takich punktów, które są wspólne, charakterystyczne dla różnych metod, a metodą, którą się zajmuję na co dzień to jest właśnie metoda Scrum, jest metodą zwinną, metodą agile’ową, tak moglibyśmy to powiedzieć.
Agata: Ok, ok, czyli Scrum, a wyżej jest całe to agile, podejście zwinne, a powiedziałeś, że zespoły same się organizują, czyli co? Przychodzą sobie do biura programiści i mówią, no dobra teraz robimy to i to, czy o co chodzi z tym, że sami organizujące się zespoły?
Mariusz: To jest bardzo w ogóle ciekawy koncept i tak bym zaczął może od tego, co ten Scrum znaczy, bo o tym chyba nie mówiliśmy. To jest nazwa, która przyszła ze sportu, z takiej gry rugby, którą gdzieś tam w internetach można sobie podpatrzeć. Na pewno czy ty, czy słuchacz, widzieli taki obrazek, jak stoją takie dwie drużyny, trzymają się za bary panowie i to tak dość dziwnie wygląda, jest taka jajowata piła i człowiek, który się nazywa łącznikiem Scrum’a wrzuca im tą piłkę między nogi, oni mają wywalczyć tą piłkę, żeby wywalczyć przewagę w polu.
Jest to taki stały fragment gry trochę, jak w piłce, używamy rzut wolny, tak samo używa się Scrum’ów rugby, żeby zacząć grę, wznowić grę, jest kilkanaście Scrum’ów na takie jedno spotkanie i sama nazwa tej metody już pokazuje, że jest to metoda, która mocno zbudowana jest na zespole.
Jak nie masz zespołu, jak nie pracujesz nad rozwojem tego zespołu, to tak jak obserwuję, czy ze swoich doświadczeń mogę ci powiedzieć, że to podejście słabo działa i teraz pytałaś jak ten zespół pracuje, faktycznie jest tak, że są takie dwa wyznaczniki, ich jest trochę więcej, ale te dwa są chyba najważniejsze.
Jedna rzecz jest taka, że ten zespół ma dość taki nietypowy w porównaniu do tradycyjnego podejścia, bo Scrum zakłada, że jak przystępujesz do pracy nad jakimś produktem, na przykład z twojej branży chcesz zrobić kampanię marketingową, to idea jest taka, że musisz zebrać ludzi, którzy będą posiadali wszystkie takie komplementarne, potrzebne kompetencje do tego, żeby taką kampanię marketingową zrealizować. Czyli jakby ten pierwszy wyznacznik zespołu Scrumowego, to jest to, że masz zespół, który jest interdyscyplinarny.
Chodzi o to, żeby nie było tak jak w tradycyjnym podejściu do pracy z projektami, że jakby te projekty dzieją się tak fazowo i do każdej fazy masz grupę specjalistów ze swoim szefem podpiętą, czyli masz grupę analityków, maszgrupę na przykład programistów, którzy programują, masz testerów, którzy testują, oni mają swoich szefów, no i wiadomo jak to jest w życiu, że tworzą się takie silosy, problem z komunikacją, problem z odpowiedzialnością za to, co powstaje, bo dla każdej takiej, dla takiego silosa produktem jest trochę co innego.
Analitycy mają zrobić dobrą analizę, testerzy mają znaleźć jak najwięcej błędów i tak dalej i tak dalej. Chodzi o to, żeby właśnie jak najbardziej usprawnić pracę tych ludzi, którzy rozwijają produkt, który gdzieś tam na końcu dla klienta powstaje.
A druga rzecz, o której wspomniałaś, to jest to, że te zespoły same organizują swoją pracę. Czyli idea jest taka faktycznie, że pracujemy w takich krótkich cyklach, takich iteracjach w scramie, to się nazywa sprint. Te sprinty trwają od dwóch do czterech tygodni, najczęściej maksymalnie 30 dni i faktycznie w ramach takiego sprintu idea jest taka, że temu zespołowi się nie przeszkadza.
Nie przychodzi żaden szef z zewnątrz i mówi co ma robić, jakie zadania w jakiej kolejności będą wykonywane, tylko idea jest taka, że paradoksalnie ten zespół zostaje szefem samego siebie i musi sobie jakoś radzić. To jest bardzo magiczna rzecz.
Ja to od kilkunastu lat obserwuję w ogóle zjawisko samoorganizujących się zespołów i muszę Ci powiedzieć, że na początku to byłem takim wielkim entuzjastą tego pomysłu. To dzisiaj zresztą jestem, ale chodzi bardziej o moje podejście do tego. Wydawało mi się, że jak faktycznie zespół dostanie takich skrzydeł, jak mu powiesz, że teraz ma pełną autonomię, stawiasz przed nim tylko pewne cele, a tak naprawdę jeśli chodzi o zadania i to jak nad tymi zadaniami będą pracować ci ludzie, jak oni się będą układać z tymi zadaniami, czy będą śledzić swoją pracę, jak to będą robić i tak dalej i tak dalej, no to po prostu oni wystrzelą w kosmos i teraz mogę Ci powiedzieć, że to tak fajnie nie działa wcale.
Wymaga to dużo pracy na pewno i tak już mówię po tych kilkunastu latach moich doświadczeń w pracy z tą metodą, mogę powiedzieć, że jest to proces, który wymaga pracy nad zespołem, bardzo dużej pracy nad zespołem. Sporo firm o tym zapomina. Wiele firm ciągle jakoś tak skupia się za bardzo na tych fajnych praktykach, które są zaszyte w tej metodzie, ale to nie wystarcza, bo wielu klientów, z którymi mam okazję na co dzień do czynienia, to mówi, że właśnie mamy te wszystkie fajne rzeczy związane z tą metodą.
Mamy stand-upy, pracujemy w sprintach, ale gdzieś tam brakuje zwinności na końcu tej drogi i faktycznie dużo pracy ta metoda wymaga nad relacjami, nad budowaniem tych relacji, nad budowaniem takiej świadomości tego, że ta autonomia jest i co z tą autonomią my możemy faktycznie zrobić.
Pracę z ludźmi, żeby się tego nauczyć, bo też tak obserwuję, że dużo łatwiej jest szefom oddawać władzę, też jest dość ciekawe zjawisko, jak wprowadzamy sobie właśnie tą metodę w organizacji, to dla liderów nie ma problemu, żeby tak oddać, usamodzielnić bardziej zespoły, ale widzę, że ludzie mają duży problem z tym, zwłaszcza w takich organizacjach, w korporacjach, w dużych firmach.
Sporo osób jest trochę przyzwyczajonych do takiej, powiedzmy, wyuczonej bezradności, że szef bierze odpowiedzialność za wszystko, szef przydzieli zadania, ja nie muszę nic robić, nie biorę odpowiedzialności, ja mam tylko wykonać pracę, którą dostanę, a reszta to już nie jest moja broszka.
I to jest trudne dla wielu osób, to wymaga pracy, jest taka rola w Scrumie, która się nazywa Scrum Master, między innymi jednym z takich obowiązków roli Scrum Mastera jest to, żeby pracować nad rozwojem zespołu. Jednym z takich ważniejszych elementów, nad którymi Scrum Master pracuje, to jest właśnie budowanie świadomości praca ze stosowaniem, z uczeniem, wdrażaniem tej samej organizacji, tak na co dzień. To jest takie dość trudne i tak jak pracuję czasami ze Scrum Masterami, którzy już mają kilkuletnie doświadczenie, to jest dużo w Scrumie, że jesteś Scrum Master, który pracuje tak przynajmniej 3 lata, to już można powiedzieć, że masz duże doświadczenie w pracy z tą metodą, bo ciągle jest to świeża rzecz i ciągle to się rozwija na różnych frontach.
No to mówią, że jednym z takich podstawowych wyzwań jest to, jak wzmocnić samą organizację w zespole, jak ten zespół pobudzi do tego, żeby ci ludzie faktycznie korzystali z tej autonomii.
Agata: To jest trudne. Bo właśnie jak mówiłeś o tym, że tutaj ta motywacja, mi brakuje właśnie, znaczy brakuje, nie brakuje, pojawia się taki wielki znak zapytania, a co z ludźmi, którzy z natury, bo są takie osoby, nie mają w sobie tej takiej odpowiedzialności, właśnie są takie bardziej bierne, to czy są na nie sposoby swojego doświadczenia, czy może ich się zwalnia albo przesuwa do jakichś innych zadań.
No bo są osoby, które naprawdę są oporne przed nowościami, właśnie nie mają takiego poczucia ani w pracy, ani w życiu, takiego odpowiedzialności, no po prostu.
Mariusz: Wiesz co, nie wiem czy od razu mówiłbym o zwalnianiu, aczkolwiek też miałem ponad 50 organizacji, już ponad 50 organizacjom pomagałem przy wdrożeniu tych metod i różne rzeczy widziałem. Były też sytuacje, gdzie pojawiały się zwolnienia, ale jest to rzadkość.
To co tu jest ważne, to co pytasz, to myślę, że to w jaki sposób pracuje się z takimi wyzwaniami, czy z konfliktami, z trudnymi sytuacjami. Tutaj idea jest taka, ponieważ tak jak kilka razy już tutaj powiedziałem, zespół jest dosyć ważny w Scrum’ie, to jest taki fundament pracy w tej metodzie. To na początku próbuje się robić wszystko, żeby zespół sobie z danym tematem, z danym problemem poradził. I to jest dosyć istotne też w pracy na przykład Scrum Mastera z takim zespołem, bo trzeba bardzo uważać na słowa, na gesty, na to w jaki sposób czasami nawet się patrzy na ludzi, bo takie mikroznaki czasami powodują, że ludzie wracają do starego trybu pracy i czują się poddanymi bardzo szybko. I to jest dosyć istotne, żeby wypracować sobie.
Ja też bardzo często jak pracuję ze Scrum Masterami, to im podpowiadam, żeby sobie ustalić taki proces pracy na przykład z konfliktem, eskalacji konfliktu. No bo idea najczęściej jest taka, i to w ogóle mają wszystkie systemy samoorganizujące, że praca z konfliktem, praca z decyzjami, z procesem decyzyjnym, komunikacja to są takie trzy rzeczy, które trzeba w jakiś sposób ogarnąć w takim systemie samoorganizującym.
Bardzo dużo inspiracji, to tak przy okazji możemy słuchaczom podrzucić książkę Frederika Lalou, “Reinventing Organizations” – “Pracować inaczej”, taki polski tytuł jest. On tam opisał 12 różnych takich case’ów firm, organizacji, które tak poszły na maksa i wdrożyły ten model taki samoorganizujący się. I właśnie to są tematy, z którymi się praktycznie każda firma boryka i praktycznie każda organizacja w Scrumie, to jest bardzo dużo też do podpatrzenia, buduje sobie taki model pracy z konfliktem, eskalacji konfliktu i pierwszą rzeczą, którą się robi to jest właśnie zostawienie takiego problemu, tematu zespołowi.
Ja pamiętam pierwszą taką historię, kiedy pierwszy raz miałem do czynienia właśnie z takim zespołem, który miał dwóch takich malkontentów. W ogóle to była duża organizacja i wydawało nam się, że dla tych dwóch osób to będzie w ogóle petarda, jak będą pracować w takiej super fajnej metodzie. To były początki w ogóle roku 2000, ten temat startował i to ciągle było nowe i atrakcyjne i to było dwie takie osoby, które chodziły po firmie i narzekały, tak jak mówisz. W ogóle wszystko im się nie podobało. No i wzięliśmy ich do projektu pilotażowego i okazało się, że jest jeszcze gorzej niż było. I pamiętam, że właśnie przyszedł do mnie menedżer liniowy, więc przełożony całego tego zespołu, no i pytał się, no Mariusz, co robimy, nie? No bo czy ja mam jakoś zadziałać w tym całym Scrumie, czy mam ich wyrzucić z tego zespołu, czy nie wiem, Scrum Master powinien coś zrobić, a może zespół powinien coś zrobić? No i właśnie obstawiliśmy tą trzecią opcję zgodnie tutaj z regułami gry, że to zespół powinien sobie poradzić z takim tematem, a przynajmniej spróbować się zmierzyć z takim tematem.
Było bardzo fajnie, była taka sensowna rozmowa. Na koniec każdego takiego sprintu jest takie zdarzenie, które się nazywa retrospektywa, która jest takim spojrzeniem w lusterko boczne, żeby zobaczyć jak w tym sprincie nam było, co działało, co nie działało, co ewentualnie chcemy poprawić. No i praktycznie gruba część tego spotkania była związana z tą sytuacją, tej relacji właśnie tych dwóch osób i zespołu i zespół sam się dogadał bez ingerencji kogoś z zewnątrz. Ale nie zawsze się to udaje, bo też miałem takie sytuacje, które się kończyły zwolnieniem na przykład pracownika i też ta ścieżka eskalacji powoduje, że też Scrum Master nie jest sam.
Bo niektórzy Scrum Masterzy myślą, że jak sobie nie poradzę, to ja jestem jakiś tam gorszy, beznadziejny na przykład. I jak myślisz o ścieżce konfliktowej, to jak zespół sobie nie radzi, takim drugim krokiem jest właśnie próba wejścia Scrum Mastera i Scrum Master też może zadziałać w pracy z konfliktem, a jak Scrum Master sobie nie radzi, no to wtedy trzeba mieć jakiś pomysł na to, kto jeszcze w tej kolejce powinien się pojawić w tej ścieżce eskalacji konfliktu, żeby pomóc rozwiązać taką sytuację.
No i tutaj jest taki bardzo ważny punkt związany z tym, jak ta rola Scrum Mastera jest umocowana w organizacji. To też jest taka historia, którą przerabiam w wielu firmach. Bardzo ważne jest to, żeby faktycznie ta rola była w strukturach organizacji niezależna, obiektywna.
Bardzo fajny case przytoczył Łukasz Michno, kiedyś nagrywałem z nim podkast. On jest takim doświadczonym bardzo Scrum Masterem. Pracuje w firmie GetResponse i on opowiadał, że u nich w firmie, żeby uniknąć tych wszystkich problemów, takich związanych z różnymi tam relacjami i rolami, Scrum Masterzy są bezpośrednio podpięci pod zarząd organizacji. To jest bardzo komfortowe rozwiązanie, bo jak są właśnie sytuacje konfliktowe, takie trudne, to nie ma żadnych przejściówek po drodze. Ale to jest rzecz bardzo indywidualna i w różnych organizacjach to bardzo różnie może wyglądać, ale jest to rzecz mega istotna. J
a pamiętam też taką swoją sytuację, jak pracowałem jako Scrum Master. Miałem do czynienia z trudnym product owner’em, właścicielem produktu. To jest druga taka rola flagowa w tej metodzie. No i widziałem, jak cierpi zespół. Ze sprintu na sprint było coraz gorzej. Product owner był niedecyzyjny, nie był samodzielny. Jak zespół wymyślał jakieś fajne rzeczy albo podpowiadał jakieś fajne rozwiązania, no to praktycznie rozmowa zawsze wyglądała w ten sposób, że product owner mówił, dajcie mi dwa, trzy dni, a ja się zapytam dyrektora technicznego, czy mogę.
Widziałem, jak zespół tracił respekt do tego product owner, ale najgorsze było to, że nam rozwalał pracę w każdym sprintie. Planowaliśmy sobie coś na dwa tygodnie, a on po kilku dniach przychodził i próbował wymieniać różne klocki z naszego planu. De facto rozwalał cały plan naszego sprintu. Często było tak, że w ogóle kończyliśmy wcześniej ten sprint. Jest taka prerogatywa product ownera. On może po prostu przerwać sprint, jeżeli na horyzoncie nie ma żadnych perspektyw, że osiągniemy jakieś sensowne cele. No ale to zawsze kończy się tym, że spada bardzo mocno morale zespołu i ludzie czują, że coś im nie wyszło, mimo że w tamtej sytuacji product owner był problemem.
No ale właśnie, gdybym nie miał jakiegoś pomysłu na eskalację, to bym pewnie miał poczucie jakiejś ogromnej porażki i stania przy ścianie, ale był nade mną człowiek, który umówiliśmy się, że jak będą takie trudne rzeczy do zrobienia, to idę do niego. Tak jak mówiłem, to może bardzo różnie w organizacjach wyglądać. Taka firma Morning star, o której Lalu też pisze, to jest bardzo też ciekawy case do przeanalizowania, jeżeli myślicie w ogóle o takich systemach samoorganizujących się. Oni sobie w sytuacjach konfliktowych wybierają zespołu jakiegoś mediatora. Można też wybrać mediatora spoza zespołu, to też jest fajny pomysł. Jeżeli się nie dogadują na tych kilku etapach, to też kończy się koniec końców na spotkaniu z kimś z zarządu. To już jest taka ostateczność pracy z takimi trudnymi sytuacjami.
Agata: Z tego co mówisz, to Scrum Master to nie jest osoba, która stricte coś programuje, to jest bardziej osoba z takimi kompetencjami miękkimi. Nie lubię słowa zarządzanie ludźmi, ale właśnie kooperacja, troszeczkę też jakiś mediator. Jest w tych sprintach, podsumowaniach, retrospektywach. Szybko się uczę słówek nowych. Ale co on w ogóle jeszcze poza tym robi? Co on siedzi i obserwuje sobie? Czy on może ma kilka zespołów? Czy to właśnie jeden Scrum Master jest do jednego zespołu? Jak to wygląda?
Mariusz: To bardzo różnie wygląda. Staram się unikać tutaj w naszej rozmowie słowa „zależy”, ale naprawdę to bardzo zależy od różnych organizacji. Zaczynając od początku zupełnie, trochę dużo nieporozumień wprowadziła ta nazwa, ten „master”. Pamiętam jak startowały w ogóle Scrum w naszych polskich firmach i brałem czasami udział w rekrutacjach i widziałem jak przychodziły różne CV. Te CV były bardzo wypasione, to byli ludzie niesamowicie doświadczeni. Widać było, że kompletnie nie czuli w ogóle, o co chodzi w tej roli.
Teraz to się bardzo mocno zmieniło. Jakbyśmy mieli użyć jakiejś metafory, ja często pokazuję, jak rozmawiam o Scrumie, mam taki zestaw zdjęć swoich góralskich i pokazuję takie metafory właśnie związane z bacą łowieckami i z pieskiem pasterskim. Pies pasterski to jest właśnie dobry obraz Scrum Mastera. Mam takie zdjęcie, jak ten owczarek tak leży leniwie, patrzy sobie na stado owiec, czy tam wszystko idzie w dobrą stronę, czy jakichś wilków nie ma gdzieś z boku. I to jest taka dobra metafora roli Scrum Mastera. Ta rola, trudność z tą rolą polega na tym, że ona jest trochę niemierzalna. Pamiętam na początku, tak pytałaś jak się organizuje tę rolę w zespołach, na początku jak zaczynaliśmy w ogóle pracować ze Scrumem w polskich firmach, to pamiętam, że był to duży problem, żeby uzasadnić w ogóle potrzebę tej roli. No bo jak mamy wydać na coś pieniądze, to trzeba wiedzieć co ta rola robi, jak ją zmierzyć i w ogóle czy nam to coś da w organizacji. Teraz już na szczęście jest tak, że jest to dosyć jasne i jakby firmy nie kwestionują potrzeby tej roli, chociaż nie wszystkie ciągle.
No to wtedy było tak, że ten Scrum Master był taki dzielony trochę, że na przykład tak jak mówisz na 50% czasu był programistą, a drugie 50% czasu pracował sobie jako Scrum Master, czyli była to rola dzielona między członków zespołu. Teraz jest taka tendencja, jestem wielkim fanem tego podejścia, żeby to był ktoś dedykowany do pracy jako Scrum Master. Czyli mamy w firmie etat, jeżeli mamy takiego Scrum Mastera, to praca z jednym zespołem to jest trochę za dużo wolnych przebiegów powiedziałbym dla Scrum Mastera, aczkolwiek są tacy Scrum Masterzy, którzy potrafią tak wypełnić ten czas.
Tak dwa zespoły, trzy maksymalnie to jest to, co taki Scrum Master może obstawić, aczkolwiek też eksperymentuję teraz z takimi podejściami, które wiążą się z tym, żeby nie przypisywać tak bardzo mocno Scrum Mastera do zespołu.
Agata: Ciekawa koncepcja, ale czy w takim podejściu nie ma ryzyka, że Scrum Master może się zbytnio odsunąć od zespołu?
Mariusz: Ja też zawsze mówię Scrum Masterom, że waszą rolą, waszym celem pracy w waszej roli jest jak najszybciej przestać być potrzebnym zespołowi, bo tutaj to jest to, o czym mówiłem przy samoorganizacji, że jak budujesz taki system samoorganizujący się, mówiłem, że trzeba bardzo uważać na gesty, na znaki, na mimikę, na różne takie rzeczy, to tutaj jest podobnie. Scrum Master jest za bardzo przywiązany do zespołu, jest taką „mamuśką Scrumową” nazwijmy to i tak za rączkę ten zespół prowadzi, przynosi pisaczki, sale rezerwuje, no to zespół się bardzo uzależnia od takiej super pomocy, no każdy by się uzależnił, jeśli by tak ktoś nam na tacy wszystko dokładnie podsuwał. No i trzeba bardzo z tym uważać i właśnie mówię, że teraz eksperymentuję trochę z takimi podejściami, że jest faktycznie Scrum Master, ale on służy różnym zespołom, nie jest tak, że jest przypisany do jednego zespołu, po prostu jak zespół potrzebuje pomocy i startujesz zespołem, to wtedy faktycznie zaangażowanie Scrum Mastera i pomoc, duża pomoc jest potrzebna, no ale później im bardziej idziemy dalej z rozwojem tego zespołu, im bardziej wchodzimy na kolejne etapy pracy zespołu, ten Scrum Master trochę odchodzi w cień.
Ja próbowałem to tak też, jak pracuję ze Scrum Masterami, jakoś pokazać ten proces pracy zespołem, bo Scrum Masterzy właśnie pytają o narzędzia, kiedy się odciąć, kiedy odejść w cień, jak dużo tego zaangażowania jest potrzebne. Znowu, bazując na różnych obserwacjach pracy zespołami, tutaj bardzo przydaje się, bo tak jakby ktoś chciał sobie jakoś pomóc, pomyśleć o zaangażowaniu Scrum Mastera w pracy z takim zespołem. Jest taki model, który na wielu szkoleniach z przywództwa się przytacza, przywództwa sytuacyjnego.
To jest taki model, który mówi tak w dużym skrócie, że lider powinien dostosowywać się do sytuacji, do pracowników. W zależności od etapu pracy z zespołem, z pracownikiem, to trochę inaczej powinien z tą osobą pracować. Dokładnie tak samo jest ze Scrum Masterem. Jak startujemy w ogóle z zespołem, to Scrum Master powinien wejść bardziej w takie buty nauczyciela, osoby, która podpowie niektóre rozwiązania, pokaże instrukcje. Ja wiem, że to dziwnie brzmi w kontekście samoorganizacji, ale na początku faktycznie, jak zespół jest w takiej fazie formowania się, to ludzie są trochę tacy skołowaciali. Nie wiedzą jak się w tym wszystkim odnaleźć, nie wiedzą czego się od nich oczekuje.
Mówimy o sytuacji, jak zespół w ogóle faktycznie jest taki konfigurowany od zera, czyli oczekują jakichś takich jasnych wytycznych od tego, jak będą pracować, na przykład w jakiej metodzie. Dlatego wtedy Scrum Master uczy Scrum, a to jest taki dobry moment, żeby o tym Scrum’ie opowiadać, wejść w buty takiego nauczyciela trochę. A później, jak zespół już idzie dalej, to ten Scrum Master z takiej roli nauczycielsko-mentorskiej przełącza się bardziej w kierunku roli takiego coacha, czyli osoby, która bardziej pyta niż podpowiada rozwiązania, bardziej słucha niż mówi jak ma być. Próbuję jakby pomóc zespołowi wydobyć ten taki ukryty potencjał, który w nim siedzi i wtedy już bardziej wchodzimy na taki poziom.
Ostatnio spotkałem się z takim bardzo fajnym określeniem emancypacji zespołu, czyli takiego odizolowania się od jakiegoś takiego lidera z zewnątrz. Bo to jest tak, że na początku startuje się z pozycji, jest takie ładne słowo w zarządzaniu Empowerment, czyli lider jakby usamodzielnia zespół, oddaje trochę swojej władzy, a później idziemy w kierunku właśnie takiego wyemancypowania się zespołu, czyli odcięcia się od tego lidera.
To jest jakby cała droga, przez którą musi przejść taki Scrum Master razem ze swoim zespołem i to są miesiące pracy. To nie jest tak, że ten proces dzieje się tak ze sprintu na sprint, ale tak gdzieś przynajmniej 12 sprintów musi minąć, żeby ten zespół przeszedł przez takie podstawowe etapy formowania się i wszedł na takie etapy, gdzie faktycznie już potrafi coraz bardziej pełniej korzystać z tej autonomii, która jest mu dana.
To są bardzo ciekawe, pasjonujące procesy. Mnie to strasznie spala. No, jeżeli coś jest takiego faktycznie, że nas wciąga i faktycznie chcemy się w to jeszcze bardziej wgłębiać, to może pobierać dużo energii. Wiesz, to są też takie rzeczy, które… Żyjemy w takich w ogóle fantastycznych czasach, moim zdaniem, i wszyscy to lubią. Ale bardzo fajnie opisała to Olga Tokarczuk. Pamiętam jeden z jej pierwszych wywiadów zaraz po tym, jak dostała Nobla. I powiedziała, że żyjemy w takich czasach kompletnej zmiany paradygmatu, czyli takiego jakby modelu świata, który nam do tej pory jakoś nam wystarczał, ale teraz mamy taką trudność, żeby jakieś te nasze mapy świata ulokować odpowiednio w tym wszystkim, co się dzieje.
Ten paradygmat się mocno zmienia, a my jeszcze tak nie bardzo potrafimy się w nim odnaleźć. To jest dokładnie to, co się dzieje w zarządzaniu. Te wszystkie mądre rzeczy, o których tutaj rozmawiamy. Pytałaś o agile, o zwinność, rozmawiamy o skramie. To są właśnie takie elementy tego nowego podejścia do zarządzania. Kiedyś pamiętam, że dla mnie bardzo odkrywcza była taka książka, która… Ja jedną nogą jestem filozofem, bo też hobbystycznie studiowałem filozofię.
Jest taka książka, którą bardzo polecam. Bez względu na to, czy ktoś z was ma jakieś zapędy filozoficzne czy nie, ale ona bardzo też oddaje to, co się dzieje w zarządzaniu. Książkę napisał taki fizyk, który został filozofem, później się przechrzcił na filozofa nauki Thomas Kuhn. Ona powstała dość dawno, bo to były lata 60., 1962 rok bodajże była data wydania. Mam zboczenie do dat, więc przepraszam od razu, że daty podaję. Żona się zawsze ze mnie śmieje, że jak robię jakieś wprowadzenia, to musi być kontekst, ale taki jestem i data. Więc rok 62. o strukturze rewolucji naukowych. Ta książka się tak nazywa. I Kuhn pokazał, po prostu cała książka jest o tym, jak dokonują się zmiany paradygmatu w nauce, czyli jak to jest właśnie, że najpierw byliśmy fanami mechaniki Newtona, a później pojawiła się teoria względności, a był czas, że fascynowaliśmy się teorią ewolucji Darwina, jak to się dzieje, że faktycznie nauka się rozwija. I on cały ten proces podzielił na kilka takich etapów.
Najpierw jest taki moment, że jest okres nauki normalnej, czyli mamy jakiś paradygmat, czyli mamy jakiś zbiór teorii, praw, narzędzi, za pomocą których próbujemy wyjaśniać świat. Ta dynamika Newtona na przykład próbowała wyjaśniać ruchy planet czy wahadeł. Ale później pojawia się taki moment, że ten paradygmat, ten zbiór teorii naszych naukowych przestaje nam wystarczać. Pojawiają się tak zwane anomalie. Kuhn używał takiego właśnie słowa. No i ten paradygmat zaczynamy coraz bardziej podważać, aż dochodzi do kryzysu. Kryzys to jest taki moment, kiedy już nie dajemy rady, żeby sobie wytłumaczyć ten stary świat z tymi nowymi rzeczami, z którymi mamy do czynienia. No i jest rewolucja w nauce.
Taka rewolucja kopernikańska na przykład, to jest dobry przykład tego, co się zadziało kiedyś w nauce. Pojawił się Kopernik, powiedział, że to Ziemia kręci się wokół Słońca. No a wcześniej był paradygmat Ptolemeusza i cała kosmologia Ptolemeusza, która wyjaśniała cały świat. No i zarządzanie jest dokładnie tak samo. Teraz mamy taki czas trochę rewolucyjny. No bo ten taki paradygmat Taylora, taki przemysłowy, w IT też to bardzo fajnie widać. Stąd w ogóle pojawił się ten cały ruch zwinności, jakby nie było. No bo na początku, jak inżynieria oprogramowania startowała, to były lata 50., 60., to takim naturalnym kierunkiem podpatrywania tego, jak zarządzać projektami było wojsko. Departament obrony Stanów Zjednoczonych, tam były różne standardy. Jakby IT się zafascynował wojskiem, ale też tym, a wojsko z kolei się zafascynowało Henrym Fordem i światem produkcji. Cała mentalność linii produkcyjnej były próby, żeby ją odwzorować w tworzeniu oprogramowania. I okazało się z czasem, że tak się nie da, bo proces pracy programisty bardziej przypomina artystę malarza, niż takiego kogoś, kto stoi na taśmie produkcyjnej gdzieś tam i próbuje rozwijać taki produkt, jakim jest samochód. No i stąd pojawiły się te wszystkie metody zwinne, które są próbą reagowania na te wszystkie anomalie, które mamy w zarządzaniu. Zrobiłem taki duży kontekst.
Agata: Ale dobrze, dobrze, bo to trzeba właśnie opisać, żeby to zrozumieć. Słowo zwinność, bo myślę, że każdy z nas rozumie, co to znaczy zwinne, sprytne, sprawne, płynne. A właśnie w zarządzaniu projektami, w tym scramie, na czym polega ta zwinność? Jak to wygląda? Czy to chodzi o to, jak te ułożone są te sprinty i to wszystko, czy o co tutaj chodzi?
Mariusz: Tak, w dużym skrócie. Zwinność dotyka tematu zmiany. Zmiana w tradycyjnym podejściu, w tradycyjnym zarządzaniu projektami, jak pewnie wiesz, była dużym wyzwaniem, nie? No bo ten proces tradycyjny jest taki mocno sekwencyjny. Są fazy, są pewne wejścia, wyjścia między fazami.
Teraz wyobraź sobie, że jak już wystartujesz, zbierzesz wymagania od klienta, opiszesz je w opasłym, 300-stronicowym Wordzie, wystartujesz z projektem i nagle w połowie się okazuje, że trzeba coś zmienić. No to cały ten proces zaczynasz jakby od początku, co powoduje duże koszty jakby całej tej zmiany. I to był jeden z takich problemów, z którymi ten świat zwinny próbował sobie jakoś poradzić. No i powstał pomysł na to, w jaki sposób pracować, tak żeby ta zmiana była czymś normalnym i oswojonym. Po prostu tak jest, że Scrum trochę zasymilował zmianę w dużym skrócie można powiedzieć. I czym to się różni?
Pierwsza podstawowa różnica polega na tym, że jak miałaś tradycyjny projekt, to w tradycyjnych projektach planowanie takiego projektu to były miesiące. Na przykład planowało się projekt na 12 miesięcy. Ja pamiętam takie czasy jak pracowałem w korporacji, pracowałem w krakowskiej Motoroli i tam były takie projekty 12 miesięcy plus, że tak powiem. I w Scrumie metoda czy filozofia pracy jest trochę inna. Zakładasz, że nie da się słonia zjeść na raz. Czyli dzielisz projekt na małe takie odcinki. Tymi odcinkami, już o nich żeśmy mówili, to są właśnie iteracje. Nazywamy je sprintami. I co taki sprint, co kilka tygodni próbujesz dostarczyć coś, co jest potencjalnie gotowe i wartościowe dla klienta. No i to jest taka rzecz, która bardzo różni się od tradycyjnego podejścia, bo zmiana w zasadzie może się pojawiać w twojej pracy co dwa, co cztery tygodnie. Możesz cały czas na bieżąco kontrolować i korygować te swoje działania.
Agata: Tak, dobrze też jest przy okazji tych różnic, mam takiego przykładu związanego z takimi podstawowymi rzeczami związanymi z podejściem do procesu. Bo w procesie takim tradycyjnym zakładasz jednak, że na początku z klientem ustalisz to, co chcesz, żeby było zrobione.
Czyli piszesz tą listę wymagań, zamykasz w Wordzie i na koniec idea jest taka, żeby tę książkę dostarczyć, ten zakres, który był planowany. A w metodach zwinnych wszystko opiera się na doświadczeniu, na empiryzmie, jest podejście empiryczne, proces empiryczny czasami mówimy. Czyli startujesz na początku z pewnymi celami, przychodzi klient i mówi jakie ma potrzeby. I ty w tym zespole interdyscyplinarnym, samoorganizującym się robisz wszystko, żeby te potrzeby zrealizować. Ale jak to zrobisz, to już tak naprawdę jest rzecz wtórna.
W tradycyjnych podejściach bardzo mocno się skupiamy na tym, żeby na początku zebrać wszystkie oczekiwania od A do Z, od klienta. Rzeczywistość nam pokazuje, przynajmniej w programowaniu, że tak się nie da do końca zrobić, bo jest to, tak jak mówiłem, proces twórczy. Dlatego trzeba bardziej empirycznie podchodzić do tematu. I teraz weźmy tego klienta, który przychodzi do nas z jakąś potrzebą. To potrzebą może być na przykład to, że klient chce pokonać taki dystans z punktu A do B. To jest jego cel na projekt. No i teraz co możesz zrobić jako zespół? Pierwszą rzeczą, którą możesz zaproponować, no to na przykład, nie wiem, możesz mu kupić bilet na autobus. To jest najprostsze co można zrobić. Ale załóżmy, że nie kupujesz biletu, tylko chcesz coś sensownego mu dostarczyć. Na przykład budujesz kawałek deseczki z czterema kółkami, taką deskorolkę. Po tych czterech tygodniach klient dostaje. Klient to bierze w łapki, testuje, ogląda, próbuje się przejechać. No i mówi, że no fajnie, faktycznie pokonuje ten dystans, ale jednak muszę włożyć trochę wysiłku, żeby się przejechać z punktu A do punktu B. A jeszcze jak mam spotkanie biznesowe z klientem, zakładam gajerek z krawatem, jest 30 stopni, to ta deskorolka nie bardzo mi się przydaje, bo chciałbym mniej wysiłku wkładać w pokonywanie tego dystansu.
No i jest kolejna iteracja, jest kolejny sprint i zespół kombinuje jak tu zaadresować te uwagi klienta. No i na przykład okazuje się, że z tej deskorolki może dołożyć napęd. To jest też taka rzecz, która jest prosta, ale może się zbudować rower na przykład po kolejnych kilku tygodniach. I cały myk polega tutaj na tym, to też jest taka różnica między tradycyjnym projektem, że tradycyjny projekt jest takim przedsięwzięciem ograniczonym w czasie.
Startujemy, planujemy, jest jakaś data końca, a tutaj po tych kilku iteracjach, jak klient dostanie rower z napędem na przykład, klient może powiedzieć, że ok, to jest to, co mi na ten moment w zupełności wystarcza, nie potrzebujemy dalej iterować. A będzie inny klient, który przyjdzie i powie, no ten rower z napędem to nie jest to, bo jak deszcz pada, no to mam mokrą głowę na przykład. No to nie, kombinujcie dalej. Kończy się kilkanaście iteracji i klient zostaje z prototypem samochodu na przykład. Ale to nie jest zdefiniowane.
Zauważ, że w zależności od klienta, w zależności od potrzeb biznesowych, możecie iterować krócej albo możecie iterować dłużej w tym naszym podejściu. Idea jest taka, że w metodach tych zwinnych, jakby na początku każdego sprintu stawiamy pewną hipotezę, robimy eksperyment przez kilka tygodni i na koniec z klientem próbujemy tą hipotezę w jakiś sposób zweryfikować, czy to jest to, czego chciał klient, czy to adresuje jego potrzeby, czy nie. Jeżeli nie, to stawiamy kolejną hipotezę w kolejnym sprintie i dalej robimy eksperyment, eksperyment, eksperyment, aż w końcu klient dostaje to, co jest dla niego ważne i wartościowe. A tutaj widzę takie dwa problemy, no nie, takie kwestie, które mnie interesują.
Pierwsza rzecz, z doświadczenia wiem, że jeżeli klient ma, wiesz, mówi na początku, chcę to i to, i jeżeli w czasie za dużo się projektu zmienia, za dużo się wtrąca, to tak naprawdę ten projekt nigdy nie dochodzi do końca, bo on sobie wymyśla w tym czasie, jak ten sprint trwa, nowe rzeczy i za każdym razem jest coś wdrażane, poprawiane. I to pierwsza rzecz właśnie praca programistów, może w pewnym momencie ich zmęczyć, odechcieć się im, bo nic nie jest dobre dla klienta, nic go nie zadowala.
A druga rzecz, trudno określić ramy właśnie czasowe, jeżeli klient potrzebuje pod koniec roku mieć, nie wiem, sklep internetowy, chce dojechać do swojego sklepu internetowego, chce mieć, załóżmy, taki faktycznie produkt, jaki sobie tam zażyczył, no to jeżeli będzie tak cały czas zmieniał nieświadomie, to tego nie będzie miał. No ale zauważ, że to też nie są, to jest taki, to o czym mówisz, to jest taki problem myślenia w skali makro i przykładania go do skali mikro trochę. To wielu product ownerów ma z tym problem, że na przykład, jak się coś nie udaje w takim sprincie, a na początku się nie udaje, no to rwą włosy z rozpaczy, że jest jakaś straszna porażka, bo zespół nie dostarczył zakresu. Ale zauważ, że te sprinty są bardzo krótkie. Najczęściej zespoły pracują w takich sprintach dwutygodniowych, czasami są to sprinty trzytygodniowe.
No idea jest taka, że na początku jakby stawiasz pewną hipotezę i umawiasz się na jakby cele, które chcesz zrealizować w ramach tego sprintu, no ale po dwóch tygodniach, no to jest raptem dziesięć dniówek roboczych, klient się pojawia i jest dalej dyskusja, pojawiają się też może użytkownicy tego produktu, który rozwijacie, co z tym dalej robimy, czy to jest właściwy kierunek, czy nie, więc nie ma tego ryzyka, tak mi się wydaje, o którym tutaj mówisz, że zespół będzie zmęczony tym, że klient ciągle coś zmienia. No jest taka idea, że ten zakres w ramach sprintu, jego nie ruszamy.
Wiadomo, że są różne sytuacje życiowe, że na przykład padnie serwer i trzeba nagle go naprawić, no bo jak nie, no to nasz produkt nie będzie w ogóle dostępny, ale idea jest taka, że planujemy zakres, planujemy jakieś cele na ten sprint i jakby nie wprowadzamy zmian w trakcie, jeżeli się okazuje, że na przykład te cele nie jesteśmy w stanie ich zrealizować, no to wtedy, to co mówiłem wcześniej, można ten sprint przerwać i zaplanować go od nowa, ale to jest rzecz, której raczej unikamy.
Agata: Ok, bo wiesz co, ja to mówię troszeczkę na swoim doświadczeniu, był projekt do wdrożenia, nie wiem czy to można przyrównać, ale myślę, że tak, jeżeli mówiłeś o marketingu, jakaś tam ścieżka marketing automation, że coś tam się ma zrobić po tym, coś tam po tym i ten projekt miał trwać miesiąc, trwał rok, bo co jakiś czas klient miał inne pomysły, inne benchmarki i tak naprawdę, no przyszło zmęczenie, zmęczenie tego, że nie możemy dowieść tego, że klient mówi jaki ma cel, my to robimy, a mu się za tydzień ten cel trochę modyfikuje albo chce iść inną drogą pod tym kątem.
Mariusz: A pracowaliście w Scrumie, tak?
Agata: Nie, to właśnie nie można powiedzieć, że to był Scrum, to bardziej było, że my dowoziliśmy właśnie część już do wdrożenia, załóżmy już zaprojektowane tam grafiki w ogóle, a się okazywało, że nie, nie, nie, my robimy coś innego, że to w ogóle nie działa.
Mariusz: No właśnie, bo to tak dlatego podpytuję, czy pracowaliście w jakiś taki w miarę zdyscyplinowany sposób, bo Scrum wprowadza pewien rytm, te iteracje faktycznie to jest coś, co powoduje, że my się uczymy też lepiej planować, uczymy się ustawiać cele, realizować te cele też pod kątem jakby właśnie tych krótkich iteracji, które są i taką pułapką, w którą wpada wiele zespołów, być może wy też mieliście takie poczucie tego, takiego niezadowolenia, czy przemęczenia, bo klient ciągle coś zmieniał, że pojawiają się wrzutki i w Scrumie to jest zmora, nie?
No bo startujemy sobie ze sprintem, zaplanowaliśmy prace, cele na dwa tygodnie, no i przychodzi jakiś dyrektor z innego działu na przykład, no i klepie Tomka po ramieniu, mówi słuchaj stary, no zawsze mi to robiłeś, dwie godzinki ci to zajmie, nie? Dwie godzinki tu, dwie godzinki tam i nagle się okazuje, że gdzieś tam 20% ekstra pracy dochodzi do takiego sprintu w Scrumie, no i to jest taka sytuacja, z którą trzeba sobie jakoś radzić, Scrum Master ma tutaj wyzwanie, żeby być taką tarczą dla zespołu i właśnie powoływać się na reguły Scrama w takich sytuacjach i przekierowywać takie ekstra rzeczy do właśnie roli produkcy, która to rola odpowiada za to, żeby właśnie ustawić cele razem z zespołem, żeby zarządzać produktem, rozwojem tego produktu i też zakresem w kontekście konkretnego sprintu, jeżeli będzie dochodziło 20% pracy albo będzie ktoś wrzucał ekstra rzeczy co dwa, trzy dni, to faktycznie zespół będzie się frustrował, że ciągle się coś zmienia i klient nie wie czego chce tak na dobrą sprawę, to zupełnie inaczej się pracuje jak masz takie właśnie ramy czasowe, takie interwały, po to też tutaj jest, żeby mieć taki stały rytm pracy w twoim zespole.
Agata: Ok, ok, no tam była też taka sytuacja, że to było niby akceptowane, a później się zmieniało, inny oczywiście, inne ustalenia, inny typ klienta też, ale właśnie tak mi ten przykład przyszedł do głowy, a powiedz mi jeszcze…
Mariusz: No ja miałem takiego klienta dość duża organizacja i pamiętam, że jak zaczęliśmy w ogóle wprowadzać tę metodę, to tam była taka sytuacja, że dział IT jakby był fakturowany za pracę przez dział biznesowy i jak myśmy zaczęli stosować Scruma, pierwsze sprinty w zasadzie pokazały, że gdzieś 20% tych ekstra rzeczy w ogóle jej nie ma na fakturze, to są takie niby ekstra przy okazji wrzutki dwugodzinne, ale tego się pod koniec sprintu zbierało na tyle dużo, że faktycznie, ponieważ pomiarowaliśmy bardzo dobrze to, co się działo w sprintach, więc było widać, że to była taka praca, która gdzieś tam znikała i rozbijała kompletnie właśnie morale zespołu i pracę nad dostarczaniem zakresu takiego sprintu.
Agata: No tak, bo cały czas wrzutki nie utrudniają dojście do celu, wydłużają tę drogę, to tak jak jedzie autobus, ma trasy, ale musi co chwilę się zbaczać z drogi, żeby kogoś wysadzić pod domem, a to tylko kawałeczek 100 metrów w lewo czy w prawo.
Powiedz mi jeszcze, od czego zacząć takie wdrażanie Scrama? Czy to jakiś jest proces, czy to właśnie trzeba specjalistę zewnętrznego wynająć, czy załóżmy można to samemu, ja wiem, że ty szkolenia też z tego prowadzisz, jak to wygląda?
Mariusz: Wiesz co, bardzo różnie to wygląda. Ja się jakby przetoczyłem przez różne sytuacje i dużych organizacji, mniejszych organizacji, ale tak myślę na potrzeby naszej rozmowy podam taką bardzo prostą ścieżkę, od czego zacząć, bo też nie chciałbym tego jakoś strasznie komplikować.
Wiadomo, że w dużej korporacji to można tak zacząć grubo i wtedy jest to faktycznie taka transformacja przez duże te, ale gdyby ktoś ze słuchaczy chciał sobie coś takiego wypróbować u siebie, to pierwsza rzecz, która się bardzo przydaje, dość oczywista, to jest zbudowanie pewnej świadomości na temat tego, czym w ogóle Scrum jest. I tutaj tak jak mówisz, to mogą być szkolenia.
Ja zapraszam, jesteśmy akurat w temacie takich szkoleń, które mam tydzień sprzedażowy teraz, więc na stronie zwinne-szkolenia.pl mam cztery takie szkolenia, które mogą zainteresować i zarówno świeżaków, jak i osoby bardziej takie doświadczone w Scramie, a dla świeżaków polecam szkolenie Scrum dla Zielonych, to jest jednodniowe szkolenie, tak pół na pół jest teorii, a druga część dnia ćwiczymy sobie robiąc bardzo różne dziwne rzeczy, więc to jest na początek takie szkolenie, które warto przejść.
Agata: A wejdę Ci w słowo, a kto powinien brać w tym Scramie dla Zielonych, Scram Master czy programiści, to tak jak jesteśmy w tym temacie?
Mariusz: Scram dla Zielonych to jest jedyny taki mój produkt, który tak jak mówiłem wcześniej, to jest moje takie baby, które jest dedykowane dla osób niezwiązanych z IT zupełnie.
Tak i mam cel, że wszystkie osoby, które chcą się dowiedzieć czegoś na temat Scruma, pracują w różnych branżach, bardzo różni ludzie się tam pojawiają, nawet ostatnio miałem żołnierzy z sił specjalnych, którzy chcieli się dowiedzieć i porównać na ile te metody są zbieżne z ich podejściem szkoleniowym, więc bardzo różne osoby się tam pojawiają.
No i też to szkolenie jest tak dostosowane pod względem przekazu, bardzo się staram, żeby było bardzo przystępne dla wszystkich i też ćwiczenia są tak dobrane, żeby faktycznie wszyscy zrozumieli, poczuli na czym polega mechanika pracy w Scramie, na czym polega mechanika pracy w zespole scramowym i też timing jest taki dosyć krótki, tak żeby tak poczuć trochę o co w tym wszystkim chodzi, bo mam jeszcze takie trzy szkolenia, ale one są już bardziej zaawansowane, tj. coaching w Scramie, to jest faktycznie takie szkolenie dla Scrum Masterów, Agile Coachów, Liderów, szkolenie na temat budowania z innych zespołów w oparciu też o model, o którym wspominałem, model Fris. To są już szkolenia dwudniowe i bardzo fajne nowe szkolenie, które była już pierwsza edycja w ubiegłym roku dla liderów, Agile Leadership też dwudniowe, takie szkolenie, które jest mocno nastawione na taką pracę z samym sobą trochę, z odnalezieniem się z tymi wszystkim w tych wszystkich parametrach, z którymi mamy do czynienia związanymi właśnie z autonomią zespołów, żeby odkrywać swój taki cel pracy z zespołem, zarządzać lepiej sobą, bo jak zarządzamy lepiej sobą, to lepiej nam się zarządza ludźmi, więc to są takie rzeczy już bardziej zaawansowane, a tak żeby budować świadomość, to na pewno Scram dla Zielonych to jest dobre miejsce, żeby się tam znaleźć.
Pytałaś czy ktoś z zewnątrz jest potrzebny? Niekoniecznie. Koniecznie jest potrzebny od razu konsultant, który wam podpowie jak to robić. Oczywiście taka pomoc się zawsze przydaje, ale nie jest to warunek taki obligatoryjny, żeby w ogóle w tej metodzie pracować.
Natomiast te kilka punktów, które dodam jeszcze, które faktycznie są ważne, to pierwsza rzecz, od której powinniście w ogóle zacząć, jak już będziecie mieli jako taką świadomość na temat Scruma, to żeby sobie odpowiedzieć na pytanie co jest waszym produktem. To jest mega ważna rzecz, bo ja tego nie mówiłem wcześniej, nie chciałem już tak za dużo namieszać, ale Scram w ogóle czy metody zwinne nie dotykają projektów.
Tam się nie mówi za dużo o projektach, tylko bardziej mówimy o produktach. Bo projekty, jak weźmiemy sobie taką tradycyjną definicję, czyli jakieś przedsięwzięcie ograniczone w czasie, które ma na celu dostarczyć jakąś usługę albo produkt, nie bardzo pasuje w ogóle tak jak tutaj już trochę opowiadałem do tej metody, bo po pierwsze nie ma tej, o czym żeśmy mówili, tej czasowości. Na dobrą sprawę taki mini projekt może być sprintem, ale to wszystko co się dzieje wokół produktu, to używanie tradycyjnego słowa projekt jest tutaj po prostu słabe.
Tak samo sukces projektu, rozumienie sukcesu projektu jest też inne niż tradycyjnie. No bo tradycyjnie tak się mówiło, że sukces jest wtedy, kiedy dostarczymy zakres w zaplanowanym czasie i wtedy mamy jakiś sukces projektu. A tutaj tak na dobrą sprawę jest takie fajne powiedzenie, które się przypisuje Leonardo da Vinci, że dzieła nigdy nie są kończone, tylko porzucane przez artystów.
Taki product owner w pewnym momencie porzuca swój produkt. Normalnie byśmy jechali do końca, tutaj na przykład po 6 miesiącach okazuje się, że taki sklep internetowy to jest to, co go już satysfakcjonuje na przykład. Więc definicja produktu też jest bardzo płynna jak pewnie zauważyłaś. Więc z tych powodów tego słowa projekt się nie używa, bardziej mówimy o produkcie, który chcemy dostarczyć. I tutaj ważna rzecz, tym produktem mogą być bardzo różne rzeczy. Na przykład kampania marketingowa, o której mówiliśmy, zrobienie e-booka może być takim produktem. Produktem może być przygotowanie serii wpisów na bloga firmowego.
Produktem może być, kiedyś pracowałem z taką firmą, która akurat z jednym działem tej firmy bardziej, z działem HR-owym. I oni sobie wymyślili, żeby proces rekrutacji na określone stanowisko też ograć za pomocą Scruma. Czyli cały proces od momentu powstania profilu stanowiskowego poprzez posting tego profilu, kontakt z agencjami, później rekrutacja tego kandydata, rozmowy i cała reszta, która się z tym wiąże, żeby to był taki produkt Scrumowy.
Przy myśleniu o produkcie to też taka uwaga na początek, cenna myślę. Ale jak będziecie patrzeć na to, co robicie, to zwróćcie uwagę, czy wasz produkt nie jest za bardzo powtarzalny. Jeżeli na przykład, kiedyś rozmawiałem też przy okazji projektu Scrum dla Zielonych z taką bardzo sympatyczną szefową księgowych, które w firmie zajmowały się po prostu wklepywaniem faktur w dużym stopniu. Więc takiego procesu, który jest bardzo powtarzalny, to ta metoda do czegoś takiego się nie nadaje. Jeżeli macie produkt, który będzie tworzeniem bardziej, czyli chcemy stworzyć kampanię marketingową, to to jest fajna rzecz, którą można zrobić za pomocą tej metody.
Oczywiście w IT jest prościej, bo mamy aplikacje, bo mamy jakiś system informatyczny, sklep, CRM, różne produkty mogą powstawać. Ale jak myślicie o stosowaniu tej metody poza IT, to też się nie ograniczajcie, bo tak jak już tutaj pokazałem wiele przykładów. Nawet, nie wiem, radio NPR w Stanach wykorzystuje do tworzenia audycji radiowych na przykład, do montowania programu odcinków. To też są takie produkty, które możecie wykorzystywać.
Podcast można robić też Scrumem, umawianie gości do podcastu, później kontakt z nimi. To są wszystko takie zadania połączone w jakiś konkretny produkt, który powstaje. Więc powiedziałem świadomość, zdefiniuj sobie swój produkt, czy się da, czy nie jest za bardzo powtarzalny. Trzecia rzecz, czy masz zespół. Też jest to mega istotna sprawa.
Też pamiętam taki projekt, którym się wszystkim chwalę. Taka firma ze Stężycy, która się zajmuje hodowlą Storczyków, firma rodzinna, bardzo sympatyczna. I tam zaczynaliśmy w dwóch zespołach i w jednym zespole ten Scram tak nie do końca działał od początku. Coś tam było ciągle nie tak. I pamiętam, że po pierwszym sprincie zrobiliśmy taką nasiadówę z zespołem. No i okazało się, że oni nie są zespołem tak na dobrą sprawę, że oni pracują jednak nazywając siebie zespołem, ale pracują nad bardzo indywidualnymi projektami, które w ogóle nie są powiązane ze sobą. Więc tutaj to trzecie kryterium dość istotne, to czy macie zespół, czyli taką grupę osób, która ma współzależne cele.
Czyli jeżeli są zadania związane z rozwojem tego produktu, jeżeli pracujecie nad kampanią marketingową, i na przykład są jakieś tematy, które wymagają współpracy kilku osób, dwóch przynajmniej osób w waszym zespole, no to możecie myśleć o stosowaniu tej osoby.
Jeżeli macie ludzi, którzy pracują nad kompletnie różnymi niepowiązanymi zadaniami, to od razu wchodzenie w Scruma, bo to będzie sztuka dla sztuki, będzie się tylko frustrować, że doszła wam jakaś ekstra praca, która jest kulą u nogi bardziej niż wpływa na to, że pracujecie jakoś bardziej efektywnie.
No i dwie ostatnie rzeczy, które trzeba dodać, to to czy macie Product Ownera, czyli taką osobę, która będzie wam, będzie nawigowała waszą pracę, będzie wam ustalała cele właśnie w ramach sprintów, będzie ustalała cele takie też bardziej długofalowe, które będzie zarządzała tymi wszystkimi wymaganiami, które będą powstawały, w Scramie to się nazywa, ten język jest taki ezoteryczny trochę, ale tak go powoli tutaj, ostrożnie go używamy, backlog produktu, czyli lista rzeczy, która jest do zrobienia w ramach rozwoju waszego produktu, lista rzeczy, która jest zmienna bardzo, to jest taka lista, która może się zmieniać w zależności od sprintu, ale ważne jest to, żeby była jedna osoba, która będzie takim oknem na świat tego zespołu. Jeśli chodzi o wymagania, to jest taka osoba, która będzie się komunikowała z otoczeniem biznesowym, będzie się komunikowała na przykład z użytkownikami, z klientem, bo to nie musi być wcale klient, czasami zdarza się, że jest to klient, ale nie zawsze, to będzie osoba, która będzie obsługiwała ten cały zewnętrzny świat, będzie samodzielna, będzie czuła produkt, będzie czuła rynek i będzie takim jedynym w zasadzie punktem kontaktowym, jeśli chodzi o wymagania dla tego zespołu.
No i ostatnia rzecz to jest, czy jest Scrum Master w tym zespole, czy macie Scrum Mastera. Spotykam się czasami z organizacjami, które stawiają na mocną rolę product ownera, a nie myślą o Scrum Masterze, czyli nie ma Scrum Mastera, no ta rola bardzo się przydaje. Jeżeli się zastanawiacie, to jak widzicie podaję to jako taki element dość krytyczny przy myśleniu o wdrożeniu Scruma, bo faktycznie na początku jest zwłaszcza, na początku jest potrzebny ktoś, kto wam pomoże z tym procesem pracować. Jest mnóstwo innych rzeczy, ale te są chyba takie, wydaje mi się, takie najbardziej istotne, żeby w ogóle wystartować z myśleniem o Scramie.
Agata: A product owner nie może być też Scrum Masterem?
Mariusz: No to jest taka mieszanka najbardziej wybuchowa, ze względu na przykład na konflikt interesów, bo product owner to jest taki ktoś, kto tak kolokwialnie mówiąc będzie dociskał zespół kolanem, żeby robił więcej, a Scrum Master to jest taka bardziej tarcza tego zespołu, więc przy różnych mieszankach tych ról to jest takie jedno połączenie, które mocno odradzam, żeby product owner nie był Scrum Masterem.
Czasami ludzie piszą do mnie, że jak mówię o tym, że a u mnie tak robimy i tak się da, więc jeżeli tak się da, no to nie wnikam, ale wiele doświadczeń takich moich pracy z zespołami pokazuje, że jest taki silny tutaj konfig interesów, że nie powinniśmy tego robić.
Podobnie takie połączenie, o którym też warto pamiętać w tyle głowy, jak te role są umocowane, trochę mówiłem o Scrum Masterze w organizacji, bo taki też taka dysfunkcja, z którą mam czasami do czynienia w firmach, to jest to, że Scrum Master jest częścią zespołu Scrumowego i przełożonym tego zespołu jest product owner.
No to też możecie sobie wyobrazić spotkanie takiego Scrum Mastera na jakiejś ocenie rocznej, przychodzi do product ownera, który jest jego szefem i ten product owner mówi, że nie byłeś mało elastyczny w ostatnim kwartale. No to też jest taka sytuacja, której powinniśmy unikać w myśleniu o obstawianiu tych ról.
Wszystkie takie role, które się wiążą z czymś, co nazywam tak roboczo, może dziwnie to zabrzmi, ale z każeniem menedżerskim. Nie mam absolutnie nic złego na myśli, tylko chodzi mi o pewne nawyki takie związane z menedżerowaniem, z liderowaniem, to też słabo się łączy z rolą Scrum Mastera, bo Scrum Master to jest taka rola, która musi się często gryźć w język, jak zespół ma jakiś problem, żeby temu zespołowi tego problemu nie rozwiązywać. A wielu liderów, wielu menedżerów, jak próbuje, też przerabiałem takie scenariusze, wchodzić w buty Scrum Mastera, to niestety jest tak, że to jest odruch, to jest nawyk, który trzeba wykorzenić.
To nie jest łatwe, bo przez wiele lat te osoby często pracowały jako szefowie i od nich się po prostu oczekiwało, to jest jakby domeną ich roli, żeby podejmować decyzje, żeby rozwiązywać problemy. Pamiętam taką historię, kiedyś pomagałem w takiej firmie Continental w Niemczech, bardzo sympatycznej, tam byłem przez półtora roku, jako osoba z zewnątrz właśnie i startowaliśmy z takim bardzo sympatycznym zespołem jako pilotaż.
Tam był taki Christian, który nie mógł sobie poradzić. Bez niego w ogóle cała ta zmiana mi się nie udała, to też warto powiedzieć, ale pamiętam pierwszą retrospektywę, jak zespół zaczął wyliczać różne problemy, z którymi się borykał w minionym sprintcie, a Christian od razu mówi, no dobra, to robimy tak, to robimy tak, ty się zajmiesz tym i nagle wszyscy wybuchnęli śmiechem i Christian też mówi, no to jest tak silne, że nie mogłem nad tym w ogóle zapanować.
No i to też pokazuje, jak ciężko jest z takim nawykiem pracować, wchodząc w taką rolę z Scrum mastera. On później zrobił taki numer w Singapurze, tam był zespół bardzo mieszany, byli Hindusi, byli ludzie z Chin też i pamiętam, że tamta kultura, jeśli chodzi w ogóle o Agile, jest bardzo specyficzna. Powiedziałbym, że dość trudno wdraża się ten sposób pracy, wciąż trudno i ludzie się tak zamknęli, że już praktycznie retrospektywa nie miała sensu.
Tak, to było bardzo trudne, jak ktoś wchodzi w taką rolę szefa, to właśnie w kulturze wschodniej jest później ciężko jakby wyjść z tej relacji przełożonej i podwładnej. Ludzie się bardzo blokują, jeśli chodzi o mówienie o takich rzeczach, które nie działają, które są trudne i tego typu rzeczy, więc… Kultura, tak, tutaj też chyba ma znaczenie właśnie takie podejście. I ludzi, i kultury, i środowiska, może być to trudne.
Bo pamiętam, miałem taki półroczny projekt też w Indiach, bardzo ciekawy w Mumbai’u i tam przyjechałem, oni pracowali, to była firma, która była takim dużym dostawcą zewnętrznym jednej organizacji w Anglii.
No i tam było tak, że jeśli chodzi o obsadzenie roli, wiele różnych było ciekawych wniosków, ale tak chcę powiedzieć o roli Scrum Mastera właśnie, bo departament i dyrektor departamentu sobie tak wymyślił, że on będzie takim Scrum Masterem.
Bo jak pytałem ich, dlaczego w ogóle zrobili coś takiego, to powiedzieli, no bo tam jest ten master, dla nich master to jest po prostu taki mistrz, który jest takim przewodnikiem duchowym i oni wymyślili sobie właśnie, że skoro Scrum Master, to najlepszym Scrum Masterem będzie właśnie dyrektor departamentu.
Jest też zaszyta gdzieś tam mocno w tej kulturze kastowość, mimo że tak wprost o tym nie mówią i jak rozmawiają z nimi, to oczywiście się wzbraniają, że czegoś takiego nie ma, w relacjach takich codziennych projektowych, zespołowych to bardzo, bardzo wychodzi.
Agata: A czy można jeszcze tak na koniec takie pytanie mam do Ciebie, czy można tylko niektóre elementy tego Scruma wdrożyć, załóżmy Sprint, czy… Znaczy jak teraz to pytam, to trochę tak trudno mi sobie to wyobrazić, że jest Sprint i później nie ma tej retrospektywy albo tych backlogów, ale może znasz przykłady, że załóżmy niektóre firmy tak na początek, żeby sprawdzić jak to będzie wyglądało u nich w firmie, wprowadzają tylko niektóre elementy.:
Mariusz: Wiesz co i tak i nie. Z jednej strony oczywiście można i zaraz powiem, jak to może wyglądać, natomiast jeżeli myślicie o wdrożeniu tej metody, jeżeli chcecie to nazywać dalej Scrumem, no to oczywiście nie. To jest tak jak, jak byłem mały, to pamiętam, że z sąsiadem, żeśmy namiętnie grali w piłkę, ale trudno to było nazwać piłką nożną, bo po prostu była piłka i jakieś podwórko z bramką narysowaną gdzieś tam na ścianie, no ale to nie była taka piłka, jaką oglądamy gdzieś tam na mistrzostwach, więc jest tutaj tego typu różnica.
Natomiast na początek jak wdrażacie, bo to też jest taka rzecz, z którą się spotykam, która jest pewną dysfunkcją, mamy taką tendencję, żeby od razu jakby wyrzucać rzeczy, które nas jakoś tam uwierają w tej metodzie. I to nie jest dobre. Dopasowywać do siebie. Mam sporo takich, ostatnio coraz więcej takich projektów, to też wynika z tego, że ta metoda się rozwija, jest bardzo popularna w różnych organizacjach, że faktycznie firma mnie prosi, żebym przyjechał, zrobił taki asesment, na ile oni mają tego skrama wdrożonego, czego im brakuje, daje jakieś uwagi ewentualnie i całkiem sporo niestety jest z takich organizacji, która zaczyna od wyrzucania rzeczy, które gdzieś tam faktycznie ich bolą i im nie bardzo pasują.
Często to wyrzucanie wynika z jakichś takich ukrytych założeń, zresztą nieprawdziwych, bardzo często na temat tej metody, bo na przykład po co nam spotkania na stojaka, na inne stand-upy, codzienne skramy, jak no przecież siedzimy razem i rozmawiamy, no to po co w ogóle się spotykać jeszcze tak na 15 minut i zrobić z tego jakąś wielką sekciarską ceremonię. To jest taki jedna z typowych rzeczy. No i później się wyciąga te różne elementy.
Natomiast jeżeli myślicie o wdrożeniu, zachęcam bardzo mocno, żeby sobie zrobić taką terapię szokową. We wszystkich tych takich organizacjach, zwłaszcza nie IT, od tego zaczynamy, żeby faktycznie, przynajmniej przez pierwszy sprint, tak bardzo dogmatycznie podejść do tej metody i faktycznie wszystko po kolei, tak jak jest to zdefiniowane w skramie, próbować zrealizować. Bo to wam pokaże bardzo szybko, gdzie są dysfunkcje w waszej organizacji. Skram jest takim lustrem trochę. Patrzycie sobie na siebie, na swój zespół, na firmę i bardzo szybko zobaczycie, które elementy nie pasują do tej metody, które trzeba by ewentualnie poprawić, zaadaptować, żeby to wszystko się jakoś kupy trzymało i co ewentualnie można by dostosować, żeby było lepiej.
Czyli zastosować to, co jest sercem tej metody, czyli podejście empiryczne. Uczymy się na doświadczeniu, stawiamy hipotezy, sprawdzamy, eksperymentujemy i korygujemy cały proces. Tak jest dobrze. To jest taki model, który też jest stosowany w sztukach walki.
Na początku ten model się nazywa shuhari. Jest ta faza shu, gdzie ten uczeń trochę na ślepo, na pamięć powtarza różne dziwne gesty swojego mistrza. W tej drugiej fazie ha, to już jest taki moment, kiedy uczeń zaczyna trochę rozumieć, po co to wszystko jest. Ta ostatnia faza ri jest taką fazą, gdzie ucznia robi się mistrz i on już jest na tyle oświecony, że może w tej metodzie, w tym podejściu tworzyć własne kroki. Na tym to polega. Jak zacznie się od końca, niestety tak jest, że się zaczyna od końca i każdy chce być mistrzem już od razu w scramie, no to później właśnie dużo na tym tracimy. Ta metoda jest tak skonstruowana, że mimo, że jest naprawdę bardzo prosta, to są tam zawsze takie elementy, które się mocno ze sobą łączą i w efekcie, jak w sposób taki zdyscyplinowany się do tego podchodzi, dają efekt w postaci takiego zespołu, który faktycznie pracuje na wynik.
A odpowiadając na twoje pytanie, czy da się, powiedziałeś i tak i nie, bo oczywiście też tak uważam, że stosowanie niektórych elementów nawet tej metody na początek ma dużą wartość. Na przykład to, co powiedziałeś, żeby myśleć w ogóle o projekcie w taki sposób, że nie robimy wszystkiego na raz. W scramie jest zaszyta taka myśl, taka zasada tak naprawdę z osobistej produktywności. Ja po raz pierwszy o niej przeczytałem u Davide Alena w książce Getting Things Done, która jest też taką legendarną, jeśli chodzi o ogarnianie swojej życiowej kuwety.
I on wprowadził tam takie bardzo mądre rozróżnienie, którego nie byłem bardzo długo świadomy, mianowicie na projekt i zadanie. Projekt to jest taki cel, którego realizacja wymaga właśnie kilku czynności, które są ze sobą powiązane. Bo my często mylimy projekt właśnie z zadaniem i próbujemy wszystko robić na raz, próbujemy tak długofalowo planować. Ja podaję często przykład takiej mojej pomyłki, mianowicie sprzątania strychu. To było takie moje zadanie, które traktowałem właśnie później jako projekt, że chciałem go posprzątać na raz i odkładałem. Jak tylko się długo to dało robić.
No ale jak sobie to podzieliłem właśnie na zadania, że najpierw wywiozłem puszki gdzieś tam do lamusowni po farbie, później zadzwoniłem do komisu, żeby zabrali wersarkę, to ten projekt przestawał być taki straszny. I tak samo jest tutaj. Myślenie o takiej pracy iteracyjnej w kontekście projektu, na koniec każdej iteracji powstaje jakiś przyrost, jakiś inkrement tego, co chcemy dostarczyć klientowi, to już jest duża wartość dodana.
Kolejna rzecz, może dwie rzeczy nawet, które nie są do końca scramowe, one tak przywędrowały z różnych innych, nie chcę powiedzieć organizacji, ale jakichś takich praktyk czy doświadczeń. No to są na przykład retrospektywy. Retrospektywa to nie jest jakaś nowość, którą scram wprowadził, bo takie spotkania na koniec projektu praktycznie w każdym podejściu są stosowane. No tylko minus jest taki, że te retrospektywy projektowe, ja pamiętam też jak pracowałem etatowo, to one się nazywały postmortem projektu, nazwa taka straszna po śmierci projektu, ale problem z nimi był taki, że na koniec w zasadzie niewiele dało się już zrobić. Projekt się skończył po tych 12 miesiącach i klops. Zebrałaś jakieś fajne akcje do poprawy, ale później rusza kolejny i tak nie wszystkim się chce tam zaglądać do tych akcji, a tutaj w scramie co dwa, cztery tygodnie masz taką pętlę informacji zwrotnej podczas tych retrospektyw i na bieżąco co kilka tygodni korygujesz działanie, więc same retrospektywy już dużo dają. To nie musicie też wprowadzać retrospektyw w kontekście iteracji, tylko w ogóle robicie jakąś rzecz, projekt, cokolwiek to jest, to jest bardzo wartościowe.
A druga rzecz, czy trzecia już, to są stand-upy, o których mówiłem, to też jest taka rzecz nie scramowa. Kiedyś popełniłem wpis na blogu na ten temat, bo taka historia mnie zafascynowała, która pokazuje moc w ogóle tych spotkań. Historia, która wydarzyła się na Mount Everestie, Eric Weichelmaier, 30-letni, wówczas to był rok, znowu data, uwaga, 2001. Wybrał się na Mount Everest i nie byłoby w tej wyprawie nic dziwnego, gdyby nie fakt, że on był niewidomy od 13 roku życia w zasadzie. I to, co pomogło mu przejść, taki trudny moment, który, zresztą jest bardzo fajna relacja na YouTubie, opis tej wyprawy, to był taki wodospad kumbu, przez który w ogóle himalaiści, którzy widzą, mają problem, żeby się przez niego przedostać, to im to trochę zajęło, ale dziwnie może to zabrzmi, ale tak jak on opisywał całą tą wyprawę, to dużo eksperymentowali. I to, co im pomagało, to były właśnie takie spotkania na stojaka w namiocie, które codziennie pod koniec dnia sobie robili, żeby popatrzeć na dzień, co działało, co nie działało, co ewentualnie mogą spróbować kolejnego dnia. W ten sposób wdrapali się na Mount Everest czy też na przykład generał Pagonis, który dowodził logistyką podczas wojny w Zatoce Perskiej. On z kolei rano robił takie półgodzinne spotkania na stojaka z żołnierzami po to, żeby były właśnie szybkie.
Zdaje się nawet, że Malcolm Gladwell gdzieś opisał w jednej ze swoich książek właśnie takie stojaki w tym wypadku. Więc to są takie rzeczy, które można niezależnie od metody wykorzystać jako takie rzeczy cząstkowe, które już wam dużo dadzą w pracy nad waszym produktem. Czy na przykład zespół, praca taka interdyscyplinarna w zespole to też jest rzecz, która może się pojawić.
Na przykład w metodzie design thinking też ten pomysł takiej komplementarności różnych kompetencji się pojawia. Też to nie jest połączone ze scrumem. Można łączyć, ale też jest przykład takiej wybranej praktyki.
Agata: Tak, tak, tak. No tak, design thinking też, właśnie też byłam nawet na szkoleniu i tam też jest takie mądre podejście, zwinne podejście do wszystkiego, do planowania głównie. Super. Słuchaj, ja ci bardzo dziękuję.
Powiedz jeszcze, ja napiszę, to jest adres strony, jeszcze raz jakbyś podał gdzie te szkolenia, jakby ktoś był zainteresowany.
Mariusz: Zwinneszkolenia.pl to jest stronka.
Agata: Ok, ja tak, ja podam.
Mariusz: Nie wiem czy będzie kolejne, bo ostatnio nawet w podcaście tak trochę postraszyłem potencjalnych uczestników, bo szykuję grubą rzecz bardzo, o której jeszcze nie mogę mówić. Ale jeżeli wszystko wypali, to mnie to pewnie tak pochłonie, że pewnie kolejnej edycji w 2020 nie będzie, także korzystajcie póki takie okienko się pojawia. Ale zobaczymy, to jeszcze nie jest przesądzone. Mam taki pomysł i zobaczymy czy wypali. No to trzymam kciuki, żeby wypalił, jeżeli ciebie kręci i to będzie coś fajnego, tak jak mówisz.
Super. Słuchaj, ślicznie ci jeszcze raz dziękuję.
Mariusz: Patrzę na zegar i strasznie długo rozmawialiśmy. Tak mnie zagadałaś skutecznie.
Agata: Ale same mądre rzeczy, przykładami wiesz, tutaj przykłady podawałeś, więc to jest najbardziej wartościowe.
Mariusz: Tak patrzę na zegarek, muszę pracować nad zmniejszeniem złożoności poznawczej zdecydowanie.
Agata: Słuchaj, ślicznie ci dziękuję i do usłyszenia, mam nadzieję, że może do zobaczenia.
Mariusz: Bardzo miło, dziękuję za zaproszenie i pozdrawiam wszystkich słuchaczy. Trzymajcie się. Hej
Agata: Hej. Ten cały Scrum to z jednej strony bardzo ciekawa rzecz, przynajmniej dla mnie. A z drugiej wydaje się taki trudny przez te swoje nazwy, sprinty, iteracje, retrospektywy. Ja przyznam, że dzięki pracy w nowych technologiach część tych pojęć trochę znam. Ale nigdy nie miałam możliwości brania udziału w tym od A do Z. A chciałabym. No bo to jest takie ciekawe, zwinne, brzmi tak kusząco. A jestem ciekawa jak to jest u ciebie. Czy w twojej firmie wdrożono skram, a może planujecie to zrobić? Fajnie jak podzielisz się swoimi przemyśleniami w ogóle o tym całym Scrumie, jak to jest u was w firmie w komentarzu na stronie achmielewska.com/63. No i jeszcze raz przypominam o szkoleniu Mariusza, link w notatkach. Może ktoś będzie zainteresowany, a ja po prostu znając Mariusza serdecznie ci polecam ten kurs. Na sam koniec bardzo ci dziękuję, że słuchasz podcastu Firma Online. Będzie mi też miło jak podzielisz się linkiem do tego odcinka z osobami, które mogą zainteresować tematy, jakie tu poruszam z moimi gośćmi. No i co, trzymaj się zdrowo i wesoło. Do usłyszenia, pa! Jeśli uważasz, że ten podcast może być pomocny także innym osobom, poinformuj ich o nim, a także zostaw opinie na iTunes. Niech konwersja i uśmiech będą z tobą.