Agile, design thinking e lean startup. Nell’ultimo decennio c’è stato un crescente buzz intorno a questi tre termini: nei siti, sui social, nel mondo accademico come in quello aziendale.
Ma parlare di buzz è riduttivo. Perché non parliamo di “mode” o concetti astratti, ma di mindset e metodologie che hanno avuto un impatto importante sui processi di innovazione, sulle strategie di business, sulla gestione aziendale. Insomma, nella realtà quotidiana di molte imprese.
Agile, lean startup e design thinking: avete le idee chiare?
A volte qualcuno di voi potrebbe aver avuto la sensazione che siano termini poco chiari, e per questo a volte utilizzati in maniera intercambiabile. Prendiamo “agile” ad esempio. Viene utilizzato in maniera estremamente ampia, intendendo spesso un approccio flessibile, reattivo, snello, nei processi aziendali. In realtà, come vedremo tra poco, ha un significato ben più preciso.
Vi anticipo sin d’ora la conclusione, almeno la mia personale conclusione. Nulla di male se nell’utilizzo comune questi termini vengono usati in maniera diluita, sganciandosi dal loro vero significato originale. L’aspetto linguistico interessa fino ad un certo punto, e peraltro io stesso non sono un purista. Però è bene sapere che un significato originale c’è.
Vedremo ora le tre metodologie e il loro reale significato, per chiarirci prima le idee. Ma sarà ancora più interessante, poi, cogliere i punti di contatto tra agile, design thinking e lean startup. Ricercarne persino una sintesi. Perché dei punti di contatto ci sono, eccome, e scoprirli è utilissimo per capire in che direzione si sta muovendo il mondo aziendale.
Metodologia agile
Agile, il termine più usato e abusato. Anche dal sottoscritto. Però è bene sapere cosa significhi davvero metodologia agile.
Facciamo un passo indietro. Nello sviluppo del software, la classica metodologia di project management è nota come waterfall. Immaginate una serie di cascate, una più in basso dell’altra, attraverso le quali l’acqua deve necessariamente passare, in un percorso lineare e unidirezionale. Ecco, il termine waterfall è davvero indovinato, perché lo sviluppo del software tradizionalmente segue un ordine sequenziale, e si muove verso la fase successiva solo se la fase precedente è completata.
Ma poi nel 2001 nasce un movimento che propone una metodologia completamente diversa, la metodologia agile, appunto. In cosa consiste la differenza?
Lo sviluppo del software passa attraverso un processo iterativo di sviluppo e immediato test dei vari “pezzi” del software. Non vi è un unico test finale con lo user prima del lancio, ma al contrario si effettua una serie di test con gli user man mano che il software viene sviluppato.
Perché prima abbiamo detto che “nasce un movimento”? Perché gli evangelist iniziali di questa metodologia si sono davvero comportati come un movimento, divulgando la filosofia sottostante con un vero e proprio Manifesto, pubblicato appunto nel 2001 e firmato da questi evangelist, che elenca i principi fondamentali.
Potrete trovare, se vi interessasse, la versione ufficiale in italiano cliccando su Manifesto Agile. Del Manifesto vi riporto uno dei 12 principi che credo dia l’idea del senso profondo della metodologia agile
“Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo.”
Ovvero: se testando continuamente quello che stiamo realizzando nel corso dello sviluppo stesso (senza attendere un unico test finale), scoprissimo che è necessario modificare profondamente i requisiti iniziali che avevamo fissato, non dovremmo esitare a rimettere in discussione quanto stiamo facendo.
Perché? Perché è molto meglio tornare sui propri passi (iterazione) che scoprire solo a progetto completato che il software sviluppato non è allineato alle esigenze del cliente!
In altre parole, l’applicazione della metodologia agile prevede una serie frequente di test di quanto abbiamo appena realizzato, con un continuo confronto con lo user per il quale il software è destinato. Ed è meglio fallire il test e tornare indietro che procedere seguendo in maniera rigida e lineare il progetto (waterfall).
Graficamente potremo vedere il processo agile come una serie di cicli, in ognuno dei quali si susseguono le fasi plan (pianifica), design (progetta), develop (sviluppa), test e infine deploy (rilascia al cliente “quel pezzo” di software una volta testato):
Quindi, il termine agile che utilizziamo così spesso, nasce in realtà in un contesto ben preciso, ovvero il project management di software. Ve bene allora usare il termine agile in senso allargato come spesso facciamo, ma teniamo sempre in mente le origini vere della metodologia agile.
Metodologia agile: l’essenza dell’agility in 3 punti
Ma ora guardiamo all’essenza della metodologia agile, astraendo dal contesto in cui è nata e andrebbe per correttezza riferita. Cosa stiamo stabilendo, in sintesi? Che nello sviluppo di un “qualcosa” è meglio effettuare una serie di test con l’utente. E che il test, anche quando fallisce e ci fa tornare indietro (o addirittura ci fa rimettere in discussione i nostri obiettivi) è preziosissimo perché genera comunque apprendimento.
Possiamo vedere il concetto di agile come una continua iterazione di cicli in cui sviluppiamo un pezzo, lo testiamo con l’utente, e cresciamo lungo la curva di apprendimento. Tre sono allora i concetti che emergono, e teniamolo bene in mente:
(1) stiamo dicendo che si anticipa il contatto tra il prodotto/servizio e lo user, senza attendere un unico test finale o peggio ancora il lancio sul mercato. Se c’è qualcosa che non va, meglio saperlo prima. Quindi, anticipazione del momento di incontro con lo user.
(2) iterazione, quindi un processo non lineare ma di cicli continui di test e apprendimento in cui si torna indietro se necessario
(3) apprendimento, quindi capiamo meglio anche durante lo sviluppo. Normalmente la fase di apprendimento avviene nei progetti nella fase iniziale, quando dobbiamo preparare il progetto e occorre disporre delle necessarie informazioni per decidere la direzione, e nella fase finale, quando il progetto e completato. Ma nella metodologia agile l’apprendimento è continuo, anche durante lo stesso sviluppo.
Ripeto: anticipazione, iterazione, e apprendimento. Teniamoli in mente, capirete più avanti la ragione.
Lean startup
E’ una metodologia così popolare che il termine lean è diventato diffusissimo, e ad aggiungere confusione viene utilizzato anche in maniera intercambiabile con agile.
Ma da cosa nasce questa metodologia? Nasce da un libro, intitolato appunto “The lean startup”, scritto dall’imprenditore e noto startupper statunitense Eric Ries e pubblicato nel 2011 divenendo immediatamente un best-seller. E’ un testo che ho letto con piacere e ve lo consiglio la lettura, se voleste approfondire il tema.
Il libro ha fatto un po’ da “manifesto” per un crescente movimento, che ha fatto da evangelist per l’adozione della metodologia nelle aziende. E prima di addentrarci nella metodologia, solo per precisione segnalo che a sua volta la lean startup affonda le sue radici – come dichiara lo steso Ries – nella metodologia produttiva giapponese del lean manufacturing, sviluppata inizialmente per le catene di montaggio della Toyota. Ma non divaghiamo oltre.
Cosa è una startup e come dovrebbe svilupparsi?
Il contesto della metodologia lean startup in questo caso non è lo sviluppo del software ma, come dice il termine, è la startup. Cos’è allora una startup? So che tutti voi avrete più o meno un’idea e una vostra definizione, ma mi piace qui ricordare proprio la definizione elaborata dallo stesso Eric Ries:
la startup come istituzione umana progettata per creare un nuovo prodotto o servizio in condizioni di estrema incertezza.
Ci tengo a condividere con voi questa definizione, e chiarisco la ragione. Spesso quando pensiamo alle startup pensiamo ad aziende ad alta tecnologia nelle loro primissime forme iniziali. Ma Eric Ries non restringe il concetto ad aziende tecnologiche, anzi nemmeno al concetto di azienda! Si focalizza piuttosto sulle condizioni di estrema incertezza in cui si trova un’organizzazione nella sua fase embrionale.
Ebbene, qual è l’obiettivo della metodologia lean startup?
E’ far progredire la startup evitando piani complessi, basati su fin troppe assumption tutt’altro che dimostrate. Perché sono piani che in un contesto di elevata incertezza potrebbero avere fondamenta fragilissime. Far progredire la startup non atttraverso rigide pianificazioni a lungo termine ma attraverso una serie di continui aggiustamenti e correzioni.
Attivando quella che Ries chiama una curva di validated learning, ovvero comprendendo – e quindi validando – le assumptions sulle quali stiamo costruendo il modello di business, e imparando – attraverso una serie di esperimenti – come allineare il prodotto/servizio offerto e il relativo modello di business al nostro customer.
In parole semplici, capire come l’idea di business sottostante la startup vada adattata e modificata perché sia trasformabile in un vero e proprio business profittevole.
Perché durante questo processo di validated learning potremmo anche capire che l’idea richiede di essere profondamente modificata, tenendo fermi solo alcuni elementi dell’idea, ed avremmo allora il cosiddetto pivot.
Lean startup: il ciclo Build-Measure-Learn di Eric Ries
E allora, chiarita la finalità della metodologia della lean startup, come si concretizza? In una serie di iterazioni, nelle quali avviene di continuo un processo circolare nel quale sviluppiamo il nostro prodotto/servizio attraverso esperimenti con i quali impariamo e gradualmente “prendiamo la mira”.
Esperimenti che passano attraverso la creazione di MVP, Minimum Viable Product: rappresentazioni essenziali del prodotto sviluppate appositamente per misurare – in un incontro “prematuro” con il customer – il potenziale del prodotto finito che abbiamo in mente.
Eric Ries rappresenta così ogni ciclo del processo, noto come Build-Measure-Learn:
Cosa notiamo? Vi sta suonando un campanello nella testa ma non capite perché? Guardate bene il processo di sperimentazione e apprendimento descritto da Eric Ries: cosa ritroviamo? Tre punti.
Primo, grazie agli esperimenti il prodotto/servizio creato dalla startup, prima ancora di essere lanciato sul mercato, incontra già il cliente al quale è destinato. Anticipazione.
Secondo, si fanno esperimenti e se è il caso si torna indietro: non è un processo lineare. Iterazione.
Terzo, come spiega con enfasi Eric Ries: “validated learning”. Apprendimento.
C’è un evidente allineamento su questi 3 punti tra la metodologia agile e la metodologia lean startup! Certo, il contesto è diverso, ma c’è un framework comune che si può cogliere tra lean e agile.
Andiamo avanti, ora, per parlare di design thinking.
Design thinking
E’ la terza metodologia di ampio successo dell’ultimo decennio. anche se affonda le sue origini all’inizio del 2000, quando l’Università di Stanford l’ha definita con chiarezza, facendone una disciplina. In sostanza, è un approccio, che poi si traduce in una vera e propria metodologia e quindi in un processo, col quale si applicano metodi e strumenti propri del design per il problem-solving, tipicamente (ma non necessariamente) in ambito aziendale.
Un approccio che, essendo ispirato al design, è per vocazione human-centered: la persona, la sua esperienza, i suoi bisogni, sono costantemente al centro di questa metodologia.
Non mi soffermerò oltre sul design thinking, anche perché ho avuto modo di parlarne in questo blog in numerosi articoli (ne segnalo alcuni nelle note finali). Veniamo piuttosto al processo, che in estrema sintesi passa attraverso le seguenti fasi:
E’ un processo idealmente circolare. Osservo gli user per comprendere il problema, arrivo a definire il problema con chiarezza, genero creativamente una molteplicità di soluzioni, mi focalizzo su quelle soluzioni che rispettano alcuni parametri (fattibilità, etc), produco dei prototipi per testare queste soluzioni, e dai test ricavo ulteriori informazioni ma anche ulteriori domande che mi spingono a tornare ad osservare lo user, rivedere il problema, e così via.
Siamo di fronte nuovamente ad un processo non lineare ma iterativo, nel quale ad ogni ciclo si fa un passo in avanti, ma in ogni ciclo si torna sempre a confrontarsi con lo user. Ed ancora una volta ritroviamo quei tre elementi.
Primo, nelle fasi di prototipazione e test anticipiamo il contatto tra la il prodotto/servizio (che fa da soluzione al problema) e il cliente/user al quale è destinato. Anticipazione!
Secondo, come detto: è un ciclo non lineare. Iterazione!
Terzo, dopo il test raccogliamo ulteriori informazioni (ad esempio, insights sul cliente) e quindi… impariamo, cioè approfondiamo la nostra conoscenza del problema. Apprendiemnto!
Gli stessi tre elementi che avevamo ritrovato nella metodologia agile e nella metodologia lean startup.
Conclusione
Indubbiamente esiste una sorta di framework, basato su quei 3 elementi, che accomuna le 3 metodologie.
Non solo. C’è in realtà un quarto elemento. Non lo abbiamo mai nominato espressamente, e tuttavia ci ha accompagnato lungo questo nostro viaggio.
Se guardate al Manifesto Agile leggerete, come primo principio in assoluto leggerete:
La nostra massima priorità è soddisfare il cliente rilasciando software di valore
Il cliente è al centro di tutto. Ma questo punto di vista lo ritroviamo in realtà anche nella metodologia lean startup. Come spiega Eric Ries nel suo libro, il processo ciclico Build-Measure-Learn è costruito tutto intorno al cliente (il customer).
Infine, il design thinking: la metodologia di problem-solving che nasce dall’human-centered design, che nasce per dare risposte ai problemi delle persone.
Ed ecco il quarto elemento. Può essere il cliente al quale è destinato lo sviluppo del software, può essere il customer di una startup, può essere la persona per la quale intendiamo risolvere un problema disegnando una soluzione… ma in ogni caso siamo di fronte a metodologie che mettono al centro le persone, e per farlo si sviluppano attraverso una serie continua di confronti con le persone.
Questa nuova attenzione alla dimensione umana del cliente non è solo ciò che caratterizzata queste metodologie, ma è un segnale forte dell’epoca in cui viviamo. Un’epoca in cui, nonostante il rapidissimo progredire della tecnologia, c’è una rinnovata attenzione verso la persona, come a ricordare che i sistemi economici e la tecnologia hanno un senso solo in quanto rispondono ai nostri bisogni. Che non sono sempre e necessariamente bisogni materiali.
In questo senso, le tre metodologie viste sono – prima che metodologie – dei mindset nei quali l’innovazione ha un significato solo in relazione alle persone per le quali è destinato.
Note: sul design thinking sono presenti in questo blog diversi articoli, tra i quali vi segnalo:
“Quali sono le fasi del design thinking”
Sulla lean startup può essere invece interessante un articolo che ho scritto su Linkedin: “Lean startup: come sviluppare una startup minimizzando il rischio”
