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?

Leider kommt es in der Praxis immer wieder vor, dass Organisationen Scrum einführen und die Teams dadurch alles andere als agil werden. Man spricht dann häufig von “Zombie Scrum”.

Was ist “Fake Agile”?

“Fake Agile” bezeichnet Teams, die zwar offiziell mit agilen Frameworks und Methoden arbeiten, ohne dabei tatsächliche Lernschleifen mit Kunden zu haben. Fake Agile bedeutet also, dass man entweder a) erst gar nicht iterativ Inkremente an Kunden liefert oder b) das direkte Kundenfeedback zum Inkrement nicht für die kurzfristige Priorisierung nutzt.

Quali sono le cause del falso Agile?

Gründe für “Fake Agile” gibt es viele. Die häufigsten Ursachen in der Praxis für Fake Agile sind meiner Erfahrung nach folgende:

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.

Wie wäre es also, wenn wir unsere Arbeitsweisen auch komplett mit Regeln festlegen - wäre das nicht toll? Nein, wäre es nicht.

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