1-3Kontynuując serię artykułów na temat zwinnych standardów zarządzania, nadszedł czas na ostatnią nowość roku 2014. Konsorcjum DSDM, wydało standardAgilePM V2. Dzięki uprzejmości konsorcjum, tuż przed końcem roku wpadł w moje ręce oficjalny podręcznik AgilePM V2, pochodzący jeszcze z pierwszej partii druku. Ten odświeżony standard zwinnego zarządzania projektami (powstały w 2010 roku jako pochodna DSDM), otrzymał nowy branding oraz wiele praktycznych zaleceń dla kierowników projektów zwinnych. Zaowocowało to podziałem podręcznika na dwie sekcje oraz zwiększeniem jego rozmiarów do 240 stron (w porównaniu do 176 z poprzedniej wersji).

V2 podobnie jak poprzednia wersja bazuje na metodzie DSDM, która od roku 2014 została „awansowana do rangi” frameworka o nazwie AgilePF – Agile Project Framework. Dzieje się tak, ponieważ DSDM AgilePF jest teraz promowany jako podstawa dla wszystkich produktów, które konsorcjum DSDM posiada w ofercie (AgilePMAgilePgM) jak również wszystkich przyszłych, które są w planach (min. AgileBAAgilePMO). Dlatego też nie zadziwi nikogo fakt, że AgilePM V2 jest w wielu miejscach podobny do DSDM. Cały pierwszy dział podręcznika (pierwsze 70 stron) został w pełni poświęcony na przybliżenie podstaw zarządzania zwinnego jakie rozumiemy przez podejście, który promuje konsorcjum od ponad 20 lat. Nie ma tutaj nowości w kontekście wydanego w czerwcu DSDM AgilePF. Esencją AgilePM V2 staje się sekcja druga, która interpretuje teorię pryncypiów, produktów, ról, itp. W skrócie sekcja #1 to teoria, a sekcja #2 to interpretacja teorii w postaci zaleceń i luźno rozpisanych najlepszych praktyk dla kierowników projektów zwinnych realizowanych w zgodzie z DSDM AgilePF.

Czytając podręcznik V2, praktycy metody DSDM, będą czuli się jakby drugi raz czytali ten sam podręcznik wzbogacony o wartościowe dodatki. Tak można podsumować to wydanie. Ponownie stabilna ewolucja bez rewolucji. Choć dodatków jest nie mało, to jednak doświadczeni Agile Coach czy Team Leaderzy nie powinni być niczym zaskoczeni. W podręczniku zachowano konwencję dodawania zaleceń dla kierowników projektów zwinnych tzw. Agile Project Manager Top Tips, pod koniec niektórych działów, czy wręcz kopiowaniem (!) niektórych działów w całości, słowo w słowo z bliźniaczego DSDM AgilePF.  Z drugiej strony niektóre działy „powróciły” i tak mamy na nowo dział zarządzania ryzykiem. Całość napisana stylem bardziej konkretnym i jednoznacznym w porównaniu do poprzedniej wersji.

Zobacz metodykę AgilePM w interaktywnej formie!

Agile Project Management V2 (AgilePM® V2)

Sekcja druga AgilePM V2 / Pryncypia

W pierwszym dziale sekcji drugiej, znajdziemy rozległą interpretację pryncypiów w kwestii projektów agile. Każdy podpunkt opisujący konkretne pryncypium otrzymał kilkunastu zdaniowe rozwinięcie ułatwiające zrozumienie pryncypium dla osób mniej doświadczonych z Agile. Drugi powód to trend transferu PM’ów z modelu „tradycyjnego” zarządzania projektami do zwinnego. Jawna interpretacja pryncypiów powinna być przydatna w początkowym okresie kariery jako Agile Project Manager. Podsumowując – bardzo przystępny dział omawiający jak w praktyce zobrazowuje się manifestacja pryncypiów w całym cyklu życia projektu DSDM/AgilePM.

Mimo, że ten dział omawia teorię, to jednak historia Manifestu Agile pokazuje nam, że jest to potrzebne. Nie każda organizacja potrafiła zinterpretować teorię zawartą w 4 wartościach oraz 12 pryncypiach Manifestu Agile w efektywne wynikowo oraz wspierające się środowisko pracy zespołowej.

2-2

Role i odpowiedzialności

Kolejny dział został poświęcony na przedstawienie ról i odpowiedzialność (tzw. bałwanek w społeczności DSDM lub drużyna RR – Roles and Resposibilities). Dział został wzbogacony o sekcję powiązań między Kierownikiem Projektu a innymi członkami projektu. Przedstawione zostały powiązania oraz odpowiedzialności w stosunku do Sponsora, Wizjonera, Koordynatora Technicznego, Analityka Biznesowego, Lidera Zespołu oraz całego zespołu. Ten krótki dodatek pozwala na łatwiejsze wprowadzenie w sposób myślenia według filozofii Agile oraz jawnie stwierdza, że od Kierownika Projektu również oczekiwana jest postawa przywódcy niż czystego kierownika.

43-2Lewa strona: role w AgilePM 1.0 do 1.2. Prawa strona: role projektowe w AgilePM v2 oraz DSDM Agile PF zarazem.

W powyższych diagramach widzimy również wprowadzenie szarej kolorystyki dla ról znajdujących się na samym dole diagramu. Kolor szary został użyty do wyróżnienia ról skupiających się na optymalizacji procesu / pracy. Rola Facylitatora – proces warsztatu, Rola Coacha – proces AgilePM.

Rewolucji nie ma, a stabilny rozważny krok ewolucyjny wprowadzający czytelność i jednoznaczność.

Cykl życia projektu / Proces DSDM + Artefakty / Produkty zarządcze

W następnych dwóch rozdziałach zostały przedstawione: cykl życia projektu wraz z opisem kluczowych artefaktów / produktów. Jako, że proces AgilePM V2 jest identyczny jak proces DSDM – nie znajdziemy tutaj niespodziewanych nowości, a jedynie subtelne poprawki stylistyczne. Jednak pojawia się bardzo ciekawy sposób opisu samego procesu. Autorzy przechodzą krok po kroku po procesie DSDM, opisując kiedy oraz na jakim poziomie szczegółowości powstają konkretne produkty.

56

Lewa strona: cykl życia projektu AgilePM 1.0 do 1.2. Prawa strona: cykl życia projektu AgilePM V2 oraz DSDM AgilePF zarazem

Dodatkowo w V2 został zastosowany opis odpowiedzialności w postaci matryc RACI, co zdecydowanie rozjaśniło kwestię odpowiedzialności. Mały, lecz wartościowy dodatek.

78

Lewa strona: produkty projektu AgilePM 1.0 do 1.2. Prawa strona: produkty projektu AgilePM V2 oraz DSDM AgilePF zarazem.

Opisane produkty oraz fazy projektu są szerzej opisane w dziale 21 – Project Planning Throught the Lifecycle, gdzie otrzymaliśmy zalecenia odnoście planowania fazy oraz tworzenia odpowiednich dokumentów. Na proces DSDM został również nałożony system bramek kontroli jakości (ang. Quality assurance) w celu zobrazowania działającego projektu AgilePM w środowisku wymagającym większej kontroli oraz nadzoru.

Timeboxing

Rdzeń metody jakim są Timeboxy (według polskiego tłumaczenia Okienka Czasu) został zaktualizowany, aby być na bieżąco z zaleceniami obecnymi w DSDM AgilePF. Tym samym mamy do dyspozycji dwa typy Timeboxów tzw. DSDM structured Timebox oraz „nowy” alternatywny Free format Timebox.

9

W poprzedniej wersji AgilePM 1.0 do 1.2 Timebox był podzielony na 5 korków: Kick-Off, Investigation, Refinement, Consolidation, Close-Out. To sprawiało, że osoby pracujące w Sprintach (Scrum) mogły postrzegać Timeboxy (DSDM) jako przerost formy nad treścią – często 1 czy 2 tygodniową pracę dzielimy sztucznie na 3 kroki.

10

W odpowiedzi na powyższe spostrzeżenia najnowsza wersja DSDM’a wprowadza drugą, uproszczoną wersję Timeboxa, który nie rozróżnia wewnętrznych działań podczas jego trwania, a jedynie mówi o rozwoju iteracyjnym, który dzieje się podczas trwania Timeboxa. Nowy format Timebox’a nazywa się Timebox’em w formacie swobodnym (ang. free format Timebox).

Nota: Dla osób nie znających różnic między Sprint’em (Scrum) a Timebox’em (DSDM), warto podkreślić subtelną, a jednak znaczącą różnicę między nimi. Scrum stosuje priorytetyzację wymagań w Sprint Backlog w postaci 1,2,3,4,5…n. Natomiast Timebox priorytetyzację relatywną w oparciu o priorytety bazujące na technice MoSCoW – Must, Should, Could, Won’t. Inne różnice między Sprint’ami a Timebox’ami są głównie w terminologii, idea pozostaje ta sama.

Szacowanie / Estymacja

Dział estymacji również otrzymał rozwinięcie. Podano przykłady szacowania w oparciu o proste techniki rozmiarów koszulek (tzw. T-shirt estimating) oraz o szacowanie w oparciu o przykłady, które stosujemy gdy tempo (ang. velocity) zespołu nie jest znane. Autorzy opisali pokrótce cykl życia wymagań oraz proces rozwijania wymagań o niezbędne szczegóły w celu pełniejszego ich zrozumienia przed rozpoczęciem pracy developerskiej / wytwórczej. Również w tym dziele na temat wymagań oraz User Stores pojawiły się oczekiwane przeze mnie opisy dobrze znanych dla społeczności Agile akronimów: 3C (Card, Conversation, Confirmation) oraz INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable).

Ludzie, Zespoły i Interakcje

Ten dział, autorstwa Marka Bunchan’a, opisuje wartość interakcji międzyludzkich, takich jak komunikacja werbalna w postaci spotkań twarzą w twarz czy video konferencje (nie mylić z telekonferencjami), która to mimo szeroko obecnej technologii, wciąż  niezmiennie pozostaje kluczowym fundamentem projektu. Dział Ludzie, Zespoły i Interakcje pokrótce omawia najbardziej fundamentalne metody komunikacji tj.: #1 komunikacja twarzą w twarz i jej wartość, #2 komunikacja w oparciu o video konferencję, #3 Komunikatory, #4 Email, #5 Miejsca kolaboracji, #6 Dokumenty.

Oprócz omówienia podstawowych aspektów komunikacji przedstawione zostały elementy współpracy w zespole projektowym i zasada T, bardzo dobrze znana osobom pracujący w Scrum oraz z innymi technikami / metodykami Agile.

12

Została też podkreślona rola Team Leader’a jako servant leadership, działającego jako osoba współpracująca i wspierająca zespół, bardziej niż zarządzająca nim. I choć było to już obecne w poprzedniej wersji standardu, teraz zostało to jawnie powiedziane.

Zarządzanie ryzykiem

Na koniec warto wspomnieć o całkowicie odmienionym od podstaw dziale zarządzania ryzykiem. Temat ten był (oraz uważam, że wciąż powinien być) traktowany diametralnie inaczej niż w podejściu tradycyjnym. Podejście zaprezentowane w tym rozdziale bazuje na PRAM Guide – Project Risk Analysis and Management Guide autorstwa APM – Association for Project Management.

Uproszczony model zarządzania ryzykiem prezentowany w AgilePM V2 składa się z trzech komponentów: Identify Risk, Assess Severity, Plan Countermeasures. Prosty model, który uchwyca istotę zarządzania ryzykiem, został wzbogacony o podział na:

  • Ryzyko projektowe – związane z realizacją projektu,
  • Ryzyko produktowe – związane z utrzymaniem jakości produktu.

Ten podział pośrednio identyfikuje odpowiedzialności danych osób w kontekście zarządzania ryzykiem w projekcie Agile wskazując, że Kierownik Projektu nie jest jedyną odpowiedzialną osobą za całościowe zarządzanie ryzykiem.

Dodano również popularne ryzyka występujące w projektach Agile, kiedy to organizacja nie jest w pełni zwinna i zaangażowanie osób decyzyjnych czy organów finansujących projekt jest na poziomie minimalistycznych. Wraz z potencjalnymi ryzykami przedstawiono sposoby jak można z nimi przeciwdziałać w oparciu o proces jaki prezentuje DSDM / AgilePM V2.

Dodatkowo podręcznik wymienia fakt istnienia Pryncypiów DSDM, Kluczowych Czynników Sukcesów DSDM oraz Kwestionariusz Podejścia do Projektu (ang. Project Approach Questionaire) które są podstawowymi elementami metody i zarazem wiążą się ściśle z zarządzaniem ryzyka.

Podsumowanie zmian

Agile Project Management
(AgilePM v1.0 – v1.2)
Lata 2010 – 2014
(właściciel konsorcjum DSDM)
Agile Project Management
(AgilePM v2)
Lata 2014 – obecnie
(właściciel konsorcjum DSDM)
rodzaj metoda metoda
typ iteracyjno-przyrostowo-adaptacyjna iteracyjno-przyrostowo-adaptacyjna
styl całkowicie rekomendacyjna całkowicie rekomendacyjna
kierowana zmianą (empiryzm) zmianą (empiryzm)
paradygmat adaptacyjny (zmiana) adaptacyjny (zmiana)
szczegółowe wymagania odkrywane w trackie (EDUF) odkrywane w trackie (EDUF)
podejście do zmiany zmiana jest nieunikniona, zalecana, naturalna zmiana jest nieunikniona, zalecana, naturalna
pryncypia 8 8
kluczowe czynniki sukcesu 9 6 (uproszenie, merytorycznie bez zmian)
role projektowe 13 (14 ze specjalistą) 13
fazy cyklu życia 7 6
produkty 17 (główne) 14 (główne)
techniki 7 7
rodzaje timebox’a 1 2
kroki w rozwoju iteracyjnym 4 3
aspekty komunikacji + +++
aspekty współpracy + +++
aspekty deklaracji wymagań ++ +++
aspekty dostosowywania AgilePM + +++
aspekty zarządzania ryzykiem + ++
aspekty konfiguracji projektu ++ +

Na koniec spójrzmy na aktualny (12.2014) portfel produktów w ofercie konsorcjum DSDM. Czy tylko ja mam przemyślenia, że małymi krokami rośnie nam pokaźnych rozmiarów portfel dobrych praktyk? Lata pokażą. Póki co wizja jest obiecująca.

dsdm

PODZIEL SIĘ
Mirosław Dąbrowski
Chief Operating Officer (COO) w ENP rozwijającej, wdrażającej i utrzymującej platformy eCommernce o łącznych rocznym cash-flow przekraczającym 10 mld PLN. Agile & Lean Coach. Konsultant oraz architekt rozwiązań IT z bogatym 13 letnim doświadczeniem w informatyce (help-desk, programista, tester, grafik, UX designer, analityk biznesowy i systemowy, administrator, kierownik projektu, audytor, product manager, scrum mastera, dyrektor). Mocno związany z inżynierią oprogramowania oraz ecommerce. Posiada 5 lat międzynarodowego doświadczenia jako Agile Coach (8+ jako Scrum Master). W Polsce uczestniczył w transformacjach między innymi w ABC Data oraz BZWBK. Autor narzędzi do badania dojrzałości projektów zwinnych. Anglojęzyczny, międzynarodowy trener z szerokiego obszaru zarządzania oraz umiejętności miękkich (zarządzania tradycyjne oraz zwinne) oraz IT (programowanie, testy, bezpieczeństwo, audyt). Posiada 12 lat aktywnej praktyki trenerskiej w ramach której przeszkolił oraz coachował ponad 5000 osób w Europie. Wiodący autor 50 akredytowanych szkoleń. Akredytowany trener PRINCE2, PRINCE2 Agile, MSP, MoP, P3O, ITIL, MoV, M_o_R, PRINCE2 Agile, RESILIA, AgilePM, OBASHI, ASL2, BiSL i wielu innych standardów. Facylitator Playing Lean oraz Lean Startup. Ma za sobą ponad 100 certyfikacji w zakresu inżynierii IT oraz szeroko pojętego zarządzania. Twórca 50+ interaktywnych map myśli nt. zarządzania oraz IT (ponad 2mln odwiedzin i 150.000 polubień): www.miroslawdabrowski.com. Prelegent na wielu międzynarodowych konferencjach (w tym tych największych jak Agile Europe organizowanych przez Agile Alliance), autor, mentor, wykładowca. Aktywny członek zarządu PMI Poland Chapter. Inicjator programu transformacji usług IT w PMI PC. Jako IT Product Manager jest odpowiedzialny za portfel inwestycyjny z obszaru portali internetowych. Dba o roadmapę oraz wizję rozwoju (w tym utrzymanie oraz standaryzację) w ramach 10 portali internetowych PMI PC. Dwukrotny finalista prestiżowego międzynarodowego konkursu Agile Awards w kategoriach: "Najlepszy zespół stosujący metodykę DSDM/AgilePM" oraz "Wkład w promocję metodyki DSDM/AgilePM na świecie". Jedyny w Polsce certyfikowany DSDM Agile Trainer-Coach oraz Certified Disciplined Agile Coach (CDAC). Ekspert merytoryczny organizacji AXELOS (właściciela metodyki PRINCE2). Tłumacz standardu PRINCE2 Agile. Ambasador konsorcjum DSDM International (pierwszy w Polsce certyfikowany DSDM Agile Professional). Tłumacz metodyki AgilePM. Pasjonat metodycznego podejścia do zarządzania projektami oraz nieustannego rozwoju ku nieokreślonej doskonałości.

2 KOMENTARZE

  1. „Scrum stosuje priorytetyzację wymagań w Sprint Backlog w postaci 1,2,3,4,5…n”

    Panie Mirosławie, czy tutaj nie wkradł się błąd? Product Backlog owszem jest uporządkowany, natomiast Scrum nie narzuca kolejności w jakiej mają być realizowane elementy Sprint Backloga w Sprincie. Kolejność i ewentualna dekompozycja na mniejsze elementy podlega inspekcji i adaptacji w ramach Daily, tak aby zmaksymalizować szansę osiągnięcia Celu Sprintu.

    Pozdrawiam,
    Piotr

    • Dziękuję za komentarz :) Rzeczywiście jest to nie do końca poprawne, gdyż priorytety w Scrumie występują jedynie na Product Backlogu… dodałbym że kolejność pracy w Sprincie wyznacza zespół Scrumowy. Ważne aby z każdym ukończonym zadaniem zespół zbliżał się do wyznaczonego wcześciej Celu Sprintu a inspekcja i adapracja dzieje się najrzadziej podczas Daily, im częściej tym lepiej z mojej praktyki. :) W ramach pracy z zespołami staram się sugerować, aby nieustannie mieli na oku Cel Sprintu oraz postęp prac (min. sprawdzajać sami, proaktywnie stan Burndown chartu lub innych zestaw informacji który da im potwierdzenie czy zbliżamy się do Celu).

ZOSTAW ODPOWIEDŹ