Scrum, Kanban, Jira, Trello... non sono sinonimi di sviluppo agile. Quando si parla di sviluppo agile, è importante chiarire i concetti per evitare fraintendimenti. Lo sviluppo agile si basa sui valori espressi nel Manifesto Agile (https://agilemanifesto.org/):
- 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.
Questi principi chiariscono che processi e strumenti non definiscono di per sé un approccio agile, ma ne sono solo un supporto. Esaminiamo ciascun pilastro per comprenderne meglio i vantaggi.
Individui e interazioni più che processi e strumenti
Quante volte, dopo un problema derivato dalla mancanza di comunicazione, si sente dire: «Avevo mandato una mail in cui spiegavo tutto» o «L'avevo scritto su una card»?
Mail, ticket su Jira o Trello, messaggi su Slack o Teams sono solo strumenti per veicolare informazioni. Ma un processo, per quanto ben definito, deve basarsi su una cultura di confronto e interazione. Altrimenti, invece di rendere efficiente il lavoro, rischia di diventare un alibi per deresponsabilizzarsi.
Adottare Scrum o pratiche Kanban non garantisce un approccio agile. Una retrospettiva ogni due settimane, senza una reale cultura del feedback, rischia di generare solo malumori e fraintendimenti.
Per un vero approccio agile, occorre creare un clima di ascolto e confronto, permettere alle persone di parlarsi liberamente, condividere opinioni e idee. Il processo di lavoro dovrebbe essere stabilito dal team, con la possibilità di provarlo, analizzarlo e affinarlo. La responsabilità si assume collettivamente.
Software funzionante più che documentazione esaustiva
La principale differenza tra un approccio agile e uno waterfall è il rilascio continuo di software funzionante, raccogliendo feedback il più velocemente possibile. Più rapido è il feedback, più velocemente si può reagire.
Basarsi su documenti che descrivono come dovrebbe funzionare un software non ha lo stesso valore di ottenere feedback direttamente sul software stesso.
Attenzione, però: questo non significa eliminare la documentazione. Essa è utile per spiegare il perché di certe scelte, definire flussi di lavoro e fornire una base di discussione. Tuttavia, alla fine, ciò che conta davvero sono le funzionalità presenti nel software: quelle che clienti e stakeholder possono vedere, usare e valutare.
Un ulteriore passo avanti sarebbe valutare non solo la funzionalità del software, ma anche il loro impatto concreto sul business del cliente. Ciò implicherebbe definire metriche per misurare il valore aggiunto del software nel risolvere problemi reali. A volte il tempo trascorso tra il rilascio software e un impatto visibile sul business del cliente può essere lungo abbastanza da indurre la definizione di indici intermedi che certifichino la direzione intrapresa.
Collaborazione col cliente più che negoziazione dei contratti
Vuoi davvero passare il tempo a discutere con il cliente su cosa fosse incluso nel contratto e cosa no? Se un dettaglio è una variante o parte della prima versione? Non sarebbe più utile concentrare tempo ed energie per trovare insieme la soluzione migliore e il percorso per raggiungerla?
Il contratto è necessario per stabilire le regole della collaborazione, sia con clienti esterni sia con altri team interni. Tuttavia, definire tutto nei minimi dettagli fin dall'inizio può rendere il processo rigido e difficile da adattare. Ogni cambiamento richiederebbe una variante al contratto, rallentando il lavoro e riducendo la flessibilità.
Meglio adottare contratti che favoriscano la collaborazione, permettano di adattarsi ai cambiamenti e facilitino un lavoro fluido e reattivo.
Rispondere al cambiamento più che seguire un piano
Se dobbiamo raggiungere un ristorante entro una certa ora, non ha importanza che strada percorreremo se questa ci permette di raggiungere l’obiettivo. All’inizio avremo di certo definito un percorso, ma se durante il tragitto incontriamo un incidente o scopriamo che ci sono dei lavori, invece di imbottigliarci nel traffico, ci faremo suggerire dal navigatore una strada alternativa per raggiungere il ristorante. Cambiare i nostri piani in funzione del contesto per raggiungere un obiettivo è qualcosa che facciamo sempre.
Il piano iniziale viene definito nel momento di minor conoscenza del problema. Se il nostro obiettivo è risolvere un problema, il lavoro stesso ci fornirà nuove informazioni per trovare la via migliore.
Seguire rigidamente un piano dettagliato ha senso solo se le condizioni restano invariate e in un mondo complesso questo è impossibile. In un contesto dinamico, invece, ha più senso essere pronti ad adattarsi ai cambiamenti, senza perdere di vista l'obiettivo finale.
Conclusione
Lo sviluppo agile non è un framework, un tool o un processo predefinito. È un approccio che valorizza la collaborazione, il feedback rapido e l'adattabilità.
Per essere veramente agili, non basta adottare Scrum, Kanban o altri strumenti: è necessario creare un ambiente in cui le persone possano interagire, condividere responsabilità e adattarsi ai cambiamenti in modo efficace.
