Project Manager w Scrum #2 — czy potrzebna jest kolejna rola?

utworzone przez | Lis 5, 2017 | Blog, Scrumpedia | 0 komentarzy

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.

Note there is no role of project manager in Scrum. This is because none is needed; the traditional responsibilities of a project manager have been divided up and reassigned among the three Scrum roles. Scrum Primer Version 1.2

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”.

Share This