Di Marco Passarella
—-
Mercoledì 12 luglio è andata in onda un’altra puntata di “Sfatiamo i miti di Scrum”, la serie di webinar di Agile Made in Italy nata per coloro che stanno utilizzando il framework Scrum in azienda, ma incontrano difficoltà ad applicarlo concretamente e si stanno chiedendo come migliorare il loro approccio Agile.
Abbiamo ascoltato l’esperienza sul campo dei membri di Agile Made in Italy: Vittorio Polizzi, Kanban Coaching Professional e Matteo Toto, CTO della startup Unguess e agilista di lunga data. Insieme a loro ho avuto modo di conversare su come superare alcuni degli ostacoli più comuni nell’applicazione di Scrum.
Il primo mito che abbiamo sfatato è “La velocity è la performance del team”. Partendo dal presupposto che la velocity è un indicatore interno al team, un numero empirico che ha senso soltanto all’interno dello sprint e ricavato semplicemente dalla somma degli story point, abbiamo concordato che non avrebbe senso prendere questa metrica come indicatore di performance del team. La velocity, infatti, può essere “sexy” quando si impenna, ma l’obiettivo deve essere la stabilità, segno che il team ha raggiunto un ritmo di lavoro sostenibile. Da qui l’importanza di valutare i trend: è l’andamento della velocity che ci deve interessare, e che può essere argomento di retrospective quando vediamo che la curva inizia ad avere dei picchi incontrollabili, sia in positivo che in negativo.
Il secondo mito che è emerso dalla discussione è “In Scrum si rilascia solo a fine sprint”. La falsità di questo assunto è data dal fatto che Scrum nasce proprio per consentire rilasci di prodotto molto veloci. Per farlo però servono qualità, disciplina e coraggio. Rilasciare molto frequentemente consente di ottenere cicli di feedback più rapidi. Questo è molto vantaggioso, anche se, soprattutto all’inizio, questo può avere dei costi, soprattutto sul piano emotivo del team, che vive il momento di portare un incremento in produzione con l’ansia che qualcosa possa andare storto. Ma la verità suggerita dall’esperienza è che rilasciare frequentemente abbatte drasticamente il rischio. Un punto importante è legato alla competenza del team e alla propensione all’utilizzo delle tecniche di sviluppo più aggiornate. Se i developer utilizzano politiche di rilascio basate su automazione, continuous integration, continuous deployment, rilasci in produzione su subset di utenti, allora possono affrontare il delivery con maggiore tranquillità. Si è parlato anche di code review applicata al lavoro dei dev, non tanto come strumento di giudizio sull’operato del singolo, ma come salvaguardia del prodotto. In questo modo diventa un fattore di responsabilizzazione e di crescita per tutto il team. Queste pratiche vanno anche a far parte della Definition of Done, a conferma del fatto che la qualità del prodotto è sempre al primo posto.
Infine, dall’ambito dello sviluppo, ci siamo spostati a quello del business, mettendoci dalla parte di un cliente con il mito “Se lavori Agile non so per cosa pago”. Il cliente può non essere disposto a pagare per un prodotto che ancora non sa quale direzione prenderà. La prima considerazione è che serve un allineamento culturale tra cliente e fornitore, che devono perdere questa connotazione e iniziare a sentirsi partner. Deve essere un rapporto in cui entrambi gli attori sono dalla stessa parte. Quando si crea questa alleanza, allora si comprende che è impossibile mettere nero su bianco tutto il dettaglio all’inizio. Si possono condividere gli obiettivi (outcome), ma poi per quanto riguarda le soluzioni tecniche (output) in Agile si può cambiare rotta anche di mese in mese. Un’esperienza emersa nella discussione ha di fatto evidenziato come una possibile soluzione sia quella di iniziare un rapporto di collaborazione riducendo al minimo il progetto. Se invece di concordare uno sviluppo di un anno o di sei mesi, si concorda di sviluppare un MVP (Minimum Viable Product), un mini prototipo funzionante, si ha la possibilità di vedere subito risultati concreti, di ottenere qualcosa di funzionante e di validare l’efficacia della metodologia di lavoro. In Italia c’è ancora molta diffidenza verso l’approccio Agile, ma molti segnali positivi stanno emergendo, e non solo nel privato, ma addirittura anche nella Pubblica Amministrazione. Abbiamo parlato infatti dell’esperienza di INPS, che ha rinnovato un servizio sviluppando in Agile e con un contratto del tipo “money for nothing, changes for free”: se nel tempo cambiano i requisiti, il cliente può chiedere di cambiare il prodotto, senza costi aggiuntivi (changes for free). Allo stesso modo, se lo sviluppatore raggiunge gli obiettivi prima del tempo, gli viene corrisposto l’intero compenso pattuito (money for nothing). La diffusione di questa mentalità è un ottimo segnale per il nostro Paese.
Come sempre in questi incontri, c’è stata una bella sinergia tra tutti i partecipanti, con interventi inattesi e di grande spessore. Noi di Agile Made in Italy continueremo a incontrarci regolarmente per sfatare altri miti, se anche tu hai in mente delle convinzioni errate su Agile e Scrum che vorresti approfondire, proponi il tuo mito! Scrivimi a m.passarella@agilemadeinitaly.com e capiremo insieme come inserirlo nei prossimi momenti di incontro.
A presto con altri miti di Scrum!
Sfatiamo altri miti di Scrum – #2