Agile o Waterfall? Meglio il Project Management dell’ascolto

Si è molto scritto della differenza tra Agile e Waterfall, le due diverse (e più conosciute) metodologie di Project Management che paiono, impropriamente, costituire i poli opposti della gestione di un progetto.

Molte società si sono lasciate sedurre dal sogno di una repentina semplificazione di processi e procedure - soprattutto nelle aziende di software - incoraggiando i manager e i loro team a diminuire il quantitativo di documentazione prodotta e incentivando la velocizzazione di deployment verso il Cliente.

“Fail frequently, learn quickly” è una suggestiva massima appartenente alla filosofia “Agile” che valorizza un apprendimento costante e rapido grazie a piccoli errori frequenti, ma non così gravi, in modo da correggere continuamente la rotta verso le richieste del mercato\Cliente.

In breve, “micro-innovare” progressivamente per raggiungere i risultati ottimali.

Benché possa apparire uno scenario intrigante e di facile realizzazione, andrebbe ricordato come non ci sia nulla di più complesso della semplificazione e, paradossalmente, l’introduzione di un approccio Agile richiede un progetto Waterfall a monte, che contempli un processo di Change Management aziendale pianificato in ogni suo aspetto e comunicato agli stakeholders coinvolti.

Immaginate la velocità del trasformismo di Arturo Brachetti senza una corretta ideazione, creazione, sequenza e posizionamento dei costumi di scena? Potrebbe mai eccellere semplicemente improvvisando?

In generale, Waterfall ben si adatta a contesti con:

  • Dominio e processi ben definiti
  • Best e Good Practices
  • Risultati predicibili
  • Bassi livelli di incertezza del rischio
  • Basso tasso di change
  • Lavoro procedurale ed automatizzabile

Al contrario, l’Agile è più attinente ai casi dove le criticità nascono da:

  • Soluzioni emergenti in modo iterativo
  • Dominio e processi non definiti
  • Risultati non predicibili
  • Alti livelli di incertezza del rischio
  • Alto tasso di change
  • Lavoro poco automatizzabile
  • Complessi livelli di Problem Solving

Il grafico sintetizza come:

  • se i requisiti sono chiari e la tecnologia è stabile, va decisamente meglio il Waterfall
  • se la complessità aumenta, in termini di requisiti non chiari e\o tecnologia in continuo mutamento, gli altri approcci sono più appropriati
  • se le esigenze del Cliente grondano anarchia, nessuna metodologia riuscirà mai a soddisfarle.

Va da sé che non si tratta tanto di abbracciare o meno una filosofia avveniristica dal sapore new age per dimostrare di essere contemporanei, ma di saper leggere contesti e situazioni per quelli che sono, valutandoli in logica sistemica, mantenendo un fortissimo approccio consulenziale e di “accompagnamento”, nei confronti del Prospect.

AGILE SI, LEGGERO NO

Prima di qualsiasi customizzazione è necessario partire da alcune considerazioni fondamentali:

  • Le scale di grigio che si manifestano durante i primi contatti con un Prospect sono infinite e affrontare questa fase con “leggerezza” o con eccessiva destrutturazione costituirebbe un errore clamoroso, con ripercussioni lungo tutto l’arco della collaborazione (anche se spesso la richiesta è di alleggerire il momento di formalizzazione iniziale perché “così intanto cominciamo a vedere qualcosa”);
  • La definizione del “Modello di Complessità” (quello della figura in alto) è, probabilmente, il primo step da compiere per ridurre il rischio di entropia e fissare nero su bianco i dettagli più salienti del Ciclo di vita del Progetto/Prodotto.

In linea con queste premesse, è proprio la corretta identificazione del terreno d’azione condiviso a costituire il momento fondamentale di reciproca educazione tra Cliente e Fornitore: vanno negoziati i significati prima delle tempistiche.

Forse è proprio questo che rende “agili”: il saper scegliere rapidamente quando non esserlo.

Email