PMP vs. Agile

Anche di recente mi sono ritrovato coinvolto in una discussione in cui le metodologie Agile sono state definite come destrutturate e prive delle caratteristiche necessarie al raggiungimento di un obiettivo. Diciamo come una piuma la vento, che si fa trasportare in tutta leggerezza e svolazza senza meta. Dall’altro lato qualcuno ha descritto le dottrine PMI come qualcosa di farraginoso e talmente strutturato da fornire alibi a chiunque per il mancato raggiungimento degli obiettivi. Credo che per entrambe le posizioni la verità sta nel giusto equilibrio.

La gestione dei progetto con metodologie tradizionali si presta bene quando c’è una buona conoscenza del dominio applicativo oggetto del progetto. Se devo asfaltare una strada, con tutte le difficoltà che posso incontrare il perimetro è ben definito e la conoscenza è ben consolidata. Una delle prime lezioni del PMBOK, il libro che descrive i processi PMI, dice che è compito del PM con il team di progetto individuare quali di tutti i processi sono necessari per il progetto e con quale livello di implementarli. Ad esempio per un progetto privo di rischi (o pochi e noti) non predispongo un registro dei rischi. Per usare una metafora, la gestione progetti tradizionale è come una vacanza in macchina, pianifico le tappe, le soste, gli alberghi. Posso ri-pianificare se un posto non mi piace e voglio scappare, avrò da affrontare degli imprevisti, una gomma bucata, lo sciopero dei benzinai, ma in un modo o nell’altro riuscirò a visitare i posti che mi sono prefissato.

Agile si applica quando l’incertezza è tale da richiedere costanti variazioni a piani di progetto con eventuale rivisitazione del perimetro. Di fatto è come separare il progetto in tanti piccoli progetti di poche settimane (sprint) che consentono di verificare costantemente se si procede nella direzione giusta mantenendo sotto controllo i tempi. In ogni sprint ho tutte le fasi tipiche gestione progetti tradizionle, compresse nel tempo e quindi con formalismi più snelli. Mi azzardo a dire, irritando i puristi) che per alcuni versi “Agile” è più strutturato delle metodologie PM tradizionali, direi che si aggiunge alle metodologie tradizionali come un add-on. Anche usando metodologie Agile posso avere un piano dei rischi un registro degli stakeholder o qualsiasi altro strumento PM che ritengo utile. Sempre usando una metafora, “Agile” è come una vacanza in barca a vela, quando sono in navigazione devo fare il punto nave ogni due ore per correggere la rotta e se il vento e corrente non sono favorevoli rispetto a dove voglio arrivare, può essere che debba cambiare destinazione. Ma la cambusa devo averla pianificata bene secondo un approccio “tradizionale”.

Riassumo:

• se ho un vincolo forte sul perimento di progetto ma posso variare i tempi e costi di progetto adotterò un approccio tradizionale.
• se ho un vincolo forte sui tempi ma ho la possibilità di variare il perimetro e i costi adotterò un approccio agile. (Questo approccio è tipico delle newco e dei progetti innovativi perché essendo “nuovi” è molto improbabile riuscire a definire a priori il dettaglio delle caratteristiche)

L’ultima osservazione, nel mondo ideale esiste un progetto che rispetta tempi, costi, perimetro e qualità, nel mondo reale non ne ho mai visti. Ma ho visto molti progetti di successo, sono quelli che soddisfano le aspettative del cliente.