Earned Value in Agile
L’integrazione dell’Earned Value Analysis (EVA) con i metodi Agili è un argomento dibattuto che divide la comunità dei project manager. Da una parte, l’EVA viene vista come uno strumento efficace per monitorare i progressi e la performance finanziaria nei progetti, dall’altra viene spesso criticata per la sua complessità e la percezione di rigidità che mal si adatta all’agilità e flessibilità tipiche delle metodologie Agile.
La critica più forte che viene proposta dalla comunità degli agilisti è legata al significato che la Earned Value attribuisce al concetto di valore: secondo il Project Management tradizionale. valore è un modo per definire il costo del bene prodotto, mentre in Agile “valore” è legato non tanto alle cose fatte ma a quanto queste siano utili per l’utilizzatore, ossia quanto queste risolvano le necessità dell’utente finale. Due visioni diametralmente opposte. Ma non è detto che non sia utile e interessante un confronto fra questi due mondi. Vediamo di che si tratta.
La Earned Value Analysis: i costi come metrica di avanzamento del progetto
Nei progetti tradizionali spesso si usano i costi sostenuti per monitorare la percentuale di avanzamento del lavoro. Sulla base di questo assunto, si costruisce tutta la EVA che si poggia su tre indicatori fondamentali: Planned Value, Earned Value e Actual Cost. Di seguito, vengono presentate le definizioni di questi concetti fondamentali
Valore pianificato (Planned Value, PV)
Rappresenta il valore del lavoro pianificato fino a una certa data. È l’importo totale che si prevede di spendere per completare il lavoro programmato entro quel momento.
Valore realizzato (Earned Value, EV)
Indica il valore (previsto) del lavoro effettivamente completato fino a una certa data. Viene usato per misurare il progresso del progetto in termini di valore.
Costo effettivo (Actual Cost, AC)
È il costo totale effettivamente sostenuto per il lavoro completato fino a quel momento. Misura le spese effettive.
in formule, EV si calcola in questo modo:
I dubbi dell’Agile
Per un agilista è difficile comprendere la differenza fra EV e AC e questo genera spesso forti incomprensioni. Una piccola variazione nella definizione di EV potrebbe mettere d’accordo i due mondi:
EV indica il costo previsto per realizzare le parti prodotte fino a un determinato momento del progetto. In questo caso Earned si riferisce al fatto che sono stati prodotti dei “manufatti” che si presume abbiano una importanza progettuale.
Si tratta di costi — questo è innegabile — e non di valore realmente prodotto. La principale differenza fra la cultura Agile e l’approccio PM tradizionale sta nel fatto che in Agile questi indicatori sono costruiti sopra i costi sostenuti e non sul valore realmente prodotto dal team di progetto.
Ma si può usare EV anche in un progetto Scrum?
Rispondere a questa domanda non è immediato… Cerchiamo di capirlo meglio con qualche esempio. Immaginiamo un viaggio fra amici in cui, a fronte dei km percorsi, il gruppo tiene sotto controllo la spesa per il carburante.
Il viaggio inizia bene, il gruppo di amici arriva alla prima importante tappa del loro viaggio e osserva che la spesa per il carburante è in linea con le aspettative. Addirittura stanno spendendo meno, grazie a una guida oculata e a una nuova strada che ha accorciato un pezzo del percorso. Il gruppo ha risparmiato soldi.
Usando la terminologia del Project Management tradizionale, si può dire che il progetto, per arrivare alla prima milestone (ML1), è in anticipo sui costi, affermazione che a prima vista può ingannare: sembra una cosa negativa, quasi che si siano dovute anticipare delle spese. In realtà, se AC < EV significa che, guardando le cose dal punto di vista monetario, abbiamo speso di meno del previsto per realizzare una certa quantità di cose o che, viceversa, con il denaro che abbiamo previsto di spendere, potremmo fare più cose. È da qui che arriva il concetto di “anticipo”.
Il burndown di un progetto agile ci direbbe una cosa simile, ma non dalla prospettiva dei costi, bensì da quella del tempo necessario per fare quelle cose: il progetto è in anticipo rispetto alla roadmap, ossia rispetto al giorno X in cui avremmo dovuto raggiungere la ML1.
Se tempi e costi sono direttamente proporzionali le due viste sono equivalenti. E fin qui…
Il viaggio prosegue
Proseguendo con la metafora del viaggio, si immagini che nella seconda metà del viaggio il gruppo abbia incontrato delle difficoltà: rallentamenti dovuti al traffico, errori nella navigazione con conseguenti allungamenti del viaggio ed evenienze simili.
Facendo il conto dei per il carburante, il gruppo si rende conto che ha speso più di quanto previsto per arrivare alla seconda tappa. Anche qui, detto in altri termini, con la quantità di denaro che aveva previsto di spendere, invece il gruppo non è arrivato alla fine della seconda tappa.
Nel Project Management tradizionale, questo è il caso in cui il progetto rallenta a causa di problemi imprevisti, ma il personale viene comunque pagato: i soldi realmente spesi (costo effettivo, AC) sono più di quanto ipotizzato (valore realizzato, EV) per arrivare alla seconda milestone (ML2) di progetto. Quindi in questo caso AC > EV o, detto dalla prospettiva del valore prodotto, EV < AC
Il PM in questo caso comunica che “Siamo in ritardo sui costi”, affermazione poco comprensibile per i non addetti ai lavori: nel linguaggio comune, essere in ritardo sui costi può apparire paradossalmente una cosa positiva.
Come per il caso precedente, se volessimo usare il burndown, tipico strumento del Product Owner, se tempi e costi sono direttamente proporzionali, avremmo una informazione simile, ossia che il progetto è in ritardo rispetto alla roadmap: il giorno Y avremmo dovuto raggiungere la ML2, ma non ci siamo ancora.
Ci troviamo quindi di fronte a due modi di monitorare lo stato di avanzamento del progetto: quello agile che guarda le cose fatte rispetto al tempo, e quello tradizionale che usa i costi per monitorare tale avanzamento.
Una prima sintesi
Personalmente — con i dovuti adeguamenti nel gergo della terminologia economica — valuto le due prospettive comunque utili anche se non del tutto sovrapponibili. In particolare, penso che l’uso dell’Earned Value come indicatore di SAL sia realistico solo se l’andamento dei costi è lineare e sopratutto se il denominatore di quella frazione (vedi formula di EV) non cambia, ossia se il budget totale previsto non cambia. Questa cosa, però, in Agile non è vera, perché il Product Backlog cambia continuamente.
Prendiamo un esempio pratico, ipotizzando:
- Tutto il lavoro da fare = 10 sprint – 1000 punti – 100% del progetto => PV = 100 k €
- Lavoro svolto = 4 sprint – 400 punti – 40% => EV = 40 k €
Questa valutazione ha senso solo se i costi sono lineari e il denominatore non cambia. Ma in Agile, il denominatore cambia spesso: il Product Backlog muta a seguito di backlog refinement, aggiunta di nuove feature, rimozione di altre cose da fare o perché si capisce che non servono oppure per tenere entro i limiti i tempi e i costi…
La visione binoculare
Quindi, che cosa dobbiamo dedurre da tutto questo? Che, se teniamo la frazione “lavoro completato / tutto il lavoro da fare” come indicatore dell’avanzamento del progetto, senza considerare i costi, allora la EVA ha senso.
Oppure potrebbe essere più facile semplificare tutto il ragionamento: assumere che l’avanzamento del lavoro in base alle cose fatte è una cosa mentre l’andamento dei costi è un’altra. Potremmo quindi adottare una modalità di gestione dell’avanzamento del progetto considerando entrambi gli indicatori.
Questa visione “binoculare” ci consente di avere una panoramica più completa e bilanciata del progetto. Da un lato, teniamo sotto controllo il progresso in termini di risultati tangibili e reali, come il completamento delle storie utente o dei deliverable previsti dal backlog. Dall’altro lato, monitoriamo anche l’aspetto finanziario, che può fornirci informazioni preziose su come il progetto sta utilizzando le risorse rispetto a quanto pianificato.
L’utilizzo di entrambe queste prospettive ci permette di vedere sia le “cose fatte” dal punto di vista del valore generato, sia i “costi sostenuti”, dal punto di vista della gestione finanziaria, consentendo una gestione più agile e consapevole del progetto. In questo modo, possiamo intervenire con maggiore tempestività e precisione sia quando ci sono problemi di avanzamento, sia quando emergono problematiche di budget.
Conclusione
Nella gestione di progetti con metodologie Agile anche la EVA può trovare un posto, a patto che si sappiano riconoscere bene la prospettiva del PM tradizionale, incentrata più sul rispetto dei costi, e quella del PO, maggiormente focalizzata sulla considerazione del valore che si rilascia all’utente nei tempi previsti.
Questa visione integrata, o “binoculare”, può essere particolarmente utile per tenere a bordo tutti gli stakeholder, indipendentemente dal loro focus principale (valore prodotto o costi sostenuti), e per facilitare il dialogo tra chi si concentra sui risultati di business e chi invece è più attento agli aspetti economici del progetto.
Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.