Project Manager w Scrumie

Przedstawiamy Ci różne układy pełnienia roli Project Managera w zespole Scrumowym. Sprawdź, w którym z nich jesteś. Temat jest rozwinięciem pytania, które zadał nam nasz Słuchacz na facebookowym live. W rozmowie nawiązujemy też do naszych zawodowych doświadczeń w tej funkcji. Wskazujemy na plusy i minusy omawianych konfiguracji. O tym posłuchasz w 46. odcinku podcastu Porządny Agile.

Zobacz wersję wideo

Dodatkowe materiały

• Zwinne projekty i produkty
• Praca na termin w Agile

Zobacz making of z tego nagrania

TRANSKRYPCJA

Jacek: W dzisiejszym odcinku nawiązujemy do pytania, które pojawiło się podczas naszego ostatniego live’a na Facebooku. Mamy poczucie, że to pytanie nie zostało dostatecznie, głęboko przez nas poruszone. Pytanie dotyczyło bardzo szeroko rozumianej roli Project Managera w Scrumie. Chcielibyśmy dzisiaj trochę bardziej systemowo podejść do tego tematu i opowiedzieć Tobie, jak podchodzimy do tematu tej konkretnej roli, w tym konkretnym frameworku.

Kuba: Odcinek poukładaliśmy w poszczególne zadania związane z możliwymi układami pełnienia roli Project Managera w zespole Scrumowym. Dla Twojej wygody podam spis treści tego, co będziemy w kolejnych częściach nagrania wspominać. Zaczniemy od sytuacji, gdy PM jest nad całym zespołem wytwórczym, nad całym zespołem Scrumowym. Później przejdziemy do sytuacji, gdy PM jest ustawiony w organizacji na równi z Product Ownerem i Scrum Masterem. Wspomnimy też o sytuacji, gdy PM istnieje w zespole Scrumowym, ale niestety nie ma ról Product Ownera lub Scrum Mastera, lub są one bardzo niewyraźne. Znamy też przypadki, gdy PM jest w środku zespołu wytwórczego i to też trochę to poeksplorujemy. Skończymy z sytuacją bardzo wyrazistą, gdy PM-a w ogóle nie ma w całym układzie zespołu Scrumowego. Zespół Scrumowy nie posiada, ani w sobie, ani dookoła siebie Project Managera. Cały odcinek skończymy z refleksją związaną z tym, jak działać w zwinności, gdy jest się w roli Project Managera. To jest zwłaszcza ukłon z tych z Was, którzy tutaj są zachęceni do pracy zwinnej w jakiś sposób, a w swojej organizacji obecnie pełnią rolę Project Managera

Jacek: Pierwszy przypadek, który chcielibyśmy omówić, to jest przypadek, kiedy Project Manager, określiliśmy to sobie, jest nad wszystkimi innymi rolami. Jest to taki case, kiedy zespół pracuje używając Scruma. Mamy rolę Product Ownera, Scrum Mastera, mamy rolę zespołu developerskiego i nad tym wszystkim, można powiedzieć, taką pewną warstwą jest właśnie Project Manager, który stanowi pewnego rodzaju taki „single point of contact” tej całej grupy, właściwie zespołu Scrumowego z resztą organizacji. W naszej ocenie jest to model, nazwaliśmy to sobie – suboptymalny, czyli taki model, który z naszej perspektywy nie jest najbardziej optymalną formą wykorzystania tego zwinnego frameworka do wytwarzania produktów, usług czy czegokolwiek czym konkretnie zajmuje się zespół developerski.

Kuba: Największy problem, jaki mamy w taką sytuacją, to przede wszystkim – z góry skazanie się na pośrednictwo, czy zjawisko takiego głuchego telefonu. Głuchego telefonu, nie tylko jeśli chodzi o obieg informacji, ale też swego rodzaju pośrednictwu czy outsourcingu, jeśli chodzi o odpowiedzialności. Product Owner jest decydentem, jeśli chodzi o priorytety rozwoju produktu, ale do wyższych warstw zarządzania, jego albo wytyczne, albo informacje, albo jakieś nowe konteksty, przechodzą przez jeszcze kolejną osobę, która nad tym wszystkim trzyma pieczę, albo zbyt bardzo wyraziste komunikaty wygładza, albo filtruje, albo nawet nieświadomie trochę przeinacza. Jakby się nie wysilać, no komunikacyjnie jest to kłopot i potencjalnie również odpowiedzialnościowo, ktoś tutaj może być odcięty od pełnej informacji, od pełnej odpowiedzialności takiego zobowiązania się do tego, co jest realizowane. No i niestety takie układanki, gdzie PM jest powyżej całego zespołu Scrumowego mogą czymś takim grozić, mogą coś takiego wprowadzać.

Jacek: Z mojej perspektywy chyba najbardziej taką negatywną stroną tej konfiguracji jest to, że najczęściej w takim ustawieniu ten nasz Product Owner, on pełni rolę taką absolutnie podwykonawczą. Czyli mówimy tutaj o modelu, w którym to Project Manager wyznacza priorytety, nadaje kierunek prac, a Product Owner jest zwykle sprowadzony do takiego zarządcy Backlogu, albo jak to niektórzy mówią – Product Owner odpowiada za delivery, czyli właściwie tylko za to, żeby na czas w określonej jakości dostarczać jakieś konkretne rozwiązania. Z mojej perspektywy, w sensie mam jakby problem z taką konfiguracją na wielu płaszczyznach, zarówno z tego powodu, że ten Product Owner nie może pełnić swojej roli tak jak ja rozumiem rolę Product Ownera. Z drugiej strony również zespół jest postawiony w takiej sytuacji, gdzie jednak dostaje konkretne, nazwijmy to zlecenia czy kawałki do zrealizowania. Zwykle, na bazie moich doświadczeń, obserwowania takich konfiguracji, no nie ma tam zbyt wiele przestrzeni do co-kreacji, co automatycznie, z mojej perspektywy, dławi nam potencjalne efekty, które możemy uzyskać pracując w Scrumie, gdzie Product Owner i zespół developerski bardzo blisko pracują, rozumiejąc doskonale, jaki problem chcą rozwiązać. Kto jest Klientem? Jakie ten Klient ma potrzeby? Zwykle w momencie, kiedy mamy pewnego rodzaju kaskadę, do zespołu spadają już takie bardzo konkretne informacje w stylu – zróbcie czerwony guzik i jak go nadusimy, to ma się zadziać coś tam. No i to jest jakby bardzo mocne spłycenie tego, czym w moim rozumieniu jest praca zwinna nad produktem.

Kuba: Z innej perspektywy jest też spore zagrożenie, zwłaszcza w tym układzie, jeśli mamy porównać te kolejne sytuacje, które chcemy jeszcze wspomnieć w tym odcinku, jest duże zagrożenie, że funkcjonowanie PM-a, jako osoby, która zarządza całą tutaj strukturą projektową, projektem, czy zespołem, może dokładać do Scruma, który sam w sobie jest bardzo prosty, jakieś dodatkowe mechanizmy. Czy to będą jakieś komitety sterujące, czy to będą jakieś spotkania statusowe? Jest spore zagrożenie w tym układzie, że już specjalnie założone, czy zamierzone do pewnych zjawisk wydarzenia scrumowe, będą mieć jeszcze dodatkowo, albo dublowane – to jest najgorszy przypadek, albo jakoś tak niepotrzebnie rozmywane, czy rozszerzane przed dosyć podobne w swojej intencji wydarzenia, które są z takiego klasycznego portfela narządzi kierownika projektu. No i tak właśnie jak wspominamy jakiś status meeting, jakieś raportowanie projektu, jakiś komitet sterujący, gdy spotykam w praktyce takie sytuacje, gdzie ten PM faktycznie w organizacji funkcjonuje i w dodatku właśnie realizuje te wszystkie takie klasyczne narzędzia zarządzania projektem, no to zachęcam do refleksji, czy czasami komitet sterujący nie powinien się odbywać na Sprint Review, gdzie po prostu te same informacje, które byśmy przekazali zarządzającym – przekażemy, a przy okazji autentycznie pokażemy produkt, a nie tylko będziemy opowiadać o jakimś takim sztucznym statusie projektu. No i tak samo informacja o tym, gdzie jesteśmy w projekcie, status meeting, w zespole są zupełną duplikacją tego, co na tym Sprint Review mogłoby się dziać, pod warunkiem, że oczywiście ono zawiera takie elementy inne niż samo demo działających funkcji,  czy działającej wersji produktu, który przygotowujemy. Tak samo jakieś narzędzia związane z planowaniem projektów w zasadzie, znika potrzeba, żeby je tworzyć osobno, bo Product Owner prawdopodobnie, jeśli jest to wymagane w danym przedsięwzięciu, ma jakiś pomysł, mocno on będzie odzwierciedlony w Backlogu, być może w jakiejś pomocniczej road mapie rozwoju produktu. No i tutaj tworzenie jakiegoś dodatkowego, szczegółowego harmonogramu jest zupełnie zbędne, albo jest zdublowaną pracą, albo jest jakimś alternatywnym obiegiem informacji, który nie do końca pasuje na tym, co faktycznie zespół wytworzył.

Jacek: Komentując to, co mówisz, to co myślę, że warto dodać, że jakby istnieje świat, w którym te odpowiedzialności, o których powiedziałeś, można je rozłożyć na role, które występują domyślnie w Scrumie. Z drugiej strony, część z tych aktywności, które w dzisiejszym świecie wydają nam się absolutnie niezbędne, mogą się okazać, że nie są tak potrzebne jak nam się wydawało. Jeżeli na przykład przeniesiemy trochę bardziej naszą optykę, tak jak powiedziałeś, na działający produkt, na przyrost, na dyskusję o tym, co faktycznie mamy, a trochę mniej będziemy się skupiać na wszelkiego rodzaju zestawieniach, tabelkach, kolorach, które jak wiemy, najczęściej papier przyjmuje wszystko i o wiele trudniej jest z mojej perspektywy rozmawiać o faktycznym stanie rzeczy no, jeżeli rozmawiamy o jakichś tam papierowych artefaktach. Zupełnie inne rozmowy są, kiedy mamy żywy produkt, żywą usługę i wtedy możemy o wiele lepsze, kontekstowe pytania zadać, no, jeżeli mamy przed oczami to, czego konkretny produkt, czy projekt dotyczy.

Kuba: Z możliwych pułapek pełnienia roli PM-a, to nie są wszystkie w tym kontentym układzie, ale one będą bardziej wyraziste w następnych częściach, więc przejdziemy teraz do drugiego możliwego przypadku, który uwypukla trochę inny problem z funkcjonowaniem roli Project Managera. Przypomnę, że ten drugi przypadek to sytuacja, gdy Project Manager jest ustawiony w organizacji na równi z Product Ownerem i Scrum Masterem. Nie jest nadrzędny, Product Owner nie musi do niego, do PM-a raportować, czy jakoś tak czuć się zobowiązany, ale jednocześnie ta osoba w organizacji funkcjonuje. Tutaj ja myślę, że tak trochę zarysuję możliwe lub całkiem realna hipoteza jest w tym, że to jest jakaś pozostałość po dotychczasowych procesach, po dotychczasowym rozumieniu jak tego zarządza się organizacją i projektami w tej organizacji, w toku jakiejś kolejnej zmiany zwinnej. No i kiedyś byli PM-i, kiedyś nawet sprawdzali się PM-i w takim podejściu bardziej tradycyjnym, albo mniej zwinnym, jakkolwiek to ująć. Teraz powołaliśmy Product Ownera, chcemy, żeby robił product ownerstwo. Powołaliśmy Scrum Mastera, chcemy, żeby robił scrum masterstwo, no ale został nam Project Manager. Być może jest, bo wymagają tego jakieś procesy. Być może jest, bo mamy fajnych ludzi i nie chcemy ich stracić. Później gdzie tu zagrożenie? Jest duże zagrożenie tego, że zakresy obowiązków tych poszczególnych ról mogą na siebie  bardzo mocno wpływać. Zwłaszcza Product Owner decydujący o zmianach, decydujący o zmianie priorytetu, ustalający trochę inne cele Sprintu ze Sprintu na Sprint, na bazie feedbacku, który dostaje. Może bardzo mieszać w tym, jakie są plany projektowe. PM może mieć ochotę na dostęp do zespołu. W zespole scrumowym nie zawsze jest to potrzebne, więc wchodzi w jakiś naturalny konflikt ze Scrum Masterem, który gdzieś tam wyprasza tę osobę z jakichś tam wydarzeń albo przymoderowuje, żeby nie wpływała na zespół. I tak się nagle okazuje, że wszyscy chcą dobrze, że wszyscy są profesjonalistami w swoim fachu, a ciągle iskrzy, ciągle coś nie gra. Jeśli faktycznie idzie coś nie tak w projekcie, to PM patrzy na PO, PO patrzy na Scrum Mastera, Scrum Master się zastanawia, czy może szturchnąć PM-a. I tak naprawdę mamy przypadek jak z przysłowia: „Gdzie kucharek sześć…”, mamy trzy role, z których dwie są w Scrumie bardzo jasno opisane. Ta trzecia jest bardziej napływowa z organizacji i się wszystko rozmywa.

Jacek: No i ja myślę, że tutaj ten konflikt taki decyzyjny, to jest najpoważniejszy problem związany z tą konfiguracją, gdzie myślę, że to może zarówno wypływać z jakichś starych naleciałości czy ustaleń organizacyjnych, że na przykład, to Project Manager ma ostatnie zdanie. Z drugiej strony może być także silny Product Owner, dobrze czujący produkt, może mieć ochotę przejąć kontrolę i jakby zdominować na zasadzie przywództwa zespół. Niemniej jednak, jakby myślę sobie, że ta konfiguracja zawsze będzie konfiguracją nie optymalną, bo tak jak wspomniałeś ta jedna z ról, nazwijmy to – modelowo wykorzystanym Scrumie, po prostu rozkłada się i na zespół developerski i na Scrum Mastera i na Product Ownera, więc z mojej perspektywy to jest taki stan, w którym trochę zapraszamy do konfliktu. Z drugiej strony, definitywnie jest to stan, z mojej perspektywy, który wymaga jakiegoś konkretnego ruchu. Jakby te możliwości, jakie są, to myślę, że pokryjemy jeszcze później w odcinku, natomiast niewątpliwie mocno iskrząca konfiguracja. Widziałem takich przypadków kilka w trakcie swoich doświadczeń pracy z różnymi Klientami. Niestety nie widziałem tak skonfigurowanego setupu, który bym powiedział, że po prostu fajnie działa. Nie mam takich doświadczeń.

Kuba: Tu warto trochę empatii, czy naszego wyrazu naszej sympatii w stronę Ciebie słuchaczu – jeśli jesteś w takiej sytuacji. Zdajemy sobie też doskonale sprawę z tego, że to często jest układ, który zrodził się po prostu w firmie. Ja jakbym miał hipotezę generować, to mi się najczęściej nasuwa to, że jednak Scrum – Scrumem, zwinność – zwinnością, ale chcemy mieć ten jeden, pół kontaktu. Chcemy mieć tego kogoś, kto nam w razie czego będzie pilnował, nadzorował, reagował. W razie czego gdzieś tam będzie umiał się zachować. Czasami to może być objaw braku zaufania, czy braku pełnego zrozumienia podejścia zwinnego, konkretnie frameworka scrumowego. Czasami niestety, i to też spotykam w takich głębszych rozmowach, to też jest odrobina braku wiary w tych konkretnych, powołanych ludzi. Zwłaszcza jeśli mamy jeszcze takie układy, że PO jest z biznesu, a PM jest z IT, albo z jakiegoś zaufanego zespołu project managerskiego. Niby wszyscy chcemy dobrze, ale każdy się jakoś zabezpiecza na tych swoich pozycjach, takich – mam wtyki w zespołach, mam wtyki w procesie, mam osoby, które w razie czego jednoosobowo będę ścigać. To ogólnie nie jest zdrowe. To jest szczególnie bardzo niezdrowe dla tych wszystkich, którzy w te układy są wtopieni. Jeśli mielibyśmy tutaj być konstruktywni, jeśli z jakichś powodów organizacyjnych, dokładnie w takim setupie tkwimy, zdecydowanie warto ustalić zakresy odpowiedzialności pomiędzy poszczególnymi osobami. Raczej wejść w tryb kooperacyjny z tymi rolami. Warto ustalić co jest czyje. Jak sobie pomagamy? Co jest czyje? Kto jest odpowiedzialny za przebieg tych spotkań? Kto jest odpowiedzialny za raportowanie? Te wszystkie zagadnienia, może się okazać, że dla takiego PM-a nie zostanie tak dużo pracy, ale lepiej po prostu ustąpić z tych obszarów, które generują konflikty i się zgodzić na jakieś formy komunikacji informacji niż na siłę udowadniać, że jest się bardzo potrzebny. Moim zdaniem to w dłuższym okresie wpływa negatywnie na komfort pracy i taką satysfakcję z wykonywanych działań w tym podejściu zwinnym. Może z tego powodu też później, w ogóle bardzo możemy się zrazić do zwinności, jako idei, nawet jeśli dzisiaj jej sprzyjamy.

Jacek: Trzecia konfiguracja, o której chcieliśmy opowiedzieć, to konfiguracja, w której w zespole scrumowym mamy Project Managera i jednocześnie nie występuje ani rola Product Ownera, ani rola Scrum Mastera. Czyli mówimy o takiej sytuacji, w której Project Manager wchodzi w obie te role, można powiedzieć jednocześnie. Myślę sobie, że można nazwać tę sytuację, że to jest taka sytuacja z nadzieją, taka sytuacja rozwojowa. Natomiast oczywiście nie jest to idealna konfiguracja, z kilku powodów. Myślę, że pierwszy najważniejszy powód jest taki, że ja patrzę na rolę Product Owner, przede wszystkim na rolę Product Ownera, że to jest taka praca no raczej na cały etat. Zwykle tej pracy jest sporo. Jeśli myślimy w szczególności o Product Ownerze, jako o takiej osobie, która odpowiada za produkt. Czyli jeżeli nam dojdą również odpowiedzialności produktowe, no to zwykle jak pracuję z tak funkcjonującymi Product Ownerami, no to tam jest raczej dyskusja, czego dzisiaj nie zrobię, niż ile przerw kawowych sobie dołożę. Po prostu tej pracy jest więcej zwykle, niż i pomysłów i czasu. Tak więc, no już jakby z tej perspektywy patrząc, jeżeli ja mam być i Product Ownerem i jeszcze mieć czas na pracę Scrum Mastera – i tutaj przypominam, to jest praca i z zespołem i z Product Ownerem i z organizacją, no to po prostu robi się ciasno. To jest jakby z mojej perspektywy pierwsza pułapka. Druga pułapka, czy drugi problem jest taki, że w praktyce zwykle obserwuję, że dosyć ciężko się żongluje tymi czapkami. Tutaj de facto mamy trzy czapki. Dosłownie ostatnio pracowałem z Klientem, który miał taką konfigurację. Zarówno zespół do końca nie wie, w której czapce się teraz PM wypowiada, czy mówi jako Project Manager, czy mówi jako Product Owner, czy mówi jako Scrum Master. Z drugiej strony, to też jest mało komfortowa sytuacja dla samego Project Managera, który czasem strukturalnie organizacja oczekuje, że on będzie za pewne rzeczy odpowiadał. Z drugiej strony, może chciałby do tego podejść trochę bardziej, na przykład wykorzystując samoorganizację. No i tak trochę między młotem i kowadłem. Tak więc rozwojowa sytuacja, bo myślę, że tutaj możemy i zarówno i kierować się bardziej w taką rolę bycia Product Ownerem, albo w rolę bycia Scrum Masterem. Natomiast, żeby też, jakby pokazać pełny obraz, to widziałem sytuacje, w których Product Owner wchodzi w rolę Scrum Mastera na takiej zasadzie, że po prostu organizacja na ten moment, na dzisiaj nie jest w stanie albo dostarczyć kogoś z tymi kompetencjami, albo nie ma chętnych osób w zespole. Natomiast to jest sytuacja bardziej komfortowa, no bo odpada nam rola PM-a. Jeżeli mówimy o konfiguracji, że to jest PO i SM i jeszcze PM, to z mojej perspektywy, to brzmi jak kłopoty.

Kuba: Wspomniałeś o tej kwestii łączenia roli Product Ownera i Scrum Mastera. Tutaj nie będę powtarzał idei tych czapek. To faktycznie jest bardzo kłopotliwe. Jak dołożę wątek tej nadziei, o której wspomniałeś, tak go może mocniej rozbuduję, że to jest dosyć popularny scenariusz uruchomiania podejścia zwinnego w danej organizacji, że istnieje struktura bardzo konkretnie projektowa. Mamy Project Managera, mamy zespół. Wielu sytuacji, które znam osobiście i sytuacji, o których słyszałem od dobrych znajomych, no to Project Manager może bardzo wyraźnie wprowadzić zasadę zwinnego podejścia, czy uzwinnić, czy nawet konkretnie uruchomić wykorzystywanie podejścia scrumowego. Tylko musi sobie wtedy dawać zmianę, że ta zmiana między innymi będzie dotyczyć również zmiany swojej własnej, czy to roli, czy postawy, czy podejścia do tego jak działamy. Czyli dobre początki, uruchomienie konkretnych praktyk. Na przykład praca w Sprincie, na przykład Daily Scrum, na przykład przyrostowość do Sprint, Sprint Rewiev. To wszystko w zasadzie da się uruchomić w projekcie i może być fajnie zainspirowane przez Project Managera. Natomiast warto wtedy z tyłu głowy mieć, że jeśli chcielibyśmy właśnie wejść w podejście zwinne trochę jeszcze mocniej, to prędzej czy później dotrzemy po prostu do naturalnych granic swojej własnej osoby pełniącej za dużo ról na raz. No i wtedy fajnie jest mieć jakiś pomysł, jakiś plan. Może wspierającego nas przełożonego wyższego stopnia. Może jeśli jesteśmy tutaj w software housie, to może Klient ma ochotę wejść w rolę Product Ownera, zwłaszcza jeśli mamy jakieś takie rzeczywiste case’y, które pokazują – zobaczcie, nie podjęliśmy pewnych decyzji, ponieważ za późno, albo za mało z Wami rozmawialiśmy. A jakbyście tak byli na każdym naszym planowaniu, to może lepiej dobieralibyśmy priorytety i rozwiązania. Tak kroczek po kroczku, przesuwając trochę granice, pokazując bardzo realne case’y, zwłaszcza jeśli mamy trochę więcej czasu, jeśli to jest jakiś większy projekt. Jesteśmy bardzo fajnie, tak naturalnie, bardzo organicznie to rozszerzyć i wtedy musimy mieć pewność i jakby taki spokój ducha. Pewność siebie, że zmiana, którą inicjujemy, którą inspirujemy, będzie również nas dotyczyć i bądźmy wtedy gotowi, że trzeba będzie się określić, oddać jakiś kawałek odpowiedzialności, kogoś skołczować, z czegoś zrezygnować, a być może nawet po prostu zacząć nazywać się jakoś inaczej.

Jacek: Tutaj oboje z Kubą mamy w pewnym sensie podobne doświadczenia. Oboje byliśmy w rolach project managerskich. Mój przypadek, to jest akurat przejście z roli Project Managera do roli Scrum Mastera. Mówię to dlatego, że to jest rozwojowa konfiguracja, przy czym, warto pamiętać, że jest sporo do nadrobienia, czy sporo do nauczenia się, jeżeli chcemy przejść czysto z kompetencji project managerski na którąś z tych dwóch ról scrumowych. No bo z jednej strony, jeżeli myślimy o rozwoju w kierunku roli Product Ownera, no to cały Product Management, olbrzymi obszar wiedzy do opanowania. Powiedziałbym, że Scrum Master może trochę bliżej, trochę prościej, ale to też wszystko kwestia jak bardzo chcemy zanurkować w zwinność. Jeżeli oczekujemy od Scrum Mastera, że to ma być faktycznie taki mistrz Scruma, czyli osoba, która bardzo dobrze rozumie zwinność, no to również są książki, podcasty, prezentacje i doświadczenia, które trzeba przeczytać. Odbyć bądź doświadczyć. Tak więc nie jest to na pewno taki wytrych, w sensie – zmieniam tylko z PM na PO i rzeczy się dzieją. Sam wiem ze swoich doświadczeń, że jest sporo pracy, chociażby na poziomie nawyków. W szczególności oduczania się pewnych nawyków, no, a jednocześnie też uczenia się jak sobie radzić z problemami w trochę innym środowisku, na przykład dając większą przestrzeń odpowiedzialności zespołowi developerskiemu.

Kuba: Jak mówisz o książkach i podcastach, to ja bym jeszcze dorzucił posiadanie mentora. Bo też jak mówisz, ja też byłem PM-em, który wszedł w rolę Scrum Mastera. Zawsze, jak myślałem o sobie – o PM-ie, to myślałem, że jestem takim miękkim PM-em, takim przyjaznym, takim fajnym, takim nierealizującym twardego Waterfalla, nawet jeśli procedury tego nakazywały. Potem mój mentor mi pokazał, że Retro odbyło się absolutnie pod moje dyktando, pod moją absolutną kontrolą. Samoorganizacji za dużo się nie dopatrzył w tym jak prowadzę zespół, bo de facto prowadzę zespół, jeśli myślę o sobie jako Scrum Master. Więc tutaj jest spora droga, to każdy sam musi ją przejść. Bądźmy na to czujni i miejmy co do tego pokorę. Taka postawa, że PM to jak Scrum Master, więc mogę swoje stare narzędzia pm-owe użyć do prowadzenia, czy jakkolwiek nazwiemy to, co robi Scrum Master z zespołem. Możemy niestety wpaść w taką pułapkę, że ekstra polowaliśmy ten sposób postępowania i nie widać żadnej różnicy. To, że ten Scrum jakoś tam nie postępuje głębiej, może być powiązany również z tym, że my czegoś nie dostrzegamy. No i tutaj warto poszukać mentora, jeśli firmę na to stać, to najlepiej jakiegoś doświadczonego agile’owca, czy to w postaci kolegi Scrum Mastera, Agile Coacha, czy to w postaci zewnętrznego konsultanta. Jeśli nie ma takich opcji, zawsze też jest opcja na spotkania społeczności, jakieś grupy lokalne. Znajdzie się ktoś, kto jest w stanie wejść z nami w relacje i trochę nam podpowiedzieć. Kuba: Jak mówisz o książkach i podcastach, to ja bym jeszcze dorzucił posiadanie mentora. Bo też jak mówisz, ja też byłem PM-em, który wszedł w rolę Scrum Mastera. Zawsze, jak myślałem o sobie – o PM-ie, to myślałem, że jestem takim miękkim PM-em, takim przyjaznym, takim fajnym, takim nierealizującym twardego Waterfalla, nawet jeśli procedury tego nakazywały. Potem mój mentor mi pokazał, że Retro odbyło się absolutnie pod moje dyktando, pod moją absolutną kontrolą. Samoorganizacji za dużo się nie dopatrzył w tym jak prowadzę zespół, bo de facto prowadzę zespół, jeśli myślę o sobie jako Scrum Master. Więc tutaj jest spora droga, to każdy sam musi ją przejść. Bądźmy na to czujni i miejmy co do tego pokorę. Taka postawa, że PM to jak Scrum Master, więc mogę swoje stare narzędzia pm-owe użyć do prowadzenia, czy jakkolwiek nazwiemy to, co robi Scrum Master z zespołem. Możemy niestety wpaść w taką pułapkę, że ekstra polowaliśmy ten sposób postępowania i nie widać żadnej różnicy. To, że ten Scrum jakoś tam nie postępuje głębiej, może być powiązany również z tym, że my czegoś nie dostrzegamy. No i tutaj warto poszukać mentora, jeśli firmę na to stać, to najlepiej jakiegoś doświadczonego agile’owca, czy to w postaci kolegi Scrum Mastera, Agile Coacha, czy to w postaci zewnętrznego konsultanta. Jeśli nie ma takich opcji, zawsze też jest opcja na spotkania społeczności, jakieś grupy lokalne. Znajdzie się ktoś, kto jest w stanie wejść z nami w relacje i trochę nam podpowiedzieć.

Jacek: Czyli, jak słucham, jak o tym opowiadasz, to mi to brzmi, że mamy po prostu osoby o pewnych kompetencjach i te kompetencje, z tego, co powiedziałeś, potrafi bardzo dobrze wykorzystać. Co więcej, jest taka potrzeba w tym przedsięwzięciu, żeby takie kompetencje mieć. Natomiast, to co jest istotne i tu bym podkreślił, to jest ta równość w stosunku do pozostałych osób w zespole. Normalny członek, członkini zespołu developerskiego. Nadal, jeśli chodzi o to, czym się zajmujemy na poziomie produktu, odpowiada Product Owner i tutaj jakby nie ma żadnego kursu kolizyjnego, no bo po prostu część zadań, często też pewnie w relacji w jakiejś tam relacji ze światem zewnętrznym, po prostu przejmuje ta osoba, która ma po prostu umiejętności, żeby takimi tematami zarządzać. Zgodzę się, że jest to wariant z mojej perspektywy z ostatnich dziesięciu lat pracy w zwinnych środowiskach, bardzo rzadko występujący w praktyce.

Kuba: To może przejdźmy do wariantu ostatniego. Tutaj prawdopodobnie temperatura emocji trochę wzrośnie. Specjalnie chcieliśmy zarysować te poprzednie sytuacje, żeby teraz poeksplorować wątek braku funkcjonowania w Scrumie Project Managera w ogóle. Wokół zespołu, ani w zespole tego Project Managera nie ma.

Jacek: Dokładnie. Konfiguracja jest wtedy prosta na poziomie zespołu. Czyli zespół developerski, Scrum Master i Product Owner. Brak, tak porównując to powiedzmy z tym drugim przypadkiem, czy pierwszym, brak jakiejś tam formy proxy pomiędzy zespołem, a organizacją. Zwykle i tak wykształca się jakaś, nazwijmy to platforma, czy tworzy się jakiś taki zespół, który jest w stanie odpowiedzieć na pytania związane z tym, gdzie jesteśmy z tematami. No ale najczęściej, to co obserwuję w takiej konfiguracji, no to jest po prostu tworzy się jakaś tam społeczność produktowa, albo prędzej jakiś departament, czy dział produktowy i po prostu naturalne jest, że jeżeli chcesz się dowiedzieć, gdzie jesteśmy z produktami, no to raczej szukasz tej odpowiedzi w dziale produktowym, który tak na mój zdrowy rozsądek, no najlepiej wie, gdzie są z produktami. Przynajmniej tego bym oczekiwał. Mówisz tak, że podgrzewaliśmy atmosferę, ale to nie jest jakiś taki wariant rzadki z mojej perspektywy. W sensie wiele firm, z którymi pracowałem, bądź pracuję, świadomie idą w ten wariant. Czyli chcemy konkretnie, pracować zwinnie z różnych powodów, z różnych powodów też wybieramy konkretnie Scruma. No i jest ok dla tej organizacji, no, że troszeczkę zmieni nam się sposób raportowania, czy sposób patrzenia na całe portfolio inicjatyw, które mamy w organizacji. Poprzez sensowne poustawianie i na poziomie osób i na poziomie kompetencji i na poziomie też pewnych ustaleń, kto, za co odpowiada, a za co nie w organizacji, jesteśmy w stanie doprowadzić do sytuacji, w której jest spora przejrzystość, wiadomo kto, czym się zajmuje. Wiadomo, co realizujemy, wiadomo na, kiedy będzie. Wiadomo, jakie są ryzyka, i tak dalej. Czyli de facto, jesteśmy w stanie tak poukładać konfigurację, że wszystkie te rzeczy najlepsze, które byśmy chcieli z dobrego project managementu, jesteśmy w stanie pozyskać, po prostu stosując sensowną konfigurację ról i umocowania osób w strukturze, używając – nazwijmy to czystej zwinności.

Kuba: No dobrze, to powiedzieliśmy o czterech możliwych przypadkach funkcjonowania PM-a w setupach scrumowych. Daliśmy też swoją ocenę, co sądzimy o tych układach. Wspomniałeś Jacek też o tej sytuacji braku PM-a w ogóle w zespole scrumowym. Ale ostatnią część odcinka chcielibyśmy poświęcić do tych z naszych słuchaczy, którzy są w tej sytuacji, że są Project Managerem. Słuchając naszego podcastu prawdopodobnie, co najmniej lekko interesują się zwinnością, a może nawet bardzo mocno w nią wierzą. No i co w takiej sytuacji zrobić? Zwłaszcza ten scenariusz usuwania PM-a, albo te scenariusze, w których PM jest w dużym konflikcie z zespołem scrumowym. One wszystkie są w pewnym sensie trochę niepokojące, bo one sugerują, że być może jesteśmy w ścieżce kariery, która albo nie ma wielkiej przyszłości, albo wręcz jest przeszkodą czy takim ogranicznikiem zwinności w tej firmie. No i tutaj mamy kilka porad, myślę, że zrzucimy je, tak trochę wysypiemy jak z rękawa. Myślę, że już sporo powiedzieliśmy o tym przypadku gdy to PM inicjuje zwinność. To jest bardzo fajna sytuacja, z której PM może do organizacji tę zwinność wprowadzać. Jeśli jest ok z tym, jest jakby spokojny, co do tego, że być może moja własna rola będzie się zmieniać, no to PM, inicjuje zwinność. To jest bardzo fajna sytuacja, z której PM może do organizacji tę zwinność wprowadzać. Jeśli jest ok z tym, jest jakby spokojny, co do tego, że być może moja własna rola będzie się zmieniać, no to PM, który wprowadza zwinność do swojej organizacji, być może jest świetnym kandydatem na swego rodzaju Scrum Mastera. Takiego inicjalnego Scrum Mastera. W ogóle całą firmę uczy zwinności, propaguje tą zwinność, czyli te wszystkie odpowiedzialności scrum masterskie związane z organizacją. No i jeśli mamy ochotę, jeśli dobrze nam to wychodzi, jeśli też trochę pracujemy nad sobą, o czym już wspominaliśmy, no to możemy być pierwszym Scrum Masterem w naszej firmie. Możemy zainicjować cały nurt, przekonać kolejne osoby. Być może zmieniając trochę też kolejne zespoły, kolejne projekty, będziemy w stanie poruszyć z podstaw wszystko to, jak to do tej pory w firmie wyglądało. Więc tutaj pierwsza myśl dla zwinnego PM-a, jaka mi przychodzi do głowy – zmieniaj swoją organizację. Wpływaj na nią, bądź gotów też, czy gotowa, że zmienić się będziesz musiał lub musiała też samemu, ale jest spora szansa na to, że tak naprawdę wcale nie jesteś w konflikcie, albo wielką przeszkodą zwinności. Wręcz możesz ją bardzo fajnie nakręcać i rozgrzewać czy przesuwać.

Jacek: Rozumiem, że to było Kuba najbardziej wysokopoziomowe. Ja chyba bym to doprecyzował o tyle, że to może być konkretnie wejście w rolę Scrum Mastera. Czyli to jest moja historia, Twoja historia. Zresztą opowiadaliśmy o tym, w którymś z odcinków wcześniej. No i sam znam, no oprócz nas, całą masę osób, które zajmowały się project managementem i na skutek tego, że organizacja zaczynały szukać innych sposobów realizowania inicjatyw produktów usług, po prostu, bądź same zgłaszały się, bądź dostawały propozycję, albo pytanie, czy nie chciałyby wejść w rolę Scrum Mastera. Takim całkiem naturalnym krokiem dla osób, które oczywiście też czują się, bo to też wymaga z mojej perspektywy pewnego takiego, po prostu czucia roli Scrum Mastera. Tam jest trochę mniej kontroli z mojej perspektywy niż w przypadku pracy jako Project Manager, to uważam, że jest to bardzo fajna i ciekawa ścieżka. Co więcej, te wszystkie doświadczenia Project Managerskie, to nie jest tak, że my je wyrzucamy do kosza i wyrzucamy z białą kartką. Z mojej perspektywy te doświadczenia Project Managerskie to jest aset, to jest coś, co dobrze mieć w swojej historii, chociażby po to, żeby po prostu mieć troszeczkę szersze spojrzenie na, czy wytwarzanie produktów, czy na realizowanie projektów. Ale także, żeby lepiej rozumieć osoby, które żyją w świecie project managementu i po prostu używają tych pojęć. Tak więc takie wspólne zrozumienie i też takie dogadywanie się na poziomie pewnych konkretnych pojęć, no po prostu pomagają w pracy Scrum Mastera.

Kuba: Jest też alternatywna ścieżka, jeśli jesteśmy Project Managerem, który o wiele bardziej czuje się merytoryczny w tym, co jest realizowane przez zespół. Jeśli dobrze się czujemy w domenie biznesowej, jeśli dobrze wychodzi nam też taki temat – nazwijmy go polityką, relacją, zarządzanie interesariuszami, może też zarządzanie trochę zakresem projektu. To możliwe, że mamy spore podstawy do tego, żeby wejść w rolę Product Ownera. Pewnie, tak jak wspominałeś, może trzeba będzie się troszkę poduczyć w tej teorii zarządzania produktem. Być może lepiej się umocować też w tym, co jest biznesem danej organizacji, czy danego zespołu produktowego. Ale znamy też takie przypadki, że PM był ciekawym i mocnym kandydatem do roli Product Ownera, zwłaszcza jeśli to jest osoba, która w organizacji ma jakąś zbudowaną wiarygodność, ma posłuch. Ma też po swojej stronie jakieś narzędzia związane i z miękkim zarządzaniem i z jakimiś takimi twardymi narzędziami – planowania, zarządzania, orientowania się co jest ważne, co jest mniej ważne. To wszystko powoduje, że być może jesteśmy świetnymi kandydatami na Product Ownera. Musimy pewnie trochę ponadrabiać, ale mamy jakieś mocne strony, które już od pierwszego dnia w tej roli nam się świetnie sprawdzą.

Jacek: Ja myślę, że tutaj, no oboje mamy też wspólne doświadczenia i znamy przypadki, gdzie z roli Project Managera osoby szły w rolę Product Ownera, żeby ostatecznie stać się współwłaścicielem jakichś konkretnych biznesów. No czyli tak absolutnie corowo zajmować się aspektami biznesowymi. Też uważam, że to jest bardzo interesująca ścieżka. W szczególności dla osób, które no po prostu dobrze się czują w rozmowach o biznesie. Interesuje ich to, śledzą swoje otoczenie, interesują się nowinkami, produktami, modelami biznesowymi. Czyli wszystkim tym, co jest po prostu chlebem codziennym każdego biznesowca.

Kuba: Jeśli jednak bardzo lubimy zarządzanie projektami, nie chcemy wychodzić z tej roli, chcemy się w tym specjalizować, w niejednej organizacji jest spora szansa na to, że project management jako zawód, jako profesja – pozostanie. Tutaj jesteśmy świadkami również tych sytuacji, że na przykład mocnej transformacji roli PM-a włącznie z być może zaoraniem w ogóle tej roli w zespołach takich czysto scrumowych, wytwórczych. Oprócz tego mamy też sytuację, że po prostu jest grupa projektów, które scrumowe nie będą, które zawsze będą realizowane zarządzaniem przez konkretnego zawodowego PM-a. Tak jak wspominam, w dużych organizacjach prawdopodobnie jest to bardzo realny scenariusz, że będziemy realizować takie projekty. Być może trzeba się pogodzić z tym, że te projekty, które bardzo dobrze do Scruma pasują, nie będą miały PM-a. Czyli jeśli się fajnie czujemy w zespołach wytwarzających oprogramowanie, to spodziewam się, że takie zespoły, które wytwarzają oprogramowanie, raczej dosyć mocno pasują do podejścia scrumowego. Te inne obszary organizacji, o których wspominam, w których będzie project management, to mogą być jakieś projekty organizacyjne, jakieś takieś biznesowe, procesowe, związane ze zmianami w firmie, ale niekoniecznie z rzeczami stricte związanymi z softwarem. Jeśli w IT, to być może jakieś rzeczy hardware’owe, być może jakieś rzeczy też znowu organizacyjne, procesowe. Te projekty mogą nie mieć takiego charakteru dotychczasowego – jeśli jesteś w tej sytuacji, ale jest całkiem spora szansa, że Twoje kompetencje i Twoja profesja i Twój profesjonalizm jeż już cały czas potrzebny, tylko w innych miejscach w firmie.

Jacek: Myślę, że taką domykającą opcją, którą też warto wymienić, to jest kontynuowanie pracy jako Project Manager w organizacji, która po prostu ma przestrzeń, żeby po prostu taką rolę pełnić. Myślę, że to jest też sensowna opcja dla osób, które lubią tę rolę i chcą zarządzać projektami i w tym kierunku się rozwijają, a jednocześnie widzą, że ich organizacja, no zaczyna rezygnować z tej roli. Pojawia się coraz więcej Product Ownerów i ta rola Project Managera, no ma trochę jakby mniej okazji do tego, żeby się wykazać. Jest sporo organizacji, w których project management, nazwijmy to, ma się dobrze. Ja sam w szczególności, jak kiedyś myślałem o sobie, jako o Project Managerze, to mnie personalnie ciągnęło w jakieś takie obszary związane z budownictwem. No i to są takie rzeczy, gdzie z mojej perspektywy ta zwinność jakby albo nie doszła, a jak dojdzie to jeszcze chwilę. W sensie, pomijając cały trend zwinności poza IT. Natomiast, są to takie rynki – myślę sobie, gdzie product management jeszcze przez długi okres czasu będzie po prostu domyślnym sposobem zarządzania projektami, inicjatywami. No i jakby nie widzę przeszkód w tym, żeby sobie takiej organizacji poszukać, jeżeli czujemy, że w naszej organizacji kończy się przestrzeń na to, żeby rozwijać się w tej konkretnej roli.

Kuba: Jeśli słuchasz tego odcinka, bo zainteresował Cię temat project managementu i to jest pierwszy odcinek naszego podcastu, to spośród wszystkich nagranych odcinków bardzo mocno rekomendujemy dwa inne, które poruszają tematy zwinnych projektów. Jest odcinek 36. – „Zwinne projekty i produkty”, gdzie właśnie dywagujemy o tym, czym się różnią projekty od produktów i jak uzyskać zwinność w tych dwóch podejściach. Znajdziesz ten odcinek pod adresem: porzadnyagile.pl/36. Drugi odcinek, też bardzo mocno kontekstowo powiązany z zarządzaniem projektami to – „Praca na termin w Agile”. Jak się zachować, jeśli mamy deadline, jeśli mamy sztywny termin, którego trzeba dochować i czy to jest możliwe w agile’u i czy to jest z podejściem zwinnym kompatybilne. Ten odcinek – 23. znajdziesz pod adresem porzadnyagile.pl/23

Jacek: Standardowo, wszystkie notatki do tego odcinka wraz z tymi linkami, o których Kuba powiedział przed chwilą, zapis audio, zapis wideo, a także transkrypcję tego odcinka, znajdziesz na stronie porzadnyagile.pl/46

Kuba: Jeżeli znasz kogoś, dla kogo ten odcinek może być wartościowy, podeślij mu go. Podziel się na mediach społecznościowych, wyślij mailem lub zarekomenduj. Myślę, że tutaj zebraliśmy dużo wartościowej treści na temat roli Project Managera w podejściu zwinnym i konkretnie w Scrumie. Może to być, albo wartościową inspiracją, albo poukładaniem pewnego tematu. Będzie nam bardzo miło, jeśli będziemy propagowali te treści do coraz szerszej grupy odbiorców.

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.