Ma la mia azienda non è adatta allo Sprint

19/05/17 15.07 / Di Gennaro Polito

Businessman standing with hands on hips against low angle view of skyscrapers at sunset.jpeg

 

Quando ci riferiamo a temi come l’innovazione, spesso dobbiamo affrontare alcune resistenze interne alle aziende, dovute in larga parte al preconcetto che solo aziende del calibro dei giganti del tech o le startup possano adottare metodologie, strumenti e processi che mettono in discussione il modo tradizionale in cui si sono sempre svolte le attività all’interno dell’organizzazione.

 

Con il metodo Sprint, ideato da Google Venture, alcune risposte comuni sono: “Ma noi non siamo Google” oppure “Penso sia più indicato per una startup, non per un’azienda consolidata”.

La verità è che non serve necessariamente essere una startup o un’azienda come Google, ma si può sicuramente apprendere dai loro esempi e imparare a muoversi in modo più rapido o sperimentare soluzioni innovative e testarle velocemente sul mercato mediante un approccio sistemico.

 

Vediamo, quindi, insieme qualche esempio tratto da storie di aziende che, anche se non appartenenti a settori vicini all’innovazione o al Digital, sono riuscite a completare con successo le sessioni di Sprint ottenendo ottimi risultati.

 

Caso 1: Applicare lo Sprint ad un progetto governativo

Il team, guidato da Charles Reynolds-Talbot, lavorava ad un progetto con l’obiettivo di aiutare le persone a dare feedback al governo mediante API.

Il focus del racconto non sarà sullo specifico progetto, che coinvolgendo un governo non può essere discusso in dettaglio, ma sarà piuttosto sugli esiti dell’applicazione del metodo Sprint in un contesto considerato molto lontano dai temi dell’innovazione.

 

Nello specifico, lo Sprint è stato usato per favorire la generazione di idee da cui far nascere i nuovi progetti del team coinvolto: lo Sprint avrebbe aiutato a comprendere meglio il problema da risolvere e se la soluzione individuata era nella giusta direzione.

 

Il processo di design in uno Sprint non è molto lontano da alcuni concetti presenti anche nella metodologia Agile Software Development, quali ad esempio la fase di discovery e la fase alpha.

 

Il team era composto da product owner, user researcher, business analyst, front-end developer ed interaction designer: quest’ultimo con il ruolo di facilitator, mentre il product owner era il decider; alle sessioni hanno partecipato anche alcuni esperti, quotidianamente a contatto con il problema e i processi esistenti, così da aiutare il team nel corso dei giorni dello Sprint.

 

Giorno 1

Durante il primo giorno è stato inquadrato il problema, fissando un obiettivo di lungo termine e annotando le ipotesi e domande al centro del progetto.

Volendo seguire rigorosamente il processo, il team avrebbe dovuto mappare l’evoluzione futura del progetto dopo aver raggiunto l’obiettivo di lungo termine, ma il team ha trovato difficoltà nel visualizzare come avrebbe potuto funzionare la soluzione prototipata nella realtà, dato che c’erano molti elementi fuori dal controllo del team.

Questa situazione è abbastanza comune quando si lavora in organizzazioni governative, in quanto la maggior parte dei servizi sviluppati deve interagire con più dipartimenti, mentre i team impegnati in una determinata attività hanno una visione limitata del piano generale.

Per risolvere la questione (concentrarsi su un singolo aspetto reale o prevedere l’intera evoluzione del progetto) si è lasciata l’ultima parola al decider, che ha approvato la decisione di focalizzarsi sul percorso attuale, del quale il team aveva una consapevolezza maggiore, legata anche alla conoscenza delle aree maggiormente problematiche e rischiose, quindi anche quelle che nascondevano le migliori opportunità di scoperta.

 

Giorno 2

La seconda giornata di uno Sprint prevede che i partecipanti creino le bozze della soluzione al problema individuato (nella forma più semplice, si tratta di disegni su carta).

Le persone non sempre reagiscono bene all’idea di dover disegnare: molto spesso sentono di non essere in grado perché pensano siano richieste competenze grafiche per riuscire a completare una bozza e renderla comprensibile.

Questo è un aspetto da non sottovalutare: molti workshop sul design falliscono proprio perché non si riesce a gestire bene questa paura dei partecipanti.

La verità è che non serve essere degli ottimi disegnatori per superare con successo la seconda giornata di uno Sprint: le bozze servono semplicemente per raccogliere informazioni, elaborarle e schematizzarle su un pezzo di carta.

Anche le parole sono ottimi esempi di bozze.

Il processo aiuta anche le persone coinvolte ad aumentare il proprio senso di fiducia, in quanto, a differenza del primo giorno, le attività del secondo giorno possono essere portate a termine dai partecipanti lavorando singolarmente alle proprie bozze; è solo alla fine del giorno che le bozze sono condivise con l’intero team e discusse insieme.

Alla fine del giorno abbiamo ritagliato un momento per improvvisare una retrospettiva su quanto fosse stato fatto finora: da un lato l’obiettivo era quello di smorzare qualche dubbio sull’effettivo commitment dei partecipanti, dall’altro è stata un’opportunità per ricevere suggerimenti su come migliorare alcuni aspetti del processo.

La risposta del team è stata più che positiva sul nuovo approccio alla generazione di idee, sul ritmo al quale si stava procedendo e sul modo in cui si lavorava insieme.

Si è anche deciso di iniziare i rimanenti giorni guardando un video di Jake Knapp e John Zeratsky, i due ideatori del metodo, che sintetizzano gli obiettivi delle giornate.

 

Puoi trovare i video in questa playlist su YouTube: Sprint | GV.

 

Giorno 3

Come richiesto il giorno precedente, abbiamo iniziato con un video dei due creatori del metodo nel quale mostravano gli obiettivi della giornata.

L’impegno del team era completamente diverso rispetto al primo giorno, non c’erano più sguardi di pessimismo nella stanza e tutti erano in piedi, muovendosi intorno alla stanza e intrattenendo una discussione sana.

Al termine del giorno avevamo raccolto le nostre idee migliori e le avevamo trasformate in uno storyboard pronto per la fase successiva: la prototipazione.

 

Giorno 4

Nella fase di prototipazione siamo stati avvantaggiati: avevamo nel team uno sviluppatore front-end con accesso agli elementi del sito gov.uk di cui avevamo bisogno.

In poco tempo abbiamo abbiamo posto le basi per lo sviluppo di un prototipo molto fedele alla realtà con il quale gli utenti avrebbero potuto interagire durante la fase di test.

Anche se il prototipo richiedeva competenze di software development, non significa che gli altri membri del team siano stati esclusi dalle attività della giornata: ognuno ha giocato la propria parte, ad esempio costruendo set di dati fittizi, realizzando mockup su carta, definendo scenari diversi.

L'intera squadra si è riunita per creare una situazione quanto più vicina possibile al mondo reale.

 

Uno dei momenti di prototipazione della soluzione

 

Giorno 5

Il resto della settimana è sembrato una maratona rispetto all’ultimo giorno dello Sprint.

Inizialmente, l’intenzione era di testare la soluzione nell’edificio di fronte quello in cui erano stati condotti i precedenti giorni di Sprint: era l’ambiente di lavoro naturale degli utenti.

Le sessioni di test sarebbero state trasmesse su Google Hangouts tramite una webcam collegata alla TV nella stanza dove erano gli altri membri del team.

A causa di problemi con il WI-FI, gli altri membri del team non riuscivano a vedere i video dei primi test su utenti reali, così si è deciso di completare i test del pomeriggio nella stessa stanza dove era presente l’intero team: non era una soluzione ideale perché non era più l'ambiente "naturale", ma almeno tutti potevano osservare.

Avendo un po’ di tempo a disposizione durante la pausa pranzo, lo si è sfruttato per sistemare alcuni elementi del prototipo che avevano dato problemi durante i primi test.

Le sessioni di test pomeridiane si sono svolte più semplicemente rispetto a quelle della mattina, e hanno permesso di raccogliere molte informazioni sulle reazioni degli utenti alla soluzione prototipata, tutte raccolte in note da usare per migliorare ulteriormente il prototipo iniziale.

 

That’s it! E ora?

In soli cinque giorni è stato possibile definire gli aspetti più rischiosi del progetto, prototipare una soluzione realistica al problema, testare la soluzione con utenti reali e ricevere feedback qualitativi per migliorare lo sviluppo. Non male!

 

Nonostante lo scetticismo iniziale, soprattutto da parte del product owner e dello sviluppatore front-end, i risultati dello Sprint sono stati ottimi, e hanno dimostrato quanto si può completare in relativamente così poco tempo, ponendo le basi per i prossimi Sprint.

 

Sicuramente l’esecuzione di uno Sprint in un’organizzazione governativa ha le proprie sfide: lavorare apertamente, ottenere il consenso dei decision maker, gestire le dipendenze tra governi diversi, policy, legislazioni, finanziamenti. Non bisogna lasciarsi fermare.

Entro la fine della settimana sarà possibile avere un output tangibile del proprio lavoro con il prototipo: sorgeranno domande durante il percorso, ma si troveranno anche le risposte, tante, ottenute in modo rapido, e questo è solo l’inizio.

 

 

Caso 2: Rivoluzionare l’educazione con il metodo Sprint

Non è un mistero che il modello educativo attuale presenta molti aspetti che possono essere migliorati. È tempo di mettere in discussione lo status quo e realizzare cambiamenti che effettivamente permettano agli studenti di essere pronti a ciò che li aspetterà durante la loro vita professionale una volta completato il percorso di studi.

Dopo aver ordinato 40 copie del libro sul metodo Sprint, un professore del Robert D. Campbell Junior High ha chiesto ai suoi studenti di iniziare a leggere il testo e condividere i propri pensieri sul metodo: da subito gli studenti hanno detto di voler usare il metodo in classe.

Prima di procedere con l’adozione del metodo e la creazione di un progetto su cui lavorare attivamente, serviva una conferma da parte anche di altri studenti della scuola: è stato chiesto a sei classi di confrontarsi su cosa si potrebbe fare per migliorare il sistema educativo per renderlo più utile. Senza alcun aiuto da parte dei docenti, ma semplicemente lasciando gli studenti liberi di esprimersi, i risultati delle diverse classi si sono rivelati molto simili: l’educazione dovrebbe essere più vicina alla realtà, le lezioni dovrebbero essere rilevanti per chi le segue, e i progetti sviluppati in classe dovrebbero avere un’utilità nella vita reale. Quello che è emerso è un senso di stanchezza nei confronti di lezioni puramente teoriche, libri di testo obsoleti ed esercizi che richiedono solo memorizzazione; inoltre, gli studenti vogliono che il loro apprendimento vada oltre l'aula e desiderano lavorare con esperti del mondo reale da cui possano imparare ancora di più su ciò che incontra le loro passioni.

 

Si è così deciso di adottare il metodo Sprint in classe per sviluppare un primo cambiamento importante: è nato l’Innovation Chamber Tournament of Entrepreneurs (Torneo degli Imprenditori della Camera dell’Innovazione).

Si è seguito il processo per determinare l’obiettivo di lungo periodo del progetto, definire il problema, stabilire obiettivi specifici da raggiungere durante lo Sprint, ed infine strutturare il torneo.

Gli studenti sono stati divisi in team e hanno iniziato a lavorare su più soluzioni, creando storyboard su come rendere reale la prima edizione del torneo.

Lo step successivo ha visto gli studenti selezionare la soluzione migliore ed elaborare un piano d’attacco: armati di adesivi e del tempo necessario a esaminare tutti gli storyboard presenti sulle pareti della classe, hanno iniziato a votare le soluzioni che ritenevano migliori attaccando un adesivo accanto alle parti degli storyboard che ritenevano importanti; allo stesso modo, in cima a ogni storyboard che giudicavano essere il migliore, ponevano un adesivo più grande.

Successivamente, sono stati esaminati i risultati e sono state raccolte le idee su come si sarebbe svolto il torneo: il giorno successivo la classe, partendo dal piano elaborato in precedenza, ha cominciato a lavorare al loro prototipo.

 

Queste le regole del torneo: gli studenti imprenditori avrebbero formato team da non più di tre persone e avrebbero sfruttato il metodo Sprint per creare un prodotto o un servizio da presentare ad un gruppo di giudici della Camera dell’Innovazione. Ogni "azienda" avrebbe presentato poi ai giudici il prototipo creato, con i dati raccolti dai test di mercato.

Durante la presentazione, ciascun gruppo avrebbe dovuto affrontare i seguenti temi: il problema da risolvere, la base di clienti target, la concorrenza esistente e il modo in cui il loro prodotto o servizio si differenzia, quanto la loro soluzione rappresenti una opportunità di business e perché i giudici avrebbero dovuto investire nel loro progetto.

Altre componenti del torneo includevano la ricerca di mentor nel mondo reale ai quali chiedere aiuto e l’utilizzo di Challonge.com per la gestione delle fasi del torneo e coronare il vincitore del primo Torneo della Camera dell’Innovazione.

 

Per il test della soluzione sviluppata, gli studenti hanno scelto tra due opzioni.

La prima comprendeva farli competere per primi nel torneo che avevano ideato, così da adattare il torneo in base ai feedback ricevuti dai primi partecipanti.

La seconda opzione avrebbe incluso nel test anche altre scuole, in modo da estendere la portata del torneo e ricevere ulteriori feedback utili a migliorare il torneo e adattarlo a nuove esigenze.

 

Dopo averlo utilizzato la prima volta con gli studenti, il metodo Sprint è diventato l’approccio di base per l’insegnamento in classe, con il risultato di aver risvegliato l’interesse nei confronti dell’apprendimento, mentre gli studenti si rendono conto di persona che stanno imparando a lasciare un segno concreto nel mondo.

 

 

Caso 3: Progettare la prossima campagna di marketing con uno Sprint

Questa storia è abbastanza particolare, e mostra in pieno la flessibilità di applicazione del metodo.

Un’agenzia creativa riceve da un’azienda la richiesta di un incontro, che si terrà la settimana successiva, durante il quale discutere della proposta di una campagna per aumentare l’awareness e le vendite di un prodotto, Guided Outcomes (GO), un software innovativo per aiutare le grandi aziende a supportare meglio i piani pensionistici dei loro dipendenti.

 

Il brief da usare per la campagna iniziava con queste parole: “Be bold. Be brave.”

Prendendo alla lettera l’approccio suggerito dal brief, la presentazione dell’agenzia va più o meno così:

  • non abbiamo una risposta al vostro brief;
  • pensiamo di avere un ottimo modo per trovare le risposte con voi;
  • lavorerete tanto quanto noi;
  • non possiamo promettervi che funzionerà, ma vi promettiamo che sarà divertente.

 

A fine giornata, l’agenzia riceve la notizia che ha vinto il progetto, e il giorno dopo iniziano i lavori. Immagino avrai già capito come sarà sviluppata la nuova campagna: sarà usato uno Sprint.

Nello spazio di una settimana avrebbero imparato direttamente da clienti ed esperti, esplorato il problema da risolvere, collaborato sullo sviluppo delle idee, deciso circa la direzione da prendere, e sviluppato un prototipo della campagna da testare su clienti reali.

Dopo aver mappato l’attuale processo di vendita sia dal punto di vista del venditore sia da quello dell’acquirente, era chiaro quale fosse l’aspetto del Customer Journey su cui intervenire e i canali da usare per avere il massimo impatto.

La scelta delle migliori idee da prototipare avviene attraverso un esercizio di votazione democratico basato su punti, anche se questo dà alla decisione del cliente un peso maggiore. Scelta la soluzione da prototipare, restano due giorni per creare lo storyboard, i dialoghi, registrare e produrre un video per testare le ipotesi circa l’idea sviluppata.

Si doveva anche creare una finta campagna di annunci che rimandavano ad una landing page dove completare il percorso.

 

Il venerdì è il momento di testare il video realizzato con cinque professionisti senior delle Risorse Umane. I risultati sono positivi, anche se emergono alcuni problemi, tutti facilmente risolvibili.

Grazie al metodo Sprint, la campagna non solo era stata realizzata attraverso una reale collaborazione tra l’agenzia e il cliente, ma aveva dato anche la prova che avrebbe funzionato bene.

Tutto nel tempo che solitamente serve per fissare un incontro.

 

Puoi vedere il video della campagna cliccando su questo link.

 

Per supportare il video, è stata creata una campagna email, campagne di advertising su Twitter e LinkedIn e contenuti editoriali per le pubblicazioni specializzate in Risorse Umane.

La campagna è partita quattro settimane dopo la fine dello Sprint, e ha generato contatti di persone che erano interessate ad approfondire la ricerca di informazioni sul prodotto dopo aver visto il video.

L’efficacia del metodo Sprint ha inoltre portato l’azienda ad adottarlo internamente: il team Marketing usa gli Sprint per pianificare campagne ed eventi.

 

 

Hai ancora qualche dubbio sulle possibilità di adottare il metodo Sprint nella tua azienda?

Scrivimi pure, ne parleremo insieme.

 

Gennaro Polito

Topics: User Experience

Gennaro Polito

Scritto da Gennaro Polito

Laureato in Ingegneria Gestionale con una tesi sul ruolo del crowdfunding come modalità di validazione di mercato e supporto alle startup, e spinto da una forte passione per l’innovazione e i modelli di business digitali, è Project Manager di Guanxi e supporta i clienti ad affrontare il percorso di Digital Transformation.

Potrebbe interessarti: