Abbiamo visto, con un precedente articolo, che la riduzione del Costo del ritardo (CoD) è la ragione che giustifica e spesa l’adozione di approcci agili nello sviluppo di prodotti fisici, che si accompagnano a maggior costo dei materiali non compensati dalla minore quantità di lavoro svolto.
L’agilità massimizza infatti il lavoro da non svolgere grazie al continuo adattamento.
La maggior velocità di sviluppo spinge le aziende ad alzare lo sguardo dal brevissimo termine perché, team sempre più performanti, vanno alimentati con idee, possibilmente innovative e valide dal punto di vista del business.
La riduzione del costo del ritardo consente alle aziende di giustificare l’adeguamento di mezzi e persone alla sfida di un mondo VUCA.
Ricordo che durante un workshop sulla agilità presso un’azienda che sviluppa prodotti elettronici dotati di software, il brillante responsabile tecnico mi fa una domanda della quale riporto cosa ho percepito: se ci organizziamo in questo modo è necessario che pensare con una prospettiva di medio e lungo termine quali prodotti sviluppare, altrimenti i team non sarebbero alimentati continuamente
Aveva perfettamente compreso una della sfide che comporta una transizione Agile. L’adeguamento di mezzi e di persone spinge fortemente l’azienda a introdurre e gestire un portafoglio di progetti di Esplorazione di idee di prodotto e progetti di Sviluppo di Nuovi Prodotti.
Senza una corretta gestione del portafoglio in termini di valore di business e di priorità, i veloci team agili, potrebbero trovarsi a sviluppare prodotti dallo scarso successo di business, o trovarsi non correttamente alimentati.
Non c’è maggior forma di spreco e di demotivazione avere team performanti che vengono impegnati nello sviluppo di un prodotto poco innovativo e dallo scarso successo commerciale.
L’insuccesso del prodotto è spesso vissuto dal team come un insuccesso del team stesso. In questo caso le responsabilità maggiori andrebbero invece attribuite al Product Owner, che ha il delicatissimo incarico di valutare correttamente il progetto dal punto di vista del business e gestendo le pressioni della direzione e del team.
Occorre quindi sviluppare particolarmente le idee di prodotto con progetti di Esplorazione che ho descritto nel precedente articolo “Il progetto di Esplorazione di Prodotto”
I progetti di esplorazione fanno quindi inseriti in un portafoglio relativo.
Per l’esperienza che ho avuto modo maturare sia con e dirigente d’azienda che come consulente ho trovato conveniente gestire un portafoglio unico contenente sia i progetti di esplorazione che i progetti di sviluppo nuovo prodotto.
Con un unico portafoglio è più facile sincronizzare l’inizio di nuovi progetti di sviluppo con il l’eventuale accelerazione o rallentamento di quelli di esplorazione
Tornerò con un prossimo articolo sulle metriche per prioritizzare i progetti all’interno del portafoglio.
