Chi si occupa di Project Management da più di un paio di decenni sa bene che l’introduzione di processi standardizzati e condivisi, avutosi con l’avvento delle metodologie Waterfall, è stato un grande passo avanti. Chi, invece, si è avvicinato al Project Management negli ultimi due lustri definisce le stesse metodologie “pesanti” proprio in contrapposizione con l’approccio Agile. Dove sta la verità? Come sempre, nel mezzo… forse!
Non potevo non dedicare un post alla domande delle domande: “Tra Agile e Waterfall qual è la metodologia migliore? Possono convivere all’interno dello stesso progetto?”.
La letteratura è piena di esempi di integrazione (vedi WaterScrumFall o AgileFall o, ancora, Hybrid Management). Ultimamente ho seguito un interessante webinar che potete trovare qui The war is over: Agile and Waterfall can actually work best together.
Come tutto, tanto Agile quanto Waterfall hanno punti di forza e punti di debolezza.
Waterfall è un insieme di processi sequenziali ben definiti, standardizzati, fortemente strutturati, con input, output e deliverables identificabili e necessari, d’altro canto è poco elastico e molto sensibile alle modifiche in corso d’opera.
Agile è un insieme di linee guida, valori e principi da applicare con metodi iterativi e incrementali focalizzati sulla produzione immediata e continua di valore, d’altro canto non ha processi definiti e standardizzati e non possiede quel livello di strutturazione che spesso viene richiesta in determinati ambiti di lavoro.
Ma allora quale scegliere? E, soprattutto, possiamo integrare le due metodologie?
Risposta in breve, per chi non ha tempo da perdere
Si…. e no! Sta a voi decidere in base a ciò che dovete fare e a con chi lo dovete fare!
Risposta lunga, per chi vuole approfondire
Ogni volta che mi confronto con un nuovo progetto, per prima cosa, cerco di rispondere a due fondamentali domande:
- Che tipo di progetto è (Intelligenza Razionale).
- Chi sono i partecipanti al progetto (Intelligenza Emotiva).
La tipologia di progetto
La tipologia di progetto fa la differenza! Questo coinvolge la vostra Intelligenza Razionale. E’ importante inquadrare l’ambito nel quale ci stiamo muovendo, tramite un’analisi razionale di tutti gli elementi in gioco.
Requisiti certi e predeterminati, presenza di date fisse non modificabili, necessità di deliverables standardizzati da fornire a enti esterni: questi sono alcuni degli elementi che fanno propendere verso una gestione di tipo Waterfall. Spesso si tratta di progetti che hanno come obiettivo la replica di un prodotto o servizio già conosciuto, in cui l’incertezza è minima.
Requisiti incerti, difficoltà nell’identificazione dei must have e delle milestone, necessità di un time to market veloce, possibilità di frequenti, e probabilmente radicali, cambiamenti in corso d’opera: tutto ciò è indice di un progetto da gestire con un approccio Agile. In questo caso ci troviamo di fronte a realizzazione di prodotti o servizi innovativi, dove la sperimentazione sul campo è uno degli elementi portanti.
Per identificare la tipologia di progetto, personalmente, faccio affidamento sul Cynefin Framework. Tramite un semplice esercizio e una veloce analisi il framework mette in condizioni di identificare in quale dominio ci si sta per muovere: Semplice, Complicato, Complesso o Caotico. E in base al dominio di pertinenza possiamo capire quale metodologia è più conveniente adottare. Qui tutte le info sul Cynefin.
I partecipanti al progetto
I partecipanti (e il vostro rapporto con loro) fanno la differenza! Qui parliamo di (e con) Intelligenza Emotiva. Cercare il giusto modo di confrontarsi con i vari stakeholder è tanto importante quanto capire la tipologia di progetto. Cercare la giusta empatia con tutti i partecipanti al progetto è una strategia vincente.
Stakeholder molto strutturati che richiedono continui “stato avanzamento lavori”, che pianificano con largo anticipo le deadline di progetto, con piani di comunicazione verso il pubblico predefiniti, probabilmente si troverebbero in difficoltà con una gestione di progetto Agile. Un GANTT renderà molto più “tranquilli” i partecipanti al progetto che, dati alla mano, sapranno confrontarsi con le varie attività con largo anticipo.
Se gli stakeholder sono invece disposti a partecipare in prima persona alla gestione del progetto, se preferiscono definire le priorità di iterazione in iterazione, se hanno una maggiore elasticità nella comunicazione verso l’esterno allora saranno molto propensi ad adottare una metodologia di tipo Agile. Come sappiamo il coinvolgimento costante del cliente/stakeholder all’interno del progetto è una delle prerogative delle metodologie Agile.
In entrambi i casi l’Intelligenza Emotiva è necessaria per capire come rapportarsi ai vari stakeholder, se ingaggiarli in prima persona o se cercare di non “svegliare il can che dorme”. Un’ottimo esempio per individuare la sfera di influenza degli stakeholder ci arriva da “The Risk Doctor” David Hillson. In base a tre parametri (approccio, potere e interesse) identifichiamo dall’amico del progetto fino al possibile sabotatore. Qui alcune informazioni sul metodo delle sfere di influenza.
In conclusione
Lavorando in ambito digital mi sono capitate situazioni ibride in cui ho dovuto gestire il progetto in modalità “Giano bifronte”: con metodologie Waterfall verso gli stakeholder esterni, fornendo GANTT, descrizione dei processi, Project Charter e Matrici di Comunicazione e con metodologie Agile verso il team di sviluppo, grazie rilasci iterativi e incrementali e con pochissima documentazione tecnica.
Altre volte sono riuscito ad applicare un approccio puramente Agile, anche se in questi casi, è stato più complicato far capire in cosa consiste Agile e cosa avrebbero ottenuto i “clienti”, piuttosto che la vera e propria applicazione.
Fatte queste considerazioni ecco dove, a mio modesto parere, è la verità: sta a voi decidere con quale metodologia avviare, portare avanti e concludere il progetto, puro o ibrido che sia… sempre che ne abbiate la facoltà.
Buon lavoro!
Agile in azione, anche nella vita reale! 
Se la domanda è “Agile o Waterfall?” la risposta non può che essere: “dipende”. Dipende dai fattori che hai bene esposto nell’articolo, utilizzando la chiave di lettura delle due tipologie di “intelligenza”, che riduco a due criteri di assessment iniziale del progetto:
1) Grado di variabilità dello scope (quanto più è alto, tanto più l’approccio Agile è efficace)
2) Possibilità di coinvolgimento attivo degli stakeholders, in particolare il business e il cliente (quanto più essa è concreta, tanto più praticabile è l’approccio Agile)
Il problema è che tra i due estremi da manuale di “progetto deterministico” con scope noto a priori e tempi e costi ricavati di conseguenza (Waterfall) e progetto “innovativo o non deterministico” con scope variabile, cercando di massimizzare il valore rilasciato con tempi e costi predeterminati (Agile) c’è un universo di situazioni intermedie, che possono richiedere approcci utilmente ibridi.
La vera differenza tra Waterfall e Agile, che spesso non emerge, è il differente approccio al “rilascio di valore” da parte del progetto. Con il Waterfall viene rilasciato tutto alla fine del progetto (es. applicazione software, a completamento del collaudo finale) . Con Agile il valore comincia ad essere rilasciato dopo poche iterazioni (es. applicazione software, ogni iterazione rilascia funzioni in produzione). Se anche avessimo parità di effort tra i due casi, il “rilascio anticipato” di valore è un vantaggio innegabile, laddove abbia senso (es. nella costruzione di un ponte non ha senso rilasciare in produzione i piloni senza la campata…, in un’applicazione software ha senso rilasciare un nucleo di funzionalità nel più breve tempo possibile e poi operare per release successive).
Non sono d’accordo solo sulla contrapposizione che fai tra Waterfall come sinonimo di strutturazione e standardizzazione, con input e output verificabili e Agile come una specie di caos creativo, col vantaggio della dinamicità ma senza processi definiti. Ogni metodo Agile ha i suoi processi, i suoi input / output, i suoi deliverable, i suoi attori e ruoli e i suoi cerimoniali. Test Driven Development (da XP), ad esempio, è una strutturazione del processo di sviluppo interamente incentrata sul concetto di test. Le specifiche dei requisiti in Scrum diventano Product Backlog e Sprint backlog, i requisiti stessi non li scrivo in UML ma come user stories, non uso l’Earned Value ma il Burndown Chart e la Velocity per misurare il progresso di progetto e il forecasting di tempi e costi a finire. Insomma, anche nei metodi Agili ci sono struttura, cerimoniali ed artefatti standard. Sono solo differenti da quelli tradizioni perché diverso è il punto di vista.
"Mi piace""Mi piace"
Ciao Marco, grazie per l’approfondito commento a sostegno della mia tesi. Una precisazione sul “caos creativo” Agile: nel post faccio riferimento ai valori e principi espressi nell’Agile Manifesto piuttosto che alle specifiche metodologie ad esso ispirate. Alcune di queste, come giustamente indichi, prevedono attori, ruoli, eventi e deliverables, altre no, ma sono sempre riconosciute come metodologie Agile. E qui sta proprio la contrapposizione che voglio portare all’attenzione di tutti: Agile offre una flessibilità metodologica che Waterfall non prevede. “Valori e principi” da un lato, “Standard e processi” dall’altro. Badando bene che non si tratta di un giudizio di merito; come abbiamo detto, non esiste “il migliore”, ma “dipende”. Grazie e alla prossima.
"Mi piace"Piace a 1 persona
Spero che questo articolo spinga la community degli agilisti a confrontarsi sulle difficoltà incontrate e i successi raggiunti nell’affrontare il dilemma waterfall vs agile. Nelle grandi organizzazioni è sicuramente uno dei primi ostacoli da superare nel faticoso percorso di cambiamento verso l’agilità.
"Mi piace"Piace a 1 persona