Perché i team diversi sono semplicemente diversi. La produttività del team è sempre un argomento delicato, ma quale può essere la strategia giusta per valutarla correttamente?
Recentemente mi è capitato di assistere a un’accesa discussione sulla produttività nei team. Penso che sia ormai tempo di rivisitare questo tema. Agli occhi di molti manager, la produttività del team non è quella desiderata. È troppo bassa, ovviamente. Da una parte ci sono i manager più tradizionali secondo i quali – «bisognerebbe aggiungere più lavoro all’arretrato del team». Dall’altra ci sono i fautori dell’Agile per i quali – «avere più lavoro aumenta la produttività dei team». Per altri invece – «vale esattamente il contrario». Perché – «quando si aggiunge più lavoro agli arretrati del team, si rallenteranno ulteriormente». Perché – «quando il team lavora su troppe cose allo stesso tempo, non si concentra». E perché – «quando i team lavorano su molte cose, alla fine non ne finiranno nessuna».
I team diversi sono solo diversi
La produttività del team è un argomento delicato. Nei primi tempi dell’Agile, circa vent’anni fa, c’erano lunghi dibattiti sull’argomento, in cui le persone cercavano di confrontare la produttività dei diversi team usando scale relative come punti storia o punti funzione. Fortunatamente, da un po’ di tempo, questi dibattiti non si vedono più. Sembra che si sia imparato che le stime a basso livello, come quelle dei punti storia, non aggiungono molto valore. E che i team diversi sono solo diversi, con persone diverse, diversi livelli di esperienza, esigenze diverse, tecnologie diverse: tutto questo aiuta. Tuttavia, ci sono ancora molte aziende in cui i manager si chiedono se i loro team stiano andando abbastanza veloci. Come i manager dei quali stiamo parlando. Dal momento che non ci sono quasi scale assolute che segnano la velocità o la rapidità dei team di sviluppo software, i manager spesso considerano i team troppo lenti, basandosi sulle proprie sensazioni. Spesso i manager vedono solo la punta dell’iceberg. Il fatto che un team produca solo alcune funzionalità per ogni release potrebbe sembrare lento, ma la complessità funzionale o tecnica sottostante di queste funzionalità è spesso trascurata. La prima domanda che i manager che discutono sulla produttività del team dovrebbero chiedersi è: sappiamo davvero se questo team è lento, o semplicemente pensiamo che il team sia lento? È interessante notare che potremmo fare la stessa domanda sui team che sembrano andare veloci: sappiamo davvero se questo team è veloce o potrebbe essere ancora più veloce?
Facciamo qualche esperimento
A mio parere, le discussioni sulla produttività del team vengono fatte dai manager in genere perché questi vogliono che i loro team vadano più velocemente e producano più funzioni in meno tempo, senza sapere se questi team stanno già dando i massimi risultati o se i team stanno solo facendo confusione. In questi casi, le decisioni su come “aiutare” i team in questione a essere più produttivi tendono a essere prese ad hoc, basandosi su sensazioni e su ipotesi rozze. Ma queste decisioni sono davvero delicate. Prendere le misure sbagliate può facilmente distruggere la motivazione del team.
Ma come si può andare oltre le sensazioni su un argomento così delicato? Ogni volta che alleno organizzazioni e team in cui tali domande vengono poste di frequente, tendo a usare la metafora dell’imbuto e delle biglie. Consideriamo un normale imbuto da cucina per versare liquidi in bottiglie e una borsa piena di normali biglie. Supponendo che la bocca dell’imbuto sia abbastanza ampia da consentire il passaggio delle biglie, si può fare un piccolo esperimento. Lasciamo cadere una biglia nell’imbuto: se la circonferenza del gambo è maggiore di quella della nostra biglia, questa passerà senza intoppi. Si sarà già capito che la biglia rappresenta una funzionalità e l’imbuto rappresenta il team. Lasciamo cadere alcune biglie nell’imbuto, con intervalli di tempo brevi tra loro. Come si può intuire, le biglie cadranno una per una. Ciò significa che se le funzionalità vengono lasciate cadere nel team a un ritmo sostenibile, il team sarà in grado di gestirle allo stesso ritmo: funzionalità in, funzionalità out.
Nel nostro esperimento, potremmo fare diverse prove, con intervalli di tempo sempre più brevi tra il lancio delle biglie nell’imbuto. A un certo intervallo, le biglie si incontreranno e non cadranno più attraverso il collo dell’imbuto agli stessi intervalli. Nella produttività del team, questa situazione rappresenta il punto in cui più elementi vengono rilasciati nella squadra rispetto a quelli che il team può gestire. Ciò che accadrà è che le funzionalità non consegnate si accumuleranno. Ora, come ultimo passo, gettiamo l’intero sacco di biglie nell’imbuto. Quello che più probabilmente accadrà ora è che l’imbuto si ingombrerà e solo poche biglie, se non nessuna, riuscirà a passare. Questo è il punto in cui le squadre di solito si arrendono. Se vengono aggiunti troppi elementi all’arretrato, il team non riuscirà più a vedere oltre il palmo del proprio naso. Facendo così, il team si stressa e le persone prenderanno in considerazione l’ipotesi di abbandonare il team e potenzialmente anche l’azienda.
Qual è la giusta strategia?
La giusta strategia per raggiungere il ritmo ottimale sostenibile per un team è quella di gettare il giusto numero di biglie nell’imbuto. Quando nell’arretrato di un team vi sono funzionalità troppo piccole, queste rallenteranno – come sostengono i manager più tradizionalisti. Infatti, i team seguono la legge di Parkinson: il lavoro si espande nel tempo disponibile. Di conseguenza, i team occupano tutto il tempo di cui dispongono nelle poche funzionalità di cui sono incaricati. D’altra parte quando si aggiungono troppe funzionalità all’arretrato, il team avrà problemi di concentrazione e si fermerà, come sostengono i manager fautori dell’Agile. Non solo. Aggiungendo più funzionalità al team, la situazione peggiora. Lavorare su troppe funzionalità diverse allo stesso tempo, causerà una perdita di messa a fuoco e un cambio di contesto, che sono entrambi inefficaci. Quindi non esiste una sola risposta giusta che valga per ogni contesto. La domanda è semmai quale approccio sarebbe quello più corretto in questa particolare situazione. Per dare una risposta, uno sguardo all’arretrato del team e alla lavagna Kanban (lo strumento reso famoso nel mondo da Toyota) potrà essere utile: una rapida occhiata a Jira (il software per il monitoraggio di problemi e progetti) mostra che la squadra in questione ha 35 storie aperte alla lavagna e 144 storie rimanenti nell’arretrato. Lavorare su 35 storie allo stesso tempo non è un buon segno. Il team cambierà costantemente il contesto in cui lavora e non si concentrerà. In questo caso particolare, spingere ancora di più il lavoro sul loro arretrato farà solo cambiare il contesto della squadra, con un solo risultato: perdita di focalizzazione e di efficienza operativa. L’attenzione è fondamentale per la fornitura di funzionalità e prodotti. Il manager fautore dell’Agile aveva ragione.
Sander Hoogendoorn
Mentore, allenatore, software architect, sviluppatore, speaker e scrittore, apprezzato come grande innovatore nello sviluppo software. Autore del best-seller “This Is Agile”, ha scritto libri anche su UML e pubblicato più di 250 articoli su riviste specializzate. Oltre a essere keynote speaker in molte conferenze internazionali, presenta seminari e corsi di formazione in tutto il mondo su diversi argomenti quali, tra gli altri: Agile, Scrum, Kanban, continuous delivery, architettura software, microservices, modeling e UML.
Sander Hoogendoorn presenterà a Roma per Technology Transfer il seminario “Progettare, sviluppare e implementare una Microservices Architecture” il 21 giugno 2019.
