Perche’ dovrei raccogliere metriche? Come possono aiutarmi? Il mio CFD e’ molto colorato ma a cosa serve?
CFD, control chart, lead time distribution…Le metriche possono incutere timore ma se sai come interpretarle puoi portare il tuo processo a un nuovo livello!
In questo experience report pieno di esempi pratici vi raccontero’ come il mio team a Sky (Londra) usa Kanban e metriche per:
- guidare il processo di miglioramento continuo
- essere prevedibili, senza bisogno di stime
Downloads
Powerpoint: https://goo.gl/mHg3nx
PDF: https://goo.gl/WFaoW8
2. About me
● ~2 anni @ Sky Network Services, Londra
● software dev & continuous improvement
● Kanban “helper”
Mattia Battiston
@BattistonMattia
mattia.battiston@gmail.com
Ciao!
6. Ma le metriche non erano cattive?
Problemi tipici:
- si imbroglia
- disfunzioni
7. Buone vs Cattive Metriche
● migliorare il sistema ● premiare/punire individui
“95% performance attribuibile al
sistema, 5% alle persone”
W. Edwards Deming
● feedback ● obiettivi
● leading (guardano al presente) ● lagging (guardano al passato)
● tutte devono migliorare ● ottimizzazioni locali
11. (Poca) Matematica
● Min, Max
Normal: data is distributed
around a central value
e.g. height of UK population
Skewed: data has a long tail
on one side (positive or
negative)
e.g. income of UK population
(positive skew)
Lead time of stories follows
skewed distribution
● Media
avg(1,2,2,2,3,14) = (1+2+2+2+3+14)/6 = 4
● Mediana: separa metà alta e metà bassa. Meno influenzata da outlier
median(1,2,2,2,3,14) = 2
● Moda: valore più frequente
mode(1,2,2,2,3,14) = 2
● Standard Deviation: misura la dispersione dalla media. Quando è alta, i valori
oscillano in un largo intervallo.
stdev(1,2,2,2,3,14) = 4.5; stdev(1,2,2,2,3,5) = 1.2;
● Percentile: percentuale di elementi che cadono in un intervallo
50% perc(1,2,2,3,7,8,14) = 3; 80% perc(1,2,2,3,7,8,14) = 7.8;
● Normal Distribution vs Skewed Distribution:
13. Cumulative Flow Diagram
● Obiettivo: retrospettiva (con un buon facilitatore)
● Obiettivo: dimostra l’efficacia dei cambiamenti
cambio WIP limit in DEV: da 3 a 2
14. Cumulative Flow Diagram
● Obiettivo: decidere su cosa lavorare oggi
● Obiettivo: forecasting. Approssimazione per lead time, wip, delivery date (ma è più
facile se sono raccolti separatamente)
WIP
LEAD TIME
15. CFD Patterns
(fonte: CFD article by Pawel Brodzinski)
growing lines: indicate large WIP + context switching.
action: use WIP limits
stairs: indicates large batches and timeboxes
action: move towards flow (lower WIP,
more releases, cross-functional people)
flat lines: nothing’s moving on the board
action: investigate blockers, focus on finishing, split in
smaller stories
single flat line: testing bottleneck
action: investigate blockers, pair with testers,
automate more
typical timeboxed iterationdropping lines: items going back
action: improve policies
17. Control Chart
Descrizione: Mostra la durata di ogni storia. Usa un limite superiore e inferiore; le storie
che cadono fuori dai limiti sono storie interessanti (insolite), le analizziamo per migliorare
storie
cycletime(gg)
18. Cycle/Lead Time stats + History
Descrizione: Statistiche per conoscere il tuo cycle time. Aiuta a predire “quanto
impiegherà probabilmente la prossima storia?”. Visualizza trend di miglioramento
19. Lead Time distribution
50%
85%
cycle time (gg)
no.storie
Descrizione: Per ogni lead time (n. giorni), quante storie hanno impiegato così a lungo.
Utile mostrarlo in percentuale per conoscere la probabilità.
21. Cycle Time vs Release Prep. Time
storie
giorni
Descrizione: Per ogni storia mostra quanto ha speso nell’iterazione e in release
preparation. Usato per discutere il costo di rilasci poco frequenti
32. Flow Efficiency
Descrizione: Mostra quanto tempo le storie spendono in code - nessuno ci stava
lavorando. Mostra quanto si può migliorare eliminando i tempi di attesa.
34. Stats per Status
Descrizione: control chart, cycle time distribution e stats per ogni stato. Utile per
simulazioni (forecast); dà indicazione di dove dobbiamo migliorare
36. Risorse
Libri
Presentazioni
● Troy Magennis LKUK13 LKCE13 Agile 2014
● David Anderson Kanban's 3 Agendas LKUK13
● Hakan Forss The Red Brick Cancer
Articoli
● Cycle-time Analysis and Monte Carlo Simulation Results (Troy Magennis)
● The Seven Deadly Sins of Agile Measurement (Larry Maccherone)
● A Tool for tracking Kanban projects (Emily Webber)
● FocusedObjective@Github
● Lean Forecasting Tutorial by Troy Magennis
● Cumulative Flow Diagram (Pawel Brodzinski)
● worldofchris@github (Chris Young)
Case Studies
Siemens Health Services Sandvik IT Ericsson SAP Lean Kanban Case Studies series
● Dan Brown Flow Like Ketchup (LLKD14)
● Dimitar Bakardzhiev LKUK14 webinar
● Larry Maccherone LKUK14
● Analyzing Lead Time Distribution Chart (Alexei Zheglov)
● Inside a Lead Time Distribution (Alexei Zheglov)
● Forecasting Your Oranges (Dan Brown)
● On Story Points and Distributions (Agile Pirate)
grazie mille per aver scelto la mia sessione.
Posso chiedere una rapida alzata di mano:
chi sa piu’ o meno cos’e’ Kanban?
chi ha mai visto o usato un CFD?
Ok, siete nel posto giusto!
Io sono Mattia Battiston, da due anni lavoro a Londra per Sky
Sky e’ la stessa Sky che c’e’ in Italia, ma in UK ci occupiamo anche di internet e telefono. Io faccio funzionare internet
Devo avvisarvi che dopo due anni a parlare in inglese il cervello mi e’ andato in pappa e faccio fatica a pensare ad alcuni termini in italiano. ci saranno molti inglesismi, perdonatemi!
a Sky sono sviluppatore, team leader e “Kanban Helper”. Aiuto team a usare Kanban e metriche
questa presentazione e’ una versione rivista di un workshop che tengo in azienda per gli altri team
spiego l’esperienza del mio team, perche’ usiamo metriche, cosa abbiamo imparato, ecc.
un minimo di conoscenza di Kanban aiuta, ma non e’ strettamente necessario.
se sapete cosa si intende con WIP Limit dovrebbe essere abbastanza per seguire senza problemi
Perche’ servono metriche? Quale problema stiamo cercando di risolvere?
- usiamo metriche per guidare il nostro processo di miglioramento continuo. Decidiamo dove dobbiamo migliorare, introduciamo un cambiamento, e valutiamo se l’esperimento e’ stato positivo o meno
- forecast. Quando ci viene chiesta una stima, invece di tirare a indovinare usiamo i dati storici che abbiamo per prevedere quanto impiegheremo. Usiamo una tecnica che si chiama Probabilistic Forecating
Forecasting e’ un argomento enorme, oggi vi faccio vedere giusto un po’, ma se volete saperne di piu’ possiamo parlarne durante la pausa
molto spesso la reazione della gente quanto si parla di metriche e’ “mmmh, no grazie”
abbiamo visto un sacco di usi spaventosi (es. punti raddoppiati)
e’ vero, i problemi tipici di ogni metrica sono che si puo’ imbrogliare, e causera’ disfunzioni
Per questo noi facciamo questa distinzione tra metriche buone e cattive:
buone metriche aiutano a migliorare il sistema, non sono usate per punire o premiare singoli individui
usiamo metriche come feedback per sapere se stiamo migliorando, ma non sono mai un obiettivo
preferiamo metriche “leading” rispetto a “lagging”
solo quando tutte migliorano allora stiamo migliorando, cosi’ non si puo’ imbrogliare
questa e’ la lavagna principale del mio team
queste buste colorate rappresentano i nostri WIP limit
la prima colonna si chiama NEXT e contiene le 3 storie che sono la priorita’. quando si libera uno spazio, decidiamo “qual e’ la prossima priorita’?”
NEXT e’ il commitment point
poi la storia va in dev e testing, fino a waiting for cut
aspetta qui fino alla fine dell’iterazione (due settimane), poi facciamo un cut. il cut va in release testing e poi viene rilasciato in produzione dopo un mese
applicazioni piu’ recenti vengono rilasciate on-demand, senza aspettare il cut
direct va da dev a done immediatamente
questi sono 3 diversi work item type. quasi tutte le metriche hanno senso solo quando consideri un singolo tipo di work item
per esempio, il lead time di storie “on demand” e’ molto diverso dal lead time di storie “iteration-based”
raccogliere i dati e’ molto semplice. quando stampiamo le storie usiamo una griglia in basso con una cella per ogni stato.
ogni volta che la storia va allo stato successivo la timbriamo con la data attuale
e questo e’ tutto quello che serve! e’ abbastanza per calcolare tutte le altre metriche
perche’ non usiamo un tool elettronico?
i dati raccolti dal tool spesso non rappresentano la realta’ (ma se ti fidi allora usali!)
i tool sono molto scarsi nell’analisi di questi dati. offrono molto poco, e quel che offrono e’ molto rigido. Preferiamo spreadsheet perche’ offre massima flessibilita’
regolarmente mettiamo i dati in uno spreadsheet
l’unico input sono qualche dettaglio sulla storia (id, descrizione) e le date in cui entra in uno stato. tutto il resto e’ calcolato
non fatevi spaventare, la matematica che serve e’ poca e probabilmente la ricordate dai tempi della scuola.
comunque ci sono le formule gia’ fatte in excel
Probabilmente e’ il grafico piu’ famoso di Kanban
per ogni giorno mostra quante storie sono in ogni stato
un buon CFD mostra linee che crescono in modo continuo e parallele
e’ molto colorato e fa figo, ma cosa ci puoi fare in pratica?
lo usiamo in retrospettive per parlare di un particulare periodo di tempo.
lo usiamo per dimostrare l’efficacia dei cambiamenti
lo puoi usare per decidere su cosa lavorare (es. se uno stato e’ troppo grosso)
ci puoi leggere informazioni sulla prevedibilita’. WIP, Lead Time, e perfino proiettare il delivery date. Ma ci sono altri modi piu’ facili se hai i dati
ci sono una serie di pattern che si possono identificare in un CFD
un altro grafico molto famoso. di solito usano punti invece di colonne, ma e’ sempre lo stesso
mostra storie insolite dalle quali si puo’ imparare
calcoliamo un po’ di statistiche che ci aiutano a capire il nostro lead time
mediana e’ meno influenzata da estremi rispetto alla media
deviazione ci da’ una indicazione di quanta variabilita’ abbiamo
un po’ di percentili sono utili per fare previsioni, e in attimo ve ne parlo meglio
usiamo “all time” e “since XXX” perche’ dati troppo vecchi non dovrebbero piu’ essere rappresentativi
se avete mai avuto problemi con stime, questa e’ la parte dove volete fare attenzione.
conta quante storie hanno impiegato un certo numero di giorni
la curva si chiama Weibull, ma non importa
posso esprimere questi dati come percentuale, e decidere quando dovrei iniziare una storia
ci serve una metrica leading; abbiamo inventato story hearth
in base a da quanto la storia e’ gia’ in progress, sappiamo se va bene o se dobbiamo preoccuparci
usiamo questo durante lo standup per decidere su cosa lavorare
per chi di voi non rilascia in produzione molto spesso, questo e’ interessante.
in blu e’ il tempo che impiega la storia per essere “pronta”. in rosa il tempo che poi impiega per arrivare in produzione
abbiamo usato questo per discutere e chiedere di rilasciare piu’ spesso
contiamo il numero di storie completate in un particolare arco di tempo. noi usiamo l’iterazione come unita’ temporale
utile per sapere quante storie dovremmo pianificare per una iterazione
utilissimo per fare montecarlo-simulation
teniamo traccia di quanto WIP c’e’ ogni giorno, e facciamo la media per ogni iterazione
l’obiettivo e’ tenere il WIP basso per limitare il context switching
avendo throughput e WIP possiamo dimostrare Little’s Law
questa slide di solito mi mette nei guai, perche’ in ambienti agili di solito criticare l’uso di story points e’ un tabu’
storie da 1 un punto impiegavano 2-10 giorni; storie da due punti impiegavano 2-20 giorni, ecc.
la correlazione tra punti e quanto impiegano in effetti e’ quasi inesistente
ci sono altri fattori che influenzano il lead time molto piu’ dei punti: WIP e blockers
adesso usiamo semplicemente la lead time distribution per predire quanto una storia impieghera’
come in coda a disneyland “quanto ci vuole da qui?”
prima di iniziare development dobbiamo identificare i task per la storia
in base al numero di task sappiamo quanto la storia impieghera’
in base al numero di task rimanenti decidiamo se dobbiamo aiutare su una storia o se va tutto bene
semplicemente contiamo il numero di bug (qualsiasi cosa riportata come bug) e il numero di storie, e lo esprimiamo come percentuale
lo usiamo per pianificare: se sto pianificando 10 storie, devo tenere conto che dovro’ anche lavorare su 1-2 bug
sappiamo quali stati aggiungono valore, perche’ qualcuno sta lavorando su una storia, e quali stati invece sono semplici code, la storia sta aspettando
flow efficiency e’ la percentuale di tempo spesa aggiungengo valore
dimostra deming: non e’ facendo lavorare le persone di piu’ che avremo un miglioramento, ma cambiando il processo possiamo eliminare le code ed essere 50% piu’ veloci
per ridurre code: abbassa WIP, cross-functional team (one piece flow)
per ogni storia mostra quanto ha speso in ogni stato, sia in tempo assoluto che in percentuale
pensato a quante volte quando un progetto e’ in ritardo viene puntato il dito sugli sviluppatori, e magari vengono aggiunti developers. questa potrebbe aiutare il blu, ma per fare la differenza dobbiamo rimuovere tutto il resto
analizziamo anche ogni singolo stato, per decidere su cosa dobbiamo concentrarci