Czy każdy Project Manager nadaje się do Agile?

Prosta odpowiedź brzmi “nie”. Po czym poznać czy dany Project Manager dobrze rokuje do Agile? Po tym na którą stronę Agile Manifesto przeważa. Jeśli pojawia się grymas twarzy, to szkoda czasu. Jeśli pojawiają się od razu komentarze kategoryczne “Ja się z tym nie zgadzam”, “Ludzie sami nie potrafią się organizować”. Próba wpasowania osoby z takimi poglądami w krajobraz zwinnej organizacji będzie mocno frustrujące. Typowe zachowania jakie obserwowałem w mojej praktyce to tunelowanie informacji, przekazywanie opinii zamiast faktów i blokowanie decyzji. Postawa “wszystko muszę wiedzieć” i “to nie było ustalone na komitecie” to klasyk w takich sytuacjach. Zacznie się również udowadnianie, że Scrum nie zadziała i konflikt ze Scrum Masterami. Konflikty szybko mogą eskalować na poziom krucjaty. Skuteczne sparaliżowanie transformacji Agile może być widziane jako jedyny sposób na zapewnienie bezpiecznej posady. Z punktu widzenia coachingu każdego można zmienić i każdy ma wszystkie niezbędne zasoby. Pytanie ile czasu to zajmie i czy organizacja chce w to inwestować czas kilku ludzi. Scrum Master będzie się użerał, Agile Coach będzie tłumaczył i eskalował do managera PMa. Może pojawi się life coach. Czy warto?

Dlaczego kierownicy projektów tak się zachowują? Przyczyn jest kilka. Przede wszystkim tak zostali wyedukowani i tego się od nich oczekiwało w organizacji. Obecna kultura organizacji i środowisko wspierają i nagradzają takie zachowanie. System premiowy może również wspierać niepożądane zachowania. Bo niby jak PM ma odpuścić, jeśli jego premia zależy od dowiezienia projektu? Jak ma przestać się wtrącać w każdy aspekt, jeżeli szefowie wymagają szczegółowych raportów i zadają te same pytania?

Jeśli przy rozmowach o Agile pojawia się uśmiech i komentarze w rodzaju “Zawsze tak chcieliśmy”, “Wcześniej też tak pracowaliśmy”, “Na reszcie coś prostego”, mamy płomyk nadziei. Tutaj udaje się wspólnie wypracować pierwsze kroki transformacji, zręby nowego sposobu podchodzenia dla projektów, a nawet od razu podział na produkty. Doświadczeni Project Managera może być pomocne w wypracowywaniu nowych procesów i KPI. Wiedza z zakresu zarządzania projektami może być bardzo przydatna w tłumaczeniu Agile interesariuszom i zarządowi.

Cypher: You know, I know this steak doesn’t exist. I know that when I put it in my mouth, the Matrix is telling my brain that it is juicy and delicious. After nine years, you know what I realize?

[Takes a bite of steak]

Cypher: Ignorance is bliss.

Project Manager zostaje w organizacji i robi to co do tej pory

Jakie są argumenty za tym, żeby Project Manager nadal był w organizacji? Pierwszy argument jaki zwykle się pojawia w rozmowach o Project Managerach w ramach transformacji Agile to przyzwyczajenie. Można usłyszeć “Bo PM zawsze tutaj był” albo “Mamy takich ludzi w organizacji, więc musimy znaleźć dla nich miejsce”. Gdzie tu wartość? Niektórzy wzruszą się troską o pracowników i docenią empatię. Jednak firma to biznes, który ma zarabiać pieniądze. Osoby, które są chętne utrzymywać stanowiska za pieniądze korporacyjne, byłyby mnie skłonne do empatii, gdyby chodziło o pieniądze z ich własnej kieszeni. Ale w sumie od czego mamy korporacje. Jak miałaby wyglądać praca takiego kierownika projektu od startu zmiany? Co tak naprawdę zmienimy poprzez zatrzymanie Project Managerów w dotychczasowej roli i w dotychczasowym procesie.

Równie popularnym argumentem padającym ze strony przeciwników zmian będzie proces. Czyli nie możemy zrezygnować z PMów, bo taki mamy proces. Zgodnie z Agile Manifesto powinniśmy stawiać Ludzi i ich interakcje ponad procedury i narzędzia. Zatem trzeba zadać sobie pytanie Czy proces daje oczekiwane rezultaty i pasuje do nowej rzeczywistości? Jeśli okaże się, że nie, a tak powinno być w większości przypadków, to proces można, a nawet należy zmienić. Zmiany procedur i procesów sa częścią transformacji.

W rozmowach pojawia się także argument chaosu czasem poparty złym doświadczeniem. Jeśli nie będziemy mieli Project Managerów, to przecież będzie organizacyjny chaos. Kto będzie przydzielał zadania? Kto będzie tworzył raporty? Oczywiście, zdarzają się organizacje, które używają słowa Agile jako synonimu na chaos. Zdarzają się osoby, których jedyną odpowiedzią na trudne pytanie jest “Bo mamy Agile” albo “W Scrum tego nie ma”. Ale nie zmienia to faktu, że jest to złe podejście. Agile i Scrum zapewniają nawet dokładniejsze informacje na temat postępów i lepszą optymalizację pracy.

Przecież musimy mieć jasne procedury, porządek, ład projektowy, żeby dowozić projekty na czas i w budżecie. Ktoś musi być za to odpowiedzialny. A przecież Scrum miał być narzędziem do tworzenia wartościowych produktów, a nie zgodnych z początkowymi założeniami projektów na czas. Poza tym jeśli nie zmienimy tego podejścia w organizacji, to de facto nic się nie zmieni oprócz naklejek na dotychczasowych praktykach i rolach. Scrum Master to nie jest mini-PM albo jak niektórzy twierdzą Agile PM. Trudno jest opuścić strefę komfortu związaną z poczuciem porządku, poukładania i jasnych informacji. Nawet jeśli to było złudne i każdy o tym wiedział.

Czy można się spodziewać, że po przejściu na Scrum sytuacja będzie stabilna? Oczywiście, że nie. Przecież po to przechodzimy transformacje do Agile, żeby mieć możliwość eksperymentowania i częstych zmian. Inny sposób pracy na początku będzie powodował chaos. Trzeba dopuścić naturalną dozę bezwładności. Zarówno organizacja jak i zespoły potrzebują mieć chwilę na odnalezienie się w nowym paradygmacie pracy. Transformacja Agile to także zmiana kulturowa. Odnieśmy się do promowanej przez Jacka Santorskiego metafory kultury folwarcznej. Chcemy zmienić tą kulturę na Agile, który jest podejściem mocno partycypacyjnym jeśli chodzi o zarządzanie. Można powiedzieć, że znika ekonom z kijem. Chłop może się wyprostować, ale teraz będzie niepewny i chwilę potrwa odnalezienie się w nowej rzeczywistości.

Często pojawia się tutaj dysfunkcja polegająca na przerzuceniu obowiązków zarządczych i raportowych na Scrum Masterów, albo specjalnie w tym celu powołanych liderów zespołów. W ten sposób zabijamy samo-organizację zanim ma szansę zaistnieć w Zespole Developerskim. Rozwiązaniem nie będzie także próba wymyślenia nowych procesów na papierze i skodyfikowanie “Agile u nas w firmie”, albo “Agile po naszemu”. Papier zniesie wszystko, ale praktyka szybko weryfikuje takie pomysły. Tego typu domowe metodyki prowadzą na drogę bez odwrotu. Jeśli metodyka nie działa, to nie możemy się zwrócić ani do Scrum Guide ani do metod zarządzania projektami.

Trzeba sobie zadać pytanie “A jaką wartość zyskamy utrzymując stanowisko PM?”. To jest bardziej pytanie “po co?”, a nie “dlaczego?”.

Project Manager przyjmuje rolę w Zespole Scrum

Jeśli nie znajdujemy zastosowania dla roli Project Managera w nowej, zwinnej organizacji, nie musi to od razu oznaczać zwolnień, czy też jak się mówi w korporacji uwalniania etatów. Można się zastanowić co z tymi osobami zrobić w nowej rzeczywistości. Podobno według badań przy każdej zmianie organizacyjnej może odejść nawet 30% pracowników. Niektórzy kierownicy mogą stwierdzić, że Agile i Scrum to nie dla nich. Za mało się dzieje, za mało walki, polityki. Niektórzy po prostu sami odejdą.
W Scrum mamy trzy role, więc może po prostu można przeszkolić i przekwalifikować PMa. Ale na jaką rolę?

Większość Project Managerów postrzega rolę Scrum Mastera jako naturalny kierunek zmiany. Dlaczego akurat Scrum Master? Ponieważ patrząc przez pryzmat dotychczasowego stanowiska, Kierownicy Projektów widzą w Scrum Masterze kogoś, kto zarządza zespołem. Niestety taki sposób myślenia i stare nawyki dyskwalifikują PMów z roli Scrum Mastera. Scrum w takiej konfiguracji będzie co najwyżej udawany. Możemy przy okazji spodziewać się kampanii propagandowej zachęcającej organizację do przejścia na metody sankcjonujące rolę project manager. Mam tutaj na myśli pomysły w stylu Prince2 Agile czy DSDM, gdzie jest rola AgilePM. Co ciekawe reszta aspektów tych metod nie jest już tak chętnie promowana, a pózniej przestrzegana.

Czasami (niestety rzadko) spotykam PMów, którzy bardzo dobrze współpracują z zespołami i skupiają się na zapewnieniu im wszystkiego czego do pracy potrzebują. Taki typ Project Managera umożliwia, żeby rzeczy się działy (facylituje), dba o innych, dyskutuje i stara się zrozumieć. Taki kierownik dba także o relację z biznesem i biznes lubi z nim współpracować. Gdyby nie był PMem, to pewnie prowadziłby cześć biznesu firmy lub nawet własną firmę. I taki profil jak najbardziej nadaje się na Scrum Mastera. Ważne jest, żeby sprawdzać opinię innych osób a nie mniemanie o sobie danego PMa. Większość kierowników projektów będzie przekonywało, że nikogo nie gonią i doskonale rozumieją Scrum. Warto spytać zespół, co sądzi o tym, żeby dany Project Manager został ich Scrum Masterem.

Scrum Master musi doskonale znać Scrum i najlepiej posiadać doświadczenie ze Scrumem związane. Jak inaczej wprowadzi Scrum do firmy i upewni się, że jest wprowadzony w życie? Skąd PM będzie się znał tak dobrze na Scrum? Zazwyczaj osoby w tej roli do tej pory traktowały Scrum jako ciekawostkę i zabawkę dla zespołu.

Jeśli nie Scrum Master, to może Project Manager może się przekwalifikować na Product Ownera? Taki manewr może się udać, jeżeli Kierownik Projektu posiada wiedzę na temat biznesu, użytkowników i potrzeb interesariuszy. Oczywiście lepiej gdyby Product Owner został wyłoniony bezpośrednio z biznesu organizacji albo był klientem z krwi i kości. Ale z tym na początku transformacji jest trudno. Z dwojga złego lepsze takie rozwiązanie.

Nie można też odmówić PMowi przekwalifikowania się na Developera. Przecież może być tak, że ten człowiek wcześniej zajmował sie programowaniem i jest to coś, co nadal lubi robić. Nie każdy zostaje Project Managerem z powołania. Zdarzają się w przyrodzie takie przypadki. Developerów nigdy nie jest za dużo.

Dziękuję Kubie Szczepanikowi za przejrzenie pierwszej wersji artykułu!

Poprzednie części artykułu:

Project Manager w Scrum #1 — czy Scrum to metoda zarządzania projektami?
Project Manager w Scrum #2 — czy potrzebna jest kolejna rola?