W metodach promujących rolę project managera w Agile, np. Agile PM wywodzący się z DSDM Atern, można znaleźć materiały, w których Scrum został opisany jako metoda wytwórcza, na poziomie delivery. W podejściu projektowym nad delivery musi górować poważna metodyka zarządcza. W tym ujęciu Scrum jawi się jako pewien sposób organizacji pracy deweloperów, którym project manager i tak musi zarządzić. Czy naprawdę sam biznes i deweloperzy nie daliby sobie rady?

Czym jest Scrum według twórców Scrum i Scrum Guide

Według Kena Schwabera i Jeffa Sutherlanda, autorów przewodnika „Scrum Guide”, „Scrum to ramy procesu, które są wykorzystywane w zarządzaniu wytwarzaniem złożonych produktów od początku lat 90. Scrum nie jest procesem czy techniką wytwórczą; opisuje jedynie ogólne sposoby postępowania, w których obrębie możliwe jest stosowanie różnego rodzaju procesów i technik. Scrum pomaga odkrywać nieefektywności praktyk zarządczych i technik inżynierskich, by można było je doskonalić”.

Zobacz również:

• Partnerstwo w zakresie rozwoju oprogramowania - 5 najlepszych praktyk
• Blaski i cienie AI
• Ataki ransomware pozostają nadal numerem 1

Scrum został stworzony z myślą o budowaniu złożonych produktów; jego esencją jest dostarczanie wartościowych produktów w krótkich iteracjach. Budowa produktu w ramach Scruma polega na dostarczaniu kolejnych przyrostów i wydawaniu ich na produkcję, kiedy strona biznesowa uzna, że a to sens. Produkt rozwijany jest tak długo, jak długo jego właściciel (product owner) uważa, że opłaca się to z punktu widzenia biznesu. Właściciel produktu zajmuje się produktem także po jego wdrożeniu, musi więc brać pod uwagę całkowity koszt jego posiadania (Total Cost of Ownership). W tym podejściu realizujemy zawsze to, co najbardziej wartościowe, a utrzymując produkt w stanie ukończonym (done) i użytecznym, trzeba pamiętać, że kolejnego Sprintu może nie być.

Definicja projektu z perspektywy Scruma

Projekt można określić jako tymczasową organizację, powołaną do wykonania pewnej pracy albo dostarczenia unikalnego rezultatu dzięki określonym zasobom. W odniesieniu do Scruma definicja projektu może obejmować każdy Sprint. Ten nie może się zaś nie udać; może jedynie dostarczyć nieakceptowalny zwrot z inwestycji.

Scrum wiąże się z innym podejściem niż w przypadku zarządzania projektami. Celem tego ostatniego jest dostarczenie całego ustalonego zakresu prac oraz zakończenie ich realizacji w uzgodnionym wcześniej terminie. Przytłaczająca większość projektów to tak zwane fixy, zakładające twardo ustaloną datę lub zakres prac, a czasem, pomimo wielu ostrzeżeń, obie te zmienne.

Scrum został zaprojektowany z myślą o budowaniu złożonych produktów. W sytuacji, w której do dostarczenia jest zakres prac, a nie produkt, warto się więc zastanowić, czy project management (nawet ze znamionami Agile) nie sprawdzi się lepiej. Nie oznacza to oczywiście, że do takich projektów nie da się zastosować Scruma. Takie podejście może okazać się korzystne, np. z racji na sprawny proces nauki czy łatwiejsze niwelowanie ryzyka. Będzie wiązało się najwyżej z wydaniem produktu na produkcję dopiero po zrealizowaniu projektu. W praktyce okazuje się, że realizacja projektu na podstawie Scruma otwiera nowe możliwości w prowadzeniu dialogu z zamawiającym.

Trzy kluczowe role

Scrum wiąże się z odgrywaniem trzech głównych ról w ramach zespołu scrumowego. Właściciel produktu odpowiada za budżet i mówi, co robić. Prace programistyczne wykonuje zespół deweloperski (Development Team). Scrum master odpowiada z kolei za stosowanie zasad i praktyk Scrum oraz współpracę całego zespołu.

Dlaczego nie ma tutaj project managera? Dlatego że nie miałby się czym zajmować. Pilnowanie zakresu i budżetu oraz kierowanie pracą zespołu deweloperskiego należy do właściciela produktu. Harmonogram i planowanie prac deweloperskich to obowiązki zespołu. Pilnowaniem standardów, procesów oraz dostarczaniem niezbędnych zasobów zajmuje się scrum master. Nie ma potrzeby dodawania kolejnych ról.

Scrum nie potrzebuje project managera również w przypadku większej liczby zespołów. Wystarczy wprowadzić dodatkowe elementy wzmacniające komunikację i synchronizację między nimi. Pomocne jest sięgnięcie po takie metody skalowania, jak: Large Scale Scrum, Nexus, SAFe (Scaled Agile Framework).

Rola project managera

Doświadczenie kierownika projektu jest potrzebne w wypracowywaniu nowych procesów i KPI. Wiedza z zakresu zarządzania projektami może być przydatna w tłumaczeniu podejścia Agile interesariuszom i zarządowi. Kluczowe pytanie powinno brzmieć: jaką wartość uzyskamy, utrzymując stanowisko project managera?

Produkt budowany w większych organizacjach często musi integrować się z innymi systemami albo ze światem zewnętrznym. Niezależnie od tego, czy w obszarach tych pracują inne zespoły scrumowe (lub inne Agile), czy też stosowane są metodyki kaskadowe, konieczna jest synchronizacja prac i pilnowanie zależności. Z perspektywy firmowych zespołów deweloperskich stanowi to duże ryzyko. Koordynacja prac i zarządzanie ryzykiem to w takim przypadku doskonałe pole do popisu dla project managera, ponieważ jeśli w momencie integracji czegoś zabraknie lub coś nie zadziała, to z dużym prawdopodobieństwem nie uda się wykonać zaplanowanej w Sprincie pracy.

Wytwarzanie produktu to jednak tylko część cyklu życia systemu (SDLC). Co z odpowiedzialnością za wdrożenie, migrację danych czy przeszkolenie użytkowników? W Scrumie tę rolę warto powierzyć właścicielowi produktu. Praca związana z wdrożeniem może być np. wprowadzona do Backlogu produktu i realizowana przez zespół deweloperski (widziałem takie podejścia z sukcesem zrealizowane w praktyce), ale także przekazana jako przedsięwzięcie dla project managera.

W przypadku organizacji, która nie zakończyła jeszcze transformacji Agile, budżetowanie i raportowanie bazuje niekiedy na projektach, mimo bieżących prac realizowanych już w Scrumie. Zdarza się też, że zakres projektów obejmuje wiele produktów, zasilając tym samym wiele Backlogów. W takim wypadku możemy zatrudnić project managera na niepełny wymiar godzinowy w celu utrzymania porządku w papierach (pracowałem w takiej konfiguracji jako scrum master i po szybkim ustaleniu podziału obowiązków współpraca z project managerem zatrudnionym na ćwierć etatu układała się bardzo dobrze).

Jeżeli firma ma zawartą umowę z zewnętrznym dostawcą, project manager może pilnować przestrzegania warunków kontraktu lub zobowiązań. Jeżeli przedsiębiorstwo samo sprzedaje oprogramowanie, rolą PM może być także precyzowanie ustaleń z danym klientem i pilnowanie, by otrzymał wymaganą funkcjonalność. W tej ostatniej konfiguracji za ogólny rozwój produktu dalej odpowiadać będzie właściciel produktu, z którym menedżerowie projektu będą ustalali kolejność elementów w Backlogu produktu.

Zmiana roli project managera

Transformacja Agile nie zawsze przebiega bezkonfliktowo, zwłaszcza jeśli pytanie o zasadność roli nie znajdzie pozytywnej odpowiedzi. Niechęć project managera do Scruma może mieć też inne przyczyny. Być może kultura organizacyjna i środowisko pracy nie wspierają zwinnego podejścia? Organizacyjny opór wiąże się często z przekonaniem, że kierownik projektu jest potrzebny, „bo zawsze był”. Jak zresztą przekonać go do zmian, jeśli jego premia zależy od dowiezienia projektu? Jak ma przestać kontrolować pracę zespołów, jeżeli szefowie wymagają szczegółowych raportów i zadają te same pytania?

Czy można się spodziewać, że po przełamaniu oporu i przejściu na Scrum sytuacja będzie stabilna? Oczywiście, że nie. Transformacja Agile odbywa się przecież po to, żeby uzyskać możliwość eksperymentowania i wprowadzania częstych zmian. Inny sposób pracy będzie na początku powodował chaos. Zarówno organizacja, jak i zespoły potrzebują czasu na odnalezienie się w nowym paradygmacie pracy. Transformacja Agile to także zmiana kulturowa. Często można zaobserwować dysfunkcję polegającą na przerzuceniu obowiązków zarządczych i raportowych na scrum masterów albo specjalnie w tym celu powołanych liderów zespołów. W ten sposób samoorganizacja w zespole deweloperskim po prostu nie zaistnieje.

Jeśli nie znajdujemy zastosowania dla roli project managera w nowej, zwinnej organizacji, nie musi to od razu oznaczać zwolnień, czy też, jak się mówi w korporacji, „uwalniania etatów”. Według badań, podobno przy każdej zmianie organizacyjnej może odejść nawet 30% pracowników. Scrum przewiduje trzy role, więc może dobrze jest przeszkolić i przekwalifikować project managera?

Większość z nich postrzega rolę scrum mMastera jako naturalny kierunek zmiany. Patrząc przez pryzmat dotychczasowego stanowiska, sądzą, że scrum masterze to ktoś, kto zarządza zespołem. Niestety, stare nawyki i taki sposób myślenia dyskwalifikują ich z tej roli – w takiej konfiguracji Scrum będzie tylko udawany. Przy okazji można będzie się spodziewać kampanii na rzecz przejścia na metody sankcjonujące rolę project managerów, np. Prince2 Agile czy DSDM, gdzie przewidziana jest rola Agile PM. Co ciekawe, reszta aspektów tych metod nie jest już tak chętnie promowana, a później przestrzegana.

Czasami (niestety, rzadko) spotykam project managerów, którzy bardzo dobrze współpracują z zespołami i skupiają się na zapewnieniu im wszystkiego, czego potrzebują do działania. Taki kierownik dba także o relację z biznesem, który z kolei lubi z nim współpracować. To profil jak najbardziej nadający się na scrum mastera. Ważne jest, żeby w takiej sytuacji spytać zespół, co sądzi, żeby dany project manager został ich scrum masterem.

Jeśli project manager nie sprawdzi się w roli scrum mastera, może powinien przekwalifikować się na właściciela produktu? Taki manewr może się udać, jeżeli dany kierownik posiada wiedzę na temat biznesu, użytkowników i potrzeb interesariuszy. Nie należy odmawiać project managerowi możliwości przekwalifikowania się na dewelopera – tych nigdy nie jest za dużo.

Autor znany jest w środowisku profesjonalistów IT jako wpływowy specjalista od Agile. Propagator pragmatycznego podejścia opartego na empiryzmie i sprawdzaniu efektów. Autor sprzedanej w tysiącach egzemplarzy książki „Scrum i nie tylko. Teoria i praktyka w metodach Agile”. Trener, który nadal pracuje jako agile coach i scrum master, żeby utrzymać więź z praktyką projektową.