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 — Scrum Master. 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 taki jak Large Scale Scrum, Nexus, SAFe.

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

W większych organizacjach może być tak, ze 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.

Scrum a projekty?

Jeśli czytałeś pierwszą część tego artykułu Czy Scrum to metoda zarządzania projektami?, to wiesz jak się ma zarządzanie projektami do Scruma. Ale czy projektów w ogóle nie będzie?

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 takie konfiguracji jak 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 oddelegowania 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 “po scrumowemu”.

Poprzednia część artykułu: Project Manager w Scrum #1 — czy Scrum to metoda zarządzania projektami?
Następna część artykułu: Project Manager w Scrum #3 — co zrobić z PMem