Nie ma PM-a w Scrumie, a przecież występuje w każdym projekcie. Jest jego nieodzowną częścią, a wydaje się, że autorzy Scrum Guide’a o nim zapomnieli. Czy słusznie? Co robi i kim jest Project Manager w Scrum?
Kim jest Project Manager?
Każdy z nas wie, jakie role wchodzą w skład Scrum Team. Wielokrotnie je opisywaliśmy na naszym blogu, mówiliśmy też o nich na naszym kanale YouTube. Jak pewnie zauważyliście, wśród ról przewidzianych przez Scrum Guide nie ma Kierownika Projektu. Niedopatrzenie twórców metodyki czy też może celowe działanie? I czy to oznacza, że Project Manager w Scrum nie występuje?
Zakres obowiązków przydzielonych zwykle Kierownikowi Projektu jest szeroki niczym dorzecze Amazonki. Plan projektu? Oczywiście! Rejest ryzyk wraz z zaplanowanymi reakcjami? Jak najbardziej. Plan zasobowania projektu? Jasne, przygotowany jest zwykle jeszcze przed jego startem. Są to zadania nieodzowne i konieczne do podjęcia, jeśli wymaga tego organizacja. Ktoś przecież musi się tym wszystkim zająć.
Czy wyobrażamy sobie, żeby tą tematyką zajmował się Scrum Team? Nie, bo został on powołany do wykonania zupełnie innej pracy. Musimy więc poszukać kogoś, na kogo barki spadną powyższe zadania i wiele więcej.
Kompetencje PM
Skoro wiemy już, że Project Managera nie ma w metodyce Scrum, to gdzie znajdują się kompetencje, za które jest on zwyczajowo odpowiedzialny? Niektórzy powiedzą, że są one rozdzielone pomiędzy cały Scrum Team. Taka odpowiedź wydaje się być sensowna, ale czy Zespół Scrumowy przygotowuje wysokopoziomowy harmonogram i plan projektu? Oczywiście, że nie.
Kompetencje, które znajdują się w zespole dotyczą głownie jego samoorganizacji. Mówię tutaj o tym, w jaki sposób dostarczone zostanie wymaganie, jak rozwiążemy codzienne problemy czy jak podzielimy się na zespoły. Plan projektu, utworzony przez Project Managera będzie dla nas wstępem do identyfikacji wielu kluczowych elementów składowych projektu, w którym bierzemy udział. Oznacza to, że zakresy naszych obowiązków mocno się przenikają.
Co w przypadku konieczności rozszerzenia naszego zespołu o nowe kompetencje? To własnie jedno z tych działań, w których zespół nie jest umocowany. Do kogo wówczas się zgłosi?
Fałszywy Project Manager
Widzieliście przypadki, w których Product Owner czy Scrum Master to właśnie Kierownik Projektu? My bardzo często. Za każdym razem zadajemy sobie wówczas pytanie czy ta konstrukcja ma szansę na sukces? Niestety często, choć podkreślamy że nie zawsze, odpowiedź brzmi nie.
Teoretycznie nie ma przeciwwskazań w łączeniu tych ról. Przecież Przewodnik po Scrum nie zabrania nawet łączenia roli Scrum Mastera i Product Ownera. Wydają się one mocno przeciwstawne, ale jednak można próbować to zrobić. Wszystko jak zwykle w takich przypadkach rozbija się o osobowość, a konkretnie o umiejętność rozdzielenia tych dwóch rozłącznych odpowiedzialności.
Nie ma tutaj znaczenia czy połączymy funkcje Kierownika Projektu z byciem PO czy SM. Za każdym razem musimy najpierw trafnie zinterpretować sytuację, w której się znaleźliśmy, a następnie zachować się zgodnie z odpowiednią rolą. Jest to niezwykle trudne i dlatego też zwykle takie połączenia są odradzane.
Najgorsze co możemy zrobić to ubierając zwinny płaszcz być w dalszym ciągu Kierownikiem Projektu. Do czego dążyć będzie ta sytuacja?
To co najważniejsze (dla Project Managera)
Słyszeliście pewnie często powtarzaną legendę o tym, że „Scrum Master jest rolą kosztową”. Czy tego samego nie można można powiedzieć o Kierowniku Projektu? Skoro możemy wyobrazić sobie życie projektowe bez Scrum Mastera, to czy możemy też żyć bez Project Managera? Skąd pochodzi przekonanie o niezastępowalności tej roli? Czy faktycznie formalności związane z uruchomieniem projektu są warte całego (kosztownego) etatu?
Wydaje się, że bezpośredni wpływ na konieczność posiadania Project Managera ma możliwość zlecenia mu każdego typu pracy oraz historyczne znaczenie tej roli dla projektu. O ile z pierwszym trudno dyskutować, tak po prostu jest, o tyle drugie jest w tym przypadku symptomem braku zrozumienia nowoczesnego podejścia do organizowania firmy.
Klasyczne rozumowanie zakłada konieczność nieustannej kontroli wszystkich i wszystkiego. Czy słusznie? Pewnie w wielu przypadkach tak. Czy można odwrócić ten niekorzystny trend? Tak, ale wymaga to z jednej strony zaufania, z drugiej – zmiany organizacji pracy. A już na pewno jawnego powiedzenia sobie, że nie ma u nas miejsca dla klasycznego Kierownika Projektu. Potrzebujemy PM’a w wersji 2.0!
Project Manager w Scrum
Czy jest więc dla Ciebie miejsce w Scrum, drogi Kierowniku Projektu? Oczywiście, że jest. Scrum jako metodyka dotyka tylko i wyłącznie zagadnienia iteracyjnego i przyrostowego tworzenia produktu. Nie mówi o żadnym aspekcie uruchamiania i prowadzenia projektu.
Każdy z nas czuje, że uruchomienie projektu to nie jest zakup 5 kajzerek w piekarni. Na proces ten składa się konieczność uzyskania wielu (czasem bardzo formalnych) zgód czy konieczność dogadania chociażby oddelegowań do naszego zespołu. Te właśnie kompetencje należą do Ciebie, drogi PM-ie.
Czy to mało? Nie! Co masz robić w trakcie trwania projektu? Obserwować, doradzać swoją wiedzą i doświadczeniem, zarządzać budżetami, ryzykami oraz umowami. Gwarantuję Ci, że wcześniej czy później zgłosi się do Ciebie (i to pewnie nie jeden raz) Scrum Master ze swoim problemem oraz Product Owner z informacjami na temat postępów pracy.
Jeśli podejmiesz wyzwanie i zostaniesz jednocześnie Kierownikiem Projektu i SM/PO – gratuluję. Pamiętaj proszę, aby zrobić to umiejętnie i z wyczuciem. Nie szukaj możliwości „tylnego” wejścia do zespołu, nie szukaj możliwości bycia „jednym z nich”, a już na pewno nie traktuj tego jako furtki do „dociskania śruby”.
Takie podejście nie przyniesie żadnych zakładanych przez Ciebie korzyści.
Od kwietnia pełnię rolę zarówno KP i PO. Nie jest łatwo, bo bycie dobrym PO to praca na cały etat. Ale ile przynosi satysfakcji ?
Z mojego doświadczenia wynika, że w agile, wszystkie dotychczasowe obowiązki PM-a są podzielone, głównie między rolę Product Ownera i Scrum Mastera.
Przede wszystkim dotyczy to sytuacji, w której mamy do czynienia z naprawdę dużym Backlogiem Produktu, który jest rozwijany przez dziesiątki Zespołów. Pojawia się dużo zależności, i to nie tylko na poziomie Zespołów, ale także dostawców i otoczenia zewnętrznego w postaci innych projektów czy programów.
To wszystko wymaga dodatkowych punktów koordynacji. I do tego właśnie potrzebny może być „Agile PM”, którego zakres obowiązków niewiele różni się od tradycyjnego PM-a, chociaż jest w pewnych aspektach mocno ograniczony.
Agile PM nie rozdziela na przykład zadań w projekcie, to robi Zespół, który sam organizuje swoją pracę w sprincie. Agile PM nie zarządza także zakresem projektu, co robi PO. Jego rola bardziej polega na koordynowaniu projektu – zarządzaniu budżetem, rozliczaniu dostawców, identyfikowaniu i minimalizowaniu ryzyk w projekcie (we współpracy z zespołem), śledzeniu przebiegu projektu.