Agile Project Management

I progetti – di qualsiasi ambito (industriale, civile, di ricerca & sviluppo, organizzativi) stanno cambiando e sempre più diventando “liquidi”, “fluidi”, “estremi”, richiedendo l’integrazione degli approcci tradizionali al Project Management con nuovi approcci cosiddetti “agili”.

Nella pratica internazionale si connotano con questi termini quei progetti:

• con obiettivi non del tutto chiari a priori, con focus sul beneficio e valore aggiunto per il cliente più che sulle specifiche di consegna, in possibile evoluzione;
• in un contesto con fattori ambientali (interni ed esterni) instabili e turbolenti ovvero a forte connotato tecnologico;
• con obiettivi temporali spesso al limite e una necessaria frequente ri-pianificazione;
• con risorse umane difficili da reperire e da gestire (a volte anche team virtuali, collaborativi a distanza attraverso le nuove tecnologie web), con “stress” causato dall’elevata incertezza e dai frequenti cambiamenti.

Il rischio e l’incertezza in tali progetti è superiore rispetto a quelli tradizionali, ma non è sufficiente il Risk Management classico, che pur appartiene al bagaglio del Project Management in quanto:

• la maggior parte dei rischi non sono identificabili in tempo,
• né è possibile pianificare per tempo una conseguente risposta ai rischi,
• spesso non vi è separazione riconoscibile fra pianificazione e controllo (che è un assunto del Project Management), ma è richiesto continuo adattamento, ancorché pre-accettato e governato.

Se allora l’innovazione richiesta è sempre più accentuata, come gestire tali progetti?

• Utilizzando tecniche più “leggere” (è il concetto Lean della semplificazione, oggi in gran voga), ma da applicarsi addirittura con maggior rigore;
• rinunciando a una pianificazione e a un controllo totali per concentrarsi sulle cose essenziali, in altri termini adottando la filosofia del “poco ma senza compromessi”;
• passando da una logica di perseguimento di un piano ad una logica di predizione di scenari;
• privilegiando la flessibilità e non necessariamente il piano, per cui l’output del progetto (“deliverable”) è in divenire e guidato dal cliente/committente (o target di mercato) dall’inizio fino alla conclusione del progetto.

L’ “Agile Manifesto” pubblicato dalla Agile Alliance (www.agilealliance.com) considera come fondamenti delle metodologie agili:

• gli individui e le interazioni più dei processi e degli strumenti,
• il prodotto funzionante per gli scopi più che l’esaustività dell’output di progetto,
• la collaborazione col cliente più che la negoziazione del contratto.

Gli approcci agili propongono un insieme di linee guida e di principi che, in taluni contesti (ad esempio nello sviluppo software), prevedono un sforzo ridotto durante la fase iniziale di definizione dei requisiti e un loro continuo aggiornamento. Conseguentemente alcune decisioni strategiche relative al processo di sviluppo vengono posticipate in modo da diminuire il costo del cambiamento ed operare scelte in condizioni di massima disponibilità informativa.

Per adottare una strategia di questo tipo sono fondamentali le abilità e le capacità delle persone: la riduzione della documentazione di progetto (la conoscenza esplicita) far aumentare la necessità di una corretta condivisione delle conoscenza implicita (quella nelle persone). Il ruolo centrale delle persone contribuisce pertanto a spostare l’accento dalle “regole di progetto” ai “comportamenti durante il progetto”.

L’elemento chiave della gestione del progetto si sposta sulla comunicazione fra il cliente e l’esecutore del progetto, caratterizzando la gestione agile da quella tradizionale, orientata più a fissare regole legate ad esigenze di processo o di carattere tecnologico che le persone devono rispettare.

Le metodologie di Project Management “ortodosse”, adatte ai progetti tradizionali, sono pesanti. Il loro obiettivo principale consiste nel descrivere la realtà e tutte le sue variabili in un unico “piano di progetto”, che occorrerà poi implementare al fine di realizzare gli obiettivi pianificati sulla base delle specifiche definite in fase di avvio. In altre parole, attraverso tale piano, i project manager si prefiggono come obiettivo principale quello di prevedere e pianificare in dettaglio, in un orizzonte temporale piuttosto ampio, buona parte delle attività di progetto. E’ facile dunque capire come questo tipo di metodologie risultino efficaci soltanto per quei progetti caratterizzati da contesti stabili, lineari e prevedibili, dove tutte le variabili in gioco sono definite, individuabili e stabili.

Gli approcci agili, spesso iterativi, adottano una gestione dei tempi e dei costi con una logica che tende ad adattare l’ambito di progetto ai cambiamenti, ponendo come prerogativa la flessibilità ed incentivando la rapidità di sviluppo e il massimo valore erogabile rispetto ai vincoli concordati. I modelli agili sono finalizzati ad un continuo coinvolgimento del cliente in tutte le fasi caratterizzanti il ciclo di vita del progetto.

I progetti agili sono “leggeri”, caratterizzati da pochi documenti, poche pratiche e poche regole.

In sintesi, si può affermare che l’Agile Project Management è adattivo piuttosto che predittivo, con un rapid planning (focalizzandosi cioè solo su ciò che al momento è realmente prevedibile, e importante, che può essere poco e pertanto la pianificazione è rapida) e frequenti quick meeting di avanzamento (anch’essi brevi, ma frequenti, dato che questo è il ritmo del mercato e/o dell’innovazione).

Non a caso, una delle tecniche agili più efficace (e adottate) è lo SCRUM, che prende il nome proprio dalla “mischia” nel gioco del rugby. Lo SCRUM è anche un esempio di come invero le tecniche agili non necessariamente sostituiscano il Project Management canonico, ma lo integrino laddove necessario. La stessa nuova edizione del testo di riferimento dello standard del Project Management (il PMBOK – “Project Management Book Of Knowlege” del PMI – Project Management Institute), nell’ultima edizione, la sesta, di Settembre 2017, prevede in aggiunta un’Agile Practice Guide, commentata come “la coppia perfetta” (“the perfect pair”).

Infatti lo SCRUM utilizza i metodi di gestione del progetto prescritti dal PMBOK (a livello macro) pur mantenendo un carattere iterativo ed una gestione delle iterazioni prettamente agile (a livello micro). In altre parole, è possibile sovrapporre la metodologia SCRUM al ciclo di vita proposto dal PMBOK a due diversi livelli di pianificazione. Il primo, a “grana grossa”, è il livello di rilascio, in cui la corrispondenza è pressoché perfetta con l’ortodossìa del Project Management: le fasi di start-up, pianificazione, esecuzione, monitoraggio e controllo e chiusura sono interpretate da un punto di vista prettamente gestionale, prediligendo ed indirizzando espressamente aree di processo fondamentali come la gestione dell’ambito, dei costi, dei tempi, della qualità, delle risorse umane, comunicazioni e tutti i processi manageriali descritti nel PMBOK. Il secondo livello, quello “a grana fine”, è il livello di iterazione.

Un progetto SCRUM, comincia con la definizione di una “vision”, che include le previsioni sul ritorno dell’investimento, sui rilasci e sulle principali milestones. La pianificazione delle attività è basata sul cosiddetto product backlog, una lista iniziale dei lavori da eseguire che comprende tutte le funzionalità ed i miglioramenti tecnologici espressamente ideati per il progetto.

La principale attività è lo sprint. Il processo SCRUM è infatti iterativo e suddiviso in una serie di sprint successivi, ognuno dei quali può durare da una settimana ad un mese. Ogni sprint comincia con un meeting per la pianificazione, organizzato dallo SCRUM master. Il meeting è suddiviso in due momenti. Nella prima parte si incontrano SCRUM master e SCRUM team al fine di:

• identificare un obiettivo per lo sprint e fornire una descrizione generale del lavoro da portare a termine durante lo sprint, al fine di concentrare gli sforzi di tutti in un’unica direzione;
• dare priorità agli oggetti (“items”) rimasti da fare o introdurre aggiunte al “product backlog”;
• selezionare il maggior numero di oggetti realizzabili per la fine dello sprint.

Durante la seconda parte dell’incontro di pianificazione vengono organizzate le attività:

• identificando per ogni oggetto selezionato uno o più compiti (“tasks”);
• aggiungendo compiti laddove necessario a portare a termine lo sprint entro i termini e pervenendo agli obiettivi stabiliti.

SCRUM utilizza cicli di sviluppo incrementale piuttosto brevi, al fine di implementare gli item contenuti nel product backlog. Alla fine dello sprint avviene il delivery della nuova funzionalità sviluppata. Il processo è iterativo e si ferma quando sono state implementate tutte le caratteristiche richieste o se il committente considera completato il progetto.

In conclusione, le tecniche agili non sono quasi mai scollegate nè autonome rispetto al Project Management classico, bensì lo integrano e completano per rispondere maggiormente alle caratteristiche di molti progetti attuali. Parimenti molta strada va ancora fatta per realizzare compituamente questa integrazione.

 

A cura di: Stefano Tonchia