Impact Mapping in pratica

La teoria la conosciamo: Impact Mapping è un potente strumento di pianificazione strategica. Ma cosa significa utilizzarlo nel concreto? Come muovere i primi passi?

Qui ho inserito le slides della mia presentazione all’Italian Agile Days 2019 su come organizzare una sessione di Impact Mapping e come cercare di renderlo uno strumento vivo nella conduzione di progetto.

In lastminute.com sto utilizzando questo strumento per la gestione di un progetto di crescita e ho preso l’occasione per condividere con voi alcune lessons learned. 

Oltre alle slide sto preparando 2 post di approfondimento per trarre il massimo da questo tool. Nel primo si entra nei dettagli di come organizzare una sessione di Impact Mapping mentre nel secondo si parla di utilizzi pratici di questo strumento.

E voi? Avete già avuto l’occasione di metterlo in pratica? Come vi siete trovati? Sarei felice di condividere esperienze a riguardo.

Impact Mapping per la pianificazione strategica

Template di esempio di Impact Map

Di ritorno da un workshop di un giorno con Gojko Adzic ho deciso di raccogliere le idee e gli appunti sull’Impact Mapping, una tecnica di pianificazione strategica che mi sembra allo stesso tempo semplice e molto potente.

Che cos’è una Impact Map?

E’ una mappa mentale che rappresenta il percorso da uno specifico obiettivo di business alle azioni che consentono di raggiungerlo.
E’ una rappresentazione creata in maniera collaborativa dal business e dalla tecnologia ed ha il vantaggio di mostrare anche le assunzioni sottostanti.
Risponde a queste 4 domande fondamentali:

  • perché?
  • chi?
  • come?
  • cosa?

Perché stiamo facendo questo progetto?

Questa parte spiega qual è l’obiettivo che vogliamo raggiungere, aiuta a renderlo esplicito e patrimonio di conoscenza condivisa.
Spesso infatti gli obiettivi di business non sono esplicitamente dichiarati; a volte sono presenti solo nella mente degli stakeholder, a volte hanno una definizione troppo vaga.

Nell’immagine d’esempio l’obiettivo è uno: far crescere l’advertising mobile.

Priorità agli obiettivi, non alle funzionalità!

Se un progetto consente di raggiungere gli obiettivi di business è un successo anche se l’ambito è variato rispetto alla visione iniziale; viceversa se tutte le funzionalità individuate all’inizio vengono portate in produzione senza che l’obiettivo sia raggiunto il progetto è un fallimento.

Non dimentichiamo inoltre un consiglio sempre valido: formulare gli obiettivi in maniera smart (specifici, misurabili, orientati all’azione, realistici e collocati nel tempo).

Chi sono gli attori?

Chi sono i nostri utenti e come sono influenzati dal nostro prodotto?
Di chi vogliamo cambiare il comportamento?
L’Impact Map ci aiuta a focalizzare tutti coloro che influenzano le decisioni di prodotto, gli utenti e le varie tipologie di clienti.
Tiene conto degli attori primari (quelli per cui il prodotto soddisfa un bisogno), gli attori secondari (coloro che forniscono un servizio) e gli attori “fuori scena” che hanno un interesse ma non ricadono nelle due precedenti casistiche (i più rischiosi in termini di pianificazione perché prima o poi si risvegliano).

Nell’esempio riportato sono stati individuati 3 segmenti potenzialmente interessanti: i fan dotati di device mobili, gli organizzatori di concerti e infine agenti e promoter.

Come vogliamo modificare il comportamento degli attori?

Questo passo è il collegamento più importante tra l’obiettivo e il prodotto finale perché mette in relazione l’attore con l’obiettivo.
Definisce come vogliamo cambiare il comportamento degli attori.
Cosa vogliamo che inizino a fare, smettano di fare o facciano in maniera differente?
Gli impatti non sono funzionalità, sono appunto comportamenti.
Dobbiamo individuare quelli che sono più rilevanti per centrare l’obiettivo e – cosa importante – misurarli.

Meglio sottolinearlo: stiamo parlando di cambiamenti nel comportamento delle persone, non a livello dei sistemi!

E’ in relazione agli attori e agli impatti che andremo a definire le nostre priorità, non sulle feature.

Nell’immagine d’esempio sono stati riportati gli impatti che si vuole indurre nei fan: una maggiore frequenza di utilizzo del sito mobile, sessioni più lunghe ed una maggiore esposizione ai banner mobile.

Cosa?

Solo nell’ultimo passaggio parliamo di ambito e funzionalità, non prima.
Andremo a mappare i deliverable rispetto agli obiettivi di business.
L’Impact Map mette tutti i deliverable in relazione con gli impatti da produrre.
Mappare queste relazioni significa portare alla luce le assunzioni che abbiamo fatto.
Gojko sottolinea che questo è il livello meno importante della mappa. Non è necessario infatti che sia fatto tutto dall’inizio alla fine; i deliverable sono opzioni, mano a mano che verranno rilasciati saranno misurati gli impatti e si potrà decidere se proseguire nell’implementazione o dedicarsi ad altri obiettivi.

Ambito di applicazione

Le Impact Map possono essere applicate allo sviluppo di nuovi prodotti, all’evoluzione di prodotti esistenti e alla gestione della roadmap, purché ci sia accordo sul fatto che lo scopo finale è raggiungere l’obiettivo di business, non un set prestabilito di funzionalità.
Se un deliverable non produce cambiamenti pur funzionando correttamente è da considerarsi un fallimento.
L’Impact Map non si presta invece ad essere applicata in progetti di pura maintenance.

Quali vantaggi offre

La progettazione iterativa è spesso carente in termini di big picture.
L’Impact Map colma questa mancanza offrendo un contesto alla progettazione.

Ha il vantaggio di farci mantenere un focus forte e ci aiuta a prioritizzare, facilita la collaborazione e l’interazione oltre a rendere visibili le assunzioni.

E voi l’avete mai utilizzata? In quale contesto?

Se siete alla ricerca di informazioni pratiche la mia presentazione allo IAD 2019 e questo post su come organizzare una sessione di Impact Mapping potrebbero esservi d’aiuto.
Per gli amanti dei podcast parlo di Impact Mapping anche in questa intervista per AgileForItaly.

LeSS (Large-Scale Scrum): 15 domande a Craig Larman

Craig_Larman

Questa settimana ho partecipato ad un Meetup con Craig Larman, uno dei pionieri nell’applicazione di Scrum in contesti allargati.
Larman era a Milano dal 4 al 6 Luglio per il suo corso di Certified LeSS Practitioner.
Durante l’incontro i partecipanti hanno avuto l’occasione di approfondire dubbi e questioni direttamente con l’autore di “Scaling Lean & Agile Development“.
Questa è una sintesi delle domande emerse nel corso della serata.

Cosa significa essere agili?

Significa essere flessibili, adattarsi al cambiamento.
Non a caso quando queste pratiche sono nate erano due le parole in lizza per descrivere il framework: agile e adaptive ed entrambe sottolineano questo concetto.
Diciamo infatti “essere agili” piuttosto che “fare Agile”.
Essere agili significa mettere da parte l’arroganza di conoscere e abbracciare l’umiltà dell’imparare.

Quali sono gli elementi caratteristici di LeSS?

LeSS prevede 3 ruoli: il Product Owner, responsabile di massimizzare il valore prodotto; da 2 a 8 team che hanno il compito di realizzare l’incremento di prodotto potenzialmente rilasciabile e gli Scrum Master ad agevolare il processo (di norma 1 Scrum Master ogni 3 team).
In LeSS esiste un unico Product Backlog per il prodotto.
Per quanto riguarda gli Sprint Backlog invece ogni Team ha il proprio che viene stabilito nel corso dello Sprint Planning.
LeSS prevede gli stessi eventi di Scrum, ma li declina diversamente per la presenza di più team.

Quanti sono i framework LeSS?

Large-Scale Scrum prevede 2 framework: LeSS e LeSS Huge
Il primo si applica a situazioni in cui è presente un Product Owner, 1 product backlog e da 2 a 8 team di sviluppo che lavorano sul medesimo prodotto.
LeSS Huge si applica in contesti ancora più ampi, dove un singolo Product Owner avrebbe difficoltà ad avere una visione complessiva dell’intero prodotto.

Ci sono delle pre-condizioni per adottare LeSS?

LeSS non è un framework che si presta ad essere adottato bottom-up; deve essere introdotto dall’alto, al senior level.
Necessita la presenza di un management evoluto perché richiede un profondo cambiamento del sistema. Stiamo parlando di eliminare tutti i component team, così come i progetti e i programmi.

Può essere utilizzato in realtà multi-site?

LeSS è stato implementato in molte realtà con persone che lavorano su diverse sedi.
Ma c’è un vincolo: all’interno di un singolo team le persone devono essere co-locate, non disperse. I diversi team possono invece essere sparsi su più sedi geografiche.

Come posso convincere il management ad adottare LeSS?

Non puoi convincerli. Non funziona la dinamica di convinzione.
Sono loro che devono arrivare a sentire davvero l’urgenza del cambiamento, perché le dinamiche di resistenza al cambiamento sono molto forti nelle organizzazioni.
L’idea di fondo è che le persone debbano arrivare a fare propria un’idea (own), invece che accoglierla da altri (rent).
Nel momento in cui la convinzione è una dinamica interna solo allora si crea davvero la possibilità per un cambio radicale.
Molte aziende hanno troppi soldi” dice Larman, quindi si possono permettere tante modalità disfunzionali e non hanno questo senso di urgenza. Mettono in atto solo “fake changes”.

Non c’è proprio nulla che posso fare per agevolare questo cambiamento?

Ciò che si può fare è cominciare a creare interesse e curiosità intorno a questo argomento.
Le possibilità sono tante: far circolare dei libri che trattano di LeSS presso persone chiave in azienda, inviare video, trovare degli sponsor interni all’organizzazione, crearsi degli alleati in questo percorso, promuovere eventi e incontri con esperti esterni all’azienda.

Come avviene lo Sprint Planning?

Lo sprint planning è diviso in due parti.

Nella prima parte sono presenti il PO ed i rappresentanti dei diversi team (è bene che ruotino da un planning all’altro).
Questa prima parte dura massimo 2 ore per uno sprint di 2 settimane, ma spesso si conclude in meno di un’ora.
In questa fase il PO presenta le user stories in ordine di priorità, viene definito lo Sprint Goal ed i rappresentanti dei team selezionano le attività sulle quali lavoreranno.

Nella seconda parte sono di fatto i team ad organizzarsi e più tavoli di discussione possono essere portati avanti in parallelo. In questo momento ogni team elabora il proprio piano per produrre l’incremento di prodotto. Il PO può chiarire eventuali dubbi in questo momento.

Come vengono assegnate le user stories ai vari team?

Le user stories non vengono “assegnate”.
In Scrum trattiamo le persone come adulti.
Sono i team ad auto-organizzarsi e a scegliere le storie da realizzare per poter produrre un incremento.

Che cosa si intende per integrazione continua?

Non parlo tanto di continuous integration ma di integrate continuously.
L’integrazione continua non è una questione di strumenti e tool, riguarda il comportamento e la forma mentis degli sviluppatori.

Si basa su 3 pratiche:

  • effettuare check in e check out del codice con cicli il più corti possibile (stiamo parlando di qualche minuto!);
  • evitare l’utilizzo di branches (tutti i team lavorano sul master);
  • utilizzare un sistema di continuous integration sempre attivo e dove i test girano continuamente.

Come è opportuno procedere quando non si hanno le idee chiare su quale architettura adottare?

In questi casi è bene utilizzare un processo di Agile Modeling in cui i diversi team si trovano assieme ed elaborano idee al fine di individuare la migliore soluzione al problema.
Vengono fatti sketches dell’architettura. Si tratta di prendere decisioni partecipate.

In fase di implementazione tuttavia solo uno dei team parte ad abbozzare la soluzione condivisa (è una questione di focus). Può così verificare se si tratta di un’idea valida o se è necessario apportare delle correzioni piuttosto che riconsiderare il tutto.

Le emerging architecture non funzionano bene in contesti large scale.

Ma in pratica per iniziare ad adottare LeSS come è bene partire?

All’inizio è bene evitare di avere un gruppo troppo piccolo (ad esempio 2 soli team) o troppo numeroso. Nel primo caso il test non è rappresentativo, nel secondo il livello di difficoltà è eccessivo.

Partite con questo set:

  • 50 persone circa
  • 1 solo prodotto
  • 1 unica sede
  • per un periodo di 6 mesi

E’ fondamentale costruire un’esperienza di successo, perché il codice funzionante è molto più convincente di qualsiasi power point. In questo modo (e solo in questo) si guadagna credibilità all’interno dell’organizzazione.

Come sono organizzati i team in relazione ai prodotti?

Da questo punto di vista LeSS è perfettamente in linea con Scrum.
Scrum è un modello product-centric.
I team devono essere disaccoppiati dal codice ma in relazione stabile con i prodotti.
Più team lavorano sempre su un determinato prodotto.
Quando l’organizzazione non è strutturata in questo modo non sto adottando un framework Agile, sto semplicemente tentando di migliorare l’efficienza nella gestione dei progetti.

Qual è il ruolo del Product Owner in LeSS?

Il ruolo del Product Owner in LeSS non cambia rispetto a Scrum e ai contesti non scalati.
Il PO è colui che gestisce il prodotto soddisfando i bisogni degli utenti finali, colui che comunica al team gli obiettivi e la vision di alto livello.
Il PO non è un Business Analyst; è un imprenditore, un innovatore, un pensatore a livello sistemico, di fatto un “mini CEO”.
In LeSS è previsto che un Product Owner possa gestire sino a 8 team (con il supporto di alcuni Scrum Master), per un totale di oltre 50 sviluppatori. Questo significa necessariamente adottare un modello di product ownership “diffusa”, dove i membri del team hanno un’elevata conoscenza del dominio e grande maturità professionale.

Quanto è grande un prodotto in LeSS?

La grandezza del prodotto dipende da diversi fattori: il numero di prodotti che un’azienda gestisce e la loro ampiezza.
Per intenderci Microsoft Word è un prodotto, un prodotto ancora più grande è MS Office.
Ad ogni prodotto corrisponde un product backlog e diversi team lavorano continuativamente sul medesimo prodotto.
Più l’azienda segmenta il prodotto e maggiore è la possibilità che diminuisca il valore delle singole user stories lavorate. Sta ottimizzando “localmente”, ma non a livello sistemico.
Per produrre maggior valore è bene avere prodotti di ampio respiro, più grandi e non più piccoli.