Questo sito web utilizza cookie tecnici e, previo Suo consenso, cookie di profilazione, nostri e di terze parti. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsente all'uso dei cookie. Leggi la nostra Cookie Policy per esteso.OK

Innovation Management

Agile, Lean Startup e Design Thinking: adottare le metodologie non basta. Cosa insegna l’esperienza

Si diffondono nelle aziende le tecniche per favorire innovazione, reattività e flessibilità. Anche se di per sé ciascuna è molto valida, molto spesso l’applicazione è parziale e lontana dai principi base. Metterle insieme, invece, richiede un coordinamento tra reparti diversi che è sottostimato: non basta adottarle, occorre governarle

21 Mar 2018

Giovanni Pepicelli

Le moderne metodologie di innovation management, in particolare la metodologia Agile, la Lean Start up e il Design Thinking,  sono oggi in rapida adozione nelle aziende. Ma sono davvero efficaci? Il trend merita almeno un paio di riflessioni. La prima questione riguarda la conoscenza di esse: spesso in azienda se ne parla, si pensa di adottarle ma non sempre il significato e soprattutto i vantaggi attesi sono chiari, quindi ho notato un po’ di confusione nella loro applicazione. La seconda questione riguarda l’uso esteso e congiunto di queste metodologie. Prendo spunto da un libretto che ho recentemente letto di Jeff Gothelf e dalla mia personale esperienza per evidenziare alcuni aspetti chiave.

Per fare chiarezza, vediamo innanzitutto sinteticamente in che consistono.

La metodologia Agile: Scrum e DevOps

L’Agile è nato dall’incontro nel 2001 di 17 sviluppatori, in un resort sul cocuzzolo di una montagna dello Utah, che avevano deciso di farla finita con lo sviluppo Waterfall solitamente utilizzato, per trovare un nuovo modo di realizzare applicazioni software in maniera più leggera, economica e rapida. Produssero un manifesto a partire dal quale sono state sviluppate specifiche metodologie di cui lo “Scrum” è quella più diffusa, che ho avuto modo di seguire da vicino.

In sostanza si procede con un team molto coeso, composto da product manager e sviluppatori, a definire i requirement per uno sviluppo di una prima parte dell’applicazione, fermandosi poi a provare quanto realizzato, a ragionarci su e definire nuovi requirement per la realizzazione di nuove funzioni o di una revisione di quanto realizzato.

Fondamentali sono i principi riportati nel manifesto che focalizzano lo sviluppo del software sugli individui e le interazioni, sul prodotto realizzato piuttosto che sulla documentazione, sull’interazione stretta con il cliente e soprattutto sui cambiamenti che possono avvenire anche durante lo sviluppo stesso del prodotto o servizio. Questa metodologia ha avuto una spinta notevole dall’introduzione del Cloud, che ha favorito il deploy continuo del software attraverso un approccio denominato DevOps.

Il DevOps (2009) prevede, attraverso la collaborazione e integrazione tra sviluppatori e addetti alle operation la gestione più flessibile, affidabile, sicura e controllabile dei rilasci, tale da rendere più veloci i cicli di sviluppo e rilascio. Il DevOps si ispira alla metodologia Agile, alla necessità di incrementare la frequenza dei rilasci in produzione e fa leva sulla disponibilità di infrastrutture virtualizzate e in cloud.

Ma l’adozione massiva in azienda della metodologia Agile richiede un coordinamento tra le varie iniziative Agile: infatti per la natura stesso dell’approccio non è definito a priori il risultato finale e per tanto, in un medesimo contesto, i risultati di iniziative diverse potrebbero sovrapporsi o interferire tra di loro. Per questo sono nate varie metodologie (LeSS, DAD …) tra queste il SAFe (Scale Agile Framework, 2007) è tra le più adottate. SAFe permette di sincronizzare gli allineamenti, favorisce la collaborazione e i rilasci tra più team Agile.

Cos’è la metodologia Lean StartUp

Ho avuto modo di impararla e di applicarla per una start up (www.powergift.it). A differenza dell’Agile, che è applicata soprattutto dall’IT per lo sviluppo di applicazioni, Lean Start Up è indirizzata soprattutto ai Product Manager delle aziende o comunque a chi vuole sviluppare una idea e trasformarla in business. L’ideatore è Eric Ries che già dal 2008 ha iniziato ad applicarla dapprima alle startup high tech e poi l’ha riportata insieme con l’analisi di differenti esperienze nel celebre libro “Lean Startup” nel 2011.

La metodologia parte dal concetto base dell’approccio Lean ovvero evitare sprechi di risorse. A partire dall’idea, la metodologia “rottama” l’approccio standard cioè di verificare immediatamente se il prodotto/servizio basato su quell’idea può essere realizzato, ma pone al centro queste domanda: È possibile costruire un business sostenibile su questo prodotto/servizio? C’è qualcuno a cui piacerebbe? C’è qualcuno che pagherebbe per questo?

Per rispondere, Ries propone di effettuare degli esperimenti ciclicamente spendendo il minimo delle risorse necessario, analizzando l’accoglimento dei clienti e proponendo un altro esperimento avendo il coraggio di “sterzare”, di tornare indietro e intraprendere un’altra strada. La tecnica “core” su cui si basa è l’MVP, il Minimum Vialable Product. Purtroppo se si parla con qualcuno soprattutto in azienda di Lean StartUp, questi molto probabilmente risponderà “ah si l’MVP”: il Lean StartUp è qualcosa molto di più importante di una tecnica, è un modo di essere in cui le persone della Startup o dell’azienda (almeno una parte significativa di essa), hanno nel DNA un modus operandi proteso alla sperimentazione e alla concretizzazione delle idee in business. È questa caratteristica che garantisce lo sviluppo dell’idea e la crescita futura. Ho avuto modo di valutare startup e dopo averne viste tante e dopo aver meditato sul libro di Ries, sono convinto che uno degli aspetti più importante della valutazione è proprio quello di valutare la capacità delle persone che lo compongono di valutare e sperimentare nuove idee, ovvero di crescere.

Purtroppo la sua adozione in azienda, come da me stesso sperimentato, incontra degli ostacoli, anche nel luogo più indicato di essa, il Product Management Office.

Il Design Thinking, metodologia in crescita

Questo approccio è stato inventato da Tim Brown di Ideo molti anni fa e negli ultimi anni si sta rapidamente diffondendo. Si basa sui principi del design strategico, il processo e i tools sono proprio del mondo del design. In genere viene applicato da un team multidisciplinare che ha come obiettivo quello di trovare una soluzione innovativa ad un problema tenendo conto del gradimento di essa, della redditività indotta e della sostenibilità economica.

Gli step sono quelli illustrati in figura. Questo “processo creativo” può essere applicato in più contesti e per problemi di natura diversa, da come operare una scelta strategica a quella di disegnare un nuovo prodotto o servizio.

Anche per questa metodologia le insidie sono tante e la sua applicazione può risolversi in un mero esercizio di brainstorming senza arrivare ad una idea geniale piuttosto che invece diventare una prassi di apprendimento e generazione continua.

L’integrazione delle metodologie e l’uso che se fa nella realtà

La seconda questione riguarda invece l’uso reale e il coordinamento delle iniziative sviluppate adottando queste metodologie contemporaneamente. L’autore Jeff Gothelf prende in prestito le parole di Joe Pesci nel celebre film “Goodfellas” (in Italia “Quei bravi ragazzi”) “One dog going one way. One dog the other way” “and what do you want from me?” Insomma, ciò che non si dovrebbe vedere in azienda, dove però capita a volte che un team vada in una direzione, un altro in un’altra direzione e il manager che alle strette si schernisce dicendo “ma che ci posso fare”.

In figura un tentativo di inquadrare insieme queste metodologie integrate tra di loro (la figura è ispirata da una vista Gartner a riguardo recentemente presentata).

Si tratta però per lo più di una indicazione di posizionamento piuttosto che il modo con cui organizzare e governare questi processi insieme.

Dall’osservazione dell’applicazione in azienda di queste metodologie innanzitutto si evince che alcuni dei principi fondamentali su cui si basano sono stati in parte stravolti. Ad esempio l’Agile, che si ispira e persegue un modo per essere più reattivi alle richieste del cliente soprattutto sul modo di usare un prodotto o di lavorare con esso e di rispondere velocemente ai cambiamenti di mercato, è diventato quasi solo un modo per rilasciare più velocemente. Gli stessi managers e trainers non spingono molto nel concentrarsi sulla natura dei problemi e le vere necessità dei clienti ma sulla praticità dell’adozione di uno schema metodologico.

Il successo che ha avuto l’introduzione del Lean Start Up nelle aziende sembra dovuto alla capacità di rivitalizzare le aziende dotandole delle energie e della agilità proprio delle piccole organizzazioni, tipicamente le Start Up. E malgrado ci si sforzi ad orientare gli sforzi di sviluppo solo su quel minimo che serve (MVP) molto spesso in pratica ci si concentra su cosa ci può essere nella release 1 e cosa nella release 2, dimenticando che questa ultima è fortemente legata all’accettazione della release 1 tra gli users. Il Design Thinking ha rivoluzionato certamente l’oggetto stesso del “design” passando dal fare un oggetto, un servizio “bello e attraente” ad un prodotto o servizio accettabile dall’utente soprattutto per la sua utilità e quindi le sue funzionalità. Una rivoluzione non da poco, un modo con il quale finalmente possono essere rappresentate le esigenze dei clienti. Ma alla fine, dopo giornate di seminari, corsi, workshop e migliaia di post-it, sono state per lo più prodotte idee non allineate alla strategia aziendale e praticamente irrealizzabili.

Insomma senza una attenta governance, una collaborazione “vera” e committed dal management tra designers, product managers, business developers e sviluppatori di prodotto, ognuno con il suo contributo professionale basato sull’uso con “buon senso” e “open” di queste potenti metodologie, si rischia di non raggiungere risultati anzi di dover gestire una sorta di caos interno.

Ma cosa fare? Non esistono ricette, ma come la pratica e l’esperienza consigliano, occorre prima di partire cercare di bilanciare al meglio organizzazione, governance, esperienze, metodologie riferendosi sempre ai principi base e avendo ben in mente l’obiettivo principale. Insomma le metodologie non basta adottarle, occorre governarle.

* Giovanni Pepicelli, Innovation Manger e IT Advisor, è da sempre attento alle tematiche e speculazioni relative ai trend in IT. Ingegnere elettronico, ha iniziato la sua carriera come progettista hardware. Dopo una specializzazione in Computer Science, ha lavorato in questo campo in Enel ricoprendo vari ruoli quale responsabile per definizione di architetture, introduzione di tecnologie, gestione dei sistemi informatici e infine quale responsabile per Technology Scouting e Innovazione. Ha fondato quale entrepreneur in Enel, una start up. Ultimamente sono state ufficialmente certificate le sue competenze di Innovation Manager.

Articolo 1 di 4