Stimare o non stimare, questo è il problema (parte #2) – NoEstimates

Nell’articolo “Stimare o non stimare, questo è il problema (parte #1) – Le stime con gli Story Point” ci siamo concentrati sulle stime e su come farle in modo da essere flessibili e adattarci ai cambiamenti che la complessità del nostro mondo ci propone continuamente.
Nella presente esposizione, invece, proveremo ad esplorare i concetti che guidano il movimento #NoEstimates il quale si basa su dati oggettivi piuttosto che su dati di stima.

#NoEstimates

Se gli Story Point ci forniscono un modo per liberarci dalle misure precise e passare a stime più o meno accurate, il movimento #NoEstimates va ancora oltre e tende a liberarsi quasi completamente delle stime.

Quando proviamo a fare una stima (o misurare) di un lavoro, quello che facciamo è pensare in quanto tempo noi riteniamo di poterlo finire considerando una condizione perfetta: dedicati per il 100% del nostro tempo con passaggio di consegne e informazioni che avvengono senza intoppi. Purtroppo, questa situazione non si verifica quasi mai, e prevedere dipendenze, ritardi e momenti di inattività in sistemi complessi è molto difficile.

Se a tutto questo aggiungiamo anche il fatto che inconsciamente tendiamo ad essere ottimisti nella nostra stima, capiamo quanto sbagliati possano essere i valori forniti.

Studi condotti su diverse aziende e numerosi progetti di durata variabile fra i 25 e i 200 giorni hanno dimostrato che in media ad una stima di 22 giorni corrisponde un valore reale di 56 giorni; altre ricerche hanno dimostrato che su una gran quantità di osservazioni fatte in un arco temporale di 20 anni solo il 25% dei progetti ha rispettato tempi e costi previsti, il resto è andato fuori budget oppure è addirittura fallito.

Fig. 1: Stime vs Valori reali (in giorni). Grafico adattato dal libro di Steve McConnel “Software Estimation, Demistifying the Black Art”

Alla luce di questi dati sperimentali, quello che si chiedono i teorici del #NoEstimates è se abbia senso continuare a sforzarsi di misurare o stimare. Può essere considerato uno spreco di energie?

In giapponese muda significa spreco, ma non nel senso che possiamo dare noi occidentali alla parola; muda per gli orientali ha un’accezione maggiormente dispregiativa, qualcosa che va assolutamente evitato, che va disprezzato.

Per il Lean Thinking (pensiero snello) tutto ciò che non produce valore per il cliente è muda.

Ma cos’è il “valore”? Una possibile definizione è la seguente:

Il valore di un processo o di un servizio è la sua capacità di soddisfare,
con le sue caratteristiche e il suo prezzo, le esigenze del cliente finale, esigenze sempre mutevoli nel tempo

Se ci pensiamo bene le stime non aggiungono alcun valore al processo o servizio che cerchiamo di fornire al nostro cliente.

Le persone che cercano valore nelle stime sono soltanto dipendenti da una pratica dalla quale pensano di ottenere un surplus: piani, riduzione dell’incertezza di costi e tempi, proiezioni finanziarie, proposte di vendita. Ma tutto ciò non fornisce valore.

Inoltre, se siamo bravi a generare profitto dal nostro lavoro, fino a che punto ha senso preoccuparci dei limiti di budget all’inizio del progetto quando non abbiamo nessun dato che ci dà indicazioni su come fare le stime accurate?

L’inizio del progetto è il momento peggiore per stimare durata e costi

Lo abbiamo già evidenziato col “Cono di Incertezza”.

Perdere tempo, investire sforzi e denaro per cercare di avere stime accurate è qualcosa che deve essere, se non del tutto evitato, almeno limitato; impieghiamo piuttosto quel tempo e quelle energie a capire come far fluire il valore più velocemente e senza intoppi dal momento in cui individuiamo un’opportunità o un’esigenza di business al momento in cui generiamo un output da consegnare ai nostri clienti per verificare se e come si genera outcome, cioè impatto, risultato, cambiamento delle abitudini, in poche parole come abbiamo cambiato la loro vita.

#NoEstimates è una strategia che si basa su misure e valori empirici per poter fare delle previsioni future.

Invece di chiedersi quanto durerà il progetto, chiediamoci: “Visto il ritmo dei progressi compiuti finora e la quantità di lavoro rimasto, quando il progetto finirà?” oppure: “Visto il ritmo dei progressi, quanto lavoro potrà essere completato alla data X sul calendario?”.

Queste sono domande molto più potenti. E avendo la possibilità di riorganizzare il backlog, ecco che abbiamo la possibilità di dare la priorità ad elementi a più alto valore.

Quali sono le misure che possono aiutarci a dare risposta alle domande appena fatte?

Per sapere quanto lavoro fluisce attraverso il nostro sistema, diventa fondamentale individuare due punti:

• punto di entrata del sistema
• punto di uscita del sistema

Questo ci permette di misurare il tempo di attraversamento degli item che lavoriamo e di calcolare il ritmo di rilascio degli stessi.

Fig. 2: Esempio di Kanban Board

Usiamo come esempio la Fig. 2 dove abbiamo individuato una serie di stati dei nostri item, un punto di ingresso (quando iniziamo a lavorare un item) ed un punto di uscita (quando riteniamo che il lavoro sull’item sia completo) del nostro sistema.

Nel 1961 il professore Jhon D. C. Little del MIT formulò la sua legge come parte della teoria delle code, legge che, rivista per i nostri scopi, possiamo formulare come segue:

Questa semplice formula (Legge di Little) mostra come il tempo di attraversamento medio degli item è direttamente proporzionale al numero degli stessi all’interno del sistema ed inversamente proporzionale al tasso di rilascio.

Da notare che qui è scomparsa la stima sugli item; abbiamo, però, introdotto il concetto di media in un determinato periodo.

In questo modo spostiamo la nostra attenzione, come accennato poco fa, non sulla complessità dei nostri item ma sulla velocità media con cui li rilasciamo, e se la uniamo alla libertà di rivedere e sistemare le priorità del backlog di continuo, ecco che ci stiamo focalizzando sulla quantità di valore che produciamo in una finestra temporale.

Dalla formula si evince facilmente che limitare il WIP, cioè non ingolfare il sistema, fa scorrere meglio il nostro flusso di lavoro e di valore.

Abbiamo trovato un modo semplice ed efficace di migliorare il sistema.

Ma quindi davvero ci dobbiamo dimenticare qualsiasi tipo di stima?

In realtà all’inizio ho detto che le stime scompaiono quasi del tutto, ad esempio una stima sulle previsioni di rilascio dovremmo farla.

E sulle dimensioni degli item? In questo caso, più che una stima, quello di cui dobbiamo preoccuparci è di avere item piccoli a sufficienza da poter essere gestiti in un arco temporale ragionevole, non ci interessa una stima accurata in quanto noi consideriamo una media dei tempi di lavorazione.

Fig. 3: Esempi di sequenza di lavoro di item di differenti dimensioni

Anche se non possiamo determinare perfettamente cosa accadrà nel futuro, l’abilità di dividere il lavoro in item “sufficientemente piccoli” ci darà un alto grado di predicibilità sul Throughput, sul Delivery Rate (anche se non sappiamo quale sarà il prossimo task, possiamo prevedere il comportamento complessivo nel tempo).

Ritroviamo, quindi, l’approccio “Value Driven”, in contrapposizione con lo “Scope Driven”.

Inoltre, uno sguardo più attento alla Kanban Board della Fig. 2 ci fa notare che alcuni stati sono divisi in due sottostati:

• Doing: è il periodo attivo in cui stiamo effettivamente svolgendo un lavoro
• Done: è il periodo di inattività, dove si attende che qualcuno “tiri” il task nello stato successivo, ed è sicuramente un tempo sprecato

L’analisi delle percentuali dei periodi attivi e dei periodi inattivi (o morti), ci aiuta a scoprire dove abbiamo più spreco di tempo e, di conseguenza, dove intervenire per diminuire il “muda”.

Anche questo modo di procedere ha i suoi vantaggi, una visione leggermente diversa da quella esaminata nell’articolo “Stimare o non stimare, questo è il problema (parte #1) – Le stime con gli Story Point”, ma entrambe le filosofie sono focalizzate sul valore da rilasciare piuttosto che sulla quantità di lavoro svolto.

Conclusione: Stimare o non stimare?

Il pensiero #NoEstimates sta prendendo sempre più piede negli ultimi tempi.

Chi lavora con Kanban è molto più propenso a non stimare e ad affidarsi all’analisi matematica e ai dati ottenuti in un periodo di tempo più o meno variabile.

Un framework come Scrum, d’altronde, ha un periodo fisso di osservazione, lo Sprint, ed è più naturale avere gli Story Point come parametro di riferimento.

Sicuramente anche con Scrum si possono semplicemente contare gli item rilasciati durante lo Sprint senza fare alcuna stima, e basarsi su questi dati per capire dove e come migliorare.

Nella mia esperienza, però, ho notato che provare a dare delle stime per avere degli elementi di paragone, è un modo per far fermare un attimo a riflettere coloro che devono eseguire un lavoro, in modo che possano capire meglio qual è la difficoltà del task/item e se questo è “sufficientemente piccolo” da poter essere gestito o completato in uno Sprint. E, anche se in qualche modo stiamo fornendo una sorta di sicurezza psicologica, tale pratica è sicuramente d’aiuto ai team meno maturi.

Inoltre, dare delle stime di gruppo (Planning Poker) può stimolare la conversazione e la condivisione delle informazioni nel momento in cui i valori forniti sono molto differenti fra loro, ma tale pratica diventa estremamente utile per l’allineamento del team.

Attenzione, però, ai pericoli che ci sono dietro le stime e a non distorcerne l’uso:

• i team sono fatti di persone, con competenze, caratteristiche e sensibilità differenti, e provare a paragonare gli Story Point di gruppi diversi non è la pratica corretta
• basarsi sugli Story Point per determinare la produttività crea inconsciamente un meccanismo di autoprotezione che farà crescere le stime senza una motivazione reale e contemporaneamente distrarranno l’attenzione dal valore rilasciato, nostro vero obiettivo

Seguire una scuola di pensiero o l’altra alla fine non è così diverso, entrambe sono “Value Driven” e questo è l’aspetto fondamentale.

Fig. 4: Triangolo di Ferro VS Triangolo Agile

Entrambi gli approcci se ben applicati portano a risultati notevoli, sicuramente migliori di quelli tradizionali dove il famoso Triangolo di Ferro del Project Management è applicato alla lettera e ci si fa guidare dai piani piuttosto che dal valore.

Autore: Nicola Lobusto – Agile Coach

Se volete sapere di più su Kanban, date un’occhiata a questi articoli:
Come usare Kanban per realizzare gli obiettivi di un M&A
Come può Kanban aiutarti con gli OKR della tua azienda?
Tre modi in cui Kanban può abilitare l’Agile Transformation
Kanban No Way Home: visualizzare per credere
Kanban pizza online: imparare divertendosi…