Backlog declutter 1: da dove partire per riordinare

Come i Product Owner possono mettere ordine nei requisiti mediante l’utilizzo del metodo KonMari 

Backlog e declutter, un binomio curioso.
Questo post è la trascrizione di un mio intervento allo IAD 2016. Datato sì, ma sempre attuale; soprattutto di questi tempi in cui abbiamo tanto tempo per fare ordine …
Il topic è nato combinando 2 interessi diversi: uno per la product ownership e l’altro per la lettura. 
Sono una lettrice compulsiva e qualche anno fa mi sono imbattuta in un libro curioso – “Il magico potere del riordino” di Marie Kondo – mentre ero alla ricerca di strumenti che semplificassero la mia vita e mi facessero sentire più leggera. 
Ma cosa diavolo c’entra un volume che ti insegna a fare ordine in casa con la gestione del product backlog? C’entra c’entra, più di quel che pensate…

Struttura del backlog

Partiamo dal backlog: è quell’artefatto che raccoglie tutti i requisiti di prodotto ordinati secondo priorità.
Diamo ora un’occhiata alla sua struttura.

Come vedete nell’immagine la granularità delle user stories è più elevata in alto (sono quelle prossime alla lavorazione) e minore mano a mano che si procede verso il basso e quindi si va più avanti nel tempo.
Altra caratteristica di questa rappresentazione è che si tratta di un elenco contenuto.
Non è tutto il possibile e l’immaginabile che riguarda il prodotto, è una selezione di ciò che produce valore per gli utilizzatori (non si tratta di una lista della spesa!). 

Com’è fatto il backlog ideale

Le caratteristiche di un backlog “da manuale” sono queste: 

  • essere dettagliato correttamente (rispettare la granularità decrescente che abbiamo visto prima)
  • avere user stories stimate al proprio interno
  • essere aperto ad accogliere nuove idee e stimoli (mantenere la caratteristica di artefatto vivente)
  • rispettare le priorità

Ma nella pratica quanti di voi hanno un backlog così ordinato?
Il vostro backlog ha davvero queste caratteristiche?
E’ possibile farsi un’idea del suo contenuto in 3 minuti?

La domanda non è peregrina… tempo fa è arrivato in azienda un nuovo manager nella funzione IT. E’ andato a conoscere i vari team e ha fatto ai PO una domanda molto semplice: “se do un’occhiata al vostro backlog sono in grado di farmi un’idea al volo dei progetti su cui state lavorando e lavorerete nel prossimo futuro?” 
La domanda di per sé è semplice, ma la risposta? 
Tutti i nostri backlog sono accessibili e possono essere consultati da chiunque in azienda, ma sono davvero comprensibili? Chi li vede per la prima volta può farsi un’idea al volo? 

Il mio backlog è esploso… e adesso?

Spesso non è così e sono tanti i motivi per cui un backlog può sfuggire al controllo.
Ma non preoccupatevi; la buona notizia è che possiamo intervenire in qualsiasi momento e riprendere le redini della situazione.
A venirmi in soccorso è stato proprio il caso letterario di questa autrice giapponese che si definisce una consulente domestica e ha venduto milioni di copie in tutto il mondo.
Ho provato ad applicare alcuni consigli e tecniche mutuati dalla gestione degli spazi fisici al mio backlog e ne ho tratto grandi benefici.

Il clutter nel backlog

Il clutter è disordine, confusione, tutto ciò che non serve ma si trova nel nostro ambiente.
C’è anche chi lo definisce come “decisioni rimandate”.
Fare declutter significa portare ordine, liberarsi di oggetti vecchi ed ingombranti e portare alla luce ciò che è realmente di valore per noi.
Penso che a questo punto vi sia chiaro il perché leggendo il libro mi si sia accesa una lampadina…
Non è esattamente il lavoro di un PO questo? Comprendere e selezionare cosa valorizza veramente un prodotto.

Fare un assessment del backlog

Come in ogni operazione di riordino che si rispetti si parte da una valutazione dello stato attuale. Dobbiamo prendere consapevolezza.
Il primo invito che vi faccio è condurre un’analisi del vostro backlog.
Proviamo ad analizzarlo rispetto a passato, presente e futuro.

Cosa è entrato in passato nel backlog e cosa ha senso che rimanga in questo preciso momento? 
Quanto è opportuno che guardi in là il mio backlog? 

Cominciate a fare una valutazione oggettiva del vostro backlog: quanti item contiene al suo interno? 30? 50? 100?
Ovviamente il numero può dipendere da tanti fattori – il prodotto che seguite, la dimensione dell’azienda, l’organizzazione della stessa – ma tenete presente che oltre una certa soglia si verificano in ogni caso dei problemi.
Un esempio? Un backlog con un centinaio di item e un team che ne lavora 5/6 ad ogni iterazione si traduce in un’attività che cuba quasi un anno.
Siamo così certi che nulla cambi nel frattempo?

Backlog di grandi dimensioni: inconvenienti

Uno dei primi effetti collaterali è che il backlog perde la caratteristica di essere emergente. 
Quando la dimensione va oltre una certa soglia si verificano comunque delle disfunzioni: è difficile avere una visione globale e unitaria di tutto ciò che è presente al suo interno.
Si crea un effetto buco nero, ovvero più caos c’è e più tende a entrarne perché si è superata la soglia di contenimento.
L’altro grosso problema è che essendo già pieno difficilmente lascia spazio all’innovazione.

Abbiamo valutato lo stato di salute del nostro backlog, vediamo ora come le pratiche di declutter possono aiutarci a risolvere il problema.
Incredibile come i consigli per il riordino degli armadi offrano supporto ai PO “congestionati”.

Pianificare il riordino 

Uno dei primi suggerimenti è che dovete pianificare questo tipo di attività.
Non pensate di fare il riordino del backlog piano piano e poco per volta perché questo approccio non porta dei risultati tangibili (parlo ahimè per esperienza). 

E’ un’operazione time-boxed a tutti gli effetti quindi dovete darvi una scadenza né troppo stringente né troppo lasca.
Dovete pianificare dei momenti di questo tipo per poterlo fare effettivamente, metteteli in agenda, se potete coinvolgete anche il team.
Evitate un’attività a spizzichi e bocconi perché questo non porta a un reale cambiamento. Facendo ordine in modo radicale cambiate la vostra forma mentis e la struttura del vostro backlog.

Visualizzare il caos

Un altro consiglio è che tutto deve essere visibile.
Questo è un principio che dovremmo già conoscere perché è affine alle metodologie agili. 

Quando questa operazione viene fatta in casa si parte dai vestiti.
Tutti vengono tirati fuori dagli armadi e posti su letto in modo da poter vedere la montagna che si crea. Stessa cosa per le librerie; tutti i libri sul pavimento. 

Ci dobbiamo confrontare con il caos, dobbiamo “sporcarci le mani”. 
Fate in modo che gli item del backlog siano stampati su un supporto fisico.
Dovete poter giocare con le carte, valutare effettivamente quante sono e vederle dispiegate davanti a voi perché in un secondo momento dovranno essere organizzate. 

Quando mi sono trovata di fronte a 300 card e oltre ho capito di avere un problema…

Eliminare prima di riordinare

Da dove si parte? Prima viene il buttare!
Il riordino è un’operazione solo successiva. 

Questo è il momento in cui interveniamo sulla dimensione del backlog e il numero di item al suo interno per riportarli sotto controllo.
Qui vi stupirete di quanto si possono snellire i backlog.

Da cosa partiamo? Esistono indubbiamente in tutti i nostri backlog una serie di elementi che possono essere tranquillamente cestinati senza timore.
Vi porto qualche esempio… vi può capitare di trovare di tutto: item che nel frattempo sono chiusi perché sono stati lavorati insieme ad altri, attività che sono rimaste nel backlog ma che in realtà sono state portate a termine, duplicati, user stories che rimangono lì per mesi e mesi… si tratta evidentemente di item che hanno un valore inferiore rispetto tutto quello che viene lavorato quindi questo ci dà un’indicazione importante.
Il tempo di permanenza nel backlog è un criterio che dobbiamo sempre tenere presente.
E’ come un vestito che non viene più messo da anni, oltre una certa soglia si può buttare buttare senza pensieri.

Ma quali criteri adottare per fare questa radicale operazione di eliminazione?
Lo vediamo nella seconda parte di questo post!

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.

Il primo Product Owner della storia

In questi giorni sto leggendo il libro di Jeff SutherlandFare il doppio in metà tempo: Puntare al successo con il metodo Scrum“.
Il volume racconta in maniera discorsiva come attraverso varie esperienze personali e professionali Sutherland – il padre fondatore di Scrum insieme a Ken Schwaber – sia arrivato ad elaborare il famoso framework.

Non mancano aneddoti divertenti sui progetti più disparati salvati dall’adozione di Scrum (dai sistemi di antiterrorismo sviluppati dall’FBI, ai primi ATM, agli applicativi per la gestione delle ricette online, ma anche ristrutturazioni edilizie e matrimoni).

Una delle parti più interessanti per me è il racconto di come è nata la figura del Product Owner e come se l’è immaginata ai tempi l’autore.

Tutto sta a mettere in ordine di priorità il lavoro da fare.
Come si fa? Beh, per prima cosa vi serve qualcuno che sia in grado di capire contemporaneamente qual è la visione e dove sta il valore. In Scrum lo chiamiamo “Product Owner”.

Il Product Owner decide quale dev’essere il lavoro. Gestisce il Backlog, i compiti che include, e soprattutto l’ordine in cui vanno messi in atto.
Nel 1993, quando ho avviato il primo team Scrum, non avevo un Product Owner. Facevo parte del gruppo dirigente e avevo tante altre responsabilità oltre a quella di capire esattamente cosa doveva fare il team in ogni Sprint.
Mi occupavo del management e del marketing, trattavo con i clienti e definivo la strategia. Ma in quel primo Sprint ho capito che potevo anche gestire il Backlog. Dovevo solo fare in modo di avere abbastanza “storie” e abbastanza caratteristiche su cui mettere al lavoro il team nello Sprint successivo.
Il problema era che dopo il secondo Sprint abbiamo introdotto il Daily Stand-up. La velocità è aumentata del 400% nello Sprint successivo, e il team ha portato a termine in una settimana il lavoro che avevamo preventivato su un mese.
Non c’era un altro Backlog su cui metterlo al lavoro! Avevo pensato di avere davanti un mese per creare altre “storie”.
È un problema che vorrebbero tutti, bisogna ammetterlo, ma andava comunque affrontato. Quindi ho ideato il ruolo del Product Owner e ho cercato di capire che caratteristiche dovrebbe avere idealmente chi è chiamato a ricoprirlo.

Mi sono ispirato al Chief Engineer di Toyota
… ciò che non hanno [ i Chief Engineer] è l’autorità.
Nessuno riporta a loro, semmai sono loro che riportano ai propri gruppi.
I collaboratori possono dire ai Chief Engineer che sbagliano, perciò costoro devono accertarsi di aver ragione.
Non valutano la performance di nessuno, e non concedono né promozioni né aumenti, ma decidono la visione della nuova vettura, e stabiliscono come verrà costruita, con la persuasione, e non con la coercizione.
È questa idea che volevo incorporare in Scrum.

Già agli albori di Scrum sapevo di aver bisogno di qualcuno che conoscesse molto bene il cliente.
Il Product Owner doveva essere in grado di riportare al team il feedback del cliente a ogni Sprint. Doveva dedicare metà del proprio tempo a parlare con le persone che acquistavano il prodotto (ascoltandone le opinioni sull’ultima release incrementale e su come creava valore), e l’altra metà a sviluppare il Backlog con il team (spiegando ai suoi membri cosa apprezzavano e cosa non apprezzavano i clienti).
Ricordatevi che il “cliente” potrebbe essere il consumatore in generale, una grande banca, vostro marito o chi ha bisogno del vaccino contro il rotavirus e dipende da voi per ottenerlo. Il cliente è chiunque tragga valore da ciò che fate.
Però non volevo un manager. Volevo qualcuno in cui il team credesse e di cui potesse fidarsi quando metteva in ordine di priorità il Backlog. Perciò sono andato a prendere il più bravo di tutti nel product marketing; attenzione, non nell’engineering, ma nel marketing. Ed è così che Don Rodner è diventato il primo Product Owner.
Conosceva il prodotto che stavamo sviluppando non da un punto di vista tecnico – pur sapendone abbastanza da poter comunicare con gli ingegneri – ma piuttosto dal punto di vista del cliente.
Di che cosa avevano bisogno coloro che usavano effettivamente il prodotto? Quando siete alla ricerca di un Product Owner, scegliete qualcuno che sia in grado di mettersi nei panni di chiunque tragga valore da ciò che fate.