Essere produttivo sì, però comparato a cosa?

Mio primo punto viene con la chiacchiera di Lewis Carroll nell’Alice nel paese delle meraviglie:

- Che strada devo prendere?

- Dove vuoi andare?

- Non lo so

- Allora, non ha importanza

Per avere un’idea su come iniziare a misurare nostra produttività dobbiamo compararla con qualcosa, qualitativo o quantitativo. Ecco qui alcuni luoghi in cui sono basato su, come obiettivi raggiunti. Es:

• Gli obiettivi dello sprint è stato raggiunto?
• Obiettivo della PI? A quale punto ci siamo?
• KPI? Quali abbiamo raggiunto e quali no?

Iniziando con queste comparazioni abbiamo un’idea della produzione del team VS quello che è atteso e, partendo da queste possiamo sapere se siamo e/o quanto siamo sotto le aspettative.

Disclaimer: Stai attento nell’eccesso di pressione per migliorare le misure del team caso loro già siano buone. Meglio fare un viaggio fino alla fine a 100km/h che andare a 180km/h ed esplodere il motore nel mezzo del cammino.

Fatto il disclaimer, scriverò alcuni metodi che uso per misurare il team:

Misurando il team e board scrum

Divisione delle attività per tipo (user story, manutenzione del sistema, gli enablers)

Non è più che fare una comparazione tra questi 3 tipi per averne un equilibrio. Il primo, per avere un avanzo nei milestone del progetto, il secondo per non lanciare in produzione una cosa che disturberà la esperienza dell’utente e il terzo è per avere un’architettura fatta per la scalabilità, aumentando così il market share e guadagnando clienti. Sotto, lascerò un esempio di come verificare i tipi delle attività che abbiamo:

Gestione delle attività sul board scrum e velocità delle consegne

Qui, il trucco è fare comparazioni sui periodi di tempi chiusi (sprint, PI, mese, trimestre) e comprendere quando il tuo team può consegnare, sia usando le ore lavorative, Fibonacci, giorni oppure la validazione che sei sistemato di più. Con questo, si diventa più facile stimare le prossime attività (ancora così è sempre difficile). Lascio sotto un esempio di Story Points in un team Scrum/SAFe.

Tempo perso – da quando l’attività se n’è entrata fino al suo termine

Facendo questa misura sappiamo in generale, quanto tempo che un’attività o feature richiede dal momento in cui la iniziamo fino al suo termine. Il grado di importanza aumenta se facciamo una relazione con il tipo di attività. Es: Attività di manutenzione richiedono nella media 5 giorni per essere esecutate a discapito dalle user stories che richiedono 3 giorni. Sotto, l’esempio di quante user stories sono esecutate VS la quantità di giorni.

Quantità di elementi attivi

Indica quanti elementi attivi hai sul board. Considero questa una delle misure più importanti per un leader, ma perché? Semplice, se hai 5 persone nel tuo team e 10 elementi attivi, significa che 5 di questi sono fermi e dovrebbero essere da un altro posto, giusto? Oltre a questo, guardando il board, sappiamo esattamente quali elementi sono a ogni fase del nostro processo. Es: X Attività sono in fase d’analisi, Y sono in sviluppo e Z sono finite. Lascio qui un esempio di come possiamo guardare queste attività:

Efficienza sull’esecuzione delle attività

In parole povere, siamo riusciti a capire per quanto tempo un’attività rimane ferma tra il termine di un processo (sviluppo per esempio) fino all’inizio di un altro (teste). Qui sotto, lascerò un calcolo che facciamo per capire questa misura. Se il calcolo risulta in 1 significa che tu non stai sprecando tempo.

Tempo del flusso = tempo attivo – tempo di attesa

Efficienza del flusso = tempo attivo / tempo del flusso

Come migliorare la produttività del team

Attraverso gli anni lavorando con la gestione di progetti, me ne sono accorto di alcuni schemi che possono essere controllati per dare una maggiore velocità alle consegne accelerando così il time-to-market del prodotto. Andiamo a loro:

Manutenzione del sistema VS User Story VS Enablers

Mia comprensione (controversa) sul questo punto è:

• User Story è andare avanti
• Enablers è andare di lato
• Manutenzione è andare indietro

Mi spiego meglio:

Attività di manutenzione sono quelle che non hanno inseguito un processo o ha mancato informazioni per farlo. C’entro qui nel testo che ho scritto: “Perché avere un’ottima definizione di ready e done è così importante per chiarire un’attività”. Attività fatte per correggere qualcosa sono semplicemente mancanza di conoscenza, sia scenari, l’utente o quello che deve essere fatto. Per risolvere questo problema, devono essere migliorati i processi e comunicazioni a dare una maggiore chiarezza, anche se ci vuole più tempo.

Enablers sono super importanti perché sono le strutture di quello che chiameremo prodotto nel futuro. Però, sono strutture e, in generale, sono creazioni e manutenzioni di ambienti che possono essere esternalizzati per dare una maggiore velocità nello sviluppo del prodotto.

User stories sì, sono quelle che ci faranno avanzare nel progetto fino alla sua consegna finale. Il più veloce le finiamo, meglio per noi.

Quanto consegna il team per periodo di tempo

C’entro nella questione: Stima dell’attività VS realtà della consegna. Particolarmente mi piace molto il poker planning perché non soltanto aiuta ad arrivare a una buona stima, come pure dà una maggiore chiarezza su quello che bisogna essere fatto. Da questo punto si diventa semplice prendere i punti (ore, giorni) che sono state consegnate negli sprint passate (PI, mese, trimestre) e usarle come base per sapere quel che nostro team è capace di fare.

Tempo di consegna da un tipo specifico di attività

Facciamo la divisione delle attività per i suoi tipi: user story, manutenzione ed enabler. Possiamo usare il tempo medio di ogni tipo di attività per creare lo sprint (PI, mese, ecc) e fare la stima su quanto evolveremo nel progetto. A ogni periodo possiamo concentrarci di più in un tipo di attività, avanzando così su un campo specifico.

Tempo d’attesa per il passaggio delle attività tra il team

Semplicemente verificare in quale momento del processo le attività rimangono fermi e correggerlo. Ma qui c’entra una decisione un può più esecutiva su:

Spendo tempo o soldi?

In generale le attività rimangono ferme perché non ci sono abbastanza persone per finirle. In questi casi stiamo perdendo tempo in relazione ai soldi. Caso aggiungiamo persone nel team, succede l’opposto perché in alcuni momenti i nostri professionisti aspetteranno il termine di un altro processo. Es: QA in attesa dello sviluppo per finire la sua parte.

Disclaimer: Persone sono mono-attività. Se le metti per fare un’altra cosa, loro ritorneranno al tuo sprint dopo il termine, generando tempo d’attesa.

Quanti elementi attivi esistono sul board?

Quando non c’è chiarezza su quel che bisogna essere fatto, comincia ad appare troppe attività sull’attivo del board. Ma perché?

I professionisti prendono un’attività, non capiscono cosa si deve fare, domandano agli altri e, mentre non ricevono una risposta, partono per un’altra attività, lasciando quella prima sull’attivo. C’entro qui di nuovo nel testo ho scritto: “Perché avere un’ottima definizione di ready e done è così importante per chiarire un’attività”. Alla fine, il corretto è la semplicità: ha preso l’attività e non ha capito, domandi al team. Caso nessuno sappia spiegare, l’attività non dovrebbe neanche essere nello sprint.

Arrivo alla fine di questa cronaca e spero che ti sia piaciuto. Qui hai imparato come fare le misure più comune sulla produttività del tuo team e come migliorarla.

Vuoi continuare questa chiacchiera? Metti mi piace, commenti sul LinkedIn o condividi sui tuoi social.

A presto!

Erik Scaranello