Come non cadere nella trappola della velocità

Ovvero, come aiutare i top manager nel percorso della generazione di valore nella trasformazione digitale. 

Nella fase di Q&A al termine di un workshop per manager sul tema della gestione di progetti di sviluppo software, mi sono state rivolte due domande sul tema della metrica della Velocity come parametro fondamentale da valutare nell’ambito dello sviluppo software in ambito Agile. 

Entrando nel merito, dopo aver verificato che i principi concettuali affrontati nel workshop fossero largamente condivisi, alle mie richieste di miglior esplicitazione delle domande, siamo giunti alla vera questione: “Spesso i dirigenti di alto livello della mia azienda cadono nella trappola di considerare la “velocity”, ovvero la capacità di un team di sviluppo nel completare lavoro durante un'iterazione, come parametro fondamentale per ottenere il meglio da un fornitore”. 

Partendo dal presupposto, ampiamente condiviso dai partecipanti al workshop, che nella trasformazione digitale - ossia nell'intervento diretto sul sistema nervoso di un'organizzazione - sia controproducente concentrarsi su parametri non correlati alla creazione di valore, ho suggerito all'aula di valutare insieme questa riformulazione della domanda: "Come posso supportare i manager di alto livello della mia azienda nell'orientare la loro attenzione verso la generazione di valore anziché concentrarsi esclusivamente su parametri di output del processo?" 

Prima di entrare nel merito della risposta, mi sono permesso di segnalare quanto il termine stesso di velocità possa essere subdolo. Ho fatto riferimento alla metafora sportiva della squadra del calcio: la velocità media di corsa di ogni atleta nelle partite viene oggi misurata, così come la velocità media della squadra. Da un lato, sappiamo tutti che spingendo e sostenendo tutti i singoli calciatori al miglior impegno e allenamento si ottengono nuovi record di velocità, dall’altro sappiamo bene che aumentare gli indicatori di velocità media di una squadra di calcio sia decisamente molto poco correlato all’ottenimento del miglior risultato sportivo. 

Successivamente, andando oltre la metafora, ho argomentato con alcuni esempi concreti, opportunamente anonimizzati, tratti dai casi reali vissuti nella mia carriera professionale. Più precisamente ho citato esperienze quali:

• considerare la velocity equivalente alla produttività del team, ignorando il fatto che la velocity è uno strumento di pianificazione e non una misura specifica di produttività; 
• considerare la velocity come un indicatore diretto di output e successo, senza valutare la qualità del lavoro prodotto o l'impatto sul valore di business generato; 
• utilizzare la velocity per confrontare le prestazioni tra team diversi, ignorando le differenze nelle dimensioni e nei contesti dei progetti; 
• creare incentivi distorti per ottimizzare la velocity a discapito della qualità del software, portando potenzialmente alla generazione di debito tecnico;

Praticamente in tutti i casi citati, l'ossessiva attenzione alla velocity ha creato nella mente dei top manager un'illusione di progresso, in quanto l’esigenza era frutto di una visione superficiale orientata ad ottenere immediate rassicurazioni circa la produttività del fornitore. In tutti questi casi ho riscontrato un'evidente limitata comprensione dei reali principi che stanno alla base dell'agilità uniti ad una superficialità evidente nella valutazione degli elementi sostanziali connessi alla generazione di valore per l'azienda di appartenenza. 

Spesso i manager di alto livello si trovano, per attitudine individuale, posizione organizzativa o cultura aziendale, in condizioni di pressione tale da non poter dedicare il tempo necessario per comprendere realmente principi dell’agilità e/o della natura complessa del processo di sviluppo software. La velocity è solo una delle molte metriche utili nel contesto agile, ma non dovrebbe essere l'unica considerata per valutare il successo del team o del valore generato. 

È quindi fondamentale sostenere, incuriosire e, se possibile, educare i top manager sulla natura multidimensionale del successo nel contesto digitale e sull'importanza di concentrarsi sul valore e sull'adattamento continuo anziché solo sulla produzione di lavoro. Come appena detto, la velocity è solo una delle molte metriche, decisamente più utile come metrica interna ai team, piuttosto che per chi è chiamato a generare valore per la propria azienda. 

In sintesi, la via che ho suggerito nella mia risposta è quella di sostenere i top manager fornendo loro stimoli per valutare reale la generazione di valore in modalità maggiormante connessa al modello di business, ai parametri citati nel piano strategico e alla capacità di attuare i principi cardine della trasformazione digitale in atto. 

La chiave per migliorare è spesso quella di ridurre il tempo di consegna delle principali fonti di valore e le dimensioni dei rilasci, concentrandosi sulla generazione di valore per gli utenti, sul preservare la stabilizzazione e clima organizzativo nei team e sulla qualità nel software messo in produzione. Questo aiuta a identificare rapidamente ciò che è veramente essenziale e a ridurre il rischio di spreco di risorse. Inoltre, è fondamentale focalizzarsi sulla massimizzazione dell'apprendimento, poiché le esigenze del mercato e dei clienti cambiano continuamente e solo imparando rapidamente si può rispondere efficacemente a tali cambiamenti. 

Ritornando alla metafora della partita di calcio, nessun vero appassionato considererebbe un reale successo il fatto che la propria squadra abbia ottenuto la velocità di corsa media complessiva dei calciatori più alta di tutto il campionato, senza però aver raggiunto gli obiettivi di valore definiti ad inizio stagione.

Al temine della risposta, ho lasciato ai partecipanti questi riferimenti per approfondire (*): 

Perché la velocità inibisce l'agilità: https://www.linkedin.com/pulse/how-focus-velocity-inhibits-agility-jayaram-hegde, di Jayaram Hegde. 

Come non incorrere nella trappola della velocità: https://www.scrum.org/resources/blog/escaping-velocity-trap, di Kurt Bittner. 

Sul rapporto produttività verso efficacia nello sviluppo software: https://www.linkedin.com/posts/stefanomainetti_non-abbiamo-bisogno-di-team-produttivi-ma-activity-7168297750034427907-hfGY di Gianluigi Sindaco. 

Sul falso mito che il software di qualità sia più costoso: https://www.linkedin.com/feed/update/urn:li:linkedInArticle:7183792390007078912/ di Mattia Ciriolo. 

Ho inoltre segnalato, sempre sul tema, anche questi miei due articoli: 

Sulle tipologie di metriche da adottare nell’ambito dello sviluppo del software: 

https://www.linkedin.com/posts/stefanomainetti_agilemyths-ciotransformation-agilemetrics-activity-7173629745304092672-MD0w 

Sulla stima dei tempi di realizzazione di un'applicazione software: https://www.linkedin.com/feed/update/urn:li:activity:7122132131136335872/ 

(*) approfondimenti che, ci tengo a precisare, ho volutamente caldeggiato all'aula. Fermarsi solo alla superficie non aiuta nella direzione della reale comprensione della natura multidimensionale della complessità da affrontare nell'ambito di iniziative di trasformazione nel contesto digitale.