Corsi Agile vs Traditional Project Management: una guida per scegliere
INTRODUZIONE
L’Agile project management e lo sviluppo software sono diventati temi caldi negli ultimi anni. Ad oggi, però, l'enfasi sembra essere su come passare da un approccio tradizionale ad uno Agile, abbandonando completamente l'approccio tradizionale.
Mentre Agile potrebbe essere l'approccio migliore per alcuni progetti, altri progetti richiedono ancora il rigore di un approccio più tradizionale. Ad esempio, l'aggiornamento di un sistema finanziario può richiedere una documentazione specifica per conformarsi a Sarbanes-Oxley. In che modo un'organizzazione dovrebbe decidere quale approccio adottare? Un'organizzazione deve utilizzare un solo approccio? L'approccio può essere modificato nel mezzo del progetto?
In questo articolo discuteremo come decidere l'approccio migliore in base a parametri chiave come il livello di rischio, il livello di incertezza e la velocità di consegna.
Tuttavia è bene ricordare sempre che l'approccio scelto dovrà essere adattato alle esigenze e al contesto dell'organizzazione.
Occorre inoltre ricordare che è necessario considerare una serie di fattori che non verranno discussi, come la gestione del cambiamento organizzativo, la formazione, il supporto alla gestione e il coaching.
PROJECT MANAGEMENT TRADIZIONALE
Il Project management è una pratica secolare. Il Project management come pratica lo si può trovare nella realizzazione delle Piramidi o del Taj Mahal o anche in progetti più moderni di sviluppo di autostrade, strade, ponti, nuove città, nuove ferrovie e nuovi prodotti per citarne alcuni.
Il Project Management è una disciplina costituita da un insieme di pratiche, strumenti e tecniche collaudate che vengono applicate nella gestione di un progetto. Secondo molte definizioni, il progetto è uno sforzo temporaneo intrapreso per creare un prodotto, un servizio o un risultato unico. Il risultato di un progetto è sempre qualcosa di unico, qualcosa di nuovo.
Per la maggior parte dei prodotti, come la costruzione di infrastrutture tradizionali, il team può definire e stabilire in anticipo l'intero requisito del prodotto finale. Quindi l'intero progetto può anche essere pianificato in dettaglio in anticipo. Si presume inoltre che il numero di modifiche sia relativamente basso. L'intero sviluppo del progetto può diventare prevedibile. In tali progetti, è possibile definire una serie di attività per il progetto come l'avvio, la pianificazione, l'esecuzione, il monitoraggio e il controllo e la chiusura, ecc. Tutte le attività si svolgono in sequenza. L'intero ciclo di vita del progetto è suddiviso in più fasi e il lavoro viene completato fase per fase. Il project management tradizionale utilizza un modello di sviluppo a cascata, in cui una fase viene completata prima che la fase successiva possa iniziare. Alla fine, il prodotto o servizio finale è pronto. Strumenti come la struttura di ripartizione del lavoro, i diagrammi di Gantt sono ampiamente utilizzati.
Una metodologia tradizionale di project management è spesso impacchettata come un toolkit che viene utilizzato per gestire progetti in cui sono presenti una serie di contenuti dettagliati, come ad esempio:
- Principi
- Processi
- Procedure
- Linee guida
- Modelli
- Liste di controllo
- Strumenti
- Definizioni di Ruoli e Responsabilità
Le procedure possono essere raccolte in un manuale di project management e contenere l'approccio alla gestione dei progetti passo dopo passo.
iLEARN® propone molti corsi riguardanti gli approcci tradizionali di project management. Per maggiori dettagli:
- APM, https://www.innovativelearning.eu/it/prodotti/association-for-project-management-apm.html
- PMI, https://www.innovativelearning.eu/it/prodotti/pmi.html
- Praxis Framework, https://www.innovativelearning.eu/it/
- PRINCE2® https://www.innovativelearning.eu/it/prodotti/prince2.html
AGILE PROJECT MANAGEMENT
Il Manifesto per lo Sviluppo Software Agile (© 2001) stabilisce i valori fondamentali per l'approccio Agile:
“Stiamo scoprendo modi migliori per sviluppare software facendolo e aiutando gli altri a farlo. Attraverso questo lavoro siamo arrivati a valorizzare:
- Individui e interazioni su processi e strumenti
Software funzionanti su documentazione completa
Collaborazione con il cliente nella negoziazione del contratto
Rispondere al cambiamento seguendo un piano
Cioè, mentre c'è valore negli articoli a destra, apprezziamo di più gli articoli a sinistra. (Agilemanifesto.org, 2001)”.
Sebbene il manifesto si concentri sullo sviluppo del software, i principi si applicano anche alla gestione dei progetti.
Tutti i metodi di agile project management hanno alcune caratteristiche comuni, come ad esempio:
- Concentrarsi sulla creazione del valore e sulla soddisfazione del cliente
- Tempi di consegna rapidi
- Adattamento continuo
- Concentrarsi sulla collaborazione
- Maggiore trasparenza
- Test rapidi e frequenti
- Un passo alla volta (costruire per iterazioni)
- Personale motivato e autonomo
- Comunicazione efficiente
Le metodologie per agile project management interpretano e dettagliano con un'enfasi diversa alcuni elementi che costituiscono un approccio tradizionale di project management (tipicamente processi, procedure). Gli approcci di agile project management rimangono "leggeri" o "semplificati".
iLEARN® propone molti corsi riguardanti gli approcci di agile project management. Per maggiori dettagli:
- AgilePM®, https://www.innovativelearning.eu/it/prodotti/agilepm.html
- PRINCE2® Agile, https://www.innovativelearning.eu/it/prodotti/prince2-agile.html
- Scrum, https://www.innovativelearning.eu/it/prodotti/scrum.html
Inoltre i corsi AgileLearn®, https://www.innovativelearning.eu/it/prodotti/agilelearn.html, offrono un’ottima panoramica degli approcci di gestione Agile e di come utilizzarli nel project management ma anche in altri contesti, come lo sviluppo di prodotti/servizi e affari come di consueto.
DIFFERENZE TRA AGILE E PROJECT MANAGEMENT TRADIZIONALE
Allora, qual è la differenza tra il project management tradizionale e quello Agile?
Tipicamente, le metodologie Agile non sono così dettagliate come la metodologia tradizionale. Ciò supporta l'idea di "individui e interazione su processo e strumenti" contenuta nel manifesto Agile. Sebbene possano esserci linee guida generali nell'approccio Agile, non ha i dettagli forniti con l'approccio tradizionale. Ci saranno meno modelli e passaggi procedurali meno specifici nella metodologia Agile.
I principi Agile sottolineano un prodotto funzionante rispetto alla documentazione. Per questo motivo, l'approccio Agile passa più rapidamente all'esecuzione e dedica meno tempo alla pianificazione. Non sono inclusi piani complessi di project management, documenti dettagliati sui requisiti o documentazione di ruoli e responsabilità, che sono documenti di pianificazione chiave di una metodologia tradizionale.
Un aspetto chiave degli approcci Agile è l'adattabilità. Il team non solo esamina il prodotto mentre viene sviluppato e apporta modifiche alle funzionalità, ma esamina anche il processo. Alla fine di ogni iterazione, il team conduce una sessione della lezione appresa, spesso definita retrospettiva. Il punto della sessione è rivedere sia il prodotto che il processo. Il team discute come sta andando il progetto e quali modifiche alle procedure aumenterebbero le loro prestazioni. Ad esempio, il team potrebbe decidere di dover modificare il processo di test o modificare il formato delle riunioni.
Nei progetti tradizionali, condurre le lezioni apprese fa parte del processo di chiusura del progetto. Come nell'approccio Agile, un argomento è la revisione delle attività di project management; sebbene eventuali raccomandazioni sui cambiamenti nel processo abbiano un impatto sui progetti futuri piuttosto che sul progetto attuale. Anche se le lezioni apprese vengono svolte alla fine di ogni fase, poiché tale fase non verrà ripetuta per il progetto, le raccomandazioni avranno un impatto solo sui progetti futuri.
Tuttavia, ci sono diversi miti comuni nell’Agile project management. Un mito è che non c'è pianificazione in un approccio Agile. La pianificazione avviene, ma, come lo sviluppo vero e proprio, è un processo iterativo. I team inizialmente pianificano funzionalità di alto livello. All'inizio di ogni iterazione, viene creato un piano più dettagliato per quell'iterazione. Sebbene i piani dettagliati non vengano sviluppati all'inizio, a causa delle incognite, la pianificazione fa sicuramente parte di un progetto Agile.
Così come non ci sono documenti di pianificazione dettagliati sviluppati all'inizio del progetto, non ci sono documenti di requisiti dettagliati. I team di progetto lavorano a stretto contatto con il cliente per definire le caratteristiche del prodotto finale. In questa fase vengono documentate solo le informazioni di alto livello per ciascuna funzionalità; i dettagli vengono determinati durante l'iterazione in cui viene sviluppata la funzione.
Un secondo mito è che i progetti Agile non richiedono project managers. In realtà, il ruolo del project manager è diverso poiché c'è meno enfasi sulle attività di gestione, come pianificazione o bilancio e maggiore enfasi sulla guida del team. Jim Highsmith usa il termine “leadership-collaborazione” per descrivere il ruolo modificato del project manager. Nell'ambiente Agile, i project managers si concentrano sulla comunicazione della visione del progetto, fornendo supporto al team e rimuovendo gli ostacoli che ostacolerebbero il progresso.
COME SELEZIONARE L’APPROCCIO CORRETTO ALL’AVVIO DEL PROGETTO
Come spesso accade, anche nel project management non esiste una soluzione immediata . La decisione di adottare un approccio tradizionale vs. un approccio agile al project management dovrebbe essere basato su diversi fattori. Tra gli altri, i fattori da considerare sono:
- Quanto sono chiari i requisiti? Un approccio Agile si adatta meglio a una situazione in cui i requisiti non sono chiari o soggetti a modifiche, mentre l'approccio tradizionale è più adatto a situazioni in cui i requisiti possono essere chiaramente definiti all'inizio del progetto
- È coinvolta la nuova tecnologia? L'approccio Agile consente una maggiore sperimentazione con le nuove tecnologie. Quando la tecnologia non è nuova, un approccio tradizionale può essere più appropriato.
- C’è molto rischio? Con un approccio Agile, il rischio può essere affrontato prima nel progetto.
- È disponibile il giusto team? Un team Agile è in genere piccolo e composto da membri più esperti. Se il progetto richiede un team più ampio, l'approccio tradizionale potrebbe adattarsi meglio al progetto.
- Qual è la criticità del prodotto o servizio finale? Poiché c'è meno documentazione, un approccio Agile potrebbe non essere appropriato per prodotti critici come lo sviluppo di farmaci o i componenti dello space shuttle. In questi casi è preferibile un approccio più tradizionale.
Sulla base di queste domande, le liste di controllo possono essere utilizzate per valutare i fattori del progetto per decidere l'approccio migliore per qualsiasi progetto. Ovviamente, lo sponsor dovrà sentirsi a proprio agio con la decisione. Se uno sponsor è più abituato a un approccio tradizionale, sostenere un progetto Agile potrebbe potenzialmente creare confusione o conflitto. Si consideri, ad esempio, il reporting sullo stato del progetto. Nell'approccio tradizionale, gli sponsor ricevono in genere un rapporto scritto settimanale sullo stato. Nel mondo Agile, agli sponsor viene detto che devono presentarsi all'incontro quotidiano in piedi per ottenere un aggiornamento sullo stato. Potrebbero resistere a questo cambiamento e chiedere comunque il rapporto sullo stato settimanale. Il project manager dovrà istruire lo sponsor sull'approccio Agile e vendere i vantaggi in modo che lo sponsor capisca come sostiene il progetto in questo nuovo ambiente. In alcuni casi, il project manager potrebbe dover svolgere alcune delle tradizionali attività di project management dietro le quinte per supportare le parti interessate mentre il team avanza utilizzando l'approccio Agile.
Una possibile soluzione e un possibile miglioramento sono approcci ibridi che significa combinare gli aspetti delle metodologie di project management tradizionali con quelle agile. Questa è una tendenza sempre più frequente nell'organizzazione. Ad esempio, un quadro di governance tradizionale basato su diversi team che lavorano su diverse fasi e/o parti del progetto con metodologie diverse, alcune tradizionali e altre agile.
CONCLUSIONI
Ogni approccio ha una serie di vantaggi. Le organizzazioni che utilizzano entrambi gli approcci devono comprendere i vantaggi di ciascuno in modo da poter selezionare l'approccio migliore per un determinato progetto. In alcuni casi l'ibridazione potrebbe essere la strada da percorrere.
In generale, l'approccio tradizionale è più adatto per progetti complessi con team di progetto più grandi. Agile funziona bene con squadre più piccole con livelli di abilità elevati. Tuttavia, questo può essere discutibile poiché negli ultimi anni stanno emergendo e maturando metodologie per scalare approcci agili in grandi organizzazioni e progetti.
Ciò che è indubbio è che l'approccio tradizionale funziona meglio in ambienti più stabili dove c'è poco uso delle nuove tecnologie. Agile funziona bene quando viene utilizzata una nuova tecnologia. Un approccio tradizionale fornisce un livello di documentazione più elevato. Agile funziona bene quando i requisiti non sono chiari o il rischio è elevato.
Sebbene Agile sia flessibile, non è sempre l'approccio più veloce. Sebbene sia vero che una versione funzionante potrebbe essere sviluppata prima, potrebbe esserci anche la situazione in cui viene sviluppata una prima versione del prodotto e, dopo averla rivista, il team ricomincia da capo. Poiché non c'era molta pianificazione, il team potrebbe scoprire come non progettare il prodotto.
Infine, gli approcci tradizionali tendono ad essere più facili da adottare quando parti fondamentali dei progetti sono assegnate a organizzazioni esterne e necessitano di accordi relativamente rigidi. In questi casi è solitamente richiesto di definire con precisione il lavoro e le condizioni con il fornitore e questo si inserisce meglio in un quadro di gestione del progetto tradizionale.