Project Manager w Zespole Scrumowym – czy to kiedykolwiek działa? Jeżeli zapytamy wyznawców Podręcznika Scrum, usłyszymy odpowiedź: „Stanowczo nie!”. Gdy zadamy to samo pytanie w jednej z mnóstwa pseudozwinnych korporacji usłyszymy: „A jak inaczej?!” My preferujemy podejście zrównoważone. Spójrzmy więc, jak to z tym PM-em w Scrumie jest.
Kim jest Project Manager i co robi w Scrumie?
Jak dobrze wiemy, Podręcznik Scruma przewiduje tylko 3 odpowiedzialności: Developer, Scrum Master oraz Product Owner. Natomiast, wiemy, że w praktyce nierzadko nad produktem pracują ludzie o różnych specjalizacjach: programiści, designerzy, analitycy, testerzy i tak dalej. Każdy, kto dodaje wartość do produktu oraz pracuje zgodnie z ustalonymi zasadami jest nazywany Developrem. Czy taką osobą mógłby być PM? Przecież wiemy dobrze, że oni potrafią dodać wartość, inaczej nie byłoby zapotrzebowania na ich usługi.
Scrum Guide nie mówi nic o planowaniu oraz zarządzaniu budżetem, ani tym bardziej o projektach. Nie definiuje, jak kierować środkami, jak radzić sobie w różnych kwestiach prawnych. A (prawie) każdy produkt potrzebuje, żeby te sprawy były ogarnięte. Przez kogo? Czy taką osobą może być Project Manager? Tak, ale koniecznie zwinny. I nie, prawdopodobnie nie będzie wtedy w Scrum Teamie.
PM kontra Scrum
Ważne jest, żeby zrozumieć kontekst. Mówiąc o Scrumie, mówimy o tworzeniu produktów w adaptacyjno-iteratywny sposób. Mówimy też o ludziach, którzy je tworzą oraz o procesach, które to umożliwiają. To wszystko nierzadko odbywa się w granicach pewnej firmy, która ma swoje realia, potrzeby i ograniczenia.
Jednym kontekstem jest Scrum Team i produkt, który tworzą. Drugim zaś organizacja, w której to się dzieje. W granicach pierwszego kontekstu PM zazwyczaj nie istnieje, tak samo jak nie istnieją umowy o pracę, kontrakty, deklaracje podatkowe czy zasady BHP. Ale już w tym drugim kontekście, Project Manager może mieć wpływ na sukces lub porażkę produktu.
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.
Co robi zwinny Project Manager?
PM może być błogosławieństwem dla zespołu (nie tylko scrumowego), wspierając ich od strony administracyjno-organizacyjnej. Na przykład może pomagać Scrum Masterowi usuwać przeszkody, z którymi boryka się zespół. Albo doradzając Product Ownerowi w sprawie zarządzania ryzykiem. W praktyce często też się zdarza, że PM występuje jako interesariusz. Jest to dosyć typowe kiedy produkt jest tworzony dla klienta wewnętrznego w dużej korporacji.
To, że roli Project Managera nie ma opisanej w Scrum Guide, nie znaczy, że ona nie istnieje. Co więcej – bardzo często ma wpływ na zespół. Dobry PM tworzy środowisko, w którym zespoły mogą wykorzystać wszystkie zalety Scruma i stać się w pełni samoorganizujące i samozarządzające.
Niektórzy mówią też, że część zadań PM-a, jak chociażby usuwanie niektórych przeszkód, realizuje Scrum Master. To prawda, zakres odpowiedzialności PM-a i SM-a się przecina, ale zdecydowanie zbyt mało, żeby stawiać te role obok siebie. Ot, czasami SM dopnie kwestie formalne, a czasami PM rozwiąże „impediment”. Ale na pewno PM nie będzie coachował zespołu, a SM zajmował się budżetem czy umowami.
Antywzorce zwinnego Project Managera
Współpracując z Kierownikiem Projektu w Scrumie musimy mieć świadomość potencjalnych zagrożeń. Wywodzą się one z podejścia, którego zazwyczaj PM-owie są nauczani. To podejście polega na postrzeganiu ludzi jako „zasobów”. Nie w makiawelskim znaczeniu, oczywiście. Chodzi tylko o to, że typowe „waterfallowe” podejście nie liczy się ani z realiami natury ludzkiej, ani z nieprzywiedlnością świata w którym żyjemy. Skutkiem tego jest prostolinijne myślenie, gdzie zespół z 5 Developerów jest równoznaczny 5 maszynom do produkowania X Story Pointów per Sprint.
Nie możemy pozwolić na micromanagement, ani na ślepą walkę z nieprzewidywalnością jeżeli chcemy pracować w Scrumie. Tak samo powinniśmy wiedzieć, że przesunięcie dwóch programistów z zespołu A do zespołu B to nie jest przesunięcie wierszy w Excelu. Konsekwencje, także w temacie wydajności obu zespołów, będą dużo większe.
Kolejnym zagrożeniem, z którym możemy mieć do czynienia przy angażowaniu PM-a jest ograniczanie kreatywności zespołu. Natura ludzka jest taka, że im bardziej jesteśmy załadowani pracą i skupieni na planie, tym bardziej tracimy poczucie perspektywy oraz zdloność do szerszego myślenia (outside of the box). Jeżeli nie mamy przestrzeni do eksperymentów, popełniania błędów, a czasem i po prostu zabawy, będziemy coraz sztywniejsi, a nie zwinniejsi. Będziemy tracili okazję do rozwoju, zarówno nas samych, jak i naszego produktu.
W zwinnym podejściu chodzi nie o to, żeby tracić mniej, tylko o to, żeby wygrywać więcej. A to wymaga wolności, którą odbiera ludziom tak lubiany przez Project Managerów micromanagement. Z tego względu, PM musi być coachowany co do tematu podejścia zwinnego oraz mieć świadomość granic własnego angażowania się w pracę zespołu. Zwinny PM to taki, który głównie pyta się, jak mógłby pomóc, a resztę czasu – nie przeszkadza.
Zwinne zarządzanie i zwinne… myślenie
Scrum Guide nie mówi za dużo o zarządzaniu, ale to nie znaczy, że jego twórcy nie byli świadomi tego zjawiska oraz jego istoty. Tematem, który porusza problemy zwinnego zarządzania bardziej głęboko jest Professional Agile Leadership. Jeżeli ten temat cię interesuje, to uderz do nas, bo szkolimy również i w tym kierunku, pomagamy też przygotować się do egzaminów takich jak PAL.
Równie ciekawym jest temat agile mindsetu. Co znaczy myśleć kreatywnie? Jak tworzyć innowacyjne produkty? Jak znajdować okazję do ulepszenia produktu tam, gdzie większość tkwi w rutynie? Czy wreszcie jak nie pozwolić ograniczeniom ludzkiego umysłu skazać naszego produktu na porażkę? Ten temat obecnie ostro poruszamy na naszej liście mailingowej. Jeżeli wciąż nie jesteś zapisany/a, to jest to właściwy moment, żeby to zmienić.
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.