Dlaczego nie ma Project Managera w Scrum?

“Projekt w Scrum trwa tylko jeden Sprint. Wydanie oprogramowania może być sumą wielu przyrostów (i wcześniej zbudowanego oprogramowania, jeśli takie było), albo może być wiele wydań oprogramowania w ramach Sprintu. Projekt w Scrum nie może się nie udać, najwyżej dostarczy nieakceptowalnego zwrotu z inwestycji” - Ken Schwaber

Jak dorosnę, zostanę PMem!

Kilka lat temu prowadziłem serię szkoleń dla softwarehouse na Śląsku. Szkolenie Scrum i nie tylko było skierowane do młodych ludzi, którzy zaczęli budować trzon firmy. Dzisiaj opowiadają o zarządzaniu softwarehouse, o byciu liderem, o Agile, a wtedy byli jeszcze studentami albo pisali magisterkę. Klient zażyczył sobie, żeby przed szkoleniami przeprowadzić ankietę zbierającą potrzeby szkoleniowe. Oprócz nudnych, standardowych pytań potrzebnych HR do statystyk, wplotłem otwarte pytanie "Gdyby wszystko było możliwe, to kim byś był?". Byłem w ciężkim szoku, kiedy w wynikach okazało się, że przytłaczająca większość napisała Project Managerem albo Kierownikiem Projektów. Jedna osoba napisała, że chciała by odwiedzić wszystkie kraje świata i pisać o tym na blogu. Na szkoleniu zapytałem, dlaczego akurat PM? Bo ma władzę, bo inni go słuchają – usłyszałem w odpowiedzi. Jeśli z tych pobudek ludzie wybierają taką, a nie inną karierę, to nie może to się kończyć dobrze. Swoją drogą ciekawe jest, że ankietowani nie widzieli negatywnych stron pracy PMa. Prawdopodobnie dlatego, że tak na prawdę nie uczestniczyli w żadnych spotkaniach i nie widzieli tej osoby na co dzień. Zrobiło się trochę dziwnie kiedy dowiedzieli się, że Scrum to nie jest ten sposób pracy, w którym jest PM, który wszystkim rządzi. Kiedy zrozumieli, że jako Zespół Developerski mają duży wpływ, cały pomysł zaczął im się podobać. Na szczęście dzisiaj te osoby myślą zupełnie inaczej i doskonale odnajdują się w Scrum.

Product Development to nie Project Management

W metodach promujących rolę PMa w Agile, tak jak chociażby Agile PM wywodzący się z DSDM Atern można znaleźć materiały, w których Scrum został pokazany jako jedynie metoda wytwórcza, na poziomie delivery. A jak wiadomo w podejściu project management, nad delivery musi górować poważna metodyka zarządcza. Scrum w tym tłumaczeniu rysuje się jako pewien sposób organizacji pracy developerów, którym PM musi i tak zarządzić. Czy naprawdę sam biznes i developerzy nie daliby sobie rady? Jest ktoś kto mówi co potrzebuje i ktoś wykonuje pracę i dostarcza produkt.

Czym jest Scrum według twórców Scrum i Scrum Guide?

"Scrum to ramy procesu, które są wykorzystywane w zarządzaniu wytwarzaniem złożonych produktów od początku lat dziewięćdziesiątych. Sam w sobie Scrum nie jest procesem czy techniką wytwórczą; opisuje jedynie ogólne sposoby postępowania, w obrębie których możliwe jest stosowanie różnego rodzaju procesów i technik. Scrum pomaga odkrywać nieefektywności praktyk zarządczych i technik inżynierskich, by można było je doskonalić."

Scrum został zbudowany z myślą o budowaniu złożonych produktów. Jeśli byśmy chcieli sprowadzić esencję Scrum do jednego zdania, byłoby to, budowanie wartościowych produktów w krótkich iteracjach. W Scrum cały czas budujemy produkt dokładając do niego kolejne przyrosty i wydajemy go na produkcję wtedy, kiedy biznes stwierdzi, że ma to sens biznesowy. Produkt rozwijamy tak długo, jak długo jego właściciel, Product Owner, uważa, że opłaca się to z punktu widzenia biznesu. Product Owner będzie również zajmował się produktem już po wdrożeniu, więc musi brać pod uwagę Całkowity Koszt Posiadania (ang. Total Cost of Ownership). W tym podejściu realizujemy zawsze to co najbardziej wartościowe i utrzymując produkt w stanie ukończonym (done) i użytecznym, mając z tyłu głowy, że kolejnego Sprintu może nie być.

Projekt można określić jako tymczasowo organizację powołaną do wykonania pewnej pracy albo dostarczenie unikalnego rezultatu w określonych zasobach. Jeśli byśmy próbowali odnieść te definicje do Scrum, zobaczymy, że każdy Sprint można określić jako projekt. A Sprint nie może się nie udać, może jedynie dostarczyć nieakceptowalnego zwrotu z inwestycji.

Scrum został zaprojektowany z myślą o budowaniu złożonych produktów. Kiedy trafiamy na sytuację, w której nie ma produktu do dostarczenia, a nadal jest zakres do dostarczenia, możemy zastanowić się czy może lepiej sięgnąć po Project Management nawet ze znamionami Agile. Scrum w takiej sytuacji może wyglądać sztucznie.

Scrum jest zupełnie innym podejściem niż zarządzanie projektem, które skupia się na dostarczeniu całego ustalonego zakresu i zakończy się w ustalonej dacie. Oczywiście można prowadzić projekty inaczej, ale przytłaczająca ilość projektów to tak zwane fixy. Fix oznacza twardo ustaloną datę lub twardo ustalony zakres, albo pomimo wielu ostrzeżeń twardo ustalone obie wartości. Nie oznacza to, że nie można stosować Scrum w projektach typu fix. Takie podejście może okazać się bardzo korzystne, bo chociażby bardzo szybko będziemy się uczyć i niwelować kolejne ryzyka. Najwyżej nie będzie wydania produktu na produkcję do samego końca projektu. W praktyce okazuje się, że takie podejście do realizacji projektu otwiera zupełnie nowe możliwości na prowadzenie dialogu z zamawiającym.

W Scrum trzy role obejmują całość

Po przeczytaniu Scrum Guide, a na pewno po szkoleniu wiemy, że w Scrum są tylko trzy role. Ktoś, kto ma budżet i mówi co robić - Product Owner. Ktoś kto, wykonuje pracę - Development Team. Ktoś, kto dba o Zespół, usuwa przeszkody i robi wszystko, żeby Scrum był dobrze stosowany. Dlaczego nie ma tutaj Project Managera? Gdzie tutaj miejsce dla Project Managera? Zadajmy sobie niewygodne pytanie i zastanówmy się, po co nam Project Manager? Czym miałby się zajmować? Ktoś może odpowiedzieć, że pilnowaniem zakresu i budżetu. Będzie mówił Zespołowi Deweloperskiemu, co mają robić. Zaraz, zaraz. Ale czy kogoś takiego nie mamy? Od tego w Scrum mamy Product Ownera. No dobrze, w takim razie może Project Manager będzie zajmował się harmonogramem i planowaniem prac. Ale przecież tym się zajmuje Zespół Deweloperski. No to niech Project Manager pilnuje standardów, procesów i załatwia co potrzeba Zespołowi Deweloperskiemu. Przecież od tego mamy Scrum Mastera. Czyli drogą dedukcji można dojść do tego, że w Scrum mamy już wszystkie potrzebne role i nie ma potrzeby dodawania kolejnych. Project Manager nie jest potrzebny w Scrum.

A co jeśli tych zespołów jest więcej? Kto nimi zarządza? Jeżeli to są 3 zespoły, to dokładamy do scrum elementy wzmacniające komunikację i synchronizację pomiędzy zespołami. Jeśli mamy więcej Zespołów Deweloperskich to sięgamy po prostu po metody skalowania takie jak Large Scale Scrum, Nexus, SAFe.

A czy jest jakiś obszar do zarządzania poza Scrum?

W większych organizacjach może być tak, że budowany produkt musi integrować się z innymi systemami albo światem zewnętrznym. W tych obszarach obojętnie czy pracują Zespoły Scrum (lub inny Agile) czy też jest waterfall, będziemy potrzebowali synchronizacji prac i pilnowania zależności. Wszelkie zależności z zespołami zewnętrznymi stanowią duże ryzyko dla Zespołów Deweloperskich pracujących w Scrum. Jeśli w momencie integracji czegoś zabraknie lub nie będzie działało tak jak trzeba, to jest duże prawdopodobieństwo, że nie uda się wykonać zaplanowanej w Sprincie pracy. Taka integracja to doskonałe pole dla Project Managera, żeby wykazać się umiejętnością koordynacji i zarządzania ryzykami.

Wytwarzanie produktu stanowi tylko część całego procesu SDLC. Co z wdrożeniem, migracją danych, przeszkoleniem użytkowników itd.? Kto w Scrum się tym zajmuje? Można powiedzieć, że Product Owner najbardziej tutaj pasuje jako osoba zajmująca się wszystkimi aspektami produktu. Praca związana z wdrożeniem może być wprowadzona do Product Backlog i realizowana przez Zespół Deweloperski. I faktycznie widziałem takie podejścia z sukcesem zrealizowane w praktyce. Natomiast łatwo zauważyć, że jeśli mamy Project Managera w naszej organizacji, to wdrożenie jest bardzo dobrym obszarem do przekazania do realizacji w formie projektu.

Może też się zdarzyć taka sytuacja, że cała organizacja nie przeszła jeszcze transformacji do Agile. I na przykład pomimo pracy w Scrum, budżetowanie i raportowanie będzie opierało się o projekty. Może też nawet tak, że zakres projektów będzie obejmował wiele produktów i tym samym zasilał wiele Product Backlogów. W takim wypadku możemy zatrudnić Project Managera part time do trzymania porządku w papierach. Pracowałem w takiej konfiguracji jako Scrum Master i po szybkim ustaleniu podziału obowiązków współpraca z Project Managerem na 25% układała się bardzo dobrze.

W sytuacji kiedy mamy zawartą umowę i jesteśmy klientem lub dostawcą można pokusić się o oddelegowanie Project Managera do pilnowania przestrzegania warunków kontraktu lub przestrzegania wypełniania zobowiązań. Może być też tak, że sprzedajemy software jako gotowy produkt wielu klientom, przy czym każdy z nich ma inne potrzeby i korzysta z nieco innej wersji oprogramowania. W takim wypadku możemy mieć oddelegowanego osobnego Project Managera dla każdego klienta. Project Manager zajmuje się precyzowaniem ustaleń z klientem i pilnuje dostarczenie funkcjonalności danemu klientowi. Nadal za rozwój produktu będzie odpowiedzialny Product Owner i z nim wszyscy Project Managerowie będą ustalali kolejność elementów w Backlogu Produktu. Jeden z moich klientów wypracował taką konfigurację i sprawdziło się to w działaniu. Z punktu widzenia Scrum mamy nadal jednego Product Ownera i wielu interesariuszy, co jest zupełnie ok.

Dlaczego nie ma Project Managera w Scrum?

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świadczenie 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.

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 mniej 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 są 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.

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.

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óźniej 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.

Dlaczego nie ma Project Managera w Scrum?

Krystian Kaczor znany jest w środowisku profesjonalistów IT jako wpływowy specjalista od Agile. Propagator pragmatycznego podejścia opartego na empiryzmie i sprawdzaniu efektów. Autor sprzedanej w tysiącach egzemplarzy książki “Scrum i nie tylko. Teoria i praktyka w metodach Agile”. Trener, który nadal pracuje jako Agile Coach i Scrum Master, żeby utrzymać więź z praktyką projektową.

Dlaczego nie ma Project Managera w Scrum?

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200