Lean Agile Product Development

Tutti concordano sul fatto che l’innovazione è vitale per il successo di ogni Azienda, ma perché sia efficace è necessario che il tempo di sviluppo dei progetti sia sincronizzato con il tempo “dettato” dal Business.

Tuttavia ci sono tanti progetti con diversi livelli di complessità. I manager si ritrovano a portare avanti il lavoro con elevato sforzo, lavorando a volte a vista e aggiungendo risorse di volta in volta.

Il primo principio Lean Agile è la “Cadence” o “ritmo dell’Innovazione” raccoglie tutti i principi e le metodologie utili al fine di usare il tempo in modo efficace e, di conseguenza, aumentare il numero dei progetti gestibili a parità di risorse disponibili.

Per controllare la cadenza dei progetti lungo tutto il loro ciclo di vita, a partire dalla raccolta e selezione delle idee, fino alla allocazione delle risorse e alla prioritizzazione dei progetti nel piano prodotti, Considi ha implementato il sistema SWIRL per la gestione del portfolio progetti su piattaforma web.

Lo SWIRL è uno strumento a supporto dei comitati innovazione e si basa sul concetto dei BIN per garantire costantemente l’allineamento tra i progetti fattibili in base alle risorse disponibili e gli obiettivi di Business. 

Poiché nello sviluppo di un nuovo prodotto c'è sempre un divario tra ciò che sappiamo e ciò che dobbiamo imparare per produrre l'output (learning cycle) con I Bins basati sul contenuto e sul rischio, è possible prevedere quanti learning cycle abbiamo bisogno per raggiungere l’output (figura successiva)

A questo punto  il leadership team è in grado di definire  un elenco di potenziali team e un piano di sequenziamento che riflette le priorità chiave dell'azienda.

Durante lo sviluppo Considi incoraggia i progettisti ad utilizzare il mix di metodologie  Lean e Agile che abbiamo riorganizzato nel secondo principio, il “Flow”.

Indipendentemente dallo specifico utilizzo, tutte queste  metodologie presentano molte analogie:

• Tutte producono ‘working software’ o ‘working product’ alla fine di ogni iterazione
• Tutte rilasciano una release di software o prodotto alla fine di ogni iterazione
• Tutte coinvolgono il cliente direttamente o attraverso qualcuno che lo sostituisce (es. Product Manager), sicuramente alla fine di ogni iteration ed a volte anche nel quotidiano
• Tutte favoriscono i cambiamenti alla fine di ogni iteration
• Tutte tendono a pianificare e a gestire i rischi mano a mano che si procede con le iterazioni e quindi con molta attenzione sullo short term, aiutando i team a stare sul concreto
• Tutte enfatizzano il lavoro in piccoli team che si auto organizzano per pianificare le attività e gestire l’avanzamento in modo condiviso e collaborativo con lo Scrum che Considi propone anche in versione digitale, particolarmente utile per team dislocati in diverse sedi o postazioni, utilizzando alcune tra le più diffuse piattaforme digitali.

Progettare ogni funzione separatamente dalle altre e testarle anticipatamente. Questo implica un importante cambiamento nel modo di concepire e sviluppare nuovi prodotti: si converge verso il set finale di soluzioni attraverso una serie di test e punti di integrazione prima che il progetto di dettaglio venga avviato.

E’ questa la metodologia precorsa dai fratelli  Wright che affrontano il problema del volo con un approccio molto diverso da quello di altri sperimentatori dell’epoca. Mentre gli altri spendono migliaia di ore per progettare e costruire un velivolo e pochi secondi per testarlo (prima di precipitare e uccidersi), i fratelli Wright non credono che questo sia un approccio sensato… e cominciano a sperimentare.

In questo modo arrivano a definire la forma ottimale delle ali per il controllo dell’aereo durante il volo e realizzano un propulsore con prestazioni adeguate.

Questo implica un importante cambiamento nel modo di concepire e sviluppare nuovi prodotti: si converge verso il set finale di soluzioni attraverso una serie di test per ogni sottosistema per acquisire la necessaria conoscenza prima di avviare la fase di progettazione (da “design then test” a “test then design”). Questa metodologia venne in seguito ingegnerizzata da Toyota che la applicò sistematicamente allo sviluppo dei suoi prodotti con il nome di Set Based Design.

Ma è grazie ad Allen C Ward che fu compreso il vero spirito del Set Based Design. Fino ad allora, infatti, si credeva erroneamente che applicare il Set Based in Toyota significasse sviluppare una serie di possibili soluzioni per poi scegliere la migliore. Il Set Based si identifica invece in una serie di sottosistemi progettati per i casi estremi volti a capire poi quanto si è lontani dal limite mentre si progetta la soluzione reale.

Si tratta di un approccio che si contrappone alla pratica, ancora oggi diffusa nello sviluppo prodotto, di “testare alle specifiche”: quando si testa alle specifiche, una soluzione può anche risultare funzionante (approccio point based) ma non è noto quanto i parametri testati siano o meno vicino al limite. Questo implica che, se interverranno modifiche ai requisiti di progetto, si sarà costretti a ripetere i test.

I consulenti Considi guidano i team di sperimentazione nel comprendere quali parametri influiscono sulle performance dei diversi sottosistemi (ed in questo senso è utile applicare tecniche statistiche come il DOE per ridurre il numero dei test), quali sono più vicini al limite e supportano i team e i manager nel costruire le “limit curve” per risolvere i problemi tecnici più difficili. Le limit curve vengono poi utilizzate anche nei progetti successivi per ridurre i tempi di sviluppo dei nuovi prodotti, in quanto non sarà necessario ripetere i test coperti dalle curve limite realizzate precedentemente.