Come rispondere alla domanda “Ma quanto mi costi?” e far felice Finance

Come possiamo collegare la roadmap di prodotto con il piano dei costi e far felice Finance?

Le pratiche agili, tramite un approccio iterativo e incrementale e grazie ai feedback frequenti, puntano a rilasciare valore all’utente finale, eliminando tutte quelle attività non funzionali per questo scopo. Questo ha comportato spesso una netta ridiscussione delle procedure classiche presenti all’interno delle aziende, ridiscussione che in taluni casi ha finito per etichettare come “anti agile” (e quindi sbagliato) processi comunque necessari per far funzionare i meccanismi di base.

Nell’articolo raccontiamo la nostra esperienza a supporto in una azienda del settore difesa che produce prodotti complessi (software-hardware-firmware-servizi logistici) dove i team di sviluppo devono interfacciarsi con “il resto dell’azienda” per la produzione di artefatti come le pianificazioni delle allocazioni e dei costi, l’impatto sul budget, le previsioni sull’ingaggio delle persone, piani di rilascio e altra “contabilità”.

[Questo articolo è estratto dal talk di Giovanni Puliti tenuto agli Italian Agile Days 2024. Su Vimeo è disponibile il video della presentazione]

Agile Project o Product Management?

Noi di Agile Reloaded definiamo l’Agile Project Management come “la gestione di un progetto sviluppato utilizzando strumenti di lavoro che si ispirano all’agilità.”
Qualcuno potrebbe dire che sia una definizione fuorviante: le metodologie agili pongono il focus non sulla gestione di progetto, ma sul rilascio del valore tramite la creazione di un prodotto utile per l’utente finale. A quest’ultimo non interessa il progetto ma il prodotto rilasciato. Per questo, la definizione così come l’abbiamo fornita potrebbe essere contestata preferendo “Agile Product Management”.

A prescindere da come vogliamo denominare l’attività, la certezza è che ci sarà sempre qualcuno nell’azienda che chiederà: “Ma quanto costa questa cosa?”, “Quanto costa il progetto e quando lo consegnerete?”, e infine “Quando verrà fornito il piano di dettaglio?”. Nella cultura agile spesso queste domande vengono interpretate come espressione di un vecchio modo di intendere la gestione dei progetti.
Seguendo queste derive integraliste e spesso un po’ naive, è veramente facile cadere nella trappola di rifiutare questa visione del progetto…. In fondo “noi lavoriamo in Agile, puntiamo al valore, non facciamo micromanagement!”.
La sfida è proprio quella di rispondere a queste lecite richieste senza cadere nella trappola di vedere le due prospettive (quella del controllo e quella dello sviluppo) antitetiche invece che parte del medesimo obiettivo: capire come rilasciare la quantità massima di valore per utente finale.

L’azienda è un sistema complesso

Facciamo una premessa iniziale e con un paio di citazioni che ci aiutano a fissare due concetti chiave per comprendere le organizzazioni, citazioni che sarebbe bene sempre non dimenticare quando si dialoga con il cliente.

1. Un’azienda è un sistema complesso e come tale non ci possiamo aspettare di cambiarla velocemente.

2. E cosa vuol dire “azienda agile”?

“[…] un’organizzazione agile rischia di non voler dire nulla: non esistono organizzazioni agili, perché un’organizzazione è una cosa complessa. Noi crediamo invece che esistano organizzazioni che per fare il loro business provano a implementare processi, strumenti e modalità che si ispirano ai Principi Agili.”
cit. Marco Calzolari, Agile Reloaded

Il racconto del caso specifico

Il caso in esame è quello che ci ha visti coinvolti in una azienda nel settore della difesa con una organizzazione complessa. Uno dei progetti che abbiamo seguito è stato sviluppato da cinque team che hanno collaborato fra loro per realizzare il prodotto finale.
Anche se il focus di questo articolo non si concentra su come è stato sviluppato il prodotto e sulle metodologie adottate, può aver senso fare una rapida panoramica su questi aspetti.
I team hanno lavorato svolgendo attività diverse: software, firmware, hardware e un team dedito alla produzione e verifica delle specifiche di qualità. La metodologia adottata dai gruppi di lavoro è in larga parte ispirata a Scrum+Kanban, e il modello di coordinamento (il framework di scaling) ha preso spunto dai principi di Nexus.

I ruoli

I ruoli che compongono i team sono:

• Chief Product Owner
• Product Owner
• Developers (da chi scrive codice a chi lavora al CAD o scrive specifiche di sicurezza)
• Persone esterne al team

Il Chief Product Owner (CPO) ha curato il Backlog ad alto livello i cui item sono poi presi in carico dai diversi gruppi di lavoro tramite il coinvolgimento dei Product Owner dei team sottostanti. Il CPO è stato poi responsabile della roadmap complessiva del prodotto e si impegna con gli stakeholder nella definizione di un release plan.
Ogni team era composto da un gruppo base, rimasto stabile per la maggior parte del tempo, e da alcuni collaboratori “esterni” che hanno contribuito per alcune parti.
Per lo sviluppo un prodotto così complicato le competenze richieste sono moltissime; questo rende veramente difficile creare team crossfunzionali stabili che sappiano fare tutto quello che serve. A volte si sono rese necessarie fino a 20-30 persone (fra softwaristi, progettisti HW ed esperti di telecomunicazioni radar) per la realizzazione di un singolo elemento del Backlog. Il ricorso a un elevato numero di SME si è reso necessario proprio per smarcare in tempi rapidi alcuni problemi di non facile soluzione.

“Ma quanto mi costi?” – “Ma quando consegnate questo materiale?”

Oltre a questo, altri stakeholder, abituati a lavorare in modo tradizionale (non secondo i principi dell’Agile), si sono interfacciati con i PO e il team di lavoro, per avere informazioni sulle tempistiche e sugli indicatori economici di progetto. Fra questi certamente le figure più impattanti sono stati:

• Responsabile degli affari economici: si è consultato con il PO per aggiornare le necessità e il flusso del denaro e della cassa allocata (budget)
• Direttori di linea delle telecomunicazioni, hardware e software: tutta l’azienda è organizzata secondo un modello matriciale in cui i team possono essere visti come le strutture orizzontali cross-dipartimento e i dipartimenti come le linee verticali. Ogni persona fa quindi riferimento a un dipartimento/ufficio e la partecipazione al team deve essere concordata (prenotata) con il responsabile di dipartimento. Questo, se vale meno per il core team (le persone stabilmente assegnate al team) diventa necessario per coloro che partecipano in modo sporadico ai gruppi, pena la non disponibilità al momento del bisogno.

Cosa è richiesto al team di progetto?

Al team viene richiesto:

• Piano di lavoro
• Il coordinamento del lavoro fra i 5 team
• Tempistiche di rilascio
• Pianificazione economica
• Pianificazione allocazione delle risorse (fisiche e delle persone)

Queste richieste al team hanno creato un groviglio di richieste. Per sbrogliare questa situazione abbiamo provato a stabilire un ordine logico per trovare il punto di inizio:

1. Avanzamento lavoro
2. Previsione temporale
3. Piano previsionale economico
4. Progressivo di spesa

Vediamoli uno ad uno.

1. Avanzamento lavoro

In agile, si monitora l’avanzamento del lavoro tramite un burndown chart per ciascun team; si visualizzano quante cose si sono fatte e come ci si sta avvicinando all’obiettivo.

La domanda che arriva dell’esterno invece spesso è “Ma complessivamente come sta andando il progetto? possiamo confrontare i punti fatti dai team? possiamo confrontare soldi spesi con l’avanzamento del progetto?”
Nei progetti tradizionali si fa riferimento ai costi sostenuti per monitorare la percentuale di avanzamento del lavoro. Per non introdurre strumenti di verifica totalmente differenti, abbiamo deciso, almeno in prima battuta, di adottare le stesse metriche di lavoro. E siamo finiti quindi a cercare di collegare il burndown con l’Earned Value (EV).
L’Earned Value è l’indicatore del mondo del PMI che si basa sull’assoluzione che sia possibile monitorare l’avanzamento del progetto sulla base dei soldi che si stanno spendendo. Indica il valore (in realtà il costo) del lavoro effettivamente completato a una certa data; rappresenta in un certo senso il progresso del progetto in termini di valore prodotto.
Detto in modo forse più chiaro, rappresenta il costo che si era presunto di pagare, per realizzare gli outcome a una determinata percentuale di avanzamento di progetto.
La formula per calcolare l’EV è la seguente:

EV= (Lavoro completato/tutto il lavoro da completare) x BAC (Budget at complection)

All’Earned Value seguono altri due valori:

• Planned Value (PV), il valore pianificato, quanto ti aspetti di spendere. Rappresenta il valore del lavoro pianificato fino a una certa data. E’ l’importo totale che si prevedeva di spendere per il lavoro programmato entro quel momento.
• Actual Cost (AC), il costo effettivo. E’ il costo effettivamente sostenuto per il lavoro completato fino a quel momento e misura le spese effettive.

NOTA: EV nasce nel PM tradizionale, dove la % di soldi spesi per costruire un muro, in qualche modo può darci un’idea dell’avanzamento del progetto. Nel mondo delle metodologie agili questa visione non ci convince del tutto, dato che ad ogni step di progetto ci si chiede sempre quale sia il valore prodotto.
Ma quindi usare i costi come metrica di avanzamento è sbagliato? possibile che in anni e anni di micromanagement fosse tutto sbagliato?
Abbiamo approfondito l’argomento con le persone, per capire come ragionano.
Immaginiamo che AC>EV: secondo la teoria di EV, allora il progetto funziona come previsto o meglio. Questo dato lo trovavamo anche nel burndown chart.
Se invece EV<AC allora il progetto non sta andando come previsto ed è in ritardo. E anche questo ce lo mostrava anche il burndown. 

Quindi è sbagliato usare la spesa come indicatore del progressivo? Alla fine strumenti diversi ci dicono la stessa cosa. O forse no. C’è un pezzo che manca nell’Earned Value guardandolo con un occhio Agile. L’Earned Value funziona solo se i costi sono lineari e se il denominatore non cambia, ma non sempre è così dato che il backlog è mutevole.

A seguito di queste riflessioni siamo giunti alla conclusione che l’Earned Value va bene a patto che sia una percentuale calcolata con la seguente formula:

EV=Lavoro completato/Tutto il lavoro da completare

Che può anche essere scritta come:

EV=Story points realizzati/Totale story points del backog

Avendo questo nuovo dato, è interessante notare come a volte ci sia capitato di fare dei passi indietro. La percentuale che rappresenta un % di lavoro svolto per realizzare gli outcome fluttua in base alle aggiunte di item al Backlog.

2. Previsione temporale

Con “previsione temporale” si intende il tempo necessario per completare le cose restano da fare. Il l Chief Product Owner crea quindi la roadmap e insieme ai PO dei team cercano di valutare il tempo necessario per completare gli step. Coordinare 5 stream non è immediato, non automatico creare la roadmap. Come insegna il Manifesto per lo Sviluppo Agile di Software, “individui e interazioni più che strumenti”. Un sano, costante, continuo confronto fra i team, magari davanti a una board di progetto è un ottimo modo per gestire questi aspetti.

3. Previsionale economico

Il previsionale economico si può riassumere in “cosa c’è da fare” e “quanto costa farlo”. Nel nostro caso studio la difficoltà non era fare il previsionale economico, ma definire i ruoli di chi fa cosa. Il Product Owner non può anche calcolare il costo delle attività che devono essere fatte, ma è lui che sa cosa sta accadendo, l’Ufficiale Economico non può vedere quello che vede il PO. Per capire come assegnare i ruoli sono stati fatti colloqui one-to-one per mappare le attività da svolgere e le responsabilità per poi trovare gli accordi.
La formula aiuta per raccontare e capire

Previsionale economico=previsione dei costi diretti di lavorazione + costi a supporto

I “costi di supporto” sono l’elenco delle attività, stilato dal Product Owner, e i costi delle attività
Le “previsioni dei costi diretti di lavorazione” sono gli sprint rimanenti * costo 1 sprint. A questo abbiamo preferito una variante: previsioni dei costi diretti di lavorazione=pt rimanenti * costo 1 pt. Psicologicamente la variante ha aiutato perché ha aiutato ad inglobare alcune variabili che prima non si sapeva come calcolare.

4. Progressivo di spesa

Il progressivo di spesa include quanto speso ad oggi, la consuntivazione oraria e la consuntivazione economica. Si fa una consuntivazione, quindi, per esempio, un lavoratore segna che ha lavorato tre ore su un’attività. L’attività veniva inizialmente chiamata “task”, un pezzetto di una storia. Il rischio era quello che pezzetti all’apparenza simili di storie venissero calcolati allo stesso modo quando richiedevano uno impegno differente. Allora abbiamo aumentato la varietà degli “oggetti” della consuntivazione: sono state introdotte storie e epiche e ora stiamo lavorando per introdurre il concetto di stream. Alcune persone lavorano su stream diversi ed è importante evidenziarlo anche nel progressivo di spesa.

Conclusione

Questa esperienza ha messo in luce come in contesti di elevata complessità come quello in esame, un approccio dogmatico nella implementazione dei principi dell’Agile possa essere, non solo inutile, ma controproducente.
Fermo restando l’importanza di lavorare in fede con la filosofia del Manifesto Agile, occorre sempre tenere sotto controllo il contesto esterno allo sviluppo di progetto, alla cultura presente in azienda per trovare i giusti compromessi e la strada più efficace verso una implementazione dell’Agile