Skip to main content

Nowa odsłona metody AgilePM V2 – Agile Project Management V2

Kontynuując serię artykułów na temat zwinnych standardów zarządzania, nadszedł czas na ostatnią nowość tego roku. Konsorcjum DSDM, wydało standard AgilePM 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 (AgilePM, AgilePgM) jak również wszystkich przyszłych, które są w planach (min. AgileBA, AgilePMO). 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 (a może zawiedzeni?).

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.

Krótka lekcja historii

DSDM został opracowany w 1994 roku. W tamtych czasach dominującą metodą była metodologia Waterfall. Jednak grupa zwolenników szybkiego tworzenia aplikacji (RAD) szukała rozwiązania oferującego większy poziom dyscypliny i zarządzania. Uświadomili sobie, że najlepszą drogą do sukcesu jest iteracyjne i przyrostowe tworzenie oprogramowania. Tradycyjne zarządzanie projektem było zbyt obszerne, wolne i nieprzejrzyste.

Celem metody DSDMa (mówimy o latach 90-tych) było usunięcie tych braków, ale sam również posiadał wadę. Czegoś brakowało, gdyż kontrola i jakość były wtedy zwykle kojarzone z podejściem tradycyjnym. Na szczęście Agile został (niejako) wprowadzony w 2001 roku, a praktykujący DSDMowie uznali go za naturalnego sojusznika. Ostatecznie oba podejścia połączyły się. To był początek tak zwanego DSDM Agile Project Management (AgilePM) o której najnowszym wydaniu V2 poniżej.

Sekcja druga w podręczniku AgilePM V2 - Dział Pryncypia

Dział ten omawia czystą teorię, to jednak historia „implementacji” Manifestu Agile w organizacjach, pokazuje nam, że teoria a praktyka mogą całkowicie rozminąć się. Nie każda organizacja potrafiła zinterpretować teorię zawartą w 4 wartościach oraz 12 pryncypiach Manifestu Agile, tak aby stworzyć efektywne biznesowo oraz wspierające środowisko i kulturę pracy zespołowej.

W tym dziale poznamy rozległą interpretację pryncypiów w kwestii projektów AgilePM. Każde pryncypium otrzymało pół lub pełnostronicowe opisy, ułatwiające zrozumienie pryncypium dla osób mniej doświadczonych z DSDM/AgilePM. Jest to bardzo przystępny dział omawiający jak w praktyce obrazowuje się manifestacja pryncypiów w całym cyklu życia projektu DSDM/AgilePM.

Drugi powód rozwinięcia tego działu, 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.

Konstruktywny komentarz

Ogólniej jest to bardzo przystępny dział omawiający jak w praktyce przedstawia się manifestacja pryncypiów w całym cyklu życia projektu DSDM/AgilePM.

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 dział, pozwala na łatwiejsze wprowadzenie do sposób myślenia według filozofii DSDM oraz jawnie stwierdza, że od Kierownika Projektu również oczekiwana jest postawa przywódcy niż czystego kierownika.

Model ról w AgilePM 1.0 do 1.2.

Model ról projektowych w AgilePM v2 oraz DSDM Agile PF zarazem

W nowym modelu ról, widzimy wprowadzenie szarej kolorystyki dla ról znajdujących się w dolnej części modelu. Kolor szary został użyty do wyróżnienia ról procesowych, skupiających się na optymalizacji procesu. Rola Facylitatora – proces warsztatu, Rola DSDM Coacha – proces DSDM (na którym bazuje metoda AgilePM).

Druga widoczna zmiana obecna jest w roli Analityka Biznesowego (które nie powinien pracować jako pośrednik w komunikacji). Rola otrzymała dwa kolory, co podkreśla aspekty biznesowe i techniczne. Sugeruje to, łączenia dwóch ról popularnych w świecie IT: Analityk Biznesowy i Analityk Systemowe w jedną rolę. Odważna decyzja. 🙂

Rewolucji nie ma. Mamy stabilny, rozważny, mały krok ewolucyjny wprowadzający jedynie większą czytelność i jednoznaczność.

Konstruktywny komentarz

Spoglądając na model ról, już na pierwszy rzut oka widzimy „kość ogonową” z podejść tradycyjnych. Istnieje coś na wzór komitetu sterującego. Jest to absolutnie anty Scrumowe i mocno nie Agilowe – z prostego powodu, znacząco wydłuża ścieżkę decyzyjną.

Drugą słabością jest praktycznie absolutny brak wizualizacji przykładów w przypadku skalowania projektów AgilePM do wielu zespołów SDT. Oprócz tekstowego opisu mówiącego o tym, że w przypadku skalowania pozostaje wciąż jeden „Project Level Team”, mamy wiele „Solution Development Teams”.

W innych oficjalnych publikacjach konsorcjum, można poznać przykłady łączenia metody AgilePM z frameworkiem Scrumem. Znajdziemy tam informacje, że Business Ambassador jest odpowiednikiem Product Ownera. He? Tak! Oznacza to, że w przypadku skalowania AgilePM mamy kilku PO, jeden per każdy zespół i jeden „master” znany jako Business Visionary… takich kwiatków jest więcej, zdecydowanie zbyt dużo, aby omawiać wszystkiem.

Scrumowiec płakał jak to czytał 🙁

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.

Cykl życia projektu AgilePM 1.0 do 1.2.

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 dla osób pracujących w tradycyjnem modelu zarządzania… jednak w mojej ocenie oddaliło całą metodykę od świata zwinności.

Produkty zarządcze (artefakty) projektu w metodzie AgilePM 1.0 do 1.2.

Produkty zarządcze (artefakty) projektu w metodzie 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.

Konstruktywny komentarz

Serce krwawie jak czyta się ten dział. Model projektowy DSDM wciąż (po blisko 20 latach rozwoju) zakłada możliwość Deploymentu TYLKO podczas fazy Deployment, czyli po zakończeniu fazy Evolutionary Development (dla uproszczenia dla Scrumowców, po zakończeniu Sprintu). Oznacza to, że model DSDM/AgilePM nie pozwala na wielokrotne dostarczanie wartości podczas Sprintu. Continuous Delivery (CD), Continuous Deployment (CD) i Release on Demand (RoD) nie zagościły w mindsecie twórców metodyki. ;(

Drugą słabością jest brak rozróżnienia między Deploy (wdrożeniem) a Release (udostępnienie dla użytkowników). W praktyce można to realizować między innymi implementując Feature Flags / Feature Toggles.

Model jest przestarzały i anty-scrumowy 🙁 (ale nie anty-agilowy) 

null

Prosto z poligonu transformacji

Podejście AgilePM aczkolwiek oparte na kompromisach z sukcesem zastosowaliśmy podczas kilku transformacji w szczególności w środowiskach korporacyjnych. U jednego klienta z sektora bankowego (retail), AgilePM sprawdził się jako idealna metoda do „uzwinniania” już istniejących i trwających projektów prowadzonych w modelu tradycyjnym. Istniejący już w organizacji komitet inwestycyjny początkowo weryfikował i zatwierdzał tylko uzasadnienia biznesowe na nowe inwestycje/projekty. w ramach naszej pracy rozszerzyliśmy działalność komitetu o weryfikację hipotez i MVP oraz rekomendował sposobu realizowania danej inwestycji (wliczając w to model kontraktowy): tradycyjnie (waterfall), zwinny (agile) czy produktowy (powołanie nowego Scrum Studio). AgilePM został zaadaptowany jako metoda na realizację inwestycji w modelu projektu zwinnego (AgilePM). Produkty Terms of Reference oraz Feasibility Assessment skupiały się na zrozumieniu problemu z jakim borykają się pracownicy bądź klienci banku. Została określona hipoteza i rozpoczął się proces budowy MVP oraz weryfikacji hipotezy. Weryfikacja MVP następowała w fazie Foundation Assessment. Po poprawnej weryfikacji, projekt ruszał pełną parą.

To podejście pozwoliło na sukcesywne mentorowanie i coachowanie wybranych kierowników projektów (z 80 dostępnych w banku). Stworzyło mechanizm do wspierania tych projektów przez Coachy DSDSM oraz identyfikacji kierowników projektów, którzy posiadają odpowiednią osobowość, charakter i dojrzałość – w skrócie potencjał do bycia zwinnym liderem pracującym jako przywódca służebny.

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

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ą, poprzez dzielenie często 1 czy 2 tygodniowej pracy na 3 kroki.

W odpowiedzi na powyższe spostrzeżenia najnowsza wersja DSDM’a wprowadza drugą, uproszczoną wersję Timeboxa. Free Format Timebox nie rozróżnia wewnętrznych działań podczas jego trwania, a jedynie mówi o rozwoju iteracyjnym.

Scrum'owe Sprinty a DSDM'owe Timeboxy

W teorii można pomyśleć, że jest to nic innego jak Scrumowy Sprint. Niestety… nic bardziej mylnego. Wczytując się między wiersz możemy znaleźć takie zdania jak: „Close Out – Formal Acceptance of the Timebox deliverables by the Business Visionary and Technical Coordinator„. Jednoznacznie widzimy, że DSDMowe wydarzenie „Close-Out”  nie jest odpowiednikiem Scrumowego „Review”. Jest to formalne spotkanie podczas którego zespół deweloperski (SDT) „rozlicza” się z pracy przed Wizjonerem Biznesu (ang. Business Visionary) i Koordynatorem Technicznym (ang Technical Coordinator), którzy formalnie akceptują lub nie (obierają) pracę…

Scrumowiec płakał jak to czytał 🙁

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 NIE stosuje priorytetyzację wymagań w Sprint Backlogu. Sprint Backlog w Scrumie jest zbiorem (nie listą) a celem zespołu Scrumowego (wbrew panującym praktykom) nie jest realizacja zadań ze Sprintu a realizacja Celu Sprintu. Sprint Backlog jest jedynie/aż planem zespołu do osiągnięcia Celu Sprintu.

Natomiast DSDM w swoich Timeboxach, stosuje priorytetyzację relatywną w oparciu o priorytety bazujące na technice MoSCoW – Must, Should, Could, Won’t. Co oznacza, że zadania określone jako Must, muszą zostać zrealizowane, aby traktować, że Timebox zakończył się sukcesem.

Szacowanie / Estymacja

Dział poświęcony estymacjom również został rozwinięty. Podano przykłady szacowania w oparciu o proste techniki rozmiarów koszulek (tzw. T-shirt estimating) oraz o szacowanie w oparciu o przykłady, analogwiczne projekty czy zadania, które stosujemy gdy tempo (ang. velocity) zespołu nie jest jeszcze 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. Myślę, że celowo, gdyż całość zostanie zaprezentowana bardzo szczegółowo w opracowywanej publikacji Agile Business Analysis (AgileBA).

Dodatkowo na temat wymagań oraz User Stores pojawiły się oczekiwane przeze mnie opisy i dobrze znanych dla społeczności Agile akronimy: 3C (Card, Conversation, Confirmation) oraz mnemoniczny INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) autorstwa Billy Wake .

INVEST User Stories

Ludzie, Zespoły i Interakcje

Ten dział, autorstwa Marka Bunchan’a. Marka miałem przyjemność poznać osobiście podczas konferencji Agile Business Conference w  Londynie. Mark jest osobą o bogatym doświadczaniu z obszaru budowania efektywnych zespołów i współpracy. Nie bez powodu jako osoba blisko związana z konsorcium DSDM, został zaproszony jako główny autor do rozbudowy tego działu w oficjalnym podręczniku.

W dziale „Ludzie, zespoły i Interakcje” znajdziecie przedstawienie wartość interakcji międzyludzkich, takich jak komunikacja werbalna w postaci spotkań „twarzą w twarz” czy video konferencje (nie mylić z telekonferencjami). Wydaje się to być tak oczywista, że aż dziwi potrzeba aby przypominać to w 21 wieku, ale jednak. Zostały przedstawione  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.

Z kolei na plus zasługują postawy jakie powinna manifestować osobą wchodząca w skład zespołu. Mowa tu o otwartości na zmiany, budująca zaufanie, traktująca innych członków z szacunkiem etc. Proste i oczywiste sprawy, ale miło że po tylu latach rozwoju metodyki w końcu się to pojawiło.

T-shaped people

Oprócz omówienia podstawowych aspektów komunikacji przedstawione zostały elementy współpracy w zespole projektowym i znana już od wielu lata zasada T (lub po prostu T-Shaped people), bardzo dobrze znana osobom pracujący w Scrum oraz z innymi technikami / metodykami Agile.

Została podkreślona rola Team Leader’a jako przywódcy służebnego (ang. servant leadership), działającego jako osoba współpracująca, mentorują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.

Ze smutkiem spoglądam na tą rolę i do dziś (ze znanych mi powodów politycznych) ubolewam nad tym, że konsorcjum DSDM tak bardzo stara się nie stosować roli Scrum Matera. 🙁

Konstruktywny komentarz

Rekomendacje przedstawione w tym dziale nie zaskakują. W mojej opinii zabrakło podkreśleni oraz zobrazowania przykładami znaczenia komunikacji osmotycznej (zarówno w świecie realnym jak i cyfrowym). Zamiast listować tak oczywiste kwestia jak komunikacja mailowa, konsorcjum mogłoby zaprezentować przykłady zastosowania narzędzi do pracy rozproszonej i współbieżnej jak: Real Time Board czy Mural. Pomijam kwestie biznesowo-polityczne, mówiące o tym, że w oficjalnych (tym bardziej brytyjskich) publikacjach nie promuje się konkretnych producentów, ale ten problem można zawsze kreatywnie obejść.

Da się wyczuć szczególnie czytając ten działa, że autorzy nie są na bieżąco z najnowszą dostępną technologią wspierająca efektywną, interaktywną i współbieżną komunikację dla całego zespołu.

Druga kwestia to interakcje. Skoro dział rzekomo porusza takie tematy jak interakcje, to zdecydowanie brakuje wprowadzenia do tematyki oceny dojrzałości zespołów oraz oceny poziomu dojrzałości komunikacji w zespołach. Brakuje przykładów jak ocenić i zwiększyć tą dojrzałość. Przykładowo podręcznik nie wprowadza żadnego modelu komunikacji czy też nie odwołuje się do jakichkolwiek modeli osobowości (typu: MBTI, DISC, INSIGHTS, BELBIN, SDI), które potrafią zbudować świadomość u ludzi na temat ich preferencji komunikacyjnych i nie tylko. A przecież od świadomości wszystko się zaczyna…

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. Co wydaje się być oczywistym w jakimkolwiek zdrowo prowadzonym projekcie, szczególnie „zwinnym”, gdzie współpraca jest fundamentem.

Dodano również popularne ryzyka występujące w projektach Agile. Między innymi, kiedy to firma/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 AgilePM v1.2 a AgilePM 2.0

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)
rodzajmetoda + certyfikacja (w ramach APMG)metoda + certyfikacja (w ramach APMG)
typiteracyjno-przyrostowo-adaptacyjnaiteracyjno-przyrostowo-adaptacyjna
stylcałkowicie rekomendacyjnacałkowicie rekomendacyjna
kierowanazmianą (empiryzm)zmianą (empiryzm)
paradygmatadaptacyjny (zmiana)adaptacyjny (zmiana)
wymaganiaodkrywane w trackie (EDUF)odkrywane w trackie (EDUF)
podejścia do zmianyzmiana jest nieunikniona, zalecana, naturalnazmiana jest nieunikniona, zalecana, naturalna
pryncypia88
kluczowe czynniki sukcesu96
(uproszenie, merytorycznie bez zmian)
role projektowe13 (14 ze specjalistą)13
faze cyklu życia projektu76
produkty / artefakty17 (główne)14 (główne)
techniki77
rodzaje timebox’a12
kroki w rozwoju iteracyjnym43
aspekty komunikacji++++
aspekty współpracy++++
aspekty deklaracji wymagań+++++
aspekty dostosowywania AgilePM++++
aspekty zarządzania ryzykiem+++
aspekty konfiguracji projektu+++

Podsumowanie portfela produktów DSDM na rok 2014

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. Należy jednak pamiętać, że są to podejścia hybrydowe, czerpiące zarazem z podejść tradycyjnych jak i zwinnych co oznacza, że należy z nich korzystać jeszcze z większą świadomością, aby nie adoptować ich w produktach, obszarach, zespołach gdzie może to zaszkodzić.

Podziękowania dla konsorcjum DSDM

Na koniec chciałbym osobiście podziękować założycielom konsorcjum DSDM oraz twórcom wymienionych metodyk. Dzięki wszystkim za indywidualne wywiady jak również wspólne spotkanie. Miałem przyjemność poznać rąbek tajemnicy o wizji DSDM na najbliższe lata czy też tak subtelne elementy i detale jak dobór czy znaczenie kolorystyki (oraz genezę ich doboru) przy konkretnych logach, produktach i rolach obecnych w modelu ról czy kolorach okładek podręczników.

Całość przedstawia obraz community dbającego o spójność i jednoznaczność przekazu. To na plus. Przyszłość najbliższych lat wygląda obiecująco jednak należy pamiętać, że rozmawiamy o rozwiązaniach hybrydowych.

Inauguracja standardu AgilePgM. Steve Messenger, wiodący autora omawia nowy standard podczas konferencji Agile Business Conference (ABC) 2014, październik 2014 / Londyn

Jedyne w swoim rodzaju egzemplarze podręczników z autografami autorów i twórców metodyk. Dziękuję wszystkim i każdemu z osobna za poświęcony mi czas, omówienie historii oraz wiedzy niejawnej przy powstawaniu tych standardów.

Miroslaw Dabrowski

Enterprise-Lean Agile Coach

Subscribe To Our Newsletter

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from our team.

GDPR EN

You have Successfully Subscribed!