Pratica dell'uso dei Burn Down Chart nel contesto di SAFe e Scrum

In questo articolo ho intenzione di raccontare come, nella nostra pratica, applichiamo il diagramma di burn down (Burn Down Chart) nel processo di lavoro secondo la metodologia SAFe

Comincerò, credo, dalla cosa più interessante. E precisamente dal fatto che l'uso di questo diagramma in SAFe non dovrebbe avere alcuna specificità rispetto all'uso di questo diagramma in SCRUM. O dovrebbe?

Da noi SAFe si distingue per la presenza di un ruolo come RTE, a differenza di SCRUM, dove non c'è. Il Burn Down Chart - è uno strumento per monitorare il volume di lavoro nello sprint ed è necessario innanzitutto per il team SCRUM, e non per qualcuno dall'esterno, non è vero?

Dunque, passerò comunque a come usiamo il Burn Down Chart, nonostante tutto, e, restando sempre all'interno del framework SAFe.

Rivesto il ruolo di Scrum Master e cerco di mettere in evidenza questo diagramma ogni giorno per tutto il Dev Team. Lo strumento che uso è la chat di team, la menzione di tutto il team tramite "@", lo screenshot dello stato attuale del diagramma. Menzionare tutto il team è uno strumento piuttosto delicato ed è importante usarlo il più raramente possibile (dopotutto, noi Scrum Master dobbiamo aiutare il team a lavorare in comfort e con la minima distrazione possibile, non è vero?)

Alla fine il team vede ogni giorno lo stato attuale dello sprint ed è in grado di monitorare i seguenti eventi

• Comparsa di lavoro non pianificato
• Lunga permanenza dei task in stato non completato
• Eccessiva messa in conto dei rischi
• Comprensione - se il lavoro procede al ritmo giusto

Di seguito cercherò di svelare ciascuno di questi eventi e portare esempi dalla mia pratica.

Comparsa di lavoro non pianificato

Su questo diagramma si vede molto bene come compare nuovo lavoro (nel secondo martedì dello sprint di due settimane).

Caso dalla pratica: "Lo sviluppatore, come membro dello scrum team, che condivide i principi agile, interagisce ottimamente con il Product Owner direttamente. Il Product Owner gli dice che questo qui va fatto al volo, lo capisci da solo, qui è veloce e i rischi sono minimi.

Lo sviluppatore è bravo, sa tutto sull'agile e sull'importanza di fornire business value, va e butta sulla board una storia dal backlog, stimata dal team in 6 sp.

Il resto del team (tranne lo sviluppatore e il Product Owner) se ne accorge all'aggiornamento mattutino del diagramma. Al daily standup il team prende una decisione su come gestire questa situazione. Con ogni probabilità, la storia viene espulsa dallo sprint, al Product Owner e allo Sviluppatore il team fa capire che così non si fa, il Product Owner può inserire questa storia nello sprint successivo se necessario.

Certo, idealmente il team dovrebbe notare la comparsa di nuovo lavoro al daily standup anche senza il diagramma. Ma il diagramma è un buon indicatore che riduce al minimo i rischi di non notare un cambiamento così importante per tutto il team.

Qui è importante capire che lo scenario sarebbe potuto andare diversamente a seconda del livello del team. Nei team forti il Product Owner difficilmente farebbe così, e se anche lo facesse, lo motiverebbe non con il fatto che «questo si può fare al volo», ma con il fatto che «valuto al 55% la probabilità che se lo facciamo ora, possa aumentare il nostro profitto del 20% il mese prossimo» o con qualche altra metrica misurabile.

Lunga permanenza dei task in stato non completato

Qui vediamo che per molto tempo il lavoro non viene completato nemmeno parzialmente. Questo può segnalare diversi problemi, ne elenco alcuni

• Cattiva decomposizione dei task

  Molto spesso i team alle prime armi parlano dell'impossibilità di decomporre. Da loro tutto brucia l'ultimo giorno, il lavoro non viene parallelizzato, ecc. Naturalmente, lo Scrum Master deve lavorare su questo e spiegare al team il valore della decomposizione.

• DOD formulato in modo non ottimale

  DOD (Definition of Done) - descrizione dei criteri di prontezza di una User Story nello sprint. A volte non esistono affatto o sono descritti in modo molto astratto. Questo può benissimo essere un problema che, naturalmente, lo Scrum Master deve aiutare a risolvere

Eccessiva messa in conto dei rischi

In questo caso vediamo una situazione in cui il team ha messo in conto troppi rischi.

Forse qualche storia è stata sovrastimata. Forse è un problema più sistemico e bisogna aumentare il volume di lavoro durante la pianificazione dello sprint. In ogni caso, questa situazione non è corretta. Dopotutto il business aveva pianificato che sarebbero stati realizzati proprio i task dello sprint e proprio entro la fine dello sprint. A seconda di come sono state pianificate le dipendenze, qui molto probabilmente bisognerà tenere riunioni per correggere le aspettative.

Nella mia esperienza è successo quando si è trovata una soluzione più rapida di quella discussa in fase di stima. Abbiamo discusso con tutto il team quale storia saremmo riusciti a chiudere entro la fine dello sprint e in retrospettiva abbiamo concordato che avremmo cercato di guardare il codice durante il grooming. È emerso che bastava semplicemente dare un'occhiata al codice per capire che la soluzione era molto più semplice.

Comprensione - se il lavoro procede al ritmo giusto

Qui vorrei richiamare l'attenzione sui modi graficamente poco riusciti di visualizzare il Burn Down Chart

Nella parte superiore dell'immagine è riportato un esempio di realizzazione grafica non proprio riuscita per due motivi, che esporrò di seguito.

• Non si nota l'ingresso di nuovi SP nello sprint

  Qui, nel diagramma superiore, quasi non si nota che è stato aggiunto lavoro non pianificato. In quello inferiore è più evidente.

• Il resto relativo del lavoro non è visualizzato correttamente

  Secondo il diagramma superiore restano ancora 3 giorni di lavoro. In realtà sono 2, nel giorno festivo, forse qualcuno pensa di riposare.

Certo, a qualcuno queste piccole cose sembreranno insignificanti. Ma bisogna capire che ogni membro del team darà solo un'occhiata di sfuggita a questo diagramma e esso deve trasmettere il massimo delle informazioni utili.