In base alla mia esperienza maturata in azienda, penso che l’approccio agile classico, basato sui framework nati nel mondo del software non sia, da solo, in grado di soddisfare le esigenze dello sviluppo di un prodotto fisico o hardware.
Bisogna infatti considerare i seguenti aspetti dei prodotti fisici:
L’approccio agile non dà abbastanza evidenza agli appuntamenti di riesame del progetto, che costituiscono dei veri e propri cancelli o Gate per autorizzare ulteriori investimenti.
E’ infatti necessario, dopo una sequenza di iterazioni che rappresentano la Fase o Relase di Concept di Prodotto (o Analisi di Fattibilità), fare una verifica con gli stakeholder principali.
Una verifica del valore atteso dal progetto, dei tempi necessari, bilanciando costi stimati e ricavi attesi.
L’insieme delle iterazioni che rappresentano la fase successiva di Sviluppo Operativo, produce la costruzione di almeno un prototipo industrializzato e validato e il rilascio della documentazione necessaria per la produzione di serie.Questa fase prevede una fortissima sovrapposizione delle attività di progettazione, costruzione e validazione progettuale.
E una fase caratterizzata da importanti investimenti per la costruzione dei prototipi o dei pretotipi e delle relative attrezzature di costruzione e validazione, che possono superare di molto il costo del team di sviluppo.
Un piano delle Milestone è quindi sempre necessario per identificare appuntamenti importanti di verifica con gli stakeholder.
Allo stesso modo le logiche lean che visualizzano il flusso come le Kanban Board possono essere molto utili in special modo per i materiali. Così pure le scomposizioni lean visuali dei prodotti denominate Barashi, durante le fasi costruttive e di montaggio, sono approcci molto potenti che è opportuno integrare.
Differentemente dai prodotti software, per i prodotti hardware, il costo dell’aggiornamento ripetuto dei prodotti presso i clienti è, nella grande maggioranza dei casi, insostenibile.
Lo è dal punto di vista delle attività produttive di aggiornamento da fare sul prodotto, lo è dal punto di vista della gestione dei materiali. Sia dei materiali necessari per l’aggiornamento del prodotto che dei materiali non più necessari dopo l’aggiornamento stesso.
In questo caso lo sviluppo agile si limita normalmente al processo che va dall’ideazione al rilascio per la produzione di serie.
La manutenzione di un prodotto hardware, come un prodotto industriale, è molto contenuta e avviene normalmente per esigenze produttive o per correggere difetti del prodotto stesso.
Nel corso della mia esperienza di sviluppo di molti prodotti fisici diversi tra loro, trovato molto efficace la seguente combinazione di elementi chiave:
- Impiego di un approccio agile basato principalmente su Scrum in combinazione con lo User Story Mapping (e con altre pratiche agili quando necessario). Per la gestione del backlog il framework più potente è per mia esperienza lo Story Mapping. E’ lo strumento più apprezzato dai team con i quali ho lavorato.
- Integrazione di una mini gestione Waterfall in termini di Milestone e Gate di valutazione del progetto e di approvazione degli investimenti.
- Integrazione di alcune logiche lean ove possibile, specialmente nella fabbrica come Kanban board di reparto e Barashi.
- Predisposizione di una gestione visuale del Portafoglio dei Prodotti in sviluppo, con evidenziazione delle Milestone e dello stato dello sviluppo stesso.
Come chiamare un approccio di questo tipo?
Il termine che secondo me più si avvicina a poterlo definire è Elastico, poiché include il concetto di flessibilità e adattabilità fisica, ma anche quello di elasticità mentale necessaria a integrare questi elementi chiave.
Uno sviluppo Agile ed Elastico è inclusivo di altri approcci pur nel rispetto di una pianificazione adattiva e flessibile perché iterativa e incrementale.
