Fake Agile: Ogni team Scrum è agile?
No, purtroppo non tutti i team Scrum sono effettivamente agili.
Mi spiego meglio: Un team Scrum è definito dal fatto di lavorare secondo il framework Scrum: Quindi ha degli sprint, determinati ruoli e rituali. E poiché lo scopo del framework Scrum è quello di aiutare i team a lavorare in modo agile, Scrum dovrebbe automaticamente rendere agile ogni team, giusto?
Purtroppo, nella pratica, le organizzazioni riescono sempre a introdurre Scrum e a rendere i loro team tutt'altro che agili. Questo fenomeno viene spesso definito "Zombie Scrum".
Quali sono le cause del falso Agile?
In base alla mia esperienza, le cause più comuni di falsi Agile nella pratica sono le seguenti:
Falso Agile Perché #1: nessun feedback dei clienti
Se un team agile non riceve un feedback diretto dagli utenti, non può lavorare in modo agile. In pratica, le richieste dei clienti sono spesso formulate dalla direzione e trasmesse ai team tramite i proprietari dei prodotti – I veri cicli di feedback con i clienti si esauriscono o non esistono nemmeno.
Un team agile ha bisogno del contatto diretto con il cliente!
Fake Agile Perché #2: concentrarsi su velocità e punti storia
Dobbiamo parlare ancora di story point nel 2025? Penso che tutti noi abbiamo avuto abbastanza esperienza di quanto l'attenzione alla velocità e agli story point sia d'intralcio ai benefici per i clienti.
Un esempio: Cosa succede se una funzione è formalmente pronta dopo la prima iterazione, ma non raggiunge ancora il beneficio per il cliente? Se il vantaggio per il cliente è importante per noi, allora lavoriamo su di essa fino a quando il vantaggio per il cliente viene effettivamente raggiunto. Alla fine possono essere necessarie 3 iterazioni, ma almeno il cliente è contento.
Ma aspettate, ora il mio manager arriva all'improvviso dietro l'angolo e si lamenta che il mio team ha realizzato meno punti storia nell'ultimo sprint. Quindi sarebbe stato meglio per la mia velocità se avessimo semplicemente abbandonato la funzione non preziosa e lavorato direttamente sulla funzione successiva, in modo da creare più punti storia.
Che sciocchezza, vero? Se ripetiamo questo processo per qualche altro mese, avremo un prodotto con molte funzioni che creano pochi vantaggi per i clienti.
Non deve quindi sorprendere che sia i clienti che i team di sviluppo siano scontenti e se ne vadano.
In termini più generali, si tratta di una legge ormai nota: Legge di Goodhardt
"Quando una misura diventa un obiettivo, cessa di essere una buona misura".
Falso Agile Causa #3: la dittatura del dogma
Gli ingegneri amano quando ci sono regole fisse per ogni cosa. Questo rende i processi pianificabili.
Quindi, come sarebbe se potessimo anche definire i nostri metodi di lavoro completamente con le regole – Non sarebbe fantastico? No, non lo sarebbe.
Solo con Scrum e le sue numerose regole e linee guida, per molti team lavorare in modo agile è già come lavorare secondo linee guida rigide. Non dovrebbe essere così.
Quindi non peggiorate le cose aggiungendo altre regole e linee guida al lavoro agile.
Nei migliori team agili che conosco, il lavoro è umano, vivace, spontaneo e collaborativo.
E, a dire il vero, la maggior parte dei team agili non lo fa.
In questo post ho già scritto in modo specifico dei passi necessari per proteggere i team Scrum da Zombie Scrum: Correggere lo Zombie Scrum
Il falso Agile è reale: come proteggersi?
Nulla vi protegge completamente dalla falsa agilità. Ma c'è una cosa che può proteggervi al meglio: Un processo efficace incentrato sul miglioramento continuo.
Naturalmente, tutto ciò inizia con delle buone retrospettive in cui i membri del team possono condividere apertamente le loro opinioni e ricavare e implementare in modo indipendente le misure di miglioramento.
Finché questo processo funziona, il potenziale di reale agilità del team non viene meno.
Se volete portare le vostre retrospettive agili a un livello superiore, vi consiglio –naturalmente – Echometer, il nostro strumento per le retrospettive. Potete provarlo gratuitamente qui: Prova Echometer
