Agile Day 2015: spunti di riflessione

Ore 8 del mattino di un bellissimo sabato. Ascolto il silenzio di un ufficio deserto. Uno scambio di battute con Ilenia e lascio brioche e pizzette sulla scrivania per lei,  Lorenzo, Michele ed Emanuele. Tutti impegnati nelle fasi finali di un progetto complesso e molto importante.
Salgo in macchina per andare in quel di Brescia e seguire l’annuale appuntamento con l’Italian Agile Day (7-8 novembre), dodicesima edizione della conferenza dedicata ai metodi Agili per lo sviluppo e la gestione di progetti software.

La metodologia Agile è un insieme di metodi per lo sviluppo del software, l’organizzazione dei team e la gestione dei progetti che si basa sul Manifesto per lo Sviluppo Agile di Software, i cui principi fondamentali sono:

• Individui e interazioni, più che processi e strumenti
• Software funzionante, più che documentazione esaustiva
• Collaborazione col cliente, più che negoziazione dei contratti
• Rispondere al cambiamento, più che seguire un piano.

Paradigma Agile vs. Paradigma Tradizionale

Il primo speech che ho seguito, di Marco Massarotto, trattava del Paradigma Agile, e si proponeva di andare oltre i limiti del tipico approccio che oppone “Agile” a “Tradizionale”.

Per “Paradigma” si intende il nostro modo di interpretare il mondo.
È limitante contrapporre agile contro tradizionale:

1. Pianificare:
   1. Tradizionale: seguire un piano definito e prestabilito
   2. Opposto di tradizionale: non seguiamo nessun piano
   3. Agile: il piano serve solo ad indicare la direzione e deve essere affinato durante il lavoro
2. Organigramma:
   1. Tradizionale: secondo uno schema top-down, solo il capo decide e gli altri eseguono
   2. Opposto di tradizionale: non c’è nessuna guida e c’è anarchia
   3. Agile: tutti sono sullo stesso piano, e si cerca di stabilire una forte sinergia tra manager e tecnici, secondo un approccio bottom-up
3. Libertà:
   1. Tradizionale: qualcuno ordina e tu fai
   2. Opposto di tradizionale: “lasciami in pace, facciamo quello che vogliamo”
   3. Agile: secondo un principio di libertà responsabile, ci sono leader a disposizione dell’organizzazione per risolvere problemi, e il team è autonomo ma responsabile.
4. La ricerca dell’ottimo:
   1. Tradizionale: a livello astratto si aspira sempre alla perfezione
   2. Opposto di tradizionale: il tecnico non ha bisogno di indicazioni né di essere educato
   3. Agile: si enfatizza il concetto di “evoluzione”. Se un membro del team non conosce qualcosa viene assistito da un coach, che gli fornirà degli strumenti per risolvergli i problemi.

Agile quindi non è antitetico a tradizionale, ma è qualcosa di diverso: un nuovo paradigma, appunto. Lo speech di Massarotto si è concluso accettando l’approccio di “agile nativo”, sganciato da riferimenti a ritroso: è necessario quindi assimilare i principi del metodo agile, comprendere il contesto e discernere per creare la migliore soluzione possibile applicando i principi al contesto.

Come lavorare costantemente sui principi cardine della resilienza

Emiliano Soldi ha parlato della resilienza, cioè la capacità di un sistema di intervenire rapidamente in situazioni di stress per assorbire e rispondere allo shock, ripristinando una situazione di equilibrio e apprendere da questa nuova esperienza.

Le caratteristiche di un sistema resiliente e cos’ha a che fare con il team:

• La ridondanza, quando è possibile e sostenibile: in un team vogliamo generalisti specialisti. Molto competenti nella propria specializzazione ma pronti ad acquisire nuove conoscenze. Imparare anche da ciò che fa il mio collega per ridondare le competenze ed intervenire nei momenti critici per rendere più stabile il team
• Il nutrirsi costantemente di feedback: ottimizzare la comunicazione interna e modulare efficacemente quella esterna.
• Modularità e adhocrazia: non avere ruoli prestabiliti ma dare alle persone la libertà di esercitare il proprio talento in base alle diverse esigenze. Il team deve avere un controllo condiviso per lavorare meglio e creare valore
• Pairing: dedicare del tempo al lavoro in coppia per aumentare la conoscenza
• Limit WIP: limitare al massimo i task contemporanei al fine di rendere visibile il lavoro e impedire eventuali colli di bottiglia
• Small batches: ridurre la quantità di lavoro per diminuire la dipendenza di fattori esterni. Aumentare la parallelizzazione
• Slack-time: dedicare una piccola parte del tempo allo studio e all’innovazione per ridurre la fragilità del sistema
• Avere amore e odio verso il rischio: un sistema resiliente deve sfruttare il rischio per creare opportunità e innovazione
• Retrospettiva: il sistema immunitario della resilienza. Leggere i feedback per identificare i miglioramenti e mettere in campo azioni correttive
• Self-organization: forte assunzione di responsabilità per risolvere i problemi. Ci vuole fiducia all’interno del team
• Networking: essere in grado di attivare delle reti informali all’interno del processo

Da dove possiamo prendere la resilienza? Soprattutto da noi stessi. In via minore dalle relazioni, dal lavoro ed infine dall’azienda. Le attitudini come fiducia, assertività, passione, collaborazione e ottimismo creano la resilienza in noi. Solo dentro al fallimento c’è la possibilità di imparare. Dobbiamo quindi imparare ad accettare il nostro fallimento.

Resilience: the glue of an agile team from Emiliano Soldi

Banche Agili: è un ossimoro?

Lo speech di Marco Trincardi ha trattato della possibilità di rendere “Agile” la struttura informativa di una banca. Se infatti pensiamo alla banca tradizionalmente intesa, ci giunge alla mente qualcosa di antitetico ad “Agile”: una cultura del controllo, dove i processi sono definiti, si dà enfasi a gerarchia e ruoli e ci si muove in un contesto di stabilità.

Ma banche e mondo “Agile” presentano delle intersezioni comuni, che potrebbero trasformare la gestione del sistema informativo delle banche. Queste, partono infatti da una pianificazione, ma una parte del processo è predittiva e risente dei feedback continui ricevuti in corso d’opera, che possono portare al cambiamento e all’adattamento della struttura. Certo, è difficile cambiare una banca intera, soprattutto se i dipendenti sono migliaia. È necessario quindi introdurre una “Isola Agile”, che coinvolga in sinergia una Funzione Business e Tecnica, in modo che la seconda possa mostrare alla prima i vantaggi del nuovo metodo.

È stato così presentato un recente caso di studio (ottobre 2014), dove si è realizzata una trasformazione Agile della Direzione dei Sistemi Informativi. Perché questa banca ha potuto cambiare? Perché a cambiare è stato il mercato su cui lavorare. È stato importante muoversi un contesto favorevole: c’erano già state delle attività lean. Dopo la costituzione del team con 4 persone della DSI e 3 persone esperte di metodi agili, si è studiato il processo in essere per vedere i punti in cui poteva essere cambiato e migliorato. Ci si scontrava però con lo scoglio della burocrazia e dei vincoli tipici delle banche: per poter continuare il lavoro di trasformazione, il team è potuto andare in deroga ad alcuni vincoli esterni provenienti da altri dipartimenti. Ciò è stato possibile grazie alla sponsorship della direzione, fondamentale per partire con il progetto e per poterlo concludere. In questo caso la gerarchia è utile.

Tutto questo ha portato a:

• riduzione degli user acceptance test, quindi di tutte le fasi di verifica dello sviluppo software in cui l’utente finale valida la corrispondenza con i requisiti inizialmente espressi
• consegna al team business di ciò che effettivamente gli serviva
• dare autonomia al team
• prosecuzione dell’attività ancora nel 2016

Perché raccogliere metriche?

Mattia Battiston ci racconta come il suo team a Sky UK usa le metriche per guidare il processo di miglioramento continuo e per prevedere il futuro:

• Le buone metriche servono a migliorare il sistema, non per premiare o punire le singole.
• Chiedere al team di fare di meglio non chiedendogli di lavorare di più perché questa è mancanza di fiducia: sono i sistemi che devono cambiare. Ci si deve fidare delle persone con le quali si lavora ogni giorno.
• Usare i dati per togliere le opinioni soggettive.
• Se lavori su poche cose, le farai più velocemente.
• Le metriche ci aiutano a guidare e validare i cambiamenti.
• Non è importante la precisione, ma i trend.
• I numeri non bastano, bisogna comunicare con le persone.
• Basta stimare, solo forecasting.

Metriche Kanban in pratica a Sky UK [ITA] from Mattia Battiston

I concetti più importanti: persone e feedback

I concetti più interessanti che ho portato a casa?

• Le persone sono più importanti dei processi
• Sono cruciali la comunicazione continua ed i feedback tra i membri del team
• È fondamentale la collaborazione tra le persone

“Ne vale sempre la pena. Sempre.”

Queste le parole di Beppe alla fine di una giornata trascorsa a discutere di paradigmi, metriche e resilienza. All’anno prossimo!