Se producessimo spilli sarebbe senza dubbio più semplice: oggi facciamo 10mila spilli al giorno, ottimizzando i processi e migliorando la catena produttiva il prossimo anno potrei produrne 30mila al giorno.
Poi un giorno inizierei a chiedermi: sono sicuri che valga la pena lavorare ancora sugli spilli? e non forse produrre linguette adesive che non forano il tessuto?
Allora inizierei a produrre le linguette, ma ecco che se volessi fare un mero conto della serva e monitorare la capacità produttiva della mia fabbrichetta non potrei certo confrontare l’anno 2 (quando producevamo spilli) con l’anno 3 (quando una parte inizia a produrre linguette, con un processo industriale totalmente diverso che mi porta inizialmente a produrne 5000 al giorno). E l’anno 4? ancora diverso, le linguette vanno a ruba e parte della produzione si sposta su quello ma una parte di clienti ha ancora bisogno di spilli, e il 30% della produzione resta ancorata a questo prodotto legacy.
Questo semplice esempio dimostra che misurare la produttività non è semplice nemmeno per chi produce spilli, in realtà.
Ma se un importante stakeholder ti chiede un giorno di definire un KPI per misurare come cambia la produttività del team, sicuramente un po’ di fatica mentale ci deve essere dedicata.
Abbiamo affrontato l’argomento in una community of practice interna, dedicata alla metodologia: un gruppo di product owners e scrum masters che inizia a buttare giù qualche idea ricordando che, per definizione, un indicatore di performance (KPI) deve essere SMART
Specifico, come motivazione di business che vuole misurare
Misurabile, per fornire un vero valore oggettivo
Achievable (raggiungibile) altrimenti si chiama utopia
Rilevante per l’azienda, altrimenti misura
Time oriented, cioè definibile in un intervallo di tempo.
Inoltre, misurando la produttività del team e non dell’intera azienda, non può posizionarsi troppo lontano nel processo aziendale per non rischiare di essere influenzato da variabili esterne su cui il team non ha controllo: quindi niente misuratori di ricavi o risparmi.
La conclusione (parziale) non è stata esaltante: esistono tali e tante variabili che sembra quasi impossibile monitorare la produttività.
Un paio di idee abbastanza interessanti, per lo meno come spunti di riflessione, sono state le seguenti.
Misuratore del tempo produttivo.
Risponde alla domanda: quanto tempo impiega il team su attività che portano un effettivo deliverable?
Abbiamo ipotizzato un rapporto: tempo totale impiegato sulle attività di sprint (e registrato in Jira, il nostro project management tool) DIVISO il tempo totale lavorato in uno sprint.
La parte restante di questa percentuale è attività non meglio precisata, attività reattiva (supporto, bug fixing), meeting e cerimonie, richieste non in sprint etc.
Il limite principale sta nella capacità che hai il team di loggare con precisione e onestà i tempi lavorati in sprint.
Misuratore di capacità di erogare deliverable
Risponde alla domanda: quanto prodotto è capace di erogare un team?
Abbiamo assunto che su lunghi intervalli di tempo la dimensione delle user stories fosse sufficientemente omogenea e di conseguenza il valore (in termini non economici ma di quantità di servizio erogato) fosse ben confinato all’interno dei limiti di una storia: quindi numero di storie erogate in uno sprint DIVISO il numero di team member, allo scopo di normalizzare questo parametro in funzione delle naturali variazioni di un team nel tempo.
Per adesso, comunque, la decisione condivisa co lo stakeholder è stata di abbandonare questo tentativo; la messa a punto di queste misure è troppo onerosa e il risultato tutt’altro che garantito.
Per ora, la risposta alla domanda nel titolo è: NO.