Waterfall contro Agile sembra essere il grande dilemma di chi gestisce progetti informatici. Per più di 10 anni l’implementazione di un ERP ha seguito logiche rigidamente tradizionali, in questi ultimi anni invece si sente sempre più parlare di approccio agile. Allora mi domando: è veramente così rivoluzionario? Si può implementare un ERP in modo agile?
Quando parlo di approccio tradizionale intendo quello chiamato “a cascata” o “Waterfall”, perché si basa su una sequenza ben definita di macro-steps: concettualmente non si passa allo step successivo senza aver terminato quello precedente.
In generale la maggior parte degli articoli che troverete su internet vi diranno che Il “Waterfall” è il metodo da seguire per progetti con budget e tempi definiti, mentre il metodo Agile è perseguibile in condizioni più flessibili, in cui il focus è sulle esigenze di business. Ma è proprio vero?
Le principali differenze tra Waterfall e Agile
Capiamo le differenze tra Waterfall e Agile. Da sempre le aree di governo di un progetto sono tempi, costi e scopo: queste tre aree sono in trade off e compito del PM è trovare il giusto equilibrio.
- In generale l’approccio sequenziale “Waterfall” privilegia lo scopo (inteso come ambito di progetto e deliverable) e vede la stima dei costi e dei tempi come una conseguenza delle specifiche dei deliverables.
- Gli approcci agile si concentrano sui tempi e costi e li gestiscono in modo “Timeboxing”, modificando l’ambito di conseguenza. Lo scoping diventa flessibile in funzione dei vincoli temporali e di costi.
Waterfall e Agile: perché ricercare un approccio ibrido?
Nei progetti ERP può capitare che i requisiti di dettaglio cambino durante la conduzione del progetto, è quindi difficile averli ben definiti e documentati. In questo contesto un approccio integralmente “Waterfall” è spesso complesso da implementare, mentre possono essere facilmente superati con un approccio iterativo.
Per capire quale è l’effetto pratico dei due approcci capiamo come si muovono idealmente i costi di pianificazione del progetto e i costi di gestione delle modifiche progettuali.
In pratica un sistema Agile tende ad essere abbastanza indifferente ai cambiamenti di ambito e di requisiti iniziali; al contrario un sistema “Waterfall” è molto sensibile ai cambiamenti di requisiti in modo particolare se fatti verso la fine del progetto.
Come sviluppare un approccio ibrido, sia Waterfall che Agile, ai progetti ERP
Prima di tutto chiariamo che l’adozione di un approccio iterativo di tipo agile non comporta l’abbandono del governo progettuale.
Il PMBOK® (primario standard di PM a livello mondiale) contiene al suo interno logiche iterative. Non si tratta di scegliere tra l’uno o l’altro approccio, quanto capire modalità di utilizzo e aree di integrazione.
Da qui quindi la possibilità di adottare degli approcci ibridi al progetto in assoluta coerenza con quelle che sono le “best practice”.
Nella realtà possiamo trovare varie forme di ibridazione. Per esempio un approccio concomitante:
- limitato ad alcune unità organizzative che utilizzano uno o l’altro
- limitato ad alcuni progetti
- la pianificazione di alto livello utilizza un approccio tradizionale, la pianificazione di dettaglio un approccio agile
Nel caso di un approccio misto, possiamo trovare diversi strumenti.
- Nei progetti dove si usa un approccio waterfall, troviamo le seguenti contaminazioni:
- incontri di coordinamento e avanzamento in stile scrum
- analisi di Lesson learned (lezioni apprese) fatto ad ogni rilascio o riunione,
- congelamento dei team fisso per l’intera durata dello sviluppo
- In progetti sostanzialmente agili:
- introduzione delle milestone per un analisi di alto livello
- strumenti di riporto verso il managment e gli stakeholder.
Waterfall vs agile, quale metodologia adottare?
Nella mia personale esperienza il modello migliore è una ibridazione orizzontale (molto simile a quello descritto dal Il PMBOK®).
Questo approccio ibrido adotta una tradizionale struttura Waterfall di WBS, identifica i risultati fondamentali del progetto come Mileston, e li organizza per l’approvazione del progetto con un Gantt.
Una volta che il progetto è stato approvato (con una visione a cascata Waterfall), si può passare a un approccio agile in cui vengono mantenuti un backlog contenente le singole attività di progetto, le funzionalità del sistema e le user stories, da cui verranno estratte quelle a massima priorità per essere sviluppate; in genere questo approccio agile nelle implementazioni ERP si concentra in elementi che noi chiamiamo RICE cioè (Report, Interfacce, Conversioni, Enanchment cioè personalizzazioni).
Waterfall e agile si alternano, la vista del progetto cambia dal tradizionale diagramma di Gantt a un elenco di RICE che consente l’assegnazione dinamica delle funzionalità alle iterazioni (esattamente come fossero degli SPRINT); in questo modo in qualsiasi momento, spesso su base giornaliera, il PM è in grado di aggiungere, eliminare e modificare il backlog per riflettere le mutevoli esigenze aziendali.
In effetti i RICE sono elementi agile esattamente come SPRINT; alla fine di ogni RICE viene fatta una pausa per una valutazione retrospettiva e per implementare i miglioramenti. Successivamente viene riesaminato il backlog di RICE e selezionate le funzionalità a maggiore valore aggiunto per la prossima iterazione. All’interno di ogni RICE, il team può utilizzare principi agili come l’incontro quotidiano e discutere lo stato del lavoro programmato per l’iterazione in corso.
Un fattore chiave del successo dei principi Agili è la capacità di implementare la soluzione definitiva attraverso rilasci incrementali.
Inoltre, è possibile ottenere una rapida convalida della soluzione, in modo che eventuali aggiustamenti possano essere facilmente presi in considerazione attraverso le funzionalità rimaste nel backlog del RICE.
Non appena i RICE ad alta priorità saranno stati completati, il progetto potrà tornare a un ciclo Waterfall per svolgere le attività di implementazione standard.
Conclusioni
La scelta delle modalità di implementazione di un sistema ERP è una scelta importante tanto quanto la scelta del prodotto.
Anzi ritengo forse più importante perché una cattiva implementazione è in grado di fare danni indifferentemente dal prodotto prescelto, mentre una buona implementazione è in grado di estrarre valore anche dalla implementazione di un software mediocre.
Le moderne tecniche di project management sono fondamentali per massimizzare l’investimento fatto in un ERP, ma la loro adozione deve essere discussa fin dall’inizio, condivisa con il cliente nelle sue implicazioni, e soprattutto essere supportata da un adeguato impianto contrattuale.
