7

Czy Project Manager może być Scrum Masterem w Zespole Scrumowym? 

(Natalia M.)

Bardzo dobre pytanie, dzięki! Ten temat od zawsze wzbudza sporo kontrowersji. Całe zamieszanie wzięło się stąd, że w Scrumie nie ma roli Project Managera. Podobnie jak nie ma roli menedżera liniowego, dyrektora departamentu, CEO, czy kogokolwiek innego. Tak samo zresztą jest z pojęciem „projektu”, o którym Scrum bezpośrednio nie wspomina. Co nie znaczy, że w metodach zwinnych projekty w ogóle nie istnieją.

Jedna z najbardziej typowych definicji projektu, które znam brzmi następująco:

Projekt to ograniczone w czasie przedsięwzięcie, zmierzające do osiągnięcia określonego celu.

No przecież to właśnie w Scrumie robimy – realizujemy ograniczone w czasie przedsięwzięcia, które zmierzają do wytworzenia określonego produktu, dostarczenia usługi lub rozwiązania złożonego problemu. Do tego właśnie została wymyślona ta metoda. Każdy sprint jest pewnego rodzaju projektem, który zmierza do osiągnięcia określonego wyniku (cel sprintu) i jest ograniczony w czasie (max. 30 dni).

I teraz, żeby skutecznie realizować takie „projekty”, potrzebujemy trzech ról: Właściciela Produktu, Scrum Mastera i Zespół Deweloperski.

• Właściciel Produktu jest odpowiedzialny za wszystkie aspekty biznesowe, realizowanych przedsięwzięć w Scrumie. Formułuje i komunikuje wizję produktu oraz zapewnia, że produkt jest budowany w odpowiedniej kolejności (maksymalizacja wartości biznesowej). Właściciel Produktu aktywnie współpracuje z Zespołem Deweloperskim i Scrum Masterem. Jest samodzielny i decyzyjny we wszystkich aspektach, związanych z rozwojem produktu.
• Scrum Master dba o to, żeby zespół stosował wartości, zasady i praktyki Scruma. Jest coachem zespołu. Usuwa przeszkody, które utrudniają efektywną pracę zespołu. Facylituje spotkania scrumowe, jeśli zespół o to poprosi lub zaistnieje taka potrzeba. Wspiera Właściciela Produktu w efektywnym zarządzaniu Rejestrem Produktu.
• Zespół Deweloperski jest interdyscyplinarny i sam organizuje swoją pracę w sprincie. Członkowie zespołu sami decydują o tym, jak zdefiniują zadania, jak podzielą pracę. To jest całkowicie ich „broszka”.

Co się stało z rolą PM-a w Scrumie?

Jak łatwo zauważyć, roli Project Managera, jako takiej, w Scrumie nie ma. Czy to jednak oznacza, że obowiązki, które normalnie wykonywał tradycyjny PM, odchodzą do lamusa? Bynajmniej.

Tradycyjny Project Manager miał całkiem sporo ważnych obowiązków, które były bardzo potrzebne z punktu widzenia realizacji projektów. Czuwał nad realizacją celów projektu. Zarządzał czasem, budżetem i zakresem projektu. Identyfikował i minimalizował ryzyka. Monitorował postęp prac w projekcie. Zarządzał interesariuszami projektu. Dbał o dobry przepływ informacji w zespole projektowym. Rozdzielał pracę (WBS).

W projektach agile, wszystkie dotychczasowe obowiązki PM-a są podzielone, głównie między rolę Product Ownera’a (PO) i Scrum Mastera (SM).

Agile PM w dużych organizacjach

O ile, model podziału obowiązków tradycyjnego PM-a między Product Ownera i Scrum Mastera bardzo dobrze sprawdza się w małych projektach, które liczą do 30 osób, o tyle przy dużych przedsięwzięciach, w których zaangażowanych jest nawet do 600 osób, takie podejście się nie sprawdza. Przede wszystkim mamy do czynienia z naprawdę dużym Backlogiem Produktu, który jest rozwijany przez dziesiątki zespołów scrumowych. 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 jest 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 więc 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, komunikowaniu się z interesariuszami projektu. 

Czy Project Manager może pełnić rolę Scrum Mastera?

Po tym wstępie, mogę się wreszcie zabrać za odpowiadanie na Twoje pytanie, Natalio. Krótka odpowiedź jest taka: tak, może. Osobiście jednak, odradzam. W większości wypadków, kiedy stosowałem takie rozwiązanie u klientów, najczęściej słabo się to sprawdzało. Chociaż, oczywiście znam kilka przypadków, kiedy taka tranzycja z Project Managera na Scrum Mastera przebiegła praktycznie bezboleśnie i PM sprawdził się znakomicie w roli Scrum Mastera. To i tak, koniec końców, zależy od osoby. Jeżeli tylko jesteś świadoma wyzwań, które wiążą się ze zmianą roli PM-a na Scrum Mastera, powinnaś spróbować. I bardzo możliwe, że Ci się uda.

I może jeszcze jedna rzecz. Z Twojego pytania nie wynika jednoznacznie, na czym takie łącznie roli PM-a i SM-a miałoby polegać. Jeżeli chciałabyś być Scrum Masterem i jednocześnie Project Managerem, zdecydowanie odradzam. Podstawowa trudność polega na przechodzeniu z roli PM-a w rolę Scrum Mastera, w konkretnych sytuacjach projektowych. To jest też duże wyzwanie dla ludzi z zespołu. Kiedy mówisz jako PM, a kiedy jako Scrum Master? Kiedy jesteś coachem, a kiedy koordynatorem? Kiedy używasz sankcji, a kiedy procesu? Jest bardzo prawdopodobne, że w takiej schizofrenii z czegoś będziesz musiała zrezygnować – jestem prawie pewny, że z roli SM-a. Jeżeli  chcesz w swojej firmie utrzymać rolę Project Managera, bo faktycznie jest potrzebna, to dużo lepszym rozwiązaniem jest połączenie jej z rolą Właściciela Produktu, zakładając że Twoja organizacjach nie jest duża i takie „małżeństwo” jest do pogodzenia.  Zanim jednak zdecydujesz się na konkretne rozwiązanie, przemyśl dobrze te sytuacje, o których wspominałem.

Dlaczego odradzam łączenie roli Project Managera i Scrum Mastera?

Jest coś takiego, co obiegowo nazywam „skażeniem menedżerskim”. Nazwa może nie jest najlepsza, ale bardzo dobrze oddaje to, co chodzi mi po głowie. Rok temu prowadziłem wdrożenie w dużej zagranicznej korporacji. Trafił mi się bardzo fajny zespół pilotażowy, łącznie z menedżerem liniowym, który zarządzał kilkoma zespołami w tej firmie. Pamiętam, że spędziłem z nim całkiem sporo czasu, żeby pomóc mu jakoś odnaleźć się w tej nowej, zwinnej rzeczywistości. Rozmawialiśmy, odgrywaliśmy różne scenki. Był Niemcem, więc naprawdę chciał się do tej całej zmiany dobrze przygotować. I mija pierwszy sprint, siedzimy na pierwszej retrospektywie, zespół zgłasza listę rzeczy, które nie wyszły w sprincie i…  co robi „agile manager”? Bardzo konkretnie, bez ogródek, mówi zespołowi, co powinien zrobić, żeby takich sytuacji uniknąć w przyszłości. Używał przy tym bardzo menedżerskich zwrotów: „Oczekuję, że zrobicie to tak i jak…” albo „Musimy to zrobić w ten sposób…”,

„Skażenie menedżerskie” nie jest niczym złym. Każdy menedżer, przez lata swojej pracy w organizacji buduje pewne nawyki, które różnią się od tych, które są promowane w projektach agile. Składa się na nie konkretny język (nakazowy) i zachowania, których wcale nie jest tak łatwo się oduczyć. I czasem musi upłynąć całkiem sporo czasu, żeby taka istotna zmiana mogła się dokonać.

Kącik kujona

Na koniec polecam kilka książek, które pomogą Ci trochę bardziej zgłębić temat zarządzania projektami w agile. Wybrałem trzy:

• Extreme Project Management, Douglas de Carlo. To jest jedna z fajniejszych książek o zarządzaniu projektami, jakie czytałem. Mimo, że autor słowem nie wspomina o zarządzaniu projektami w agile, jego książka jest bardzo agile’owa. Często do niej wracam.
• Agile Project Management: Creating Innovative Products, John Higmisth. To jest chyba pierwsza książka o zwinnym zarządzaniu projektami, którą przeczytałem. Każdy rozdział zaczyna się krótką rozmową między tradycyjnym PM-em i Agile Project Managerem. I to jest bardzo fajne w tej książce, bo te krótkie dialogi oddają istotę problemów, z którymi w zwinnym zarządzaniu PM-owie muszą się mierzyć.  Poza tym jest tutaj sporo praktycznych wskazówek, które przy wchodzeniu na zwinną ścieżkę projektową mogą się przydać. Jest także polskie wydanie tej książki, jednak tłumaczenie, jak w przypadku wielu podobnych publikacji, pozostawia wiele do życzenia. 
• Managing Agile Projects, Sanjiv Augustine. W tej książce dużo jest myślenia systemowego, za co ją szczególnie cenię. Poza tym, jest w niej pokazane, na czym polega rola Agile PM-a, jakie ma obowiązki, także w kontekście zespołu projektowego. Dodatkowo, ciekawie jest opisany sam proces wdrożenia agile w firmie.

Polecam!