Marco MerlinoIn molte organizzazioni Agile, l’attenzione si concentra sulla capacità dei team di consegnare più velocemente, riducendo i tempi di sviluppo e aumentando la frequenza dei rilasci.
Tuttavia, essere più rapidi nella delivery non garantisce automaticamente di costruire il prodotto giusto.
Il rischio è quello di rendere estremamente efficiente un processo che produce funzionalità poco utili, poco adottate o non realmente allineate ai bisogni degli utenti.
Il modelloDual-Track Agilenasce per affrontare questo problema, separando ma integrando due flussi fondamentali:discoveryedelivery.
L’articolo approfondisce il significato del Dual-Track Agile, il ruolo della discovery, il rapporto con il Product Management e le condizioni organizzative necessarie per applicarlo.
Attraverso il caso concreto di MedSupply, viene mostrato come un’azienda possa evitare di costruire una piattaforma ampia ma poco efficace, concentrandosi invece su funzionalità realmente validate.
Il risultato è un approccio più maturo alla trasformazione digitale, in cui il backlog non è una semplice lista di richieste, ma un sistema dinamico di ipotesi, evidenze e apprendimento.
Perché il vero obiettivo non è soltanto consegnare prima, maimparare prima cosa merita davvero di essere costruito.
Quando consegnare velocemente non basta più
Per molti anni, una parte significativa della trasformazione Agile nelle organizzazioni si è concentrata su un obiettivo apparentemente semplice:aumentare la velocità di esecuzione.
Ridurre i tempi di rilascio, accorciare i cicli di sviluppo, migliorare la capacità dei team di consegnare valore in modo incrementale e continuo. In questo senso, l’Agile ha rappresentato una risposta potente a un modo di gestire i progetti troppo rigido, troppo sequenziale, troppo distante dalla realtà mutevole dei mercati e dei clienti.
Eppure, con il passare del tempo, molte aziende hanno scoperto un paradosso difficile da ignorare.
I team sono diventati più veloci.
Gli sprint sono stati rispettati.
Le roadmap sono state aggiornate con maggiore frequenza.
Le release sono diventate più continue.
Ma non sempre il prodotto è migliorato davvero.
In alcuni casi, l’organizzazione ha semplicemente imparato acostruire più velocemente funzionalità che non servivano abbastanza. Ha ridotto il tempo necessario per consegnare, ma non il rischio di consegnare qualcosa di poco utile, poco usato o poco rilevante per il cliente.
È qui che emerge una delle domande più importanti per chi si occupa di Agile, Product Management e Innovation Management:
stiamo costruendo bene il prodotto o stiamo costruendo il prodotto giusto?
La differenza è sostanziale.
Costruire bene significa avere qualità tecnica, efficienza operativa, sostenibilità del codice, capacità di rilascio e controllo del debito tecnico. Costruire il prodotto giusto, invece, significa avere compreso davvero un bisogno, validato un’ipotesi, ridotto l’incertezza, verificato che ciò che vogliamo realizzare generi effettivamente valore.
Il modelloDual-Track Agilenasce proprio per affrontare questa distinzione. Non sostituisce l’Agile, non nega l’importanza della delivery, non introduce una nuova moda metodologica. Piuttosto, porta alla luce una tensione che in molte organizzazioni resta implicita:prima di accelerare l’esecuzione, bisogna ridurre il rischio di eseguire nella direzione sbagliata.
Il limite nascosto dell’Agile applicato solo alla delivery
In molte aziende, l’adozione dell’Agile avviene partendo dai team di sviluppo. Si introducono Scrum, Kanban, sprint planning, daily meeting, retrospettive, backlog refinement e review. Il lavoro viene scomposto in user story, il backlog viene prioritizzato, le attività vengono pianificate in cicli brevi.
Questo approccio produce spesso miglioramenti immediati. Il lavoro diventa più visibile, le priorità vengono discusse con maggiore frequenza, il team impara a rilasciare in modo più incrementale. Tuttavia, se l’organizzazione non cambia anche il modo in cui decidecosacostruire, il rischio è quello di rendere più efficiente solo una parte del sistema.
Il team di delivery riceve un backlog già definito, popolato da richieste, funzionalità, desiderata degli stakeholder, ipotesi di business e vincoli organizzativi. Il suo compito diventa realizzare nel modo migliore ciò che è stato deciso a monte. Ma se quelle decisioni non sono state validate, se le esigenze non sono state realmente comprese, se le priorità non derivano da evidenze ma da opinioni, l’Agile rischia di diventare un motore molto performante collegato a una direzione strategica incerta.
In questo scenario, il problema non è la capacità del team di consegnare.
Il problema è la qualità delle ipotesi che alimentano il lavoro del team.
Un backlog non validato è una forma ordinata di incertezza.
Può essere ben scritto, ben gestito, ben prioritizzato. Può contenere user story formalmente corrette e acceptance criteria dettagliati. Ma se non nasce da un processo serio di comprensione del problema, resta comunque un contenitore di assunzioni.
Ed è proprio qui che Dual-Track Agile introduce il proprio contributo più rilevante: distinguere e far convivere due flussi di lavoro diversi, ma profondamente interdipendenti.
Discovery e delivery: due nature diverse dello stesso processo
Dual-Track Agile si basa su una separazione concettuale tra due binari di lavoro:discoveryedelivery.
Ladiscoveryriguarda l’esplorazione. Serve a comprendere problemi, bisogni, comportamenti, vincoli, opportunità e rischi. È il luogo in cui il team formula ipotesi, le confronta con la realtà, raccoglie evidenze, esplora alternative e cerca di ridurre l’incertezza prima di investire nello sviluppo.
Ladelivery, invece, riguarda la costruzione. Serve a trasformare ciò che è stato validato in prodotto funzionante, rilasciabile, mantenibile e utilizzabile. È il luogo dell’esecuzione tecnica, della qualità, della continuità operativa, della capacità di consegnare valore in modo sostenibile.
Il punto chiave è che discovery e delivery non rappresentano due fasi rigide e sequenziali, come accadrebbe in un modello waterfall mascherato. Non si tratta di “fare prima tutta la discovery” e poi “passare alla delivery”. Il valore del modello sta proprio nella loro compresenza.
Discovery e delivery devono procedere in parallelo, con ritmi diversi ma connessi.
La discovery alimenta la delivery con elementi sufficientemente compresi e validati. La delivery, a sua volta, genera dati, comportamenti reali, feedback e apprendimenti che ritornano nella discovery. In questo modo il prodotto non viene trattato come il risultato finale di un piano, ma come un sistema che evolve attraverso cicli continui di apprendimento e realizzazione.
Questa distinzione è fondamentale perché consente all’organizzazione di evitare due errori opposti.
Il primo errore è costruire troppo presto, investendo in funzionalità non validate.
Il secondo errore è analizzare troppo a lungo, senza mai trasformare l’apprendimento in valore concreto.
Dual-Track Agile cerca di bilanciare queste due tensioni. Non rallenta la delivery per fare più analisi. Non banalizza la discovery trasformandola in una raccolta informale di idee. Progetta invece un sistema in cuil’apprendimento guida l’esecuzionee l’esecuzione alimenta nuovo apprendimento.
Il vero obiettivo: ridurre il rischio di prodotto
Ogni iniziativa digitale contiene diversi tipi di rischio.
Esiste un rischio tecnico: siamo in grado di costruire questa soluzione con le tecnologie, le competenze e le architetture disponibili?
Ne esiste uno operativo: siamo in grado di gestirla, mantenerla, integrarla nei processi esistenti?
Ed uno economico: il valore generato giustifica l’investimento richiesto?
Ma soprattutto esiste un rischio spesso sottovalutato:il rischio di prodotto.
Il rischio di prodotto riguarda la possibilità che ciò che costruiamo non risponda realmente a un bisogno significativo. È il rischio di sviluppare una funzionalità che il cliente non usa, un servizio che non modifica i comportamenti, una piattaforma che risponde più alla percezione interna del problema che alla realtà esterna.
In molte organizzazioni questo rischio viene affrontato troppo tardi, quando ormai il budget è stato consumato, il team ha lavorato per mesi e la soluzione è già stata rilasciata. Solo allora si scopre che l’adozione è bassa, che gli utenti continuano a usare strumenti alternativi, che il processo non è migliorato quanto previsto o che il mercato non reagisce come ci si aspettava.
Dual-Track Agile sposta questo apprendimento a monte.
Non elimina l’incertezza, perché nessun modello può farlo. Ma consente diridurre progressivamente l’incertezza prima che diventi costo strutturale.
Questa è una differenza cruciale.
Un errore scoperto durante la discovery è un apprendimento.
Un errore scoperto dopo mesi di sviluppo è un investimento perso.
La discovery non è brainstorming
Uno degli equivoci più frequenti riguarda la natura della discovery. In alcune aziende viene interpretata come una fase creativa, quasi informale, fatta di workshop, idee, lavagne, post-it e discussioni aperte. Questi strumenti possono certamente essere utili, ma non esauriscono il senso della discovery.
La discovery non è semplicemente generazione di idee.
Èvalidazione disciplinata delle ipotesi.
Significa partire da una domanda chiara: quale problema stiamo cercando di risolvere? Per chi? In quale contesto? Con quale impatto atteso? Quali evidenze ci fanno pensare che il problema sia reale? Quali comportamenti osservabili confermerebbero che la soluzione produce valore?
In questo senso, la discovery richiede rigore. Non il rigore burocratico della documentazione eccessiva, ma il rigore dell’apprendimento strutturato. Interviste agli utenti, osservazione dei comportamenti, analisi dei dati, prototipi, test di usabilità, esperimenti controllati, metriche di adozione e validazione delle ipotesi diventano strumenti per trasformare l’incertezza in conoscenza utilizzabile.
Il risultato della discovery non è un documento perfetto.
È una decisione migliore.
E questa decisione può assumere forme diverse. A volte conferma che vale la pena procedere, altre suggerisce di modificare l’idea iniziale. A volte porta a scartare una funzionalità prima ancora di svilupparla. Quest’ultimo caso, nelle organizzazioni mature, non dovrebbe essere percepito come un fallimento, ma come uno dei risultati più preziosi del processo.
La discovery crea valore anche quando impedisce di costruire qualcosa.
La delivery non è semplice esecuzione
Allo stesso modo, sarebbe sbagliato interpretare la delivery come una fase puramente esecutiva. La delivery non è la catena di montaggio del prodotto digitale. Non è il luogo in cui il team tecnico “realizza quanto deciso da altri”.
In un modello Dual-Track maturo, la delivery mantiene una forte componente di apprendimento. Ogni rilascio produce feedback, dati, osservazioni e nuove domande. La qualità tecnica non è separata dalla qualità del prodotto, perché una soluzione difficile da mantenere, fragile o poco scalabile limita la capacità futura dell’organizzazione di apprendere e adattarsi.
La delivery ha quindi una responsabilità doppia: costruire valore oggi e preservare la capacità di costruirlo domani.
Per questo motivo, Dual-Track Agile funziona solo se il team di prodotto non è diviso rigidamente tra chi pensa e chi esegue. Product manager, designer, sviluppatori, stakeholder di business e utenti devono contribuire in modo diverso, ma integrato, sia alla comprensione del problema sia alla costruzione della soluzione.
La separazione tra discovery e delivery non deve diventare una separazione tra persone.
È una distinzione di attività, non una frattura organizzativa.
Il ruolo del Product Owner e del Product Manager
Dual-Track Agile mette in evidenza anche una questione spesso delicata: il ruolo di chi guida il prodotto.
In molte implementazioni Scrum, il Product Owner viene sovraccaricato di responsabilità. Deve raccogliere bisogni, gestire stakeholder, prioritizzare il backlog, chiarire requisiti, prendere decisioni, validare output, rappresentare l’utente e dialogare con il team tecnico. Quando questa figura opera senza un vero processo di discovery, rischia di diventare il punto di accumulo di tutte le pressioni organizzative.
Il backlog finisce così per riflettere non tanto una strategia di prodotto, quanto la capacità del Product Owner di mediare tra richieste concorrenti.
Dual-Track Agile aiuta a rendere esplicito che la gestione del prodotto non può essere ridotta alla scrittura e alla priorizzazione delle user story. Richiede un lavoro continuo di comprensione, validazione e scelta.
Il Product Owner, o Product Manager nei contesti in cui questa distinzione è presente, diventa allora una figura di connessione tra strategia, utente, mercato e delivery. Non è semplicemente il proprietario del backlog. È il custode della coerenza tra problema, soluzione e valore atteso.
Questa evoluzione è particolarmente importante nelle organizzazioni che vogliono passare da una logica di progetto a una logica di prodotto. Nel progetto il successo è spesso misurato dalla consegna rispetto a tempi, costi e ambito. Nel prodotto, invece, il successo dipende dalla capacità di generare valore nel tempo.
Dual-Track Agile accompagna proprio questo passaggio: dalla consegna dell’output alla validazione dell’outcome.
Il caso concreto: la piattaforma digitale di MedSupply
Per comprendere meglio l’applicazione del modello, immaginiamo il caso di un’azienda ipotetica, ma realistica, che chiameremoMedSupply.
MedSupply opera nella distribuzione di dispositivi medicali per strutture sanitarie, cliniche private e reti ambulatoriali. Negli ultimi anni l’azienda è cresciuta rapidamente, aumentando il numero di clienti, fornitori e linee di prodotto. Questa crescita ha reso più complessa la gestione degli ordini, delle disponibilità, delle consegne e delle richieste di assistenza.
Il management decide quindi di sviluppare una nuova piattaforma digitale B2B per consentire ai clienti di consultare il catalogo, verificare disponibilità, effettuare ordini, monitorare spedizioni e aprire richieste di supporto.
Il progetto nasce con obiettivi ambiziosi: ridurre il carico sul customer service, migliorare l’esperienza cliente, aumentare la frequenza degli ordini digitali e rendere più efficiente la gestione operativa.
In una logica tradizionale, l’azienda avrebbe probabilmente raccolto i requisiti interni, definito un perimetro funzionale, costruito una roadmap e avviato lo sviluppo. Il backlog iniziale avrebbe incluso un catalogo prodotti completo, un sistema di login, un carrello, la gestione degli ordini, il tracking delle spedizioni, un’area documentale, le notifiche, i ticket di assistenza e un cruscotto di reportistica.
Tutto apparentemente sensato.
Ma il rischio sarebbe stato elevato: costruire una piattaforma molto ampia prima di aver compreso quali funzionalità avrebbero realmente modificato il comportamento dei clienti.
La discovery: scoprire che il problema non era quello immaginato
MedSupply decide di adottare un approccio Dual-Track Agile. Prima di alimentare la delivery con un backlog esteso, avvia un percorso di discovery parallelo.
Il team di prodotto coinvolge clienti appartenenti a segmenti diversi: grandi cliniche, piccoli ambulatori, centri diagnostici, buyer amministrativi e responsabili operativi. L’obiettivo non è chiedere semplicemente quali funzionalità desiderano, ma osservare come oggi gestiscono realmente gli ordini e quali attriti incontrano.
Dalle prime interviste emerge un dato interessante. I clienti non percepiscono come problema principale la mancanza di un catalogo digitale. Molti di loro ricevono già listini, schede prodotto e informazioni commerciali. Il vero problema è un altro:l’incertezza sulla disponibilità effettiva dei prodotti e sui tempi di consegna.
Per le strutture sanitarie, non sapere se un dispositivo sarà disponibile nei tempi necessari genera telefonate, solleciti, ordini duplicati, richieste urgenti e una continua pressione sul customer service. La piattaforma immaginata inizialmente come “portale ordini” inizia quindi a essere ripensata come strumento di trasparenza operativa.
La discovery evidenzia anche un secondo elemento. I clienti non vogliono necessariamente aprire ticket in autonomia. Preferiscono farlo solo se il sistema è in grado di dare risposte rapide e contestualizzate. Un semplice modulo di richiesta assistenza, quindi, non ridurrebbe il lavoro del customer service. Potrebbe addirittura aumentarlo, generando richieste incomplete o mal classificate.
Questi insight modificano la direzione del prodotto.
Non vengono eliminati gli obiettivi iniziali, ma cambia la priorità. Il primo incremento non sarà una piattaforma completa, ma un’esperienza focalizzata su disponibilità, tempi di consegna e riordino rapido dei prodotti abituali.
La delivery: costruire meno, ma costruire meglio
Mentre la discovery continua ad approfondire bisogni e comportamenti, il team di delivery avvia lo sviluppo di un primo Minimum Viable Product.
Il perimetro viene ridotto in modo significativo. Non si costruisce subito tutto il catalogo avanzato, non si implementa immediatamente l’intero sistema di ticketing, non si sviluppano funzionalità di reportistica complesse. Si concentra invece l’investimento su un flusso essenziale: accesso cliente, lista dei prodotti acquistati abitualmente, disponibilità stimata, tempi di consegna previsti e possibilità di riordino.
Questa scelta non è una riduzione di ambizione. È una scelta di apprendimento.
Il team vuole verificare se, fornendo maggiore trasparenza sui prodotti più frequentemente ordinati, i clienti riducono le telefonate al customer service e aumentano l’utilizzo del canale digitale.
Dopo il primo rilascio controllato su un gruppo limitato di clienti, emergono dati utili. L’adozione è buona nei clienti con ordini ricorrenti, meno significativa nei clienti occasionali. Le chiamate al customer service diminuiscono per le richieste di disponibilità, ma aumentano temporaneamente per chiarimenti legati alle differenze tra disponibilità stimata e disponibilità garantita.
Questo feedback genera un nuovo ciclo di discovery. Il team comprende che non basta mostrare un dato: bisogna spiegare il livello di affidabilità dell’informazione. La delivery introduce quindi una distinzione più chiara tra disponibilità immediata, disponibilità prevista e prodotti soggetti a conferma.
Il prodotto evolve non perché qualcuno ha cambiato idea, ma perché il sistema ha iniziato ad apprendere.
Il cambiamento organizzativo prodotto dal Dual-Track
Nel caso di MedSupply, il valore del Dual-Track Agile non riguarda solo la piattaforma digitale. Riguarda il modo in cui l’organizzazione impara a decidere.
Prima dell’introduzione del modello, le priorità erano determinate prevalentemente da stakeholder interni: direzione commerciale, operations, customer service, IT. Ognuno portava bisogni legittimi, ma spesso filtrati dalla propria prospettiva funzionale.
Con Dual-Track Agile, la conversazione cambia. Le priorità non vengono più discusse solo sulla base dell’importanza percepita, ma sulla base del rischio, delle evidenze e dell’apprendimento necessario.
La domanda non è più soltanto: “quanto vale questa funzionalità?”
Diventa anche:“quanto siamo sicuri che questa funzionalità risolva davvero il problema?”
Questo passaggio modifica profondamente la governance del prodotto. Il backlog smette di essere una lista di richieste e diventa un sistema dinamico di ipotesi, decisioni e apprendimenti. Alcuni elementi entrano in delivery perché sufficientemente validati. Altri restano in discovery perché richiedono ulteriori verifiche. Altri ancora vengono eliminati, perché non giustificano l’investimento.
Per l’organizzazione è un cambiamento culturale importante. Significa accettare che non tutte le idee debbano essere realizzate, anche quando provengono da stakeholder autorevoli. Significa riconoscere che l’incertezza non si governa con la pianificazione dettagliata, ma con l’apprendimento continuo.
Le condizioni per applicarlo davvero
Dual-Track Agile non funziona se viene ridotto a una semplice divisione del backlog in due colonne: cose da scoprire e cose da sviluppare. Per essere efficace richiede alcune condizioni organizzative precise.
La prima è la disponibilità a coinvolgere utenti, clienti o utilizzatori reali con continuità. Senza contatto con la realtà, la discovery si trasforma rapidamente in discussione interna. E una discussione interna, per quanto intelligente, non è una validazione.
La seconda è la presenza di un team realmente cross-funzionale. Designer, product owner, sviluppatori e figure di business devono poter contribuire alla comprensione del problema. Se la discovery viene delegata solo a una funzione e la delivery solo a un’altra, il modello perde forza e rischia di ricreare una separazione waterfall.
La terza condizione è la capacità del management di tollerare l’incertezza. In un approccio Dual-Track, non tutto può essere deciso all’inizio. Alcune scelte emergono lungo il percorso. Questo non significa procedere senza controllo, ma accettare una governance basata su evidenze progressive anziché su false certezze iniziali.
La quarta condizione riguarda le metriche. Se l’organizzazione continua a misurare solo output, numero di funzionalità rilasciate, rispetto delle date e saturazione del team, tenderà inevitabilmente a spingere sulla delivery. Per sostenere davvero il Dual-Track, deve iniziare a misurare anche outcome, adozione, apprendimento, riduzione del rischio e impatto sul comportamento degli utenti.
Non si può governare un prodotto adattivo con metriche pensate per un progetto statico.
I principali errori da evitare
Uno degli errori più comuni è trasformare la discovery in una fase lunga e separata, che precede la delivery. Quando accade, il Dual-Track perde la propria natura e diventa semplicemente un waterfall con una fase iniziale più moderna.
Un secondo errore è trattare la discovery come responsabilità esclusiva del Product Owner o del designer. In realtà, anche gli sviluppatori devono partecipare almeno in parte alla comprensione del problema. La loro presenza consente di valutare vincoli tecnici, opportunità architetturali e alternative realizzative fin dalle prime fasi.
Un terzo errore è considerare la delivery come una macchina da alimentare continuamente. In molte organizzazioni esiste la paura del “team fermo”, per cui ogni sprint deve essere riempito di sviluppo. Questa pressione porta spesso a inserire in delivery elementi non sufficientemente compresi, solo per mantenere alta l’occupazione del team.
Ma un team sempre occupato non è necessariamente un team che genera valore.
L’efficienza locale della delivery può diventare inefficienza sistemica se produce funzionalità sbagliate.
Perché Dual-Track Agile è anche uno strumento di innovation management
Sebbene venga spesso collocato nell’ambito Agile e Product Management, Dual-Track Agile è anche uno strumento potente di Innovation Management.
L’innovazione, infatti, non consiste soltanto nel generare nuove idee. Consiste nel trasformare l’incertezza in valore. E questo richiede un equilibrio delicato tra esplorazione e realizzazione.
La discovery rappresenta lo spazio dell’esplorazione: permette di capire dove esistono opportunità, quali problemi meritano attenzione, quali soluzioni hanno potenziale. La delivery rappresenta lo spazio della concretizzazione: trasforma ciò che è stato appreso in prodotto, servizio, processo o esperienza utilizzabile.
Senza discovery, l’innovazione diventa produzione di funzionalità.
Senza delivery, l’innovazione resta conversazione.
Dual-Track Agile collega questi due mondi, rendendo l’innovazione meno episodica e più sistemica. Non affida la capacità innovativa solo a workshop, laboratori o iniziative straordinarie, ma la integra nel modo ordinario con cui il prodotto evolve.
In questo senso, il modello è particolarmente utile per le aziende mature che vogliono innovare senza perdere controllo, ma anche senza soffocare l’apprendimento sotto il peso della pianificazione.
Non basta andare veloci se la direzione è sbagliata
Dual-Track Agile introduce una lezione tanto semplice quanto difficile da applicare:la velocità non è valore se non è orientata dalla comprensione.
In molte organizzazioni, l’Agile ha migliorato la capacità di consegnare. Ha reso i team più reattivi, i cicli più brevi, il lavoro più trasparente. Ma la vera maturità non si misura solo nella rapidità con cui si rilascia una funzionalità. Si misura nella capacità di capire se quella funzionalità merita davvero di essere costruita.
Separare discovery e delivery non significa creare distanza. Significa riconoscere che esplorare e costruire sono due attività diverse, entrambe necessarie, entrambe strategiche, entrambe da integrare in un sistema coerente.
Il caso di MedSupply mostra come questo approccio possa modificare radicalmente il modo in cui un’organizzazione prende decisioni di prodotto. Non più backlog come accumulo di richieste, ma backlog come risultato di apprendimento. Sviluppo non più come risposta automatica alle idee interne, ma delivery come trasformazione disciplinata di ipotesi validate. Non più innovazione come intuizione isolata, ma come processo continuo di scoperta, verifica e realizzazione.
In ultima analisi, Dual-Track Agile aiuta le organizzazioni a superare uno dei rischi più costosi della trasformazione digitale:costruire con grande efficienza qualcosa che non produce abbastanza valore.
Perché il punto non è solo consegnare prima.
È imparare prima.
E costruire, solo dopo, ciò che merita davvero di essere costruito.
