Non tutti i team Scrum sono agili: Fake Agile

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 continuamente a introdurre Scrum rendendo i team tutt’altro che agili. In questi casi si parla spesso di “Zombie Scrum”.

Cos’è il “Fake Agile”?

“Fake Agile” si riferisce a team che lavorano ufficialmente con framework e metodi agili, senza però avere cicli di apprendimento effettivi con i clienti. Fake Agile significa quindi che a) non si consegnano affatto incrementi in modo iterativo ai clienti oppure b) non si utilizza il feedback diretto dei clienti sull’incremento per la prioritizzazione a breve termine.

Quali sono le cause del falso Agile?

Le ragioni del “Fake Agile” sono molteplici. Secondo la mia esperienza, le cause più comuni nella pratica per il Fake Agile 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

“When a measure becomes a target, it ceases to be a good measure.”

Falso Agile Causa #3: la dittatura del dogma

Gli ingegneri amano quando ci sono regole fisse per ogni cosa. Questo rende i processi pianificabili.

E se definissimo i nostri modi di lavorare interamente con delle 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 la situazione 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, nella maggior parte dei team agili non è così.

I team Agile devono avere almeno la libertà sufficiente per poter collaborare in modo flessibile con i clienti. Se le regole e i processi lo impediscono, è necessario esaminare le regole e i processi.

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