SCRUM WARS — Episode I: the Waterfall menace

Dialoghi semiseri sul Project Management

Ciao e benarrivata/o: siamo Mauro e Michael, piacere!

Il nostro obiettivo è di riuscire a spiegare — raccontando una storia realmente accaduta — le principali differenze tra Agile e Waterfall, in modo semplice e soprattutto imparziale.

Mauro difenderà il più tradizionale approccio Waterfall, mentre Michael cercherà di dimostrargli dove (e soprattutto se) Agile è meglio …

(Trovi le nostre bio in fondo)

I tuoi commenti saranno preziosi anche per “indirizzare” meglio i prossimi posts, per cui … ci possiamo contare?

Bene, iniziamo!

No, dai seriamente, tutto ebbe inizio quella volta, in occasione di un incontro periodico tra operatori del settore IT (… insomma, i soliti nerd, diciamolo :D), quando a Michael fu chiesto di illustrare qualche slide per riepilogare, brevemente (10 minuti!) le principali differenze tra Waterfall e Scrum ma durante la preparazione … forse è meglio lasciare la parola ai protagonisti.

Immagina di poter viaggiare nel tempo … eccoci trasportati qualche anno fa, un Venerdì pomeriggio a Londra …

[Mauro]

Da qualche tempo mi chiedevo “Cos’è davvero Agile? Funziona veramente? O è solo una cosa che oggi “fa figo”? Ma soprattutto, una cosa moderna, americana e fighetta, può funzionare in Italia su tecnologie tradizionali?” Con questi — e altri dubbi — di base ero stato incuriosito dall’agenda che menzionava una presentazione relativa al “fantomatico” Scrum, una delle anime di Agile.

Arrivato con un po’ di anticipo, durante i momenti di preparazione, mi trovo davanti il relatore, un tale Michael: si presenta bene, professionale, molto preparato, usa un linguaggio comprensibile, però… a naso mi sembra che dica un sacco di cose interessanti ma di difficile applicazione nel mestiere di Project Manager tradizionale, per esempio su SAP.

Comincio allora a convincermi che forse avevo ragione: è la solita “roba fighetta americana” che con gli Italiani non funzionerà mai… approfitto del fatto che siamo ancora in pochi e comincio a fare qualche domanda esplorativa … con una piccola vena polemica:

Michael, io non sono un esperto. A proposito di Scrum, Kanban e “metodologie agilì” ho giusto sentito dire qualche affermazione surreale. Tipo che si fanno i progetti senza stima, o che il cliente ti paga a mano a mano che rilasci, o che la governance del team di sviluppo è in mano agli sviluppatori… [segue risatina].

Ma mi spieghi com’è possibile stimare un progetto senza fare un’analisi preliminare di tutto il lavoro che andrà fatto? Come fa un cliente a firmarti un ordine senza sapere quanto gli costerà alla fine?”

[Michael] Beh Mauro, questo è forse IL problema.

Lasciamo stare le “leggende metropolitane” che mi hai appena menzionato. [segue risatina]

Per “abbracciare” davvero Agile è necessario innanzitutto che questo vero e proprio cambio di paradigma sia accettato non solo dal Fornitore ma, soprattutto, dal Cliente… “hai detto niente!” mi dirai!

Appunto: mica è un lavoro semplice! Si tratta di “spostare” la fiducia che “mi farai XY nel tempo ZY per il costo XZ” verso “so che mi darai quello che mi serve — e servirà — ad un prezzo profittevole per entrambi”.

Ogni “rivoluzione” ha bisogno di partire da un punto…Seguimi.

Con Waterfall sia il Fornitore che il Cliente — in perfetta buona fede entrambi — sono incrollabilmente convinti che il prodotto X “spaccherà e che sarà un successo” e si accordano sul costo Z, magari con una variabilità del X % perchè sanno che c’è un alea di incertezza.

A questo punto viene a me di farti una domanda chiusa: 

vista la durata lunga o lunghissima dei progetti Waterfall (non meno di 6 mesi o un anno), cosa succede se a metà — o peggio ancora, quasi alla fine — si scopre che la tecnologia usata è diventata obsoleta o i potenziali Utenti/Clienti hanno cambiato idea, o se un agente esterno richiede che la soluzione sia radicalmente rivista?

La risposta che mi sono sempre sentito dare (e ti confesso, davo anche io quando ero un PM Waterfall…) era:

“Come si è sempre fatto, si butta via tutto e si ricomincia da capo: è parte del rischio”

Con l’approccio Agile, quantomeno, questo rischio è scongiurato (e il Cliente ottiene una versione del software non completa certo, ma funzionante e testabile dal Mercato molto, molto prima).

[Mauro] Come fai a convincere un cliente a pagarti ad ogni singolo rilascio?

[Michael] Già.. questa è una bella sfida. In effetti, se non ne vengono percepiti i benefici di medio-lungo periodo, Agile non sarà mai accettato da un Cliente abituato da sempre all’approccio Waterfall. Capirai che questo è uno scoglio molto difficile da superare.

In più di un’occasione mi è capitato di vedere la “conversione” ad Agile solo dopo esperienze disastrose con Waterfall … l’essere umano è solito apprendere dai propri errori… anche se non sempre.

[Mauro] Si, la teoria mi sta anche bene, ma nella realtà, quando fai un progetto vero, con un cliente vero, al massimo puoi chiedere un anticipo, puoi avere una milestone di fatturazione al collaudo, ma i soldi “veri” sempre solo alla fine li becchi… se li becchi!

[Michael] Come darti torto … in effetti questo è uno degli equivoci più frequenti in merito ad Agile.

Premesso che il “singolo” rilascio deve consegnare valore al Cliente (funzionalità che permettano a lui o di generare cash flow o di risolvere un problema che gli costa denaro) è come se — permettimi l’azzardo — si chiudesse un “mini-progetto waterfall” ad ogni release.

Come accennato prima, con Agile il Cliente — ad ogni rilascio — ottiene SOLO codice funzionante, testato e perfettamente compatibile con quanto rilasciato in precedenza!

Non pensi che sia, addirittura, disposto a pagare di più? ;)

[Mauro] Uhm … ci devo pensare… 

Un altra cosa: dimmi come fai a dire al manager/proprietario dell’azienda cliente che non deve impicciarsi e deve lasciar lavorare il team?

[Michael] Io lo chiamo, simpaticamente, “effetto Umarell”.

No, dai non fare quella faccia … [sorride]… hai presente “gli omìni”, spesso distinti pensionati col cappello, che stazionano davanti ai cantieri sotto casa?

“No, no non si fa mica così … ma cosa fa quello la? Maddaiii … più acqua!Ci vuole più acqua nella malta!”.

Se ci pensi, essendo gli abitanti della strada nella quale vengono fatti i lavori, sono loro “i Clienti” del Cantiere e dunque si sentono autorizzati a “dare il loro contributo” …

Ora …. mettiti nei panni degli operai o, meglio, del capomastro che è alla sua trilionesima costruzione di una rotonda: che “valore aggiunto” dà questo “controllo”? … ci vuol pazienza, no?

Tornando al nostro caso, siamo tutti d’accordo che se esiste un rapporto di fiducia Cliente/Fornitore; il Cliente mica viene in Azienda ogni giorno a “toccare con mano” come procede il “cantiere”.

Allo stesso modo, in Scrum è previsto che nemmeno il titolare dell’azienda (che paga gli stipendi, per inciso) si metta a sindacare il lavoro dei programmatori … deve riferirsi al Product Owner, il quale è, per l’appunto, responsabile dei risultati che ha promesso al Titolare, esattamente come questi ha fatto con il Cliente finale.

[Mauro] Mah! Sarà, ma non mi hai convinto. Mi sembra di capire che Agile possa essere utile solo per sviluppare un’app indirizzata al mercato consumer, dove non hai un cliente diretto che ti da le specifiche ma sei tu a dover immaginare le specifiche in base alla tua conoscenza del mercato, dove sviluppi per un mercato che è in costante cambiamento e a cui devi poterti adattare rapidamente, dove i requisiti iniziali cambiano normalmente in corso d’opera, dove hai un prodotto di base che si realizza rapidamente su cui poi costruisci sopra 1000 addon, ognuno con un proprio valore, per cui ha in sostanza un progetto potenzialmente senza fine.

Lì la capisco, sembra fatto apposta. Ma su un progetto per un prodotto gestionale qualsiasi come ti metti?…

[Michael] Giusta osservazione! Ecco, vedi … ehi, mi dicono che devo iniziare: lo vedrai tra poco …

La presentazione inzia con questa slide …

[To be continued …]

Mauro, imprenditore IT — oggi CIO/CTO di un gruppo di aziende IT operanti in Italia, UK, USA e Russia — è un ex Project/Program Manager SAP di lunga data in grandi realtà corporate; legato a metodologie di progetto tradizionali di tipo Waterfall, non nasconde una sana ma costruttiva diffidenza per Agile.

Michael, ex Project Manager Waterfall (ERP, CRM, prodotti software verticali), è oggi “Agilista” convinto, certificato come Scrum Master e Scrum Coach, ghostwriter part-time nella comunicazione sui social media.