Kojarzą się one jednak raczej z filozoficznymi dywagacjami niż z opracowywaniem karty projektu, czego większość organizacji wolałaby uniknąć. Nie dziwi więc wymóg szybkiego udzielenia odpowiedzi – takich, które zapewnią Project Managerowi oraz interesariuszom wrażenie stabilnej perspektywy. W konsekwencji diagram Gantta kreśli iluzję komfortu, składając ryzykowną obietnicę braku zmian. Zła wiadomość jest taka, że komfort w zarządzaniu projektami nie jest dobrym doradcą. Kolejna zła wiadomość jest taka, że weryfikacja obietnicy w zderzeniu z rzeczywistością często przypomina rozczarowujący moment odpakowywania prezentów pod choinką. Wszak w dokumentacji była mowa o czymś innym… Dlaczego trzeba zwolnić Project Managera z pełnienia roli świętego Mikołaja? Po pierwsze, Scrum udowadnia, że to, czego należy się obawiać, to nie jest brak niektórych odpowiedzi, ale przekonanie, że znamy odpowiedzi na wszystkie pytania. Po drugie, Scrum nie potrzebuje każdego Project Managera. Scrum potrzebuje zwinnego Project Managera.

Super niemoc

Umiejętność czytania w myślach, przewidywania przyszłości czy przemieniania dyni w karocę stanowią mile widziany zbiór predyspozycji, o którym można przeczytać między wierszami typowego ogłoszenia o pracę dla Project Managera. Wspomniane wymagania tworzą wyjątkową rolę superbohatera, dodatkowo wzmocnioną przeświadczeniem o niezależnej odpowiedzialności za powodzenie projektu. Ilu Project Managerów wpada w pułapkę tego schematu? Wystarczająco wielu, by ryzyko dostarczenia 45% zbędnych funkcjonalności stało się przekleństwem większości projektów. Które zatem wyobrażenie o supermocy jest najbardziej zgubne dla Project Managera? W wielu przypadkach będzie nim wyłączna odpowiedzialność za projekt. Przykładem niech będzie globalna organizacja, w której rola Product Ownera jest rozłożona na grupę interesariuszy pracujących w różnych lokalizacjach. Przyjmijmy, że ani różnica stref czasowych, ani fakt, iż dany projekt jest tylko jednym z wielu mniejszych obszarów strategicznych, nie powodują wyjątkowego zaangażowania ani uwagi interesariuszy. Co więcej, interesariusze oczekują od Project Managera jedynie raportów z Jiry o postępach w zamykaniu User Stories.  Project Manager ma w tej sytuacji dwa wyjścia. Ciemna strona mocy podpowiada, by nie wychylać się, próbując dołączyć przynajmniej niektórych z interesariuszy do spotkań takich jak Review czy Demo. Pytania, czy komentarze interesariuszy mogłyby w konsekwencji zburzyć w kolejnych iteracjach wygląd – stabilnego jak dotąd – Burndown Chart. Po co wprowadzać zamieszanie? Jasna strona mocy jednak wie, że nie należy ufać jednostajnym wykresom ani poprzestawać na kurtuazyjnej wymianie maili. Jeżeli Product Owner nie jest zaangażowany i nie mówi „sprawdzam!” – zespół nigdy nie otrzymuje feedbacku ani nie jest traktowany jako partner do rozmowy. W rezultacie blokuje się cel, jakim jest Continuous Improvement w projekcie. Nie ma bowiem miejsca na usprawnienia bez fermentu. O wiele mniej kosztuje bowiem wycofanie się z realizacji jakiejś funkcjonalności po dwóch tygodniach niż po siedmiu miesiącach. Jeżeli Project Manager pozostaje w strefie komfortu – tracą na tym produkt oraz zespół

Wiem, że nic nie wiem

Gdyby zechcieć sportretować zależności i specyfikę ról w projekcie scrumowym – na pierwszym planie znalazłby się produkt. W jego kierunku patrzą zespół projektowy oraz Product Owner. Z kolei Scrum Master patrzy na zespół i na Product Ownera. W odległym tle kadru ledwie widoczny jest Project Manager, który w chwili naciśnięcia spustu migawki niespodziewanie wbiega na pierwszy plan. Praktyka podpowiada, iż niejeden zespół scrumowy może pochwalić się albumem z serią nieudanych zdjęć dokumentujących codzienne próby współpracy z Project Managerem. Dlaczego menadżerski photobombing1 nie sprawdza się jako strategia budowania relacji Project Managera z zespołem scrumowym? Żeby odpowiedzieć na to pytanie należy zwrócić uwagę na dwie kwestie. Po pierwsze, Project Manager znajduje się poza kadrem projektu. Powodem może być skłonność do reaktywnych zachowań. Przykładem niech będzie sytuacja, w której Project Manager rzadko opuszcza swoje biurko w pracy. Właśnie sprawdza Sprint Backlog, a następnie udaje się z wątpliwościami i pytaniami do zespołu – w najgorszym wypadku pisze wiadomość – zaraz po tym jak zespół skończył swój Stand-up meeting, ale jeszcze nie wszyscy zdążyli zaktualizować backloga. Stand-up, Planning, Backlog Refinement, Review czy Demo są spotkaniami, dzięki którym Project Manager syty, a zespół cały. Po drugie, Project Manager powinien patrzeć w tym samym kierunku, co reszta: skupiając się na zespole i na produkcie. Do poprawnego funkcjonowania wskazanej optyki służą zarówno rytuały komunikacyjne Scruma, jak i narzędzia, takie jak Product Backlog. Burndown Chart nie stanowi jednak kompletnej opowieści o danej iteracji – dopiero informacje oraz komentarze od zespołu w czasie Review czy Demo dopełniają treści.  W konsekwencji „Chodź, słuchaj i pytaj” powinno stanowić regułę odnoszącą się do tego, w jakiej kolejności Project Manager powinien podejmować kroki by budować relację z zespołem, nie dezintegrując przy tym pracy w projekcie.

Błądzić jest rzeczą zespołową

Innowacyjność jest jednym z synonimów firmujących dobrze rozwijającą się organizację lub wyznaczających kierunek aspiracji biznesowych. Nikt jednak nie rodzi się w czepku innowacji ani nie dziedziczy jej w genach. Innowacyjność jest bowiem pochodną zderzenia ślepego założenia z głuchym eksperymentem. Oznacza przyzwolenie na kwestionowanie pewników i testowanie alternatyw. Jaka jest wartość innowacji? Wystarczy posłuchać Elona Muska2 . Co takiego jego zespół zrobił lepiej niż inne, że parę miesięcy temu cały świat usłyszał o zaawansowanym planie podróży i stworzenia cywilizacji na Marsie? Zaryzykuję stwierdzeniem, że kluczowym czynnikiem sukcesu była liczba prób i niepowodzeń w pracy zespołu. Czy jakikolwiek inny zespół byłby w stanie przygotować własną strategię stworzenia kolonii na jednej z planet układu słonecznego? Tak, jeśli zwinny Project Manager będzie współpracować z interesariuszami, żeby zapewnić środowisko przyjazne eksperymentom. Tylko dzięki konsekwentnej komunikacji o sensowności celów projektu oraz praktyce ustalanych rozwiązań zespół jest w stanie skonfrontować założenia z nieustannie dostarczaną funkcjonalnością produktu. Trudno sobie wyobrazić by zespoły Elona osiągnęły podobny etap pracując bez przyzwolenia na pomyłki, które w praktyce stanowią jeden z konstruktywnych sposobów osiągnięcia celu.

Argonauci projektów

Co łączy antropologa kultury opisującego życie mieszkańców na Trobriandach w 1916 roku z Project Managerem w 2016 roku? Więcej niż może się wydawać. Wystarczy porównać metody oraz narzędzia pracy obu stron, żeby zauważyć, że sto lat temu pionierzy antropologii kulturowej czerpali z praktyk, których syntezą jest dziś Agile. Bronisław Malinowski sformułował metodę badawczą, która wyparła wcześniej obowiązujący styl pracy. Malinowski udowodnił, że zrównoważone i zdystansowane zaangażowanie w rytm życia społeczności zamiast wyrywkowych i przypadkowych kontaktów oraz regularne „Go See” przynoszą najlepsze rezultaty i katalizują odkrycia, o których wcześniej nie miał pojęcia. Metoda obserwacji uczestniczącej została przeciwstawiona antropologii gabinetowej, która faworyzowała wyłączną pracę z tekstami i dokumentami, formułując niezweryfikowane teorie i oderwane od rzeczywistości założenia.  W każdym z waloryzowanych pozytywnie przykładów można odnotować rolę Project Managera jako umiarkowanego, acz ciekawego obserwatora zespołu. Takiego, który zniesie niewygody wspierania zespołu niż zaakceptuje iluzję komfortu. Dzięki takiej postawie zyskują zespół oraz produkt. Jakkolwiek trudno porównywać wyprawę na Trobriandy z podróżą na Marsa – można zgodzić się co do wspólnego mianownika. Niech będzie nim Agile Project Manager Manifesto, które bardziej ceni: Pytania od odpowiedzi Obserwację uczestniczącą od gabinetowej Konstruktywny ferment od strefy komfortu Próby i błędy od braku innowacji. 1. Sposób zepsucia fotografii (osobie lub rzeczy) poprzez nieoczekiwane pojawienie się w polu widzenia kamer, w momencie robienia zdjęcia. 2. Elon Musk na Międzynarodowym Kongresie Astronautycznym w Meksyku 27 września 2016 roku przedstawił plan stworzenia kolonii, a następnie całej cywilizacji na Marsie, wraz z międzyplanetarnym systemem transportowania ludzi i ładunku. Zdjęcie dokumentuje zniszczone kręgi dojrzewającego parmezanu – jedną z konsekwencji trzęsienia ziemi, jakie w 2012 r. nawiedziło północne Włochy. Szef kuchni Massimo Bottura uratował tysiąc kręgów parmezanu poprzez stworzenie interpretacji tradycyjnego przepisu na risotto cacio e pepe wykorzystującego parmezan po trzęsieniu ziemi. Do realizacji dania zwerbował lokalnych szefów kuchni, ratując jednocześnie sytuację ekonomiczną regionalnych wytwórców parmezanu.

Artykuł pochodzi z 15 numeru kwartalnika „Strefa PMI”.

Magdalena Baran – Antropolożka korporacji oraz praktyk metodyk Scrum i Large-Scale Scrum (LeSS). Obserwacje i komentarze publikuje na blogu: www.itisnotrocketscience.me