Come superare la riluttanza interna allo sviluppo prodotto agile

Lo sviluppo agile dei prodotti si trova in una posizione strana. Nel software è visto come una pratica comune, mainstream e, francamente, non ha senso. Nell'hardware, invece, lo sviluppo agile dei prodotti è spesso considerato complicato, impegnativo e forse un espediente. Eppure Agile è già un elemento di differenziazione per la creazione di prodotti fisici.

In una recente indagine di PTC, è stato chiesto agli intervistati di auto-identificarsi come leader o ritardatari per quanto riguarda la loro posizione competitiva. Sebbene questa segmentazione abbia fornito molte differenze, una in particolare è risultata netta. (Tratteremo i risultati completi di questa indagine in un whitepaper di prossima pubblicazione, The Approach to Agile Product Development: What Leaders Do Differently).

I ritardatari hanno molte più probabilità di incontrare una riluttanza interna quando si tratta di sviluppare prodotti Agile. In effetti, la probabilità di incontrare questo ostacolo è quasi doppia rispetto a quella dei leader. Ma perché questo problema e cosa possono fare i ritardatari per convincere la leadership interna ad accettare lo sviluppo di prodotto Agile?

Prima di entrare nel vivo della filosofia, però, poniamo alcune basi: Cosa intendiamo quando parliamo di sviluppo prodotto agile?

In PTC definiamo lo sviluppo prodotto Agile come un'applicazione della metodologia software a un processo di produzione fisica. In un certo senso, costruire un prodotto utilizzando Agile o, per dirla in modo più diretto, fare hardware come si fa software. Lo sviluppo di prodotti Agile segue in genere quattro valori fondamentali:

• Individui e interazioni più che processi e strumenti
• Prodotto funzionante oltre a una documentazione completa
• Collaborazione con il cliente rispetto alla negoziazione del contratto
• Rispondere ai cambiamenti piuttosto che seguire un piano

Questa metodologia è ora dominante nel settore del software, proprio grazie alla sua natura flessibile e alla sua priorità di sprint chiaramente definiti e orientati al valore. Per le organizzazioni è più facile suddividere progetti software complessi in segmenti di lavoro realizzabili e comprensibili e concentrarsi sulla realizzazione di un compito prima di essere distratti da un altro.

Vedetela in questo modo: Sarebbe importante se Microsoft Teams avesse la chat video se prima non potesse integrarsi con la vostra webcam? Dando una priorità al lavoro (ad esempio, abilitare l'integrazione della webcam e poi abilitare la funzionalità di video chat), un progetto complesso diventa più trasparente e più facile da capire, e c'è meno rischio di perdere un passaggio cruciale.

Questi vantaggi non sono esclusivi del software, ma molti creatori di prodotti fisici provano esattamente questo sentimento: "Agile, ottimo per loro, ma non per me. Non è possibile".

Ebbene, è possibile e, cosa più importante, è probabile che stiate facendo almeno un po' di sviluppo di prodotti Agile senza rendervene conto.

Comprendere la riluttanza interna allo sviluppo Agile dei prodotti

Agile può essere una metodologia difficile da seguire. Non esiste una polizia Agile - nessuna forza esterna a cui un'organizzazione possa rivolgersi per chiedere "la mia azienda è davvero Agile?". Di conseguenza, abbiamo visto aziende dichiarare di essere Agile quando non lo sono, e aziende affermare di non essere Agile, nonostante seguano diverse procedure chiave di sviluppo del prodotto Agile (di solito riunioni quotidiane, feedback frequenti dei clienti, sprint rapidi attraverso almeno una fase di produzione per creare un prototipo, ecc.) Questa confusione può essere una delle ragioni per cui i dirigenti rifiutano l'Agile.

Detto questo, gran parte della riluttanza nel settore dell'hardware deriva dall'associazione di Agile con l'agilità. Un decisore potrebbe leggere dello sviluppo prodotto Agile e dire: "Certo, il software può essere realizzato in poche settimane, ma l'hardware richiede molto più tempo". Sebbene lo sviluppo di prodotti Agile si riferisca alla velocità, tuttavia non si tratta di andare veloci.

L'attenzione di Agile per il progresso sostenibile

Uno dei principi fondamentali dello sviluppo prodotto Agile è la sostenibilità, ma non necessariamente nel contesto del rispetto dell'ambiente. Tutto ciò che viene realizzato con le metodologie Agile dovrebbe, in teoria, poter essere ripetuto all'infinito senza creare problemi o ostacoli. Gli sprint sono utili solo nella misura in cui sono affidabili. Le organizzazioni non sono incoraggiate ad andare troppo veloci, per evitare di stressare i dipendenti o di fissare standard irrealistici per il progetto successivo.

Nel software, uno sprint sostenibile può essere di settimane, ma l'hardware non dovrebbe mai sentirsi obbligato a rispettare questo ritmo. Tuttavia, se lo fanno, lo sviluppo di prodotti Agile è abbastanza flessibile da adattarsi. Gli sprint non riguardano sempre la consegna di un prodotto funzionante, ma piuttosto di un valore misurabile. Quindi i prodotti fisici non devono essere creati in poche settimane. Tuttavia, le aziende acquisiscono una comprensione più completa delle fasi e delle suddivisioni necessarie per fornire costantemente un valore misurabile durante lo sviluppo del prodotto.

Sapere che il tempo e la velocità non sono i fattori cruciali di Agile, come alcuni credono, può contribuire ad attenuare la riluttanza interna al suo utilizzo. Lo sviluppo di prodotti Agile dà la priorità alla coerenza, alla collaborazione e all'avversione al rischio, tutte cose che si ottengono attraverso sprint progettati per fornire un valore misurabile, che si tratti di un prototipo funzionante o semplicemente di un segno di spunta definitivo nel percorso verso la creazione del prodotto fisico.

Le chiavi del successo di Agile

Iniziare in piccolo

La riluttanza allo sviluppo di prodotti Agile deriva anche dalla percezione dei costi di investimento. La trasformazione digitale è raramente poco costosa e le aziende sono abituate a soppesare i benefici di un'iniziativa digitale rispetto al costo della sua implementazione. Agile, tuttavia, non è legato alla tecnologia. Non c'è alcun costo di investimento iniziale. Infatti, lo sviluppo di prodotti Agile utilizza tipicamente software che sono già sempre più diffusi. Programmi come Jira, Microsoft Teams e Zoom possono essere utilizzati nei flussi di lavoro Agile.

Inoltre, il passaggio ad Agile non deve essere necessariamente a livello aziendale. Anzi, quasi sempre non dovrebbe esserlo. Le aziende che si cimentano con lo sviluppo Agile dei prodotti spesso scelgono un piccolo team con cui sperimentare. Questo team dovrebbe lavorare su un progetto che sembra adatto all'applicazione dei concetti Agile. Iniziare in piccolo permette alle organizzazioni di compartimentare l'Agile rispetto ai flussi di lavoro esistenti e di capire se e come sta avendo un impatto.

Misurare e misurare ancora

Uno dei maggiori successi della trasformazione digitale è stato l'aumento della trasparenza. Con gli strumenti digitali, le organizzazioni possono tracciare meglio le prestazioni e misurare il successo, capendo esattamente come funzionano determinati sistemi e sapendo quando regolarli. Agile non è diverso da questo punto di vista. Non è sufficiente dire a un team di provare lo sviluppo di prodotti Agile e poi non fare alcuno sforzo per misurare le prestazioni. Naturalmente non ci si deve aspettare risultati immediati e il primo progetto sarà probabilmente il meno efficiente, in quanto il team si adatta allo sviluppo di prodotti Agile, ma in seguito i risultati dovrebbero arrivare presto.

Scegliete un flusso di lavoro in cui i risultati possano essere facilmente letti e compresi dal team di leadership. In questo modo, l'impatto di Agile sul processo attuale è misurabile. In questo modo, gli stakeholder interni avranno qualcosa di concreto a cui fare riferimento per valutare se lo sviluppo di prodotti Agile è la soluzione giusta.

L'adesione interna allo sviluppo di prodotti Agile è fondamentale per il suo successo, e i ritardatari rischiano di subire un'ulteriore concorrenza ignorando quello che potrebbe essere un vero e proprio vantaggio per la produttività. È vero che Agile è spesso associato alla velocità, ma non è necessario che sia così. Lo sviluppo di prodotti Agile non ha bisogno di investimenti significativi, ma semplicemente del team giusto, delle persone giuste e della mentalità giusta che lo accompagnino nella fase di test, in modo da poter stabilire se lo sviluppo di prodotti Agile è adatto alla vostra azienda.

Sul tema dello sviluppo Agile, vi segnaliamo anche l’episodio 31 del podcast di PTC in Italiano Trasformazione Digitale, dal titolo "Agile come un prodotto complesso"

Transizione allo sviluppo agile

Lo sviluppo agile dei prodotti sta diventando sempre più diffuso per i prodotti fisici. Scoprite perché e come farlo in modo efficace.

Scopri di più