Project Manager w Scrum #1 — czy Scrum to metoda zarządzania projektami?

utwor­zone przez | Paź 25, 2017 | Blog, Scrum­pe­dia | 2 Komen­tarze

Jak dorosnę, zostanę PMem!

Kil­ka lat temu prowadz­iłem ser­ię szkoleń dla soft­ware house na Śląsku (Ślun­sku ?). Szkole­nie Scrum i nie tylko było skierowane do młodych ludzi, którzy zaczęli budować trzon firmy. Dzisi­aj opowiada­ją o zarządza­niu soft­ware house, o byciu lid­erem, o Agile; a wtedy byli jeszcze stu­den­ta­mi albo pisali mag­is­terkę. Klient zaży­czył sobie, żeby przed szkole­ni­a­mi przeprowadz­ić anki­etę zbier­a­jącą potrze­by szkole­niowe. Oprócz nud­nych, stan­dar­d­owych pytań potrzeb­nych HR do statystyk, wplotłem otwarte pytanie “Gdy­by wszys­tko było możli­we, to kim byś był ?”.

Byłem w ciężkim szoku, kiedy  w wynikach okaza­ło się, że przytłacza­ją­ca więk­szość napisała Project Man­agerem albo Kierown­ikiem Pro­jek­tów. Jed­na oso­ba napisała, że chci­ała by odwiedz­ić wszys­tkie kra­je świa­ta i pisać o tym na blogu.

Na szkole­niu zapy­tałem dlaczego aku­rat PM? Bo ma władzę, bo inni go słucha­ją usłysza­łem w odpowiedzi. Jeśli z tych pobudek ludzie wybier­a­ją taką a nie inną kari­erę, to nie może to się kończyć dobrze. Swo­ją drogą ciekawe jest, że anki­etowani nie widzieli negaty­wnych stron pra­cy PMa. Praw­dopodob­nie dlat­ego, że tak na prawdę nie uczest­niczyli w żad­nych spotka­ni­ach i nie widzieli tej oso­by na co dzień. Zro­biło się trochę dzi­wnie kiedy dowiedzieli się, że Scrum to nie jest ten sposób pra­cy, w którym jest PM, który wszys­tkim rządzi. Kiedy zrozu­mieli, że jako Zespół Devel­op­er­s­ki mają duży wpływ, cały pomysł zaczął im się podobać. Na szczęś­cie dzisi­aj te oso­by myślą zupełnie inaczej i doskonale odna­j­du­ją się w Scrum.

Zapraszam do serii postów na tem­at zarządza­nia pro­jek­ta­mi i roli Project Man­agera w kon­tekś­cie Scrum.

Product Development to nie Project Management

W meto­dach pro­mu­ją­cych rolę PMa w Agile, tak jak cho­ci­aż­by Agile PM wywodzą­cy się z DSDM Atern moż­na znaleźć mate­ri­ały, w których Scrum został pokazany jako jedynie meto­da wytwór­cza, na poziomie deliv­ery. A jak wiado­mo w pode­jś­ciu project man­age­ment, nad deliv­ery musi górować poważ­na metody­ka zarząd­cza. Scrum w tym tłu­macze­niu rysu­je się jako pewien sposób orga­ni­za­cji pra­cy devel­op­erów, którym PM musi i tak zarządzać. Niedawno ze swoi­mi pomysła­mi dołączył Prince2Agile, który też pro­ponu­je Prince2 po stare­mu a Agile np. Scrum w środ­ku. Wyda­je mi się, że celem tych metod jest udowod­nie­nie, że nadal może być po stare­mu, a Scrum to tylko taka zabawka dla zespołów IT. Jak już tak bard­zo chcą tego, to niech sobie mają. Byle tylko za dużo nie dzi­ało się bez udzi­ału PMa.

Czy naprawdę sami biznes i deweleop­erzy nie dal­i­by sobie rady?  Jest ktoś kto mówi co potrze­bu­je i ktoś wykonu­je pracę i dostar­cza pro­dukt. Czego jeszcze potrze­ba?

A czym tak naprawdę jest Scrum według twór­ców Scrum i Scrum Guide? “Scrum to ramy pro­ce­su, które są wyko­rzysty­wane w zarządzaniu wyt­warzaniem złożonych produktów od początku lat dziewięćdziesiątych. Sam w sobie Scrum nie jest pro­ce­sem czy tech­ni­ką wytwórczą; opisu­je jedynie ogólne sposo­by postępowania, w obrębie których możliwe jest stosowanie różnego rodza­ju procesów i tech­nik. Scrum poma­ga odkrywać nieefektywności prak­tyk zarządczych i tech­nik inżynierskich, by można było je doskon­al­ić.”

Scrum został zbu­dowany z myślą o budowa­niu złożonych pro­duk­tów. Jeśli byśmy chcieli sprowadz­ić esencję Scrum do jed­nego zda­nia, było­by to, budowanie wartoś­ciowych pro­duk­tów w krót­kich iter­ac­jach. W Scrum cały czas budu­je­my pro­dukt dokłada­jąc do niego kole­jne przy­rosty i wyda­je­my go na pro­dukc­je wtedy, kiedy biznes stwierdzi, że ma to sens biz­ne­sowy. Pro­dukt rozwi­jamy tak dłu­go, jak dłu­go jego właś­ci­ciel, Prod­uct Own­er, uważa, że opła­ca się to z punk­tu widzenia biz­ne­su. Prod­uct Own­er będzie również zaj­mował się pro­duk­tem już po wdroże­niu, więc musi brać pod uwagę Całkow­ity Koszt Posi­ada­nia (ang. Total Cost of Own­er­ship). W tym pode­jś­ciu real­izu­je­my zawsze to co najbardziej wartoś­ciowe i utrzy­mu­jąc pro­dukt w stanie ukońc­zonym (ang. done) i użytecznym, mając z tyłu głowy, że kole­jnego Sprintu może nie być.

 

PROJECT (noun) A temporary endeavor toward achieving a unique result. In Scrum:Can be applied to part of the Product Backlog with a specific cohesive objective or a complete Product Backlog. Or every Sprint.

Pro­jekt moż­na określić jako tym­cza­sowo orga­ni­za­cję powołaną do wyko­na­nia pewnej pra­cy albo dostar­cze­nie unikalnego rezul­tatu w określonych zasobach. Jeśli byśmy próbowali odnieść te definic­je do Scrum, zobaczymy, że każdy Sprint moż­na określić jako pro­jekt. A Sprint nie może się nie udać, może jedynie dostar­czyć nieak­cep­towal­nego zwro­tu z inwest­y­cji.

Jak pojaw­ia się coś takiego jak pro­jekt, to od razu pojaw­ia się potrze­ba mianowa­nia kogoś, kto tym zarządza, czyli kierown­i­ka pro­jek­tu, project man­agera. A zas­tanaw­iałeś się kiedyś dlaczego w ogóle mamy pro­jek­ty w orga­ni­za­c­jach? Jaka stoi za tym potrze­ba? Jeśli nie wiado­mo o co chodzi to chodzi o pieniądze. Pro­jekt to abstrak­cyjny twór do którego moż­na przy­czepić budżet. W dużych kor­po­rac­jach budże­towanie zostało zbu­dowane wokół pro­jek­tów i dopó­ki tak będzie dzi­ałało przy­dzielanie pieniędzy, pro­jek­ty będą potrzeb­ne.

Scrum został zapro­jek­towany z myślą o budowa­niu złożonych pro­duk­tów. Kiedy trafi­amy na sytu­ację, w której nie ma pro­duk­tu do dostar­czenia, a nadal jest zakres do dostar­czenia, może­my zas­tanow­ić się czy może lep­iej sięgnąć po Project Man­age­ment nawet ze znamion­a­mi Agile. Scrum w takiej sytu­acji może wyglą­dać sztucznie.

 

A Scrum project is only one Sprint long. A release of software may be the sum of multiple increments (and previously developed software, if any), or there may be multiple releases of software within a Sprint. A Scrum project cannot fail, only deliver unacceptable return on investment.
— Ken Schwaber

Scrum jest zupełnie innym pode­jś­ciem niż zarządzanie pro­jek­tem, które sku­pia się na dostar­cze­niu całego ustalonego zakre­su i zakończy w ustalonej dacie. Oczy­wiś­cie moż­na prowadz­ić pro­jek­ty inaczej, ale przytłacza­ją­ca ilość pro­jek­tów to tak zwane fixy. Fix oznacza twar­do ustaloną datę lub twar­do ustalony zakres, albo pomi­mo wielu ostrzeżeń twar­do ustalone obie wartoś­ci. Nie oznacza to, że nie moż­na stosować Scrum w pro­jek­tach typu fix. Takie pode­jś­cie może okazać się bard­zo korzystne, bo cho­ci­aż­by bard­zo szy­bko będziemy się uczyć i niwelować kole­jne ryzy­ka. Najwyżej nie będzie wyda­nia pro­duk­tu na pro­dukcję do samego koń­ca pro­jek­tu. W prak­tyce okazu­je się, że takie pode­jś­cie do real­iza­cji pro­jek­tu otwiera zupełnie nowe możli­woś­ci na prowadze­nie dia­logu z zamaw­ia­ją­cym.

Kole­jne częś­ci artykułu:

Project Man­ag­er w Scrum #2 — czy potrzeb­na jest kole­j­na rola?
Project Man­ag­er w Scrum #3 — co zro­bić z PMem