di Tiziano Interlandi

Quest’anno io e la mia compagna abbiamo deciso di fare il cammino di San Francesco, un cammino che prevede 250 km a piedi, un dislivello positivo di 7400 metri e negativo di 8300 metri con uno zaino in spalla di circa 10 kg.

Premetto che non sono cattolico o cristiano, non seguo nessuna religione. Mi definisco agnostico. Non seguo nessuna religione ma ho una mia forma di spiritualità. 

Ma che c’entra con l’Agile? Diciamo che ho avuto modo e tempo di pensare, ed era uno dei motivi che mi ha spinto a fare questi 12 giorni a piedi tra Toscana ed Umbria. 

Il dolore alle spalle dovuto alla scelta errata dello zaino ed il costante dolore dei piedi dato dalle condizioni diversificate del terreno ed i 37 gradi perenni mi hanno fatto fare delle analogie con le Roadmap. 

Lungo il percorso abbiamo conosciuto diversi pellegrini, chi più organizzato, chi meno e chi assolutamente no. Io facevo parte della prima categoria (non è necessariamente la categoria migliore il “super-organizzatore”).

La cosa interessante è che tutte e tre le tipologie di pellegrino hanno raggiunto la meta (Assisi) con pochissimo scarto temporale.

Mi sono domandato a lungo come mai e queste sono le mie considerazioni sulle Roadmap e di come sia complesso realizzarle. 

Anche qui una premessa: tutti sono capaci di creare una roadmap che non verrà rispettata. Non penso servano particolari skills. Ma allora cosa ci permette di crearne di attendibili? Quali strumenti abbiamo e quali considerazioni possiamo fare ? Ma prima di tutto: cosa è una roadmap?

Una roadmap è un insieme di passi che ci portano progressivamente e incrementalmente ad un obbiettivo che ci siamo preposti.  Una roadmap non è fissa, tiene conto delle dipendenze ma cerca in tutti i modi di disaccoppiarsi da esse. L’adattività e imparare sono più importanti della rigidità.

I gantt al contrario sono rigidi e calcolano minuziosamente ogni micro attività finendo sempre per non essere veritieri e facendo perdere l’obbiettivo finale. Qui la rigidità è il fondamento.

Abbiamo realizzato la roadmap del cammino che porta da La Verna a Perugia via Assisi in circa due giorni, avevamo qualche contraints (dati da noi stessi):

Non volevamo soggiornare nelle strutture da pellegrini fornite dalle comunità francescana (non per particolari pensieri socio-religio-politici, ma perché volevamo anche stare un po’ per i fatti nostri).

Volevamo vedere un po’ meglio qualche cittadina, ma non era lo scopo principale

Primo passo: informarsi

Ma cosa è il Cammino di San Francesco? Per fortuna esistono diverse risorse e libri. Optiamo per il sito, completo ed ufficiale. Ci sono diversi modi per raggiungere Assisi. Scegliamo il cammino da Nord: sette tappe con una variante per Perugia. Scopro per caso che esistono delle “Credenziali del Pellegrino” in stile Cammino di Santiago. Ad ogni tappa completata un timbro (particolare da non considerare secondario e che affronterò dopo). Inoltre sono importanti per essere identificati come pellegrini e quindi accettati nelle varie strutture con sconti. Le strutture in questione, per capirci, sono quelle nelle quali non vogliamo pernottare (gestite dalla comunità francescana).

Secondo passo: capire la nostra capacità di cammino

La mia compagna è da me nominata la “Gazzella di Gaggiano”, ingegnere come me ed alpinista. Cammina alla grande ed ha un passo molto veloce. Io sono cresciuto facendo trekking con mio zio in montagna e sono un pugile e non uno scalatore, sono più vicino ad un mulo piuttosto che ad una gazzella. 

Una cosa ci accomuna: moriamo su di un fianco piuttosto che non concludere un percorso.

Detto questo un cammino di questo tipo è molto diverso dal trekking di montagna. A meno che uno non faccia una serie di rifugi uno dietro l’altro (ad esempio il giro del Monte Bianco – 10.000 metri di dislivello e circa 180 Km – solo pernottamento in tenda o rifugio), solitamente si va in giornata, sparata verso la cima con dislivello importante per poi scendere. E’ come comparare i 100 metri con la maratona, due diversi modi con diverse difficoltà. 

Il primo giorno abbiamo capito questa differenza, ma il piano era già stato fatto.

Ma allora saremmo riusciti a fare tappe da 38 Km con 1800 metri di dislivello? Abbiamo deciso di no in quanto avremmo vinto la battaglia ma non la guerra. Camminare tutti i giorni con questi ritmi richiede di fare considerazioni diverse rispetto alla tappa singola.

La nostra capacità di cammino al momento di strutturare le tappe era una sicura incognita. Le condizioni meteo non erano chiare in quanto erano previsioni a 3 settimane. Camminare in mezzo ad un bosco durante un temporale non è bellissimo e neanche fare 30 Km senza ombra a 37 gradi. Insomma molte incognite. 

Terzo passo: come suddividere il cammino?

La guida diceva molto chiaramente in alcuni casi: meglio suddividere la tappa. Si parla di tappe impegnative da circa 38 km l’una. Ma la domanda vera è: quanti sono 38 Km? No sinceramente, riuscite ad immaginarli se non li avete mai fatti? La presenza di pendenze importanti complicava il tutto, 1 Km in piano non è uguale ad 1 Km con forte pendenza (fatica) o forte discesa (dolori a caviglie e schiena). Abbiamo optato per fare mediamente 22 Km a tappa, sperando di averci preso.

Le tappe sono passate da 8 a 10 per andare incontro a questo “medione”, a cui aggiungiamo un giorno per arrivare alla partenza, un giorno per visitare bene Gubbio ed un giorno a Perugia dalla quale avremmo preso il treno di ritorno.

Abbiamo optato per arrivare e ritornare in treno, bloccando le date di partenza e ritorno. Abbiamo prenotato le strutture divise per tappa. Praticamente abbiamo blindato il tutto. 

Quarto passo: quali i rischi?

In questo processo di formulazione mentale è inevitabile farsi trascinare dall’eventualità che qualcosa possa andare storto. Per noi è normale farsi delle domande quando dobbiamo arrivare ad un appuntamento in tempo, ad esempio se il treno sarà in ritardo o ci sarà la tangenziale bloccata dal traffico. Allo stesso modo interessante vedere come queste domande non ce le facciamo quando siamo di fronte a formulare un’ipotesi di roadmap con complessità molto più elevate rispetto ad un treno in ritardo.

Nel nostro caso ci siamo domandati: 

E se uno dei due non fosse riuscito a concludere una tappa

E se arrivati ad un struttura questa non avesse avuto la prenotazione

E se si fosse rotto lo zaino

E se si fossero rotte le scarpe

E se avesse piovuto parecchio

E se avesse fatto un caldo dell’inferno

Interessante vedere come sono cambiati durante il cammino, ovvero la realtà dei fatti:

Lo zaino pesa troppo, e se mi faccio male veramente alle spalle?

Cosa fare in caso di insolazione?

Se mi si rompono le scarpe dove posso ricomprarle (siamo spesso nel nulla)?

Insomma, cercare predittività in questa fase sa più di arroganza invece che saggezza.

Agile cerca di abbassare costantemente i rischi a differenza di waterfall che li amplifica con il passare del tempo.

Come è andata veramente?

Diciamo una fatica immane ma abbiamo fatto tutto. 

Non abbiamo mai preso temporali, ma bensì ci sono stati 35 gradi in media a volte su tratti asfaltati. Il numero di vesciche è stato quindi importante. Abbiamo dovuto imparare a trattare le vesciche nel modo corretto per proseguire.  Ci sono stati momenti in cui pensavamo di svenire dal caldo, pressati da ore di cammino senza ombra. Il vero e serio problema è stata l’acqua: poca sul percorso, siamo stati costretti a portarcene molta, aumentando quindi il peso dello zaino.

Parlando con altri pellegrini abbiamo capito che a parte una serie di rischi palesemente validi per tutti (ad esempio il meteo), ognuno però aveva una diversa paura collegata. Quando ci domandiamo la presenza o meno di un rischio in realtà ci stiamo chiedendo come risponderemo al rischio stesso. Ad esempio davanti ad un temporale potremmo reagire in modi completamente diversi, soprattutto in relazione a quanto siamo esperti di temporali estivi e dove si svolgono. 

Il concetto di usura è stato predominante: anche la più piccola cosa come lo sfregamento dello zaino, se ripetuto per km può provocare un infortunio tale da interrompere il cammino. Il tempo di effettivo recupero è molto scarso (cammini 10 ore e poi il letto del B&B non ti fa dormire!).

Cosa ha contato veramente?

Per me anche saltare 1 metro del cammino sarebbe stato come “barare”, forse per rispetto degli altri pellegrini. Altri, in presenza di piccoli infortuni, hanno saltato delle tappe con bus, senza avere nessun rimorso. Per altri l’importante era vedere i luoghi di culto. Ognuno aveva una sua idea di cammino.

Per noi era fare tutto fino a Perugia, vedere qualcosina, ma soprattutto riflettere e staccare la mente. 

Cosa c’entra con Agile?

Se pensate bene a quanto ho scritto prima, spesso ci troviamo a dover ragionare su come arrivare ad un obbiettivo, ed altrettanto spesso andiamo in panico e quindi ci rifugiamo nella nostra zona di comfort.

Per noi la zona di comfort nasconde molte insidie:

Micro management

Pushing

Software pieno di errori per rilasciare in tempo

Sviluppare features non di valore

Insomma tutto quello che cerchiamo di combattere introducendo metodologie agili.

Purtroppo (o per fortuna) lo sviluppo prodotto non porta con sé le fatiche fisiche di un cammino quindi spesso siamo scollati rispetto all’effettivo impegno necessario per portare a termine i nostri obbiettivi. Inoltre camminare da un punto A ad un punto B ha una bassa complessità, di fatto le variabili in gioco sono allenamento, fattori ambientali, logistica. Nello sviluppo prodotto siamo nell’ambito del complesso e quindi molto poco predittivo.

Quando pensiamo ad una roadmap spesso non ci focalizziamo sugli obbiettivi che ci prefiggiamo ma cominciamo a sentire il peso di una data da raggiungere.  

In Agile le date esistono!!

Le date ci aiutano a focalizzarci sulle cose più importanti.

Il concetto di triangolo rovesciato ci aiuta a concentrare la nostra attenzione sul cosa e sul quando. Il quando è un vincolo di business che non può essere tolto.

Ma allora perché ci è tanto difficile fare una roadmap ed evitare che diventi gantt?

Continuiamo con il parallelo del cammino.

L’unico elemento che ci toglie dal contesto totalmente predittivo ad uno complesso è senza dubbio il rischio. In contesti con assenza di rischio riusciamo sempre a concludere quello che avevamo pianificato.

Una corretta gestione dei rischi ha diversi vantaggi:

Permette ai team di ragionare a fondo su ciò che si frappone tra loro ed il raggiungimento di un obbiettivo

Permette al/ai Scrum Master/Coach di aggredire questi rischi tramite azione diretta/indiretta

Permette al management di essere proattivo nell’aiutare i team nella risoluzione di questi rischi

Ma veramente la presenza dei rischi è ciò che ci permette di passare dal complesso al complicato? Ovvero ricondurre la nostra realtà progettuale a qualcosa che richiede molta competenza ma che diventa più predicibile?

Date, date, sempre date!!

Siamo sempre qui a parlare di date. Come già spiegato le date esistono. Punto. Molti team dovrebbero cominciare ad essere più empatici nei confronti di chi deve pensare a come aggredire il mercato o chi cerca di creare un business plan per la crescita aziendale . Si è sempre parlato di scollamento delle persone del business rispetto a chi implementa il prodotto, ma poco del contrario. Oggi molti team passano molto tempo a disquisire sulla data di rilascio invece di lavorare su una roadmap che sia il massimo valore erogabile con il budget assegnato. Diciamo anche che molti team non sanno neanche quale sia il budget.

La guida Scrum dice tra le altre cose per la Sprint Review:

Passare in rassegna come il mercato o il potenziale utilizzo del prodotto possa avere cambiato la cosa di maggior valore da implementare prossimamente; 

Passare in rassegna la timeline, il budget, le funzionalità potenziali e il mercato per i prossimi previsti rilasci di funzionalità o di capacità del prodotto.

In maniera collegiale i partecipanti alla Sprint Review discutono per creare prodotti migliori, ma soprattutto guadagnare.

Grande tabù: le azienda esistono per guadagnare soldi.

Nei libri su Agile poche volte viene nominato, ma ricordiamoci che i nostri stipendi o i nostri investimenti sono legati al fatto che l’azienda abbia un profitto. 

Spesso si dà troppo per scontato che il guadagno di un’azienda sia diretta conseguenza del fatto che si lavori bene. Ogni tanto però ricordiamoci che le aziende sane sono tali perché chi le compone combatte giornalmente affinché questo avvenga, tenendo presente non solo il proprio orticello ma cercando di vedere le cose dalla idea alla vendita. 

In un’ottica di così grande responsabilità per tutti coloro i quali lavorano in una azienda, è necessario che tutti i coinvolti partecipino alla realizzazione di una roadmap.

ROADMAP: prerequisiti

La data o le date vengono fissate dal Business, owner del time-to-market

Il Product Owner ha la libertà di massimizzare il lavoro svolto dal dev team e non è un proxy

Il Management è proattivo per aiutare i team 

Tutti ascoltano i Coach e gli Scrum Master perché qualcosa di giusto lo dicono sempre e sanno cosa serve per far funzionare la “macchina”.

Rispettare ruoli e competenze è fondamentale. I developers devono essere fieri di esserlo e fare al meglio software, architetture e codice. Sono artigiani del software. Il marketing conosce il mercato e cerca di essere sempre un passo avanti. Il segreto è la crossfunzionalità e che ci sia scambio di idee diverse.

La Leadership del Management.

Una rappresentazione grafica di cosa si intende per Leadership a livello di Management è l’organigramma rovesciato. 

Il classico organigramma piramidale spesso viene utilizzato come fine invece che come mezzo. Si dà per scontato che chi sta sopra ne sappia di più di chi sta sotto e che chi sta sotto ha meno potere di chi sta sopra. Questa è una deviazione di quello che l’organigramma dovrebbe rappresentare. Questa deviazione porta sempre alle stesse conclusioni: un’organizzazione gerarchica che non funziona. Gli organigrammi non servono a questo. Per cercare di uscire da questo meccanismo (che va avanti da 100 anni) dovremmo pensare all’organigramma in maniera rovesciata. Se parliamo di Servant Leadership dobbiamo rivedere il concetto di Management, ovvero un Manager che è al servizio degli altri per togliere impedimenti e far progredire l’intera organizzazione. Tutto questo deve avvenire in maniera “ricorsiva” in modo che tutti i livelli possano trarne giovamento. Ogni livello cerca di aiutare gli altri, sia sopra che sotto. Ritornando al concetto di Roadmap e di come possiamo crearla, il Management deve essere al servizio dei team, che sono i veri creatori di valore all’interno delle organizzazioni. Ciò non significa che il management non serva, anzi, ma che dovrebbe passare più tempo ad aiutare piuttosto che cercare di essere allineato (spesso generando effetti più negativi che positivi). Le Roadmap sono create dai team e supportate dal management. 

Ad oggi si sta rivedendo il concetto di Servant Leadership integrandolo con quella di Host Leadership. Dedicheremo articoli futuri in quanto il tema è realmente ampio.

I ruoli nelle Roadmaps

Scrum non ne parla ed in generale dobbiamo fare un mix tra metodologie e correnti per capire ruoli e compiti affinché si arrivi agli obbiettivi prefissati.

L’immagine parla chiaro, abbiamo parlato di Servant Leadership e di team come owner della roadmap, ma più in dettaglio:

I team creano le roadmap su indicazione di persone del Business che conoscono bene il mercato ed il time-to-market. Stimano e si misurano per capire come raggiungere l’obbiettivo in un’ottica di vero Inspect & Adapt.

Sarebbe cosa buona avere le persone del business all’interno dei team per creare una vera crossfunzionalità ed accorciare la filiera il più possibile. 

Il Product Owner è veramente empowered e tutti rispettano a pieno il suo compito. Può fare descoping e passa il proprio tempo a cercare di massimizzare il valore invece di mettere d’accordo i vari attori.

Lo Scrum Master/Coach è nella possibilità di aiutare l’intera organizzazione perché conosce strumenti e tecniche per far si che tutto funzioni. 

Il Dev Team è realmente cross-funzionale.

Gli Stakeholder sono proattivi e partecipano alla costruzione del valore.

Come potete vedere si tratta semplicemente di remare tutti verso la stessa direzione e di applicare bene i ruoli prescritti da Scrum/Agile.

Chi sono gli stakeholders?

Se le persone del business entrano nei team, chi sono allora gli stakeholders?

Domanda lecita, oggi troppo spesso si pensa che il Development Team sia fatto di soli tecnici dimenticando che invece devono farne parte coloro che sviluppano il prodotto, e ciò significa anche scelte di marketing, operations e vendita. 

Ma così gli stakeholders spariscono? No , ogni team deve capire questa linea di confine e soprattutto se portare all’interno qualcuno significhi potenziare la cross-funzionalità invece che minarla.

Oggi dovremmo spostare il pensiero dalla cross-funzionalità in senso stretto (il dev + il tester + il business analist) a value team, ovvero team che cercano di tirare il valore. Il concetto di value team introduce anche il fatto che potenzialmente chi prima era considerato uno stakeholder, oggi è nel dev team. Capire la linea di confine, come detto prima, dipende da team a team e da realtà a realtà. Oggi considerare che “pensare il prodotto” sia fuori da chi lo implementa è un po’ demodè (come vedete sono forte anche in francese). Il consiglio quindi è di limitare fortemente il numero di stakeholder, non tanto evitando di parlarci, ma quanto cercando di portarli nella catena di produzione del valore.

Steps di creazione di una Roadmap

Ma alla fine come si fa una roadmap?Oggi parleremo di una serie di esercizi che ci permettono di aprire la mente in maniera collegiale e di arrivare alla formulazione di un backlog stimato in maniera massiva, dei rischi esistenti e di uno o più MVP di prodotto, fino all’MMP.

Gli step che vi presentiamo sono quelli che noi abbiamo trovato utili, ma ne esistono moltissimi. Non vogliamo essere totalmente esaustivi, vi rimandiamo ai libri in bibliografia per tutti gli approfondimenti del caso.

Prerequisiti

  • La presenza di un facilitatore che conosca bene questi step
  • La presenza di totale cross-funzionalità rispetto al prodotto o progetto che vogliamo affrontare (invitate rappresentanti di tutti i reparti coinvolti)
  • Un tempo definito: consigliamo almeno 2 giorni
  • Un luogo isolato e che permetta di lavorare bene con tavoli e pareti da utilizzare
  • Lo sponsor di progetto
  • Consigliamo vivamente la presenza fisica rispetto a quella virtuale almeno per queste giornate. Stanca molto stare 8 ore in cuffia o cercando di capire un qualcosa che nasce per essere “dal vivo”. Eventuali trasferte in tal senso saranno soldi spesi bene, soprattutto in relazione al vantaggio che porta operare in questa maniera.
  • Preparate la stanza in anticipo per evitare sprechi di tempo durante le giornate

Step 1 : perché siamo qui?

Lo sponsor introduce brevemente le motivazioni di progetto e prodotto. Sembra una banalità, ma spesso non si sa perché si sta implementando una cosa, è molto frustrante e non ci permette di fare le scelte corrette. La presenza di uno sponsor è sicuramente un punto che permette una maggior probabilità di riuscita della nostra iniziativa.

Tempo medio 15 min.

Step 2: Vision Board

Ma per chi facciamo questo prodotto o progetto? Quali sono i bisogni che effettivamente dobbiamo soddisfare? Quali metriche possiamo mettere in piedi per vedere l’avanzamento e capire se le nostre affermazioni sono corrette?

La Vision Board è un ottimo template che ci aiuta a capire meglio tutti questi punti. La vision board è un artefatto vivo e può cambiare nel tempo, rimane però un qualcosa che ci permette sempre di ritornare sui razionali iniziali e quindi stare ancorati all’essenza del prodotto che stiamo facendo evolvere.

Modalità:

Il facilitatore pone le domande del template al team. Il team scriverà su post-it diversi il proprio punto di vista. I post-it vengono applicati sulla board, clusterizzando dove server. A questo punto parte la discussione e si diverge per poi convergere insieme.

Particolare attenzione alle Expectations: qui devono esserci reali “numeri” in modo da capire on maniera oggettiva se stiamo procedendo correttamente. Le eventuali barriere emerse possono essere inserite nella tabella dei rischi che vedremo più avanti.

Tempo medio 1h

Step 3: Rischi

Durante tutto l’evento in realtà continueremo ad alimentare la board dei rischi. Vale però la pena soffermarsi su far capire quanto sia importante questo step e di come evolva nel tempo.

Modalità:

chiedere al team di scrivere su post-it eventuali rischi che possono identificare. Clusterizzarli ed inserirli in todo nella board.

Chiedere al team per ognuno se sia possibile:

  • Mitigare il rischio: azioni che possono abbassare l’impatto
  • Accettare il rischio: reputiamo la possibilità che avventa, ma riteniamo che sia di basso impatto e tale che probabilmente evitarlo costa più che subirlo
  • Owned: qualcuno ha in carico l’analisi o risoluzione del rischio.
  • Risolto: rischio azzerato

Potreste non essere in grado di indirizzare tutto, è normale. Ricordate che la board dei rischi è un artefatto vivo e come tale evolve. La board dei rischi è da considerarsi a tutti gli effetti come un backlog di attività che il team deve affrontare.

Tempo medio 30 min.

Step 3: What is In – What is Out

Uno step simile alla board dei rischi è il “cosa è nel perimetro, cosa non lo è”. Spesso ci troviamo di fronte ad iniziative il cui perimetro cresce costantemente. Come rimanere focalizzati su quello che effettivamente ci serve?

Modalità:

Sempre su post-it clusterizzati chiedete al team cosa secondo loro sia nell’iniziativa e cosa no. Porre sulla board e discuterne.

Scoprirete quanto questa fase crei molta consapevolezza e focalizzazione.

Anche questo step evolve durante tutte le giornate. Alimentatelo costantemente come i rischi.

Tempo medio 30 min.

Step 4 : Stakeholder Map

Chi sono i nostri stakeholder? Se dovessimo effettivamente applicare la definizione di Stakeholder avremmo

“Ciascuno dei soggetti direttamente o indirettamente coinvolti in un progetto o nell’attività di un’azienda.” In realtà questa definizione non ci piace. Sembra poco orientata al valore, quindi a noi piace “Chiunque possa tratte vantaggi diretti o indiretti dal nostro operato”, che in questo caso è una iniziativa progettuale o di prodotto.

Sicuramente una definizione un po’ troppo ampia, ed è per questo che questo esercizio ci aiuta a capire come e in che modo sono impattati gli altri dall’iniziativa e come possiamo trasformare questo “scenario” in modo che l’iniziativa ne tragga il maggior vantaggio possibile e quindi anche gli Stakeholder stessi.

Costruite una board come in figura e chiedete al team di scrivere il nome, il tipo, l’ufficio dello Stakeholder e di posizionarlo sulla board in relazione all’interesse e potere decisionale. Clusterizzate. Discutete.

Questa board offre la fotografia di chi interagisce con noi. Ma cosa possiamo fare? Come vedete ogni quadrante identifica il comportamento. Sicuramente possiamo cercare di spostare gli afferente al primo quadrante cercando di renderli promoters.

Come riuscire a farlo dipende dalle singole organizzazioni.

Anche questo è un artefatto vivo ed evolve.

NOTE

Cerchiamo di non concentrarci sul cliente in questo esercizio, per lui esistono strumenti che analizzeremo in seguito.

Tempo medio 45 min.

Step 5: Personas & Empathy Map

Chi sono i nostri clienti, utenti? L’esercizio delle personas è molto importante. Il consiglio è di chiedere alle persone capaci di identificarli ad arrivare già con un premasticato. La costruzione delle Personas richiede analisi di mercato, studi ecc. Cerchiamo di partire da una base già solida per farla evolvere con i contributi della stanza.

Partite da uno dei tanti template disponibili e cercate di comprendere a pieno i vostri clienti/utenti anche con l’utilizzo del template di Empathy Map. Il risultato è una comprensione maggiore dei nostri clienti/utenti in modo da massimizzare il valore nei loro confronti.

Modalità

Arrivate con un pre masticato e generate ulteriori personas solo se emergono. Fateli raccontare dalla persona che meglio li conosce. Discutetene ed eventualmente correggete ed arricchite.

Entrate nel vivo dello studio con l’Empathy Map: quali sono aspirazioni e malesseri delle nostre personas? Cosa sentono? Cosa vedono?

Tempo medio 1h.

Step 6 e 7: Customer Journey e User Story Mapping

Ora cerchiamo di capire come interagiscono le personas con le features che abbiamo pensato in fase  di Vision. Questi steps sono i più sostanziosi in termini di tempo, impegno e concentrazione.

Cerchiamo di ragionare sulle nostre features e proviamo a dividerle e posizionarle temporalmente in orizzontale. Poniamoci poi la domanda: come interagiscono le personas con queste features?

In questa fase possiamo anche inserire delle “personas particolari”, ovvero i sistemi: in aziende grandi è normale che una nuova funzionalità o prodotto usufruisca di qualcosa che già esiste. Questa considerazione però porta con sé il problema delle dipendenze: chi gestisce questo sistema? Ha bisogno di modifiche? Saremo autonomi?

Questi passaggi portano anche alla suddivisione delle features in attività più piccole. Passeremo da Features ad Epiche a storie “a grana grossa” fino a storie stimabili (User Story Mapping).

E’ importante ricordare che questa attività non genererà un backlog immutabile, ma un backlog di partenza che potrà solo evolvere. La parte fondamentale è ragionare insieme sul prodotto e far emergere dipendenze e rischi.

Alla fine avremo un backlog stimabile massivamente,dipendenze e rischi aggiornati.

In questa fase è importantissimo l’apporto del business e del futuro product owner in modo tale da far capire bene alla stanza le necessità e le peculiarità del prodotto.

Attenzione a non focalizzarsi troppo su micro attività e mantenere la focalizzazione sulle personas e su come utilizzeranno il nostro prodotto. E’ normale parlare anche di tecnologia e soprattutto dei vincoli collegati, ma lasciate questi verticali ai normali refinement di team.

Tempo medio: 3h

Step 8: Facciamo un check di tutto quello che abbiamo fatto

A questo punto è il caso di tirare le fila e riassumere quanto fatto. La tecnica migliore è far raccontare a qualcuno della stanza quanto abbiamo fatto e ripercorrere tutti gli artefatti prodotti, con particolare attenzione al Customer Journey.

Domandatevi: c’è altro? Torna tutto?

Raffinate Customer Journey, dipendenze e rischi.

Step 9: High Level Architecture

E’ buona cosa a questo punto parlare di sistemi.

Cercate di disegnare un diagramma di massima dei sistemi coinvolti e delle loro interazioni. Andate pure nel dettaglio, meglio evidenziare un passaggio in più che dimenticarlo.

Da questo step ci aspettiamo un’architettura del prodotto di massima e le dipendenze legate.

Step 10: Stima Massiva

Pronti per stimare? In questa fase è impossibile avere una stima “secca”. Ricordiamoci che le stime sono sbagliate per definizione, in questa fase lo sono ancora di più. Ma allora perché lo facciamo? Il nostro goal è di ottenere un range di sprints entro i quali siamo sufficientemente sicuri di concludere le attività. Potremmo dire di aver bisogno dai 6 agli 8 Sprints, oppure da 2 a 10. Ovviamente più è ampia questa forchetta e più implicitamente stiamo dicendo di conoscere ben poco quello che andremo a fare.

Come stimare quindi così tante attività in poco tempo?

Posizionate (meglio ricopiare) le attività in uscita dalla user story mapping e mettele in un backlog. Create colonne indicati T-Shirt sizes (XS, S, M, L, XL, XXL e ?).

Scegliete chi dovrà stimare all’interno della stanza, indicativamente chi farà parte del Dev Team o loro rappresentanti.

A turno ogni partecipante avrà due mosse disponibili: muovere un item dal backlog verso una colonna di size oppure prendere un item già con size e muoverlo in un’altra colonna.

Il gioco termina quando tutte le attività del backlog sono ultimate.

Il gioco avviene in silenzio, ma diamo 2 domande in totale a partecipante in modo da dipanare i grossi interrogativi.

Una volta concluso il gioco si chiede alla stanza se vedono grandi discrepanze o anomalie e raffinate.

Tra le colonne abbiamo anche ?, ovvero attività che è veramente impossibile interpretare. Usatelo con cautela.

A questo punto dobbiamo tradurre queste sizes in story points. La stanza potrebbe essere composta da team già rodati oppure da persone che hanno lavorato poco insieme. Chiedete di stimare con il Planning Poker un’ attività in qualsiasi colonna, vi aiuterà a capire come costruire i vari range.

Ipotizziamo di aver stimato un item della colonna M con 5 story points, a questo punto potrete costruire qualcosa di simile:

XS da 1 a 2

S da 2 a 3

M da 3 a 5

L da 5 a 8

XL da 8 a 13

XXL da 13 a 21

? da 40 a 40

Facciamo apposta sbilanciare il ? con 40 sp per porre immediatamente l’attenzione sulla necessità di raffinare al meglio questa attività per ricondurla in una o più attività delle altre colonne.

Ora come step finale sommiamo tutti i i minimi ed i massimi, ottenendo quindi due valori e utilizziamo la velocity di team per capire quanti spints ci serviranno.

Ad esempio: con una velocity di 30 sp a Sprint ed un minimo di 150 sp ed un massimo di 300 sp possiamo dire che siamo confidenti di rilasciare tra il 5 ed il 10 sprint. 5 Sprint di differenza sono troppi? Sicuramente! Ma il business avrà un intervallo per agire sul time to market ed iniziative connesse. Ma la domanda più importante che possiamo fare a questo punto è: cosa possiamo fare in termini di rischi e roadmap per abbassare questa incertezza?

Queste considerazioni non vanno lasciate li a “fermentare”, abbiamo un artefatto da mantenere ed utilizzare per le considerazioni che faremo in futuro. In questo caso ci viene incontro il BurnUp Chart. Ci aspettiamo che la minima e la massima stima convergano nel tempo diminuendo sempre di più l’incertezza. Un comportamento diverso è segnale di forte pericolo per il progetto e le nostre roadmap.

Step 11: Team – come, quando, chi

A questo punto abbiamo abbastanza elementi per provare a creare un o più team cross-funzionali e fare riflessioni su eventuali framework di scaling da adottare. Domandiamoci sempre: abbiamo tutte le competenze per concludere le attività? Ci sono SME da includere?

Step 12: MVP/MMP

Partiamo con una considerazione.

MVP : Minimum Viable Product, ovvero insieme di feature che servono a darci feedback dal mercato/utilizzatori in modo da validare o invalidare le nostre tesi. E’ un percorso di comprensione crescente su quello che è più di valore. Possiamo anche pensare l’ MVP come un modo di abbassare i rischi, ovvero il rischio di dare al pubblico qualcosa che non serva.

MMP: Minimum Marketable Product, ovvero insieme minimo di feature che vogliamo dare al mercato/utilizzatori mantenendo alto il focus su “meno è meglio”. Su 20 feature pensate quante sono quelle veramente importanti per poter uscire sul mercato senza avere il rischio di dare qualcosa di incompleto dal punto di vista dell’utilizzatore?

Possiamo dire che un insieme di MVP danno un MMP, ovvero validiamo costantemente le nostre tesi fino a costruire un pacchetto minimo di funzionalità di alto valore da dare ai nostri clienti.

Riprendiamo il nostro Customer Journey e creiamo diverse Swimlanes secondo gli MVP ipotizzati. Insieme alla stanza spostiamo i vari items sopra e sotto in modo da costruire l’insieme dei nostri MVPs

Aggreghiamo gli MVPS in uno o più MMPs.

Conclusioni

Concludendo

Gli esercizi presentati necessiterebbero di pagine e pagine. Il nostro intendo è stato quello di dare una panoramica sistemica rimandando a numeri futuri tutti gli approfondimenti del caso.

Abbiamo inserito alcuni esempi di esercizi ma ce ne sono per tutti i gusti. La lista presentata rappresenta però un set minimo di passi da fare per arrivare a capire come muoversi all’interno della complessità di un progetto/prodotto.

Una cosa molto importante: alla fine di questo cammino potremmo chiederci se ha senso sviluppare un prodotto, ovvero se ci porterà un guadagno (dove guadagno non è necessariamente economico). Avremo però impiegato poco tempo (e quindi pochi soldi) per capirlo invece di “sbattere contro un muro” dopo mesi di implementazione ed aspettative.