Quattro valori, non quattro regole
L'Agile Manifesto, pubblicato nel 2001, si riduce a quattro preferenze: individui e interazioni su processi e strumenti, software funzionante rispetto a documentazione completa, collaborazione con i clienti rispetto alla negoziazione contrattuale e risposta al cambiamento rispetto a un piano. Il testo afferma che gli elementi a destra hanno ancora valore. Non dice "nessun piano" o "nessuna documentazione": dice cosa viene prima quando bisogna scegliere.
Dieci anni dopo, un numero speciale del Journal of Systems and Software fece il punto della ricerca e cercava ancora di spiegare perché queste pratiche funzionano, invece di limitarsi a descriverle (Dingsøyr et al., 2012). In altre parole, l'agilità è un insieme di pratiche che si sono dimostrate efficaci nel campo, con la teoria che arriva dopo.
Cosa cambia giorno dopo giorno
Il lavoro diventa visibile
Non puoi modificare ciò che non vedi. La prima mossa di un team che diventa agile è spesso mettere tutti i compiti su una bacheca condivisa, anche se questo rivela dieci cose "in corso" per tre persone.
Il ciclo si accorcia
Invece di pianificare dodici mesi, ti dai una o due settimane, un obiettivo e una demo alla fine. Questo è il principio base del metodo Scrum, anche se puoi applicarlo senza adottare l'intero framework.
La misurazione rimane semplice
Alla fine di un ciclo, due o tre numeri bastano: cosa è fatto, cosa è bloccato, cosa è scivolato. Il punto è discuterli, non valutare la squadra.
Iniziamo questa settimana con una squadra di cinque persone
- Lunedì: tutti elencano i compiti attuali e futuri, senza filtri. Vengono messi su una bacheca condivisa.
- Scegli una durata del ciclo (inizialmente una settimana) e un obiettivo realistico e unico.
- Ogni giorno, cinque o quindici minuti: ciò che si muove, ciò che è bloccato.
- Venerdì: trenta minuti per mostrare cosa è davvero fatto, poi dire ad alta voce cosa cambia la prossima settimana.
Se l'obiettivo viene mancato dopo due cicli, prima guarda la dimensione e la stima del compito prima di cercare un altro metodo.
Fonti
- Beck, K. et al. (2001). Manifesto per lo Sviluppo Agile del Software. agilemanifesto.org
- Dingsøyr, T., Nerur, S., Balijepally, V., & Moe, N. B. (2012). Un decennio di metodologie agili: verso la spiegazione dello sviluppo software agile. Journal of Systems and Software, 85(6), 1213-1221. doi:10.1016/j.jss.2012.02.033