SAL per ogni progetto

Siamo abituati a considerare lo Stato di Avanzamento di Progetto (SAL) come un progresso delle funzioni da implementare misurato su scala temporale. Nel Project Management tradizionale ci è stato insegnato a misurare questo SAL per mezzo di complicate tabelle, calendari, WBS, diagrammi Gantt e altre diavolerie del genere.

Questo approccio si basa su un assunto di fondo, peraltro antitetico a quello che abbiamo in Agile: quanto abbiamo fatto fino ad oggi, misurato su quanto avevamo in mente di fare in totale. Per questo si fa un piano upfront e poi, passo dopo passo, si cerca di capire a che punto siamo su quel piano. Quante funzionalità abbiamo implementato? Quante parti sono già finite? Come siamo messi coi tempi di consegna?

Ovviamente questo approccio si basa sul poter stimare “correttamente” il tempo per fare le cose e prevedere quanto ne manca al completamento di tutte le parti. Qualcuno si avventura  a misurare questo avanzamento in tempo puro (tempo trascorso / tempo totale preventivato) o risorse (soldi spesi ad oggi / budget complessivo).

Ci sono due aspetti di questa concezione che “stonano”  quando si guarda il progetto con un approccio Agile: il quando e il cosa. E prima di vederli nel dettaglio, occorre un’ultima premessa: non si fa agile, ma si è agili.

“Agile” è aggettivo con cui connotare un insieme di valori e principi a cui ispirarsi per mettere in campo pratiche: lo scopo è costruire prodotti che rilascino valore all’utente finale. Per questo pensiamo che non abbia troppo senso parlare di un “progetto agile”. E forse, anche “Agile Project Management” è una etichetta che ci piace poco: meglio parlare di prodotti e di valore.

Nonostante questo, per semplicità e chiarezza espositiva, chiameremo “progetto agile” un lavoro volto a produrre un prodotto o servizio di valore per l’utente e che si ispiri ai principi dell’agilità fra cui il miglioramento continuo del processo di lavorazione, la creazione di un prodotto in modalità  iterativa grazie ai feedback dal campo, la collaborazione fra business e dev, l’adattamento ai cambi di scenario.

Primo punto: il “quando” non è quello che ci serve

Misurare l’avanzamento di progetto su tempi determinati in fase di pianificazione ci porta di fronte a un problema evidente: i tempi ipotizzati saranno affetti da un errore molto ampio, per cui può essere poco utile costruire un piano di rilascio sulla base di una previsione che ha per definizione un livello di incertezza piuttosto alto.

Poi, non è detto che le funzionalità immaginate al giorno 0 siano esattamente quelle che realmente ci servono, o che ha senso fare: lo scopriremo meglio a mano a mano che procediamo.

Nella pratica infatti accade che, in gran parte dei progetti — quelli già “agili” per definizione ma anche in quelli “tradizionali” per forza di cose — le tempistiche sono costantemente riadattate e lo scope modificato.

Per questo in Agile ci diciamo spesso che il focus dovrebbero essere sul valore rilasciato e non tanto su tempi e costi: è il famoso “triangolo rovesciato”.

Per questo al Gantt e al calendario preferiamo un approccio empirico  e consuntivo; la rigida WBS diventa un dinamico Product Burn Down Chart che può, anzi deve, cambiare. Il SAL sul Gantt diventa un Burn Down Chart e il piano previsionale fatto a inizio progetto diventa un piano che si adatta di sprint in sprint sulla base delle reali potenzialità del gruppo di lavoro, e dell’ecosistema al contorno.

Secondo punto: neanche il cosa è quello che ci serve

La figura 1 mette in luce un aspetto fondamentale dell’approccio agile, ovvero che fissando tempi e costi, si può variare sullo scope, piuttosto che il contrario. Ma perché mai dovremmo non completare tutte le feature di sistema? Perché dovremmo fissare la data di scadenza e impegnarci per non  superarla? Non è forse una resa? “Tanto non ce la faremo a fare tutto, vediamo cosa riusciamo a fare per la data di scadenza, poi decidiamo”. In parte c’è del vero in questa presa di coscienza…

Ma c’è dell’altro. Partiamo dal backlog: sappiamo che contiene tutte le domande a cui dobbiamo rispondere per soddisfare i bisogni utente. Sappiamo che è ordinato per priorità, che in alto ci sono le cose di valore. Sappiamo che soddisfare anche una minima parte potrebbe comunque fornire una quota importante del valore complessivo.

Quindi, se da un punto di vista delle cose fatte possiamo fare una media aritmetica, parlando di valore rilasciato — ossia del senso di quello che stiamo facendo — occorre pesare il contributo di ogni elemento del backlog.

Vediamo di spiegare meglio con un esempio: immaginiamo di avere un backlog di 100 elementi e ipotizziamo che avendoli stimati tutti, tali items diano complessivamente 1000 punti effort. Come chi lavora in Scrum già sa, per punti effort si intendono proprio quelli che il team usa per stimare le user stories e con i quali poi si aggiorna a fine sprint la velocity e si compila il Burn Down Chart.

Il grafico di figura 3 ci dice quindi che, iterazione dopo iterazione, i punti effort rimanenti scendono per andare a zero. Se i punti erano inizialmente 1000, dopo averne realizzati 500 possiamo dire di essere più o meno a metà de lavoro? Dal punto di vista artimetico probabilmente si… ma forse serve altro.

Un nuovo approccio

Osservare solo il trend dei punti fatti — o di quelli che restano, come nel Burn Down Chart — non è altro che un modo differente per misurare la stessa cosa che si faceva nel Project Management tradizionale: contare quante cose abbiamo fatto e ipotizzare quante cose mancano.

Se vogliamo fare un reale cambio di passo, occorre mutare prospettiva e modificare radicalmente il significato di avanzamento di progetto.

In Agile è di primaria importanza focalizzare il lavoro sul rilascio di valore, sul massimizzare la soddisfazione utente e sul portargli un reale beneficio, o un nuovo, migliore, modo di fare le cose. In tal senso i punti effort non ci dicono molto: se abbiamo implementato 500 pt su 1000 pt sappiamo solo che abbiamo implementato 500 punti su un totale di 1000 ma non sappiamo nulla di quanto beneficio stiamo portando all’utente. Se per assurdo, il progetto non riuscisse a portare alcun beneficio reale anche dopo aver implementato il millesimo punto del backlog, potremmo dire di aver finito? Oppure dovremmo continuare?

E se, viceversa, dopo soli 100 punti il nostro utente fosse talmente contento di quello che ha da non volere più il resto? A che punto del progetto saremmo in quel caso? Dal punto di vista matematico al 10%, ma dal punto di vista del senso di quello che stiamo facendo, potremmo anche fermarci e dedicare le nostre energie a  un altro importante progetto.

Ma in Scrum abbiamo proprio che nel backlog, se ben organizzato, le cose in alto valgono di più, in termini di valore e di soddisfazione utente.

Punti valore

Se quindi introducessimo il concetto di “punti valore” accanto ai punti effort, potremmo dire che pochi punti effort, relativi alle storie in alto nel backlog, dovrebbero produrre tantissimi punti valore.

Se dicessimo che “La maggior parte degli effetti è dovuta a un numero ristretto di cause”, ci viene in mente nulla? Se vi dicessi Pareto?

Se prendessimo il trend dei punti effort rimanenti — come si fa con il Burn Down Chart — e lo comparassimo con il trend dei punti valore, otterremmo qualcosa di simile a quanto mostrato in figura 6: la curva del valore da erogare scende rapidamente all’inizio — si eroga molto valore e si risolvono i business needs più importanti nel progetto — per poi stabilizzarsi a tendere. Non è detto che vada a zero: vuol dire che potremmo decidere di lasciare qualcosa, tipo qualche bisogno di poco conto che potrebbe rimanere non soddisfatto.

Dal grafico si evince facilmente che, da un certo punto in poi, continuare a lavorare aggiunge poco valore o cambiamenti all’utente. Fermarsi allo sprint n o n+1 o n+m cambia poco.

Quindi lo stato avanzamento lavori assume una concezione completamente differente: invece di dire “Siamo giunti quasi a fine perché abbiamo completato tutte le funzionalità che ci eravamo proposti di fare”, possiamo dire “Siamo a un punto tale che potremmo anche fermarci, perché abbiamo già rilasciato gran parte del valore al cliente”.

Questa visione stravolge pesantemente la concezione di progetto tradizionale: “Dobbiamo fare tutto entro il”, o “Dobbiamo completare il progetto rimanendo nei costi” (scope, time, budget).

Cosa dobbiamo cambiare nell’operatività?

Se questo nuovo modo di considera il SAL ha un impatto molto importante dal punto di vista culturale, nella pratica della operatività quotidiana di team probabilmente le cose cambiano poco.

Un accorgimento che certamente dovremmo adottare è introdurre i punti valore su ogni item del backlog. Per esempio, si potrebbero modificare le card delle storie del backlog, introducendo uno spazio per misurare il valore in punti, analogamente a quanto facciamo con i punti effort.

Compito molto più difficile è invece capire come trovare le metriche per misurare il valore. Cominceremo a parlarne adesso per approfondire maggiormente nei prossimi articoli.

Ma come misurare il valore?

Abbiamo già trattato in passato le metriche con cui misurare il valore riportato [1]; all’epoca abbiamo parlato di misurazione della soddisfazione utente dopo che abbiamo rilasciato qualcosa; allora il tema era “Non è finito quando è finito, ma dobbiamo misurare se l’utente trova utile quello che gli abbiamo dato”.

Per quanto sia importante questo tipo di valutazione — misuriamo il beneficio del prodotto mentre l’utente lo usa — in ottica di Agile SAL è necessario valutare le cose che stiamo facendo in proiezione; in estrema sintesi il PO dovrebbe trovare il valore strategico di quello che è nel backlog.

L’argomento è molto ampio, lo affronteremo più approfonditamente nella prossima puntata, limitandoci a introdurre a livello macroscopico alcuni aspetti che potremmo prendere in considerazione per estrapolare queste metriche. Per esempio potremmo considerare:

• Prospettiva sulla user journey: scomponendo l’intera Customer Journey in tanti passi, è probabile che ognuno di questi passi contenga al suo interno la risposta a determinate necessità. Non tutte dello stesso valore.
• Prospettiva dei differenti stakeholders o utilizzatori: un esercizio utile è quello di introdurre differenti scale di misurazione del valore in funzione dell’utente a cui ci si rivolge. E si può fare una media, aritmetica o pesata.
• Prospettiva su end-to-end: pensando alla Customer Journey in ottica end-to-end, non è detto che tutti i passi siano necessari o che sia necessario realizzarli con lo stesso livello di dettaglio. Suggerimento: si pensi al walking skeleton dello User Story Mapping.
• Allineamento con la strategia dell’organizzazione e con la prioritizzazione delle iniziative: i razionali che possiamo usare per mettere in fila le iniziative di una organizzazione possono darci informazioni utili per misurare e classificare le storie di un backlog. Suggerimento: si veda Agile Portfolio Management.

“Prima” e “dopo” devono comunque cortocircuitarsi

Prima di lasciarsi e rimandare gli approfondimenti alla prossima puntata, è doveroso ricordare un punto fondamentale. Le metriche o i razionali che ci possono essere utili per misurare il valore rilasciato (punti valore delle storie) come presentati in questa puntata, sono di fatto valutazioni predittive: ci immaginiamo che quella particolare funzione sia più utile o di valore di quell’altra. Quando il PO mette in fila gli elementi del backlog è guidato da considerazioni di questo tipo.

Come visto in una precedente serie [1] queste considerazioni dovrebbero sempre essere confrontate con quanto poi realmente accade quando un utente usa il prodotto. Le metriche di misurazione del valore devono per forza di cose essere associate poi alla soddisfazione utente. Ricordo a tal proposito l’ultima slide della presentazione fatta insieme a Ilaria Mauric all’Agile Business Day [2].

Riferimenti

[1] Giovanni Puliti – Ilaria Mauric, Product Ownership e misurazione del valore di un prodotto –

I parte: Le misurazioni interne/indirette. MokaByte 247, febbraio 2019 (e articoli successivi della serie)

https://www.mokabyte.it/2019/02/productvalueownership-1/

[2] Agile Business Day

https://www.agilebusinessday.com/abd_2019-it/