Z tego podcastu dowiesz się:

• Kto najcześciej wdraża scruma…
• … i dlaczego nie zawsze jest to scrum master
• Dlaczego scrum master bywa rolą, a nie stanowiskiem w firmie
• Jak ma się scrum do project managera
• Czy ten proces można wdrożyć częściowo
• Co powoduje, że zamiast scruma często jest kanban
• Jakich błędów należy unikać, gdy wdrażamy scruma
• Czym skutkuje brak procesu w developmencie
• Kiedy najwcześniej warto wdrożyć proces

I bonus:

• Ciekawostka na koniec, czyli jak się ze mną spotkać i zasięgnąć porady 🙂

Podcastu wysłuchasz także na:

Materiały dodatkowe

Poniżej linkuje dla Ciebie video, o którym wspominam w podcaście. Zachęcam do obejrzenia tego nagrania, ponieważ jego autor w bardzo zwinny sposób wyjaśnił jak sprytnie można skalować proces, gdy nasza organizacja się rozrasta.

Transkrypcja

Dobra, jedziemy z tym. „Być Jak Manager”. Podcast, epizod 11. 

Dzień dobry. Jak samopoczucie? Chciałbyś powiedzieć, u mnie dobrze. Dziękuję, że pytasz drogi słuchaczu. Dziś porozmawiamy sobie o Scrumie. Temat dla mnie bardzo przyjemny. Czy to temat lekki? Nie wiem. Scrum, o ile dobrze kojarzę, jest niezwykle lekki w teorii, ale niezwykle trudny w praktyce. 

Ja przez pewien czas w mojej karierze byłem także scrum masterem i rozwinę się dzisiaj troszkę w tym  temacie. To nie jest tak, że skupiam się teraz na Scrumie i wielbię ten Scrum, jako jedyną najważniejszą  najwłaściwszą metodologię, czy tam metodykę pracy nad oprogramowaniem. Natomiast jest wciąż pewien ogromny potencjał tej metodologii i wydaje mi się, że na takim podcaście i w takiej przestrzeni, którą ja tutaj tworzę tym podcastem warto, żeby od czasu do czasu takie tematy metodyczne, czy tam metodologiczne się pojawiły. 

Zanim zaczniemy serdecznie dziękuję, że tutaj jesteś. Jeżeli nie jest to pierwszy podcast, którego słuchasz. To również serdeczne dzięki za każdy komentarz, każdą opinię, którą zostawisz pod tym podcastem na moim blogu bycjakmanager.pl. Ja cię także zachęcam, jeżeli jeszcze tego nie zrobiłeś do subskrybowania mojego newslettera i zawsze to podkreślam, że każdy, kto zostawi swoje imię i adres mailowy na stronie bycjakmanager.pl tam, gdzie zbieram zapisy do newslettera może być pewien, że ja nie handluję danymi moich słuchaczy. Twój mail nie zostanie absolutnie udostępniony żadnej firmie trzeciej. I druga sprawa, którą ja zawsze podkreślam to to, że ja nigdy nie spamuję. Nie wysyłam żadnych reklam o środkach do konserwacji toalet, to są newslettery pisane przeze mnie osobiście, bardzo często osobiste, takie dość prywatne, gdzie odkrywam się wręcz przed moimi słuchaczami, których informuję o nadchodzących lub tych, które dopiero opublikowałem podcastach.

Ja dzisiejszy podcast podzieliłem na takie dwa akty. W akcie pierwszym porozmawiamy o tym, kto tak naprawdę wdraża Scruma. Odpowiedź wydawałaby się oczywista, ale w wielu przypadkach oczywista nie jest. Natomiast w 2 akcie, punkt po punkcie opowiem tobie o tym jakie błędy bardzo często popełniają, czy to konkretne jednostki czy organizacje, gdy próbują wdrażać Scruma lub usprawniać Scruma, który już teoretycznie w tej organizacji się znajduje. Chcę też podkreślić, że, co też powtarzam przy innych podcastach, ja nie jestem alfą i omegą. Po pierwsze mogę się mylić. Po drugie mój podcast i przestrzeń, w której ja się realizuję jako broadcaster, służy mi do tego, żeby dzielić się z tobą bardzo często subiektywną opinią. Jeżeli nie zgadzasz się z czymkolwiek, co zostanie tu powiedziane, nie krępuj się powiedzieć mi o tym wprost, czy to w komentarzu pod wpisem na moim blogu i tym podcastem na stronie bycjakmenedzer.pl, czy na moich mediach społecznościowych, ponieważ uważam, że komunikowanie się na poziomie ekspert i audiencja to nie powinna być komunikacja jednostronna ode mnie w twoim kierunku. Natomiast ja chcę zbudować przestrzeń do dyskusji, dlatego jestem cholernie ciekaw zawsze opinii każdej osoby, która słucha mojego podcastu. Dużo gadam, a jeszcze nie w temacie. 

Akt 1 dzisiejszego podcastu. Kto tak naprawdę wdraża Scruma?

Najczęściej będzie to, a przynajmniej powinien to być, scrum master i to się mówi samo przez się. I jeżeli jest taki specjalista w zespole, no to jesteśmy w domu. Tutaj mamy scrum mastera. Proszę bardzo, ten człowiek nam wdroży Scrama, powie nam później, jak mamy się z tym Scrumem obchodzić. Ale co też warto podkreślać to to, że scrum master na co dzień challenguje i sam zespół deweloperski, ale także zarządy, wyższy management, aby krok po kroku wdrażać wszystkie artefakty scrumowe, aby następnie je dobrze utrzymywać i także rozwijać, ale scrum master nie zawsze jest pełnoetatowym stanowiskiem w firmie. Czasem rolę scrum mastera może przyjąć jeden z członków zespołu projektowego lub deweloperskiego. Ja osobiście odradzam to podejście. Chyba, że sam zespół jest z tym okej. Uważam, że na tym polega specjalizacja, żeby móc się skupić na pewnym zestawie kompetencji i dowodzić wartość w tym, czym jesteśmy naprawdę najlepsi. Rozdzielanie kompetencji na różne sektory. Ja nie do końca jestem fanem takiego podejścia. Natomiast często, jeśli rolę w zespole są łączone, no to może wynikać najczęściej z 2 przyczyn. Albo jest brak budżetu na pełen etat scrumowy. Organizacja jest jeszcze na nie tak rozwiniętym poziomie albo nie tak rozwiniętym levelu biznesu, żeby otworzyć takie stanowisko scrumowy. Albo zwyczajnie zespół nie widzi zapotrzebowania na taki etat, bo być może zespół deweloperski jest tak doświadczony z poprzednich projektów w pracy w Scrumie, że nie potrzebują scrum mastera, który im w tym będzie pomagał. Ja, kiedy to nagrywam, to wydaje mi się, że scrum master jest obecnie jedną z najpopularniejszych ról w świecie, to zaraz po programiście, testerze czy designerze. Kolejną osobą, tutaj chyba nie zdziwi się część osób, które to usłyszy, która wdraża Scruma w organizacji jest o dziwo product owner. No i tak, to jest w sumie właściwa osoba na właściwym miejscu, żeby wspierać podejście zwinne w zarządzaniu. I czy to jest Scrum, czy to jest Kanban, czy scrumban, to właśnie produkt owner nierzadko ma na swojej liście zadań opiekę nad właściwym procesem dewelopmentu. Ja, tak jak wspominam o różnych metodach zarządzania, to też odsyłam do jednego z moich pierwszych podcastów, gdzie opowiadałem o tym, jak dobierać odpowiednią metodykę do projektu, którym będziemy zarządzać. Inną osobą, i to też ja sam będąc kiedyś uwaga project managerem wdrażałem Scruma. No, bo załóżmy sobie taką sytuację, a takich przykładów znajdziemy dość sporo na rynku firm technologicznych, że w zespole nie ma ani scrum mastera, ani product ownera, jest za to project manager. Project manager w ogóle nie jest drogą scrumową, jakby nie występuje w Scrumie, ale to już jakby odkładam to na bok. Ja nie chcę dziś analizować lub diagnozować żadnych mniejszych lub większych patologii. Jest faktem to, że project managerowie albo od project managerów wymaga się często znajomości Scruma i wdrażania go w organizacjach. Oczywiście, gdy w takiej konfiguracji organizacja chce być pro scrumowy i rozwijać dalej zarządzanie zwinne, to to pachnie rzeczywiście już na wejściu pewną patologią. No, bo jak tu wdrożyć Scruma skoro nie chcesz zatrudniać speca w tej dziedzinie, na full time. Dwa, zespołem projektowym kieruje PM, którego rola, czyli rola PM ma się do scrum managera tak, jak gra w kręgle pod wodą. Na upartego można to zrobić, ale w sumie po co. Mimo wszystko, takie sytuacje się zdarzają. Im organizacja jest mniej dojrzała, pod kątem metod zwinnych, tym bardziej egzotyczne figury zarządzania są emplementowane do pracy codziennej. Ja wiem, że już trochę pejoratywnie się wypowiadam, że project managerowie wdrażają Scruma. Natomiast znam przykłady firm i małych organizacji, gdzie łebscy PM-owie bardzo fajnie tego Scruma wdrożyli i on działa do dziś. Więc nie banuję, nie neguję. Natomiast podchodzę z dużą rezerwą do takiego podejścia. Tyle w akcie 1. Kto może, a kto powinien tego Scruma wdrażać. 

A teraz wchodzimy do 2 części. Drogi słuchaczu, zapamiętaj proszę, że w poprawnie występującym przyroście personalnym w firmie IT, Scrum w organizacji powinien wdrażać scrum master. Koniec kropka. Do tego została stworzona ta szlachetna rola. Aczkolwiek, to druga rzecz, którą fajnie by było, jakbyś pamiętał. Jeśli z pewnych przyczyn, a firma nie może pozwolić sobie na scrum mastera, to doświadczony product owner także może pomóc utrzymać taki zwinny proces. A teraz bum, bum, bum. 

Akt 2 podcastu 11. Jakie błędy popełniają organizacje, gdy wdrażają Scruma? I od razu pewien taki disclaimer, bo ja używam słowa organizacja, ale najczęściej mam tutaj na myśli ludzi powołanych do tego, żeby kierować zespołem. Przyjmijmy umownie, że nieco oberwie się teraz managerom średniego i wyższego szczebla, no bo oni są najczęściej tymi driverami tego, dlaczego, po co i w jaki sposób tego Scruma chcemy wdrażać. 

Błąd 1. Organizacja wdraża Scruma na siłę, chociaż go nie potrzebuje. Ja w 4 epizodzie mojego podcastu opowiadałem o tym właśnie, jak dobierać metodykę zarządzania do projektu i dwie rzeczy, wspominam o tym, ponieważ, jeżeli kojarzysz tamten odcinek, to wiesz, że świat zarządzania IT nie kończy się na Scrumie. I to nie zawsze musi być najlepsza metodyka spośród innych, jaką wybieramy do projektu. Dwa, jako że tych metodyk jest dużo więcej niż jedna, to tą, którą wybierzemy powinno zależeć od specyfiki tego projektu. Często jest tak, że organizacja wdraża Scruma na siłę, chociaż on jest nie do końca idealnym odzwierciedleniem, jak wygląda development albo, jak powinien wyglądać development tego, czy innego produktu. 

Błąd 2, który sobie wynotowałem, to to, że organizacja wdraża Scruma częściowo, a nie w całości. To jest najczęstszy błąd, z jakim spotkałem się dotychczas w mojej karierze. Często jest tak, że firma chce pracować scrumowo, ale do procesu developmentu wdraża tylko wybrane artefakty scrumowy. Najczęściej te, które pasują managerom, bo na inne nie ma, rzekomo, czasu albo nie są już tak bardzo potrzebne. I niektórym nawet wydaje się, że wdrożenie samych daily, codziennych calli z zespołem już świadczy o tym, że ten Scrum jest, ale okazuje się, że on jest po prostu niekompletny [śmiech]. Ja sięgnę po taką, przepraszam, fekalną metaforę, takiego podejścia, żeby łatwiej to było zapamiętać. Z posiadaniem Scruma jest trochę, jak z biegunką. Nie można go mieć i nie mieć jednocześnie. Albo mieć tylko w połowie. Albo ten Scrum jest albo go nie ma. Biegunkę można mieć tylko w połowie? No nie. Ja wspominam o tym na blogu z kwietnia 2021 roku, gdzie pisałem o tym, że Scrum jest trochę, jak potwór z Loch Ness. Wszyscy o nim mówią, ale nikt nie widział. Ja zachęcam do odgrzewania tego tekstu z mojego bloga ze strony bycjakmenadzer.pl i zgłębić temat poza dzisiejszym podcastem. 

Błąd numer 3, który umieściłem na dzisiejszej liście to organizacja wdraża inną metodykę niż Scrum, ale nazywa to Scrumem [śmiech]. No i słuchaj. Często ambicje posiadania Scruma kończą się posiadaniem Kanbana. Dlaczego? Dzieje się tak dlatego, że Kanban zwalnia nas z obowiązku prac w iteracjach, a iterowanie, to jest tak naprawdę podstawa pracy w Scrumie i pilnowanie tego, żebyśmy donosili użytkownikom pewną wartość, czyli tak zwany increment w stałych odstępach czasu, w praktyce może się okazać bardzo kłopotliwe i nierzadko w tym miejscu część organizacji rozkłada ręce. Ja raz trafiłem do korporacji, gdzie teoretycznie pracowano w Scrumie, a praktycznie to był miks Scrumbana z Waterfallem. Z moich kilkuletnich obserwacji mogę wywnioskować, że im większa firma, im większa liczba zespołów, tym trudniej jest wdrożyć ich w nowy, świeży albo naprawić już istniejący proces. A skoro już o tym mówimy, to na moim bloku bycjakmenadzer.pl we wpisie z dzisiejszym podcastem, na pewno łatwo go odnajdziesz, zamieszczam dla ciebie link na Youtube, w którym w ciekawy sposób pokazano, jak procesem developmentu zarządza ekipa z aplikacji Spotify. Ja jako miłośnik aplikacji Spotify zachęcam, abyś rzucił okiem na ten film i zobaczył, jak to robią zawodowcy. Ten film ma kilka lat, nie wiem, jak bardzo się zmieniły te procesy od tamtej pory. To, co zostało udokumentowane w formie takiego krótkiego wideo, no może być naprawdę inspirujące. Jako, że Spotify jest dużą korporacją, to tym bardziej powinna stanowić za wzór dla innych, nawet przy tak dużej, skomplikowanej organizacji można pracować zwinnie oraz metodycznie, co się rzadko zdarza. Zwłaszcza w przypadku takich gigantów. 

Błąd numer 4 z listy Najwera o błędach w czasie wdrażania Scruma, to organizacje próbują wdrażać Scruma za późno. Ja wiem, co powiesz, że lepiej późno niż wcale. Natomiast brak odpowiedniego procesu zawsze przełoży się na to, co wyląduje w kodzie. Tutaj ciężko to podważyć. W skrócie to, jak prowadzimy projekt zawsze ma bezpośrednie przełożenie na jakość tworzonych rozwiązań przez zespół deweloperski, a też przez testerów i przez wszystkich, którzy są zaangażowani w pracę nad projektem. Owszem, bez procesu też można funkcjonować, ale jednak życie uczy, że bałagan organizacyjno-komunikacyjny rzutuje zawsze na bałagan powstały w czasie implementacji. Po to powstały procesy, żeby taki potencjalny bałagan okiełznać. A im wcześniej zabierzemy się za wprowadzenie pewnych standardów, tym mniejszy dług sobie narobimy. Co mam na myśli mówiąc, że proces jest wdrożony za późno. Za późno oznacza, że już mamy ogromny dług techniczny w kodzie, z którego będzie się ciężko wygrzebać. Zespół jest sfrustrowany, jak sprzedawca parasolek w słoneczny dzień. Nadszarpnięta została motywacja zespołu, a dług techniczny przekłada się na niskie opinie użytkowników o naszej aplikacji, gdzieś w sklepie na storach i tak dalej, i tak dalej. Frustracja wśród osób z teamu, która powoduje też dużą rotację. Ludzie się wkurzają, rzucają tę robotę, programiści odchodzą i idą do innych firm. Kolejnym punktem jest też to, że do tak zaniedbanego środowiska deweloperskiego trudno będzie ściągnąć doświadczonych seniorów i przez to wpadamy w błędne koło. Nie mając doświadczonych ludzi ten dług się powiększa, nie będziemy się wygrzebywać z tego. Redaktor nie będzie szedł tak, jak powinien bez poprawnego procesu. Spirala innych błędów spowodowanych tym, że nie wprowadziliśmy fajnego prezesa developmentu będzie się powiększać i będzie nas dusić wręcz. Zawiąże się nam spirala tego całego szamba wokół tego shein [śmiech]. Dobra, nie chcę takich tutaj katastroficznych wizji uskuteczniać. Natomiast domyślam się, że wiesz o co chodzi. I żeby nie obudzić się z ręką w nocniku, polecałbym wdrażać odpowiedni proces dużo, dużo wcześniej. Pytanie, kiedy dokładnie? No dla mnie to pytanie ma oczywistą i jedyną odpowiedź. Na samym początku prac deweloperskich, chyba że zespół i ty, to jesteś ty i twój kolega z liceum. No to wtedy nie bardzo jest dla kogo takiej pracy wdrażać. Aczkolwiek taki mały Scrum już by, wydaje mi się znalazł tutaj swoje uzasadnienie, ale jeśli na pokładzie masz już zbiór potrzebnych kompetencji, kilku programistów, testerów no to nic nie stoi na przeszkodzie, żeby Scruma albo inną metodykę wdrożyć. Jest to wręcz dla mnie obowiązek. 

Błąd numer 5. Scrum wdrażany jest bez odpowiednich kompetencji w zespole. Nawiązuję trochę do aktu 1 dzisiejszego podcastu, w którym mówiliśmy o tym, kto wdraża Scruma. Brak scrum mastera, gdy wdrażamy sprawa może być problemem. Zwłaszcza, że dla innej osoby, takiej jak product owner lub project manager wdrożenie takiego procesu może nie być tak wysoko na liście priorytetów, jak dla scrumowca. Dla project managera scrum też może być gdzieś dopiero na drugim, trzecim, czy tam piątym miejscu. Więc wdrażając takiego scruma od podstaw warto mieć takiego scrumowca. Chociaż na pewien czas, na full time niech zrobi to raz, a dobrze. Nie wystarczy powiedzieć zespołowi, jak chcecie mieć Scruma, to wprowadźcie go, kiedy chcecie. No, bo to jest taki bullshit trochę, za którym chowają się, na przykład właściciele małych firm, jak chcecie Scruma, to sobie go wprowadźcie. To rolą managementu, niższego, średniego, wyższego jest, żeby wspierać zespół we wdrożeniu procesu na poziomie kompetencyjnym, na przykład zatrudniając w organizacji scrum mastera oraz na poziomie operacyjnym, na przykład dostosować się, jako management do rozwiązań w firmie, których wymaga wdrożenie tego procesu. Jakby kończąc ten wątek. Brak kompetencji oznacza brak procesu lub wdrożenie procesu błędnie. 

Błąd numer 6 i będzie to ostatni błąd, o którym sobie dziś opowiemy. Mianowicie wybrana metodyka zwinna jest źle skalowana. Kiedy zespół się powiększa, to też jest challengujące i to też nie jest łatwe, żeby wyskalować proces. Jednym wyzwaniem jest wdrożyć Scruma w organizacji, a zupełnie innym wyzwaniem będzie wyskalowanie tego procesu, gdy firma urośnie nam z kilku procesów scrumowych do kilkunastu albo kilkudziesięciu. Ja byłem świadkiem tego, jak szybko potrafi się wyskalować firma. W momencie pojawiają się ogromne pieniądze, jakiś produkt zassał na rynku albo pojawili się inwestorzy i nagle zaczynasz rok jednym, dwoma zespołami deweloperskimi, a kończysz rok, gdy masz tych zespołów 12 albo 13. Nie będę jeszcze się rozwijał wątku skalowalności procesu, bo to większy temat, któremu warto poświęcić cały osobny podcast. Natomiast dzisiaj chcę jedynie zaznaczyć, że rzecz, wydawałoby się subpozytywna to znaczy, gdy firma pnie się w górę, rozrasta się wśród kolejnych sukcesów, zrywa słodziutkie owoce ciężkiej pracy deweloperów, może okazać się przekleństwem dla Scruma, jeśli nie dostosujemy naszego procesu do tych specyficznych warunków szybkiego wzrostu, ale w tym momencie muszę powiedzieć, ciąg dalszy nastąpi [śmiech]. 

A teraz nieformalny akt 3. Pożegnanie.

Dziękuję za wysłuchanie. W sumie to nie żegnam się, tylko mówię do widzenia. Dziękuję tobie za każdą opinię i komentarz, które zostawisz albo na moich mediach społecznościowych albo na stronie bycjakmenadzer.pl. Ja wiem, że publikuję nieregularnie, z uwagi na sporo ciekawych rzeczy, jakie się dzieją u mnie po stronie produktowej ostatnio. Natomiast nie chcę być jedynie teoretykiem i od lat pomagam firmom realnie tworzyć i budować produkty technologiczne. Tym bardziej zachęcam cię do wpisania na mój newsletter na moim blogu i taka ciekawostka na koniec. Jako, że często dostaję pytania na skrzynkę, czy prowadzę konsultacje jeden na jeden, bo na przykład ktoś chciałby wejść do branży IT, ale nie do końca wie, jak to zrobić. Odpowiadam tak, prowadzę takie konsultacje. W zeszłym miesiącu zdzwaniałem się z kilkoma słuchaczami, dość regularnie, żeby pomóc ukierunkować ich karierę bardziej w stronę IT. W związku z taką jakby coraz większą potrzebą na takie konsultacje, na swoim blogu w zakładce konsultacje umieściłem proste narzędzie, taki kalendarz, gdzie właśnie wspomniane konsultacje ze mną możesz sobie zabukować. Zachęcam. Zapraszam. Raz jeszcze dziękuję za wysłuchanie podcastu. Dużo zdrowia, dużo radości, dbaj o siebie i innych. Cześć.