di Dimitri Favre

Finalmente, abbiamo l’agognato budget di progetto. Un piccolo tesoretto in attesa di essere speso in attività che migliorino in modo sensibile il nostro portfolio prodotti. Potrebbe essere un prodotto nuovo, oppure la tanto agognata evoluzione di un prodotto che da un po’ di tempo aveva bisogno di una ventata di aria fresca.

In un mondo VUCA (in italiano sarebbe VICA, ma può prestarsi ad ambigui difetti di pronuncia), che evolve nella direzione dell’agilità, le persone hanno bisogno di certezze. E va bene che rispondere al cambiamento è più che seguire un piano, ma alla fine, e ce lo dice il Manifesto per lo sviluppo agile del software, avere un piano non è esattamente indesiderabile. E per redigere un piano dobbiamo sapere cosa fare, giusto?

Qualcuno la chiama preparation, qualcuno la chiama requisitazione. Qualunque sia l’etichetta che avete deciso di dargli, a un certo punto un manipolo di avventurieri si riunisce per decidere il da farsi. Sessioni di envisioning, user story mapping, impact mapping come se non ci fosse un domani e pareti piene di post-it, a testimoniare il duro lavoro svolto.

Ovviamente non possono mancare canvas di vario genere che fanno mostra di sé, a metà strada tra la natura morta e l’arte astratta, sulle pareti di una sala riunioni che è stata adibita a campo base del team esteso. E infine, esposta dietro a un vetro blindato come la Gioconda al Louvre, c’è lei: la Vision. Non passa inosservata neanche al più distratto dei passanti, con il suo inglese maccheronico a riempire gli spazi bianchi dell’elevator pitch template (perché diciamocelo, certi template in italiano non si possono ascoltare). 

Donne e uomini del business, sviluppatori, designer, facilitati dall’immancabile coach agile (#agiailcocc) si rinchiudono nel loro accampamento e dopo qualche giorno escono come cardinali dal concistoro: habemus backlog.

Il problema del backlog

Non ce la possiamo fare. Siamo ancora succubi al concetto dello scope definito. Hai voglia a fare l’aggile, con più g di @agilegigi. Hai voglia a dire che tempo e risorse sono fissi e lo scope è stimato. Lo scope parte sempre con l’idea che quello è e quello si deve fare. Al più ci saranno cose nuove da aggiungere.

In realtà, il problema non è tanto nello scope fisso, è’ nello scope, per come è definito. Lasciando un attimo da parte la definizione tatutologica della Guida a Scrum (un backlog formato da elementi del backlog, e grazie tante), il backlog quadratico medio di un team Scrum contiene, essenzialmente, user stories. A seconda della vostra cultura aziendale, potreste chiamarle Epiche, Features, o anche un più volgare Requisiti.

“Cosa c’è in un nome? Ciò che noi chiamiamo con il nome di storia utente, anche se lo chiamassimo con un altro nome, serberebbe pur sempre lo stesso dolce profumo. Di funzionalità”. Il Bardo Immortale (al secolo, William Shakespeare) vorrà perdonare l’abuso che ho fatto della sua celeberrima citazione. Quale che sia il nome che date agli oggetti del backlog, questi descrivono funzionalità. In altre parole, descrivono lo spazio della soluzione.

Qualcuno dice che in un team agile il product backlog è il piano, e mi sento di condividere questo punto di vista. Ma lo sponsor quadratico medio non capisce questo modo di esprimere un piano. Tutto sommato è comprensibile, considerato che si è abituato a diagrammi temporali, a vedere il tempo che scorre sull’asse delle ascisse, da sinistra verso destra, come in un qualunque diagramma di Gantt.

La roadmap

La migliore sintesi temporale che possiamo fare è una bella roadmap. Cos’è una roadmap? Senza avere l’ambizione di essere formali, possiamo dire che una roadmap rappresenta, spesso in modo visuale, in quale release ipotizziamo di rilasciare le funzionalità emerse durante la preparation.

Forse non ve ne siete accorti: ho scritto “in quale release”, non “quando”. In effetti, nel tentativo di rispettare il principio indissolubile che, dovendo abbracciare il cambiamento, il piano è un esercizio inutile, le roadmap agili tipicamente non hanno una scala temporale. Il tempo si misura in release. Quanto dura una release? Una release dura una release. E ogni release dura il tempo necessario a realizzare la release.

Per un certo periodo della mia vita ho anche compreso, e forse condiviso, il ragionamento che ne sta alla base. L’elenco di funzionalità incluse in ogni release risponde alla domanda: cosa rende ogni release consistente e ragionevolmente di valore da poter essere considerata per il rilascio in produzione?

Un problema spaziale

Ogni volta che scriviamo una funzionalità da implementare una esperienza utente muore, mettiamo una pietra tombale sullo spazio del problema e entriamo a piedi pari nello spazio della soluzione.

Lo spazio del problema è il grande assente dal backlog, e dalle roadmap. Il nome non è neanche dei migliori. Forse lo si dovrebbe chiamare più correttamente spazio dei bisogni, o addirittura spazio dei desideri. O ancora meglio, lo spazio del cliente.

Nello spazio del cliente si descrivono i suoi bisogni insoddisfatti e i suoi desideri non ancora esauditi. Durante le sessioni di envisioning, spesso si fanno workshop mirati a definire quali siano, questi bisogni e questi sogni, a volte partendo da informazioni più circostanziate, come una ricerca di mercato o una serie di interviste a utenti veri.

Indipendentemente dal percorso seguito, a un certo punto avremo individuato chi è il nostro utente target e di che cosa ha bisogno. Ragionevole pensare che giunti a questo punto, il passo successivo sia quello di entrare nello spazio della soluzione. Infatti è quello che normalmente accade. Si esplora, in modo più o meno esteso, tutto lo spazio del cliente per trovare tutte le soluzioni, che poi gergalmente chiamiamo funzionalità, o storie utente.

A differenza del classico documento di specifica dei requisiti, ci si limita a stare a un livello alto, a scrivere poco più di un titolo, magari un piccolo sketch di interfaccia utente. Perché non vogliamo sprecare le nostre energie andando a dettagliare troppo qualcosa che poi magari non si implementerà mai.

Tutto giusto, tutto sbagliato. Uno degli insegnamenti dell’approccio Lean Startup è che la prima, grande assunzione che ogni prodotto dovrebbe validare è che si stia risolvendo il problema giusto. Insomma, è un problema dello spazio che osserviamo. In altre parole, è un problema spaziale (ed è anche bello grande).

Assunzioni, ovvero ipotesi non validate

Lo sviluppo di ogni prodotto è basato su una quantità pressoché illimitata di ipotesi. Ipotizziamo che il problema da risolvere sia quello giusto, e poi assumiamo che la soluzione immaginata sia quella giusta, ci convinciamo di saperla implementare, e magari anche di riuscire a farlo nel rispetto di vincoli di soldi e di tempo.

Ognuna di queste è una assunzione, ovvero una ipotesi non validata. Solo che nel momento in cui la scriviamo su un post-it (e poi su Jira, o su Excel), ci dimentichiamo che era solo un’ipotesi. Diventa un fatto.

Per ricordarci che bisogno e soluzione sono mere assunzioni, potremmo adottare un lessico di questo tipo:

Assumiamo che implementando <funzionalità>

Soddisferemo il bisogno <bisogno/desiderio> dell’utente <utente/persona>

In questo modo, qualunque elemento del backlog ci ricorderà che non abbiamo certezza né del problema, né della soluzione.

Riconciliare gli obiettivi di business

L’altra dimensione che sparisce completamente dalla vista del team che implementerà le funzionalità del backlog è come, una volta realizzata e rilasciata in produzione, questa contribuisca al raggiungimento degli obiettivi di business. Alla fin fine, per il team di sviluppo questo problema è già stato affrontato, e brillantemente risolto, da quel semidio caduto sulla terra che risponde al nome di Product Owner.

Per evitare questa disconnessione, ci sono un paio di strumenti che un buon team di prodotto dovrebbe sempre utilizzare. La GO (Goal Oriented) product roadmap di Roman Pichler e Impact Mapping di Gojko Adzic.

Attraverso una GO roadmap, ogni release viene associata a un obiettivo di business e a metriche ben definite. Il template suggerisce l’outcome che una sessione dedicata alla scrittura di una roadmap dovrebbe avere. L’outcome guida il lavoro, e trovo pregevole che Pichler abbia esplicitato in modo così chiaro obiettivo di business e le metriche per verificare se sia stato raggiunto o meno.

Impact mapping è una tecnica di facilitazione per supportare la pianificazione strategica. Come si vede nell’immagine seguente, si parte dal perché, o in altre parole dall’obiettivo. Nella mappa, appaiono gli attori del sistema (non solo gli utenti), ma anziché ragionare in termini di bisogni, si ragiona più sull’impatto, e cioè sul cambiamento di comportamento che vogliamo generare per ottenere gli obiettivi definiti nel why.

Il cosa (what) dell’ultima colonna è, ancora una volta, un insieme di funzionalità. Letta da destra verso sinistra, la mappa ci dice che la funzionalità (what) genererà il cambiamento (how) della persona (who) per raggiungere l’obiettivo (why). In aggiunta, e in modo simile a quanto definito nella GO product roadmap, all’obiettivo vengono associati degli elementi di misura per poterne determinare il raggiungimento. A ogni percorso della mappa, inoltre, viene indicato in modo quantitativo il contributo che quel percorso porta al raggiungimento dell’obiettivo.

Ancora una volta, una volta completato il lavoro, avremo storie che nasconderanno le ipotesi fatte durante la costruzione della roadmap o della mappa di impatto, e in assenza di una evidente incertezza, diventeranno fatti.

Per ricordarci che soluzione e obiettivo di business sono collegati in via del tutto ipotetica, potremmo adottare un lessico di questo tipo:

Assumiamo che implementando <funzionalità>

Raggiungeremo <obiettivo di business> entro <data>

Assumptions stories

Mettendo insieme i due template, otteniamo quella che io chiamo una assumption story. Contiene sostanzialmente tutti gli elementi di base di una user story (per chi, valore e funzionalità) e li collega agli obiettivi di business, in questo modo:

Assumiamo che implementando <funzionalità>

Soddisfaremo il bisogno <bisogno/desiderio> dell’utente <utente/persona>

E raggiungeremo <obiettivo di business> entro <data>

Troppa attenzione alle funzionalità

Indipendentemente dal template adottato e dalla specifica tecnica di facilitazione e descrizione del backlog, le nostre roadmap sono ancora troppo piene di funzionalità. Ricordiamoci che la prima ipotesi da validare è che stiamo risolvendo il problema giusto.

Riutilizzando il formato delle assumption stories, questa ipotesi potrebbe essere dichiarata come segue:

Assumiamo che soddisfacendo il bisogno <bisogno/desiderio> dell’utente <utente/persona>

raggiungeremo <obiettivo di business> entro <data>

Questa potrebbe essere la base di partenza della costruzione di un nuovo tipo di roadmap, che anziché concentrarsi su cosa verrà realizzato, si focalizza su quali problemi verranno risolti.

Una roadmap needs-driven

Una roadmap needs-driven è un piano allo sviluppo di prodotto che lavora sullo spazio del cliente. Facciamo un esempio, Ipotizziamo che lo sviluppo riguardi un app bancaria su dispositivo mobile e che il nostro obiettivo di business sia di aumentare il numero di utenti su dispositivi mobili del 10% in tre mesi.

Una user story potrebbe essere scritta così:

In qualità di cliente mobile della banca

Voglio poter fare un bonifico

Al fine di trasferire i soldi su un altro conto corrente bancario

L’ipotesi sottostante è che il bisogno dell’utente sia quello di poter trasferire soldi su un altro conto corrente bancario, e che rendere disponibile un bonifico in app sia la soluzione da implementare. Aggiungiamo una seconda storia:

In qualità di cliente mobile della banca

Voglio poter pagare un acquisto online con PayPal

Al fine di effettuare transazioni online senza comunicare il numero di carta di credito

Cosa differenzia le due storie? Quale dovremo fare per prima? Quale produce maggior valore? A questo livello, non abbiamo più nessuna informazione su questo punto. E quale delle due garantisce più facilmente il raggiungimento dell’obiettivo di business? A questo punto dovrebbe essere chiaro come il tanto usato formato delle user stories sia insufficiente a fornire queste risposte.

Seguendo i template precedentemente indicati potremmo scrivere:

Assumiamo che soddisfacendo il bisogno di trasferire soldi a un altro conto corrente

Raggiungeremo un aumento del 10% di utenti del servizio bancario su dispositivi mobili in tre mesi

In realtà, realisticamente, la sola presenza di questa funzionalità potrebbe non garantire il risultato desiderato, e quindi la nostra formulazione più verosimilmente sarà:

Assumiamo che soddisfacendo il bisogno di trasferire soldi a un altro conto corrente

Raggiungeremo un aumento del 2% di utenti del servizio bancario su dispositivi mobili in tre mesi

La seconda storia potrebbe essere riscritta così:

Assumiamo che soddisfacendo il bisogno di effettuare pagamenti online senza esporre la carta di credito

Raggiungeremo un aumento del 7% di utenti del servizio bancario su dispositivi mobili in tre mesi

In sostanza, una roadmap basata sui bisogni indicherà, per ogni release, non tanto la funzionalità da implementare, ma il bisogno che si intende soddisfare e come questo è collegato all’obiettivo di business della release.

Il primo vantaggio di questo tipo di approccio è che, anche senza entrare nel merito di come verrà risolto il problema, abbiamo a disposizione tutti gli elementi necessari a definire le priorità del backlog e di conseguenza della roadmap. 

Il secondo vantaggio è la flessibilità. Data l’esistenza di vincoli temporali ed economici, focalizzarsi sui bisogni rende più flessibile lo scope, e abilita il defer commitment. Decidere la soluzione in fase di preparation è quanto meno prematuro. Il livello di conoscenza è bassissimo, e non siamo ancora neanche sicuri che stiamo risolvendo il problema giusto. 

Il terzo vantaggio è quello di abilitare l’empowerment e la self-organization del team. Fintanto che nella roadmap è presente il bisogno e non la funzionalità da implementare, il team è aperto a più di un’opzione, tra le quali, in accordo con il product team, potrà selezionare quella più rispettosa dei vincoli di tempo e di soldi.

Il quarto vantaggio è che il soddisfacimento di un bisogno si collega in modo più naturale e diretto agli obiettivi di business (la funzionalità lo fa in modo indiretto, e per farlo deve passare dal bisogno). Quando si ragiona su questo aspetto, diventa molto facile (o rendere meno prioritari) elementi del backlog che non hanno nessuna attinenza con l’obiettivo di business. Senza dimenticare, tuttavia, che la prima assunzione da verificare o confutare è che si stia risolvendo il problema giusto. Ma questa è un’altra storia.

L’ultimo, piccolissimo, vantaggio è che nel nostro backlog non avremo più etichette diverse a seconda della dimensione: avremo solo bisogni da soddisfare (e da raffinare).

Conclusioni

Avere un piano è una necessità organizzativa alla quale nessun team di prodotto, neanche un team agile, può sottrarsi. Va bene abbracciare il cambiamento, ma se il mondo non cambia, che facciamo, abbracciamo gli alberi?

Il backlog è una forma di piano, ma una roadmap comunica in modo più efficace. Possiamo costruire la roadmap scrivendo funzionalità come se non ci fosse un domani, perché tanto prima o poi lo dovremo fare. Oppure, possiamo provare a concentrarci un po’ di più sui bisogni del nostro utente e costruire un piano che definisca, release per release, quali bisogni andremo a soddisfare e quali desideri esaudire.

Non dobbiamo mai dimenticare che siamo sempre nel mondo delle ipotesi. Un modo per farlo è l’adozione di un formato come quello delle assumption stories, che mette in chiaro che tutto ciò che scriviamo deve essere validato o confutato. Perché alla fine scrivere software è un esperimento.

Se siete come il Tenente Colonnello Hannibal Smith e vi piacciono i piani ben riusciti, non potete non fare una roadmap. Magari, la prossima che farete sarà più focalizzata sui bisogni e sugli obiettivi di business, e un po’ meno sulle funzionalità.