Sì, all’interno del team; dannosa al di fuori di esso. La velocità è un dato di previsione su cui il team basa la propria guida; nel momento in cui diventa un obiettivo o un parametro di confronto tra team, assume proporzioni esagerate e perde ogni significato. Non rientra tra le metriche di consegna di DORA.

Quasi tutti i partecipanti al dibattito concordano sul fatto che la velocità non dovrebbe mai essere esclusa dal team, eppure quasi tutte le organizzazioni la escludono comunque. È proprio questo divario il fulcro della discussione. Questo indicatore è davvero utile per un determinato ruolo e decisamente dannoso per gli altri, pertanto il verdetto non può che essere contrastante.

L’argomento a favore dell’utilità della velocità

All’interno del team, la velocità produce risultati concreti. Consente di fare previsioni: dividendo l’ambito di lavoro rimanente per la media recente del team, si ottiene un numero approssimativo di sprint necessari per il rilascio. Consente inoltre di definire le dimensioni realistiche di uno sprint: selezionando le storie fino a raggiungere circa l’ottanta-novanta per cento della media recente, lasciando spazio agli imprevisti. Inoltre, segnala cambiamenti reali: un calo del trenta per cento è un segnale che merita una discussione, non un’accusa.

Anche l’intenzione gestionale alla base dell’utilizzo della velocità come parametro di valutazione è legittima e merita di essere esposta in modo imparziale. I dirigenti sono responsabili dei risultati e desiderano avere visibilità su di essi. «Se non riusciamo a misurare in qualche modo il team, come facciamo a sapere se sta ottenendo risultati?» è una domanda ragionevole, non una frase da cattivo. Il problema non è il desiderio in sé, ma il fatto che la velocità sia lo strumento sbagliato a tal fine.

Velocity over six sprints with two outliers pulling the average above the sustainable rate 0 30 60 points avg 35 actual 29 s1 s2 s3 s4 s5 s6 easy sprint carry-over plan to the teal line, not the orange one
Due sprint facili portano la media al di sopra del ritmo sostenibile della squadra. La velocità è utile per pianificare lo sprint tipico, ma diventa fuorviante nel momento in cui si trasforma in un valore da aumentare.

L’ipotesi secondo cui la velocità costituisce una trappola

Se si indica la velocità come obiettivo esterno, questa si evolve in modi prevedibili. Se la si definisce come obiettivo (“aumentare la velocità del venti per cento in questo trimestre”), il team si adegua, aumentando il peso assegnato allo stesso lavoro anziché ampliarne la portata. Basta trasformare un paio di “tre” in “cinque” e il numero sale senza un reale aumento della produzione. Si tratta della legge di Goodhart che opera su un ciclo di due settimane, e non è un’ipotesi: persino Mike Cohn, il principale sostenitore a favore degli story point, ammette che il minimo accenno al fatto che le velocità verranno messe a confronto produce un’inflazione graduale ma costante dei punti.

Il confronto tra team è ancora peggiore, poiché appare rigoroso pur essendo privo di significato. Due team che valutano lo stesso backlog producono cifre diverse perché effettuano la calibrazione rispetto a storie di riferimento diverse: questo è proprio il punto centrale della stima relativa. Il calcolo della media o la creazione di una classifica compromette la calibrazione di entrambi i team al solo scopo di alimentare un dashboard. Il segnale rivelatore che un’organizzazione sta sbagliando in questo senso è quando una figura senior deve intervenire personalmente per proteggere i propri team dall’uso della velocità come KPI, una soluzione che funziona esattamente fintanto che quella persona rimane in carica.

In quali circostanze potremmo cambiare idea

Sosterremmo senza riserve l’uso della velocità per qualsiasi team che la utilizzi esclusivamente a fini di previsione e pianificazione, senza mai farla uscire dalla sala. Utilizzata in questo modo, non rappresenta affatto una trappola. Si tratta semplicemente di calcoli aritmetici che il team effettua autonomamente.

Decideremmo di abbandonarla del tutto in due casi. In primo luogo, se il lavoro è sufficientemente omogeneo da consentire di prevedere i risultati contando le storie, oltre che sommando i punti, allora la velocità rappresenta un onere superfluo, mentre la produttività è più semplice e più difficile da manipolare. In secondo luogo, se l’organizzazione non riesce a impedire che quel dato venga strumentalizzato. Quando la spirale è culturalmente radicata e nessun individuo è in grado di frenarla, la mossa più onesta consiste nel smettere di produrre il dato oggetto di abuso e passare a metriche di flusso che non lo siano.

L’aspetto pratico

What leadership should watch Deployfrequency Lead timefor changes Change-failrate Time torestore DORA’s original four keys — hard to game team boundary Velocity a planning input the team steers by not a KPI Send outcomes up; keep velocity in the room.
Fornite alla dirigenza le metriche di consegna di DORA, difficili da manipolare, e mantenete la velocità all’interno del team come dato di riferimento per la pianificazione, mai come un numero da aumentare artificialmente.
  • La velocità misura il ritmo, non la produttività. Lo dica ad alta voce nella sala la prima volta che qualcuno la interpreta come un indicatore di rendimento.
  • Non mettete mai a confronto le squadre, non fissatelo mai come obiettivo, non convertitelo mai in ore previste per sviluppatore. Si tratta sempre dello stesso errore, solo sotto forme diverse.
  • Riferite i risultati ai vostri superiori, non il conteggio dei punti. I cinque indicatori di DORA – frequenza di implementazione, tempo di attesa per le modifiche, tasso di fallimento delle modifiche, tempo di ripristino e tasso di rilavorazione delle implementazioni – misurano l’efficacia dell’erogazione senza dare adito a manipolazioni e, a differenza dei punti, hanno lo stesso significato per tutti i team. Questo è l’insieme di metriche che la dirigenza desidera realmente.
  • Non modificate il valore del backlog quando il team accelera il ritmo. Le storie non sono diventate più brevi. Il team è diventato più veloce e il valore della velocità aumenterà di per sé. Modificare il valore del backlog per mantenere costante la velocità equivale a far funzionare il meccanismo a cricchetto al contrario e compromette le previsioni allo stesso modo.

La velocità serve alla squadra come guida, non ai manager per assegnare voti. Se la si mantiene all’interno del gruppo, è uno degli indicatori più utili nell’ambito dell’agile. Se invece la si rende pubblica, diventa l’esempio più lampante di modalità di fallimento del “Power” che esista.

Domande frequenti

La velocità è un indicatore di produttività?

No. La velocità misura il ritmo, non la produttività: quanti story point un determinato team porta a termine per ogni sprint, in base alla propria calibrazione. Non è in grado di indicare se il lavoro sia stato di valore, né è mai stata concepita a tale scopo. La velocità non rientra nemmeno tra le metriche di consegna di DORA.

È possibile confrontare la velocità tra i vari team?

No. Due team che valutano lo stesso lavoro ottengono valori di velocità diversi perché utilizzano story point di riferimento diversi: è proprio questo il punto centrale della stima relativa. Confrontarli è come confrontare due termometri con punti zero diversi. Mike Cohn, sostenitore degli story point, ammette che il minimo accenno al confronto delle velocità porta a un costante aumento dei valori.

Cosa dovremmo comunicare alla direzione al posto della velocità?

Riferite i risultati, non i punteggi. I cinque indicatori di DORA (frequenza di implementazione, tempo di consegna delle modifiche, tasso di fallimento delle modifiche, tempo necessario per ripristinare il servizio e, dal 2024, tasso di rilavorazione delle implementazioni) misurano le prestazioni in modi che non favoriscono le manipolazioni e hanno lo stesso significato in ogni team, anche se DORA sconsiglia di usarli per stilare classifiche dei team. La velocità rimane all’interno del team come dato di input per la pianificazione; gli indicatori di DORA sono ciò che la dirigenza dovrebbe effettivamente monitorare.

Approfondimenti