Come usare le Flow metrics per pianificare in modo più accurato

Come usare le Flow metrics per pianificare in modo più accurato?

In questo prima parte del post, noi – Giuseppe Romeo, Scrum Master @ Hudl e Andrea Pacchioni, Product Manager of Recruitment @ Wyscout – Hudl – condivideremo con voi la nostra esperienza con le flow metrics, uno strumento validissimo per team di prodotto per poter pianificare con maggior sicurezza e serenità. 

Quale impatto ci aspettiamo di avere da questo articolo? 

Vogliamo contribuire alla crescita di giovani PM (e confrontarci anche con chi ha più primavere di noi) condividendo uno strumento che può essere l’arma in più nella gestione del team di sviluppo e nell’organizzazione del lavoro. Noi crediamo che avere un approccio analitico, che aiuti a vedere la realtà dei fatti, sia il punto di partenza da cui migliorare. 

Come è possibile essere più sicuri durante gli sprint planning?

Questa domanda è forse quella che non deve essere mai chiesta ad un product manager. 

Specialmente quando si ha a che fare con un team nuovo, gli strumenti più conosciuti ed usati su cui noi PM facciamo totale affidamento sono le stime degli sviluppatori (rigorosamente in story points). Col tempo, le actions delle varie retrospective e la propria esperienza personale possono possono migliorare la confidenza delle proprie previsioni.  

Tuttavia; 

• Gli story points sono stime soggettive, che non hanno alcun riferimento oggettivo reale. Con questo ovviamente non vogliamo togliere o sminuire una certa sensibilità acquisita col tempo dagli sviluppatori, però è così; 
• Le actions delle retrospective potrebbero concentrarsi su temi che il team ritiene più urgenti e in linea col gruppo anziché soddisfare una nostra specifica esigenza;
• infine, la propria esperienza soggettiva, pur rimanendo un metro di giudizio, rimane comunque ancorata a situazioni ormai passate; 

Cosa vedremo in questo post:

• Contesto e problemi per il PM
• La soluzione: le flow metrics – cosa sono?
  • Mi metto in coda o no?
  • Le 4 metriche fondamentali
• Un flusso stabile di lavoro: la chiave per la predicibilità
  • La legge di Little
  • Perché un approccio lean è possibile anche in un contesto complesso
• I vantaggi nell’adozione delle flow metrics
  • Approccio probabilistico vs approccio deterministico

Come usare le Flow metrics per pianificare in modo più accurato

Contesto e problemi per il PM: perché è importante aumentare la predicibilità del team per un PM?

Partiamo dalle basi, facendo un giro un po’ largo ma che ci aiuterà a fare chiarezza. 

Il Product manager ha come obiettivo l’outcome, l’impatto delle scelte che compie. Con lo stesso principio, il PM prioritizza gli elementi del proprio backlog secondo il proprio contesto aziendale e gli obiettivi trimestrali. 

Di solito, però, questo principio viene meno quando il PM ha a che fare con il team di sviluppo. In quel momento, l’istinto di produrre un output tangibile e considerevole nelle due settimane a venire prevale sull’outcome.

Questo bias provoca una stesura di uno più goal simili ad una checklist delle cose da fare e, di riflesso, il team stesso affronterà lo sprint come una serie di cose da smarcare, pianificando in base alla propria capacity storica.

È necessario quindi che la outcome mindset venga mantenuta anche nella fase di planning per poter sfruttare le flow metrics. 

Le metriche di flusso, cosa sono?

Premessa fondamentale. Le metriche di flusso ci aiutano in uno dei temi fondamentali del product management: la consegna di valore, per i nostri utenti e il nostro business. 

Domande come: 

• Quando i nostri utenti avranno questa funzionalità?
• Quando finiremo il nostro MVP?
• Qual è un timeframe realistico per misurare i nostri outcome?
• Quanto valore consegneremo nel prossimo mese?

hanno risposte in cui le metriche di flusso ci possono aiutare. Questo perché permettono in modo semplice la gestione del flusso di valore e abilitano strumenti di forecast avanzati.

Ma procediamo gradualmente. Siamo nel mondo della delivery, quindi un mondo sfaccettato che ci consente di fare esempi familiari: partiamo da una situazione “culinaria”.

Mi metto in coda o no?

Immaginate di avere una gran fame e di aver deciso di andare a prendere un panino in quel posto che conoscete, dove lo preparano esattamente come vi piace. Siete appena arrivati e vi trovate davanti una lunga fila di persone, ecco che dovrete prendere la difficile decisione: mi metto in coda o no? 

E se non siete proprio accecati dalla fame, proverete a fare una rapida previsione di quando sarete serviti, guardando quante persone vengono servite in un minuto e quante persone sono in coda. Intuitivamente, avrete usato le metriche di flusso. 

Se vi rendete conto che le persone sono servite un po’ a caso, e con tempi molto variabili, probabilmente lascerete la coda per andare dove vi serviranno con tempi più certi.

Le metriche di flusso hanno proprio questa particolarità: sono immediatamente comprensibili ed estremamente potenti, sia in termini predittivi, sia per capire dove intervenire per stabilizzare un sistema produttivo. 

Le quattro metriche fondamentali

Passiamo al mondo del product development, dove predicibilità e stabilità sono particolarmente importanti. Non sarà più il flusso dei panini all’interno del sistema “il mio paninaro preferito” che ci interessa, ma il flusso degli elementi di valore del nostro prodotto (Story, Task o qualunque altra rappresentazione abbiate deciso), dalla loro definizione alla loro realizzazione, all’interno del nostro product team.

Il primo riferimento è definire un punto di partenza e un punto di arrivo. Parlando del sistema “il mio paninaro preferito”, il punto di inizio è la presa del numero mentre il punto di arrivo è la consegna del panino. 

Allo stesso modo, nel sistema di software development, ci serve definire quelli che consideriamo i punti di inizio e fine del nostro workflow. Va da sé che nel caso quest’ultimo non fosse stato definito, è opportuno farlo. 

È pratica comune utilizzare delle Kanban board per visualizzare i workflow, ed è quello che farò per rendere chiare queste e le prossime definizioni.

L’immagine si riferisce alla potenziale board di uno scrum team. Lo start, il punto di inizio, corrisponde alla fase successiva del backlog; in questo caso una fase esplorativa del codice che il team chiama “preparation”. Lo stop coincide col “done”; in questo esempio dopo le attività di release. 

Gli sticky sulla board potrebbero essere le nostre story, le task o le spike, ma chiamiamoli genericamente Work Item per semplicità.

Possiamo quindi definire le 4 fondamentali metriche di flusso:

• WIP (Work In Progress): Il numero di Work Item iniziati ma non finiti. Tutti quelli dopo lo start, ma prima dello stop (in figura 4, tra preparation e release)
• Throughput: Il numero di Work Item finiti, allo stop, nell’intervallo di tempo scelto, ad esempio giornalieri. Questa misura è semplicemente il conteggio esatto all’interno dell’intervallo scelto (es. nella figura, 2 il lunedì, 1 il martedì)
• Work Item Age: Il tempo trascorso da quando è iniziato il lavoro sul dato Work Item. Quanto tempo è passato da quando il Work Item è stato messo nella colonna “preparation”.
• Cycle Time: Il tempo trascorso tra quando un Work Item è iniziato e quando è finito, dallo start allo stop.

Un flusso stabile di lavoro: la chiave per la predicibilità

Stabilizzare il sistema

Il primo vantaggio dell’introduzione del monitoraggio delle metriche di flusso: possiamo renderci conto quanto e se il nostro sistema è instabile ed intervenire per stabilizzarlo.

Tenendo a mente le nostre definizioni, ecco le premesse per avere la stabilità del nostro sistema team all’interno di un periodo di osservazione:

1. Tutti i Work Item che entrano nel sistema devono essere conclusi per uscire dal sistema (dallo start allo stop); 
2. Le variazioni di WIP sono minime durante il periodo di osservazione;
3. La Work Item Age media complessiva degli elementi in progress è costante nel periodo di osservazione.

Se vi domandate da dove spuntano queste condizioni, vi rimando al lavoro di Daniel Vacanti sulla Legge di Little (rispetto alle 5 di Dan, ho tenuto le 3 strettamente necessarie), una legge fondamentale della teoria delle code che è solitamente molto utilizzata nel contesto Kanban.

Le tre condizioni diventano immediatamente tre regole di collaborazione con cui come guidare il lavoro del team giorno per giorno: 

• La 1: se iniziamo a lavorare su un Work Item lo portiamo a conclusione, non abbandoniamo il lavoro a metà. Come possiamo farlo concretamente? Qui ogni team troverà la sua soluzione: lavorando ad esempio sul miglioramento del decision making prima di iniziare il lavoro, o sulla dimensione dei Work Item. BEST TIP; più “piccoli” sono meglio è, per non essere interrotti da altre attività.
• La 2: non iniziamo più cose di quelle che riusciamo a consegnare. Come farlo? Anche qui sta al team trovare la sua strada, ma sicuramente è utile monitorare il throughput (la velocità di consegna) per decidere quanti item iniziare (anche i forecast, che vedremo in seguito, aiutano in questa decisione).
• La 3: non lasciamo invecchiare i Work Item arbitrariamente. Come? Anche qui le soluzioni sono diverse, ma sicuramente è utile misurare la Work Item Age degli elementi per identificare le anomalie.

Con queste accortezze potremo evitare le situazioni instabili, come quando i Work Items su cui il team lavora aumentano ogni giorno, o si bloccano su dipendenze lasciandoli lì a morire, o tornano in “To do” da semi-lavorati per essere dimenticati nella coda delle priorità.

Con un sistema stabile siamo finalmente nelle condizioni migliori per la predicibilità, l’efficacia e l’efficienza della consegna di valore, ai clienti/utenti e all’organizzazione in sé.

Perché un approccio lean è possibile anche in un contesto complesso

Prima di andare avanti sul tema predicibilità facciamo una parentesi per chi sta pensando in questo momento: il mondo è complesso, il mercato è complesso, il prodotto è complesso, lo sviluppo software è complesso, non è possibile fare previsioni. E avete le vostre ragioni. 

Lo sforzo che facciamo adottando un mindset agile è provare ad essere adattivi, raccogliere dati, fare delle ipotesi, e verificarle in brevi cicli di feedback per capire se la strada che stiamo seguendo per raggiungere i nostri outcome va bene o va cambiata. 

Un approccio lean, che rende stabile e ottimizza la delivery diventa fondamentale proprio per migliorare i cicli di feedback, e quello che lo rende possibile è che nei nostri workflow ci sono fasi (es. build, test, deploy…) che si ripetono.

I vantaggi nell’adozione delle flow metrics 

Approccio probabilistico versus flaw of averages

Usare le flow metrics per monitorare un sistema ha il vantaggio di rendere facile un approccio probabilistico al problema della delivery.

Torniamo al nostro paninaro preferito. Ipotizziamo di esserci infine messi in coda, convinti dal fatto che abbiamo visto un cartello che dice: “tempo medio di attesa: 34 minuti”. 

Benissimo: avremo il nostro cibo tra mezz’ora. 

E invece no: la delivery agognata arriva dopo più di un’ora. 

Come clienti siamo incavolati (e affamati), sicuramente ci hanno ingannati. Ma non è stato così, il problema è che abbiamo usato un approccio inadeguato al problema della consegna del panino; quell’unico tempo di attesa, 34 minuti, ci si è scolpito nella mente, per cui il panino è arrivato “in ritardo”.

Se avessimo potuto vedere come era stato calcolato quel tempo medio di attesa forse non avremmo gridato all’imbroglio:

Nelle ultime 6 consegne la delivery era stata molto ballerina, con variazioni anche significative dovute all’indisponibilità dello chef, ma la media era proprio 34 minuti. Tuttavia, la media per sé non è in grado di darci una rappresentazione accurata della realtà. 

È un fenomeno chiamato “flaw of averages”, una fallacia logica che ci fa semplificare un problema dando una risposta semplice, un solo numero, di solito una media.

In questo caso, il problema era relativamente innocuo, ma è esattamente lo stesso problema che si verifica quando rispondiamo alla domanda. Sì, quella domanda: “quando consegneremo questa feature?”. 

La media degli Story Points degli ultimi sprint è proprio la risposta facile e “più comune” ad un problema complesso.

Se un team ha una media di 10 SP per sprint, è ragionevole pensare che sarà in grado di consegnare una feature di 50 SP in 5 sprint. Facile no? Sì, ma è ipersemplificato oltre che estremamente rischioso se usato come forecast per prendere dei commitment.
Non appena avrete detto “5 sprint” sarete fregati: si scolpirà nella testa dei vostri stakeholder, e non rispettandolo sarete “in ritardo”.

Problemi di questa natura sono invece affrontati molto meglio con un approccio probabilistico, che ammette che esistano più esiti ed associa a questi esiti una probabilità di accadere. 

Nel caso del panino, per prendere una decisione, invece della media, non sarebbe stato meglio sapere che nel 50% dei casi monitorati la consegna di un panino era almeno 50 minuti e nel restante 50% di un minuto?

Ed eccoci arrivati alla fine della prima parte di questo post dedicato alle Flow metrics. Nella seconda parte vedremo, in particolare: il Forecasting, la scelta dei dati (Big caveat), come si calcolano le Flow metric, come possono essere proposte, un altro approccio al sizing e un case study.

Pronti? Non perdetevelo e restate sintonizzati 😉

Per leggere la seconda parte del post, iscriviti alla newsletter di Product Heroes!