Przeprowadziliśmy wywiad z bardzo ciekawym i inspirującym człowiekiem z naszej branży – Mariuszem Chrapko, ekspertem w dziedzinie wdrażania i adaptacji metod agile w dużych organizacjach i autorem bestsellerowej książki „Scrum. O zwinnym zarządzaniu projektami”. Mariusz Chrapko prowadzi również bardzo wpływowego bloga o zwinnym zarządzaniu oraz podcast „Menedżer Plus”. Na co dzień pomaga liderom oraz członkom zespołów projektowych w procesie budowania zwinnych organizacji. Zapraszamy do lektury i komentowania.
JestemPM.pl: Jak opisałbyś Scruma w jednym zdaniu, początkującemu project managerowi, a jak „wyjadaczowi” z wieloletnim doświadczeniem, ale zakorzenionym w kaskadowych metodykach takich jak Prince 2 czy PMBOK?
Mariusz Chrapko: Jednemu i drugiemu powiedziałbym to samo. Scrum jest pewnego rodzaju metodą organizacji pracy, która dotyczy rozwoju produktu. To by było moje jedno zdanie. (śmiech) Ale, znając siebie, dodałbym jeszcze, że tym produktem może być software, ale też zrealizowanie konkretnej kampanii marketingowej. Scrum nie ogranicza się do konkretnej domeny, czy typu działalności firmy. Oczywiście, póki co, wciąż najbardziej popularny jest w projektach IT. Ale z powodzeniem można stosować go także w innych przedsięwzięciach. Ja sam, kilka razy miałem przyjemność wspierać wdrożenie Scruma w organizacjach pozarządowych.
JestemPM.pl: I, co? Dało się?
MC: Tak, jak najbardziej. Co, ciekawe te organizacje mają bardzo podobne problemy wdrożeniowe jak te, z którymi „boksują się” duże korporacje. Jednych z nich jest na przykład prowadzenie wielu projektów na raz. Na upartego, można to jakoś próbować zrozumieć. Mała organizacja, brakuje ludzi. Trzeba tę pracę jakoś zorganizować. Ale w dużych korporacjach jest dokładnie tak samo. Tam problem wielozadaniowości też występuje. A przecież firmy te mają zupełnie inną skalę, niż mała fundacja.
JestemPM.pl: A jak najlepiej nauczyć się Scruma?
MC: W mojej książce „Scrum. O zwinnym zarządzaniu projektami” porównałem naukę Scruma do lekcji pływania. Możesz bardzo długo teoretyzować o tym, co powinieneś zrobić, żeby pływać. Możesz godzinami dyskutować ze swoim trenerem, jak się powinieneś ustawić, jak poruszać rękami, jak oddychać. Ale tak naprawdę, koniec końców, najlepiej jest wskoczyć do wody. Im szybciej to zrobisz, tym lepiej.
Typowym błędem, które popełnia większość firm, przy projektowaniu wdrożenia agile, jest próba zdefiniowania wszystkich możliwych warunków, które muszą być spełnione, żeby Scrum się udał. A tak się nie da. Nie da się wszystkiego na początku przewidzieć. Przede wszystkim, nie da się przewidzieć, jak zareaguje firma na taką zmianę. Przy okazji, polecam bardzo dobrą książkę na temat nieprzewidywalności różnych losowych zdarzeń „Czarny Łabędź”, autorstwa Nassima N. Taleba. Oczywiście, istnieje kilka podstawowych elementów, które muszą być spełnione, żeby ruszyć. Ale reszta to już efekt inspekcji i adaptacji. Ogromną siłą Scruma jest właśnie empiryzm. Powinniśmy z niego korzystać.
JestemPM.pl: Co Twoim zdaniem jest przyczyną popularności Scruma?
MC: To, że ta metoda naprawdę działa. Jest „lekiem” na wiele bolączek, z którymi nasza dotychczasowa skrzynka narzędziowa (podejście kaskadowe) sobie nie radzi. Jednym z nich jest na przykład możliwość szybkiego reagowania na zmieniające się wymagania. W projektach kaskadowych zmiana w trakcie prac projektowych nie jest mile widziana. Bo wiąże się z dużymi kosztami jej implementacji. Filozofia agile poradziła sobie z tym problemem w bardzo prosty sposób. Zaakceptowała zmianę. Uznała jej normalność. Zmiana stała się nieodłącznym elementem prac nad rozwojem produktu.
Drugi powód, o którym chciałem wspomnieć, to fakt, że Scrum bardzo mocno stawia na ludzi, którzy wspólnie pracują nad rozwojem produktu. Mają wspólny cel. Ten cel ich łączy, cementuje. Filozofia agile, zakłada, że nie wystarczy, tylko nająć pary rąk do pracy, bo za nimi idzie cały człowiek. To od ludzi zależy sukces projektu. Mam trochę wrażenie, że tradycyjne zarządzanie o tej pracy zespołowej jakoś zapomniało. Skupiliśmy się na różnego rodzaju procedurach, checklistach, audytach, i gdzieś w tym wszystkim zapomnieliśmy o człowieku. Agile jest popularny, bo zauważa ludzi.
I może wspomnę jeszcze o trzecim powodzie popularności Scruma. Dostarcza wartość w 30 dni. Żyjemy w czasach, kiedy nie opłaca nam się czekać. Bo konkurencja nie śpi. Bo rynek nie śpi. To, co wymyślimy dzisiaj, a dostarczymy po dwunastu miesiącach może się okazać już niepotrzebne. Bo się zestarzeje. Dzięki bliskiej współpracy z Biznesem oraz pracy w krótkich cyklach wytwórczych (sprintach), za każdym razem możemy dostarczać coś wartościowego szybciej.
JestemPM.pl: Powiedzieliśmy o zaletach, ale jak we wszystkim, istnieje też zapewne druga strona medalu. Co według Ciebie jest piętą achillesową Scruma i agile?
MC: Lubię określać agile jako filozofię tworzenia oprogramowania. Filozofia w starożytnym języku greckim oznacza „umiłowanie mądrości”. Filozofia próbuje „zmóżdżyć” się nad podstawowymi problemami naszej rzeczywistości. Próbuje dotrzeć do ich istoty. Wyjaśnić je. Podobnie jest z agile. To zbiór wartości i zasad, które tłumaczą rzeczywistość naszych projektów. Mówią, na co powinniśmy zwrócić uwagę, żeby się udało. Żeby nasza praca miała sens.
Muszę przyznać, że trudno jest mi mówić o wadach tej filozofii. Bo się z nią w stu procentach zgadzam. (śmiech) Ale na upartego, można poszukać jakichś wad. (śmiech) Bo filozofia agile, wiąże się bardzo mocno ze zmianą naszego światopoglądu. To zupełnie inny paradygmat zarządzania. Inny, niż ten, który dotychczas stosowaliśmy w naszych projektach. I zmiana tego paradygmatu nie jest łatwa. I nie tylko, jeśli chodzi o menedżerów, ale także członków zespołu projektowego.
Natomiast Scrum… Jest jedną z metod filozofii agile. Tutaj jako „wadę” wskazałbym na pewno jej ogromną prostotę. Ta prostota jest bardzo zwodnicza. To jest trochę tak jak z rowerem, w którym odwrotnie skręca kierownica. Pamiętam, że jak pierwszy raz zobaczyłem kogoś, kto próbował jeździć na takim rowerze. Pomyślałem sobie: – Banał. Ja też dam radę. Wsiadłem, no i klops. Nie jadę. (śmiech) Próbuję utrzymać równowagę. Nidyrydy. Próbuję skręcać. Nie mogę utrzymać równowagi. A przecież, kiedy tak sobie patrzyłem z boku na popisy cyrkowe różnych ochotników wydawało mi się to taaakie proste. I ta prostota w Scrumie, to prawdziwy „minus” tej metody. Bo Scrum jest dziecinnie łatwy, ale jak już zacznie się go wdrażać, to już wcale tak prosto nie jest.
JestemPM.pl: Czy mógłbyś podać jakiś przykład projektu z życia, który był nie do zrealizowania metodyką kaskadową?
MC: Osobiście, nie spotkałem się z takim projektem. Z drugiej strony, każdy projekt można jakoś tam zrealizować. Warto sobie uzmysłowić, że agile, wcale nie powstał w ten sposób, że ktoś tam zamknął się na tydzień w pokoju z kartką papieru i wymyślił jak to wszystko ma działać. Ogromną wartością metod agile jest właśnie to, że powstały one jako pewnego rodzaju kontra – próba zaadresowania tego wszystkiego, co w podejściu kaskadowym po prostu się nie sprawdzało. A co się nie sprawdzało? Brak elastyczności. To, że klient jest tylko na początku i na końcu. To, że ludzie pracują w silosach. To, że nie ma wspólnej odpowiedzialności za produkt. To, że dostarczamy funkcjonalności, który nikt później nie używa. I tak dalej.
Agile został wymyślony przez ludzi, którzy próbowali poradzić sobie z tym wszystkich, co w podejściach kaskadowych utrudniało im życie. I krok po kroku, zastępowali je praktykami, które lepiej się sprawdzały. Eksperymentowali. Uczyli się na błędach. I adaptowali to do nowej sytuacji. Potem opowiadali o tym na konferencjach, dzieli się swoim doświadczeniem na blogach. I tak to się zaczęło. Takie były początki ruchu agile. Potem, oczywiście pojawiły organizacje, które zaczęły to rozwijać, certyfikować… Pojawiła się społeczność. Ale na początku tak nie było.
JestemPM.pl: „Easy to learn, hard to be master”. To bardzo często przewijająca się opinia o tej metodyce, zgodzisz się z nią?
MC: Zacznijmy może od tego, że Scrum nie jest metodyką. Ja wiem, że wiele osób tak właśnie określa Scruma. Ale metodyka, zakłada pewien standard działania, pewien konkretny, z góry założony sposób rozwiązywania problemów. A w Scrumie tak nie jest. Scrum nie jest standardem. Jeżeli weźmiesz pod lupę pracę dwóch zespołów i dasz im jakiś produkt do zrobienia, każdy z nich może użyć zupełnie innego podejścia, żeby go dostarczyć. Mimo, że zrealizuje ten sam cel, który przed nimi postawiłeś.
Scrum jest pewnym modelem działania. Dostarcza zespołom projektowym jedynie pewną strukturę – konkretne praktyki i zasady, które wyznaczają ramy dla ich dalszego działania. To jest trochę tak jak z grą w piłkę nożną. Zasady gry, opracowane przez International Football Association Board (IFAB), są jasno i precyzyjnie określone. Ale jak grać, żeby wygrać? O tym zasady już nie mówią. To już zależy od zespołu. Ze Scrumem jest bardzo podobnie.
I to, można powiedzieć, jest w pewnym sensie odpowiedź na Twoje pytanie. „Easy to learn” – bo zasad można się bardzo szybko nauczyć. To nic trudnego. Ale zarazem „hard to be master”. Bo jak grać, żeby wygrać?
JestemPM.pl: Prowadzenie projektów w metodzie Scrum coraz bardziej zyskuje na popularności. Jak myślisz, czy ten trend będzie kontynuowany czy jest to raczej chwilowa moda?
MC: Chwilowa moda, z pewnością nie. Tak jak mówiłem wcześniej, ruch agile jest jednym z elementów nowego paradygmatu zarządzania, który się rodzi. Ten proces jest bardzo podobny do rozwoju nauki. Tam w zasadzie cały czas mamy do czynienia ze zmianą paradygmatów. Najpierw jest jakiś okres „nauki normalnej”. Naukowcy tłumaczą świat za pomocą określonych teorii, praw i narzędzi, dostępnych w ramach danego paradygmatu. Na przykład paradygmat newtonowski za pomocą metod dynamiki Newtona wyjaśniał ruchy planet, wahadeł, czy zderzeń kul bilardowych.
Ale później przychodzi taki moment, że to nie wystarcza. Pojawiają się pytania, problemy, których tradycyjny paradygmat nie jest już w stanie wyjaśnić. Trzeba poszukać czegoś nowego. Nowych metod, praktyk, narzędzi. Nowych metryk. Tak rodzi się konieczność zmiany paradygmatu. Wielu naukowców przez jakiś czas próbuje się przed tą zmianą wzbraniać. I próbuje, trochę na siłę, tłumaczyć tę nową rzeczywistość – za pomocą narzędzi i metod dostępnych w „starym” paradygmacie. Ale to tłumaczenie jest bardzo miałkie, nie wystarcza.
Tak było na przykład z „Przewrotem Kopernikańskim”. Wcześniej przez lata obowiązywała kosmologia Ptolemeusza, a wraz z pojawieniem się dzieła naszego toruńskiego astronoma „O obrotach sfer niebieskich”, świat już nie był taki sam.
Podobnie jest ze Scrumem. Ogromna popularność metod agile dzisiaj jest pewnym sygnałem, że kończy się stary świat zarządzania i idzie nowy. Część „tradycyjnych” menedżerów może ten świat kontestować, tłumaczyć go po swojemu. Może używać „starych” narzędzi i praktyk do wyjaśniania nowych problemów. Ale z czasem będzie musiała go zaakceptować. Od tej zmiany nie ma odwrotu.
Natomiast, jeśli chodzi o Scruma… Jak długo będzie jeszcze popularny? Kiedyś, podczas jednego ze spotkań z Czytelnikami mojej książki, ktoś z sali zadał mi dokładnie takie samo pytanie. Był nawet bardziej konkretny. (śmiech) Ile lat ten boom na Scruma jeszcze potrwa? Zażartowałem, i powiedziałem, że dziesięć lat. Była to bardzo spontaniczna odpowiedź, ale często sobie o niej myślę, choć tak naprawdę nie wiem, jak długo Scrum będzie jeszcze „na fali”.
Wiem jednak, że idee, pomysły, nowe technologie – mają swój cykl życia. Tak jak ludzie. (śmiech) I wcześniej, czy później rynek się nasyci. Firmy uznają tę metodę jako część nowego paradygmatu. I wtedy pewnie Scrum straci na popularności, bo nie będzie już kolejną nowinką, ale pewnym standardem pracy, którą wszyscy będą stosować. Mam nadzieję, że tego wszyscy doczekamy. (śmiech)
Już dzisiaj można na przykład zaobserwować, że coraz więcej firm, chce iść dalej. Nie wystarcza im wdrożenie Scruma, czy innej metody agile. Chcą budować zwinne organizacje, które będą umiały sobie radzić w dzisiejszych turbulentnych czasach. Scrum jest metodą organizacji pracy nad rozwojem produktu, a nie organizacji. Scrum w ogóle nie wchodzi na ten poziom. I absolutnie nie ma w tym nic złego. Został przecież stworzony po to, żeby rozwijać świetne produkty. Ale Scrum nie działa, jeżeli system operacyjny firmy jest niedopasowany. To jest tak, jakbyśmy chcieli używać aplikacji z Androida na iOS’ie. Nie da się.
Sukces wdrożenie Scruma, zwłaszcza w dużej organizacji, zależy od zmiany systemu operacyjnego firmy. Można to robić na własną rękę, a można skorzystać z „gotowego” rozwiązania – na przykład holokracji. To „gotowe” rozwiązanie należy wziąć w cudzysłów, bo holokracja, zresztą podobnie jak Scrum, wyznacza tylko pewne ramy działania. Nie jest żadnym „gotowcem”, który wystarczy wziąć i wdrożyć w firmie, i będzie działać. Ale, według mnie, na tym polega jej piękno – bo umożliwia ewolucyjne budowanie firmy.
JestemPM.pl: Bardzo dziękujemy za rozmowę.
MC: Dzięki.
Polecamy wszystkim oczywiście bloga Mariusza Chrapko oraz jego podcast Menedżer Plus.
[do_widget id=helion-widget-single-book-2]
Powstaje jednak pytanie, czy aby przypadkiem za analizę i znajomość biznesu nie odpowiada Product Owner? Otóż tak, jednak ta rola nie występuje w DSDM czy AgilePM. Product Owner, to typowa rola w Scrumie, ale nie w produktach konsorcjum DSDM. Najbliższym odpowiednikiem PO jest Business Ambasador. Jest to rola biznesowa, która jest integralną częścią każdego zespołu. Każdy zespół posiada dokładnie jednego Ambasadora. Jednak Business Ambassador pracuje na poziomie pojedynczego zespołu, natomiast Analityk biznesowy wspiera kilka zespołów, dbając o synchronizację oraz komunikację wymagań. Analityk na poziomie organizacji i jego zadaniem jest zrozumienie szerszego kontekstu projektu, m.in. ograniczeń biznesowych, prawnych, technicznych, itp.
Poprzedni
