Non solo credo che una retrospettiva “fatta a metà” sia meglio di “nessuna retrospettiva”, ma credo che in diversi casi sia anche meglio di una retrospettiva “completa”.
La fascinazione del metodo
Qualche giorno fa sono incappato in questa proposta di neologismo, methodolatry, definito come:
Worship of a method that employs it uncritically regardless of ever- changing particulars and steadfastly ignoring past negative results.
Collins Dictionary
Chi come me si deve costruire una cassetta degli attrezzi pronta all’uso per qualsiasi situazione, conosce il rischio di adorare i propri strumenti: seguire un metodo in maniera ripetibile porta conforto al consulente che non deve re-inventare la ruota e porta conforto al cliente che sa cosa sta “comprando”.
La retrospettiva viene descritta in mille varianti più o meno creative, e viene prescritta in diversi modi e da molti: io stesso sono un “paladino della retrospettiva” e la ritengo la prima pratica da applicare – e talvolta forse anche l’unica – quando si vuole iniziare a cambiare qualcosa nel modo in cui si lavora.
Ma siamo sicuri di aver capito davvero bene a cosa serve la retrospettiva, e che ci sia un modo unico di farla?
Teoria e tecnica della retrospettiva
La retrospettiva è un incontro che, prescritto all’interno del framework di Scrum, è figlia del dodicesimo principio del Manifesto per lo Sviluppo di Agile di Software:
A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
I principi sottostanti al Manifesto Agile
È uno di quei principi del Manifesto Agile che potremmo definire universali, in quanto importanti e applicabili in qualsiasi ambito lavorativo – e non – e quindi non è appannaggio esclusivo del mondo di chi fa software.
Nonostante il nome, “retrospettiva”, possa suggerire un incontro “fumoso” e poco concreto, ci sono cinque fasi ben distinte che una buona retrospettiva dovrebbe seguire, e sono:
- Apertura
- Raccolta dati
- Generare ipotesi
- Decidere cosa fare
- Chiusura
Ci possono essere retrospettive di varia natura, alcune più metaforiche, alcune più analitiche, alcune più emotive: ma una buona retrospettiva viene valutata sulla base di come viene usato il tempo a disposizione, che deve essere distribuito tra quelle fasi e da quante azioni concrete di miglioramento il team si prende in carico alla fine.
Fino a qui, tutto bene e tutto sensato: ma nella realtà cosa succede?
Farla o non farla?
C’è un gioco che ogni tanto si fa per fare famigliarizzare le persone con i principi del Manifesto Agile:
- Si prendono i dodici principi
- Si discute che cosa significano questi principi nel contesto specifico dell’azienda
- Si chiede alle persone di dare un voto da 1 a 10 su quanto questo principio venga applicato in azienda
- Si chiede cosa si potrebbe fare per aumentare il voto di una unità
L’esito più frequente riguardo quel dodicesimo principio, il prendersi del tempo per riflettere sul come si lavora, è: non lo facciamo.
Oppure: lo facciamo, solo a progetto finito (è, forse, un post-mortem).
Oppure: lo facciamo, solo per dare la colpa a qualcuno (è, sicuramente, blaming)
Non solo, anche in organizzazioni che applicano Scrum o Kanban, talvolta anche con modelli di scaling in cui abbiamo, teoricamente, decide di team che adottano le stesse pratiche, la retrospettiva è il primo degli eventi che “salta”, non viene fatta, o non viene fatta regolarmente o adeguatamente: questo perché la retrospettiva viene vista come “non lavoro”.
Evito di scoperchiare il vaso di Pandora dei mille motivi culturali per cui la retrospettiva viene evitata, andando dritto a qualche osservazione pratica e consiglio.
Farla a metà, apposta
Il quadro che ho descritto finora è desolante: fare la retrospettiva è importante e allo stesso tempo difficile, e la probabilità di non farla o smettere di farla è altissima, per una lunga serie di fattori che ho affrontato solo parzialmente.
Fino a non molto tempo fa avrei considerato fallimentare una retrospettiva che finiva senza azioni concrete, o che si fermava in alcune delle fasi preliminari: poi, invece di pensare a quello che avrei voluto fare io (“una bella retrospettiva seguendo per bene tutte e cinque le fasi”) ho iniziato a prestare attenzione a cosa serviva alle persone.
Ricordate l’esercizio con i voti di cui sopra?
Ricordate il principio sottostante la retrospettiva?
A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
I principi sottostanti al Manifesto Agile
Dato che il voto molto spesso è molto basso, sapete qual è la prima azione per aumentare quel voto di una unità? La prima azione è: iniziare farla.
A volte basta una retrospettiva dove ci si ferma a raccogliere i dati (quantitativi o qualitativi che siano), a volte basta una retrospettiva dove ci si ferma a generare ipotesi.
È una retrospettiva completa? No.
È una retrospettiva sbagliata? No.
Consideriamo sempre il punto di partenza in cui troviamo le persone e la complessità della retrospettiva: la mia esperienza finora è che in molte situazioni ad una retrospettiva completa ci si arriva dopo mesi di lavoro, e servono altri mesi per poterne apprezzare gli impatti positivi.
Ogni quanto il tuo team si ferma a pensare a come ha fatto e non solo a cosa ha fatto? In che modo lo fa?
Se vuoi ricevere i miei articoli via email, ti puoi iscrivere qui sotto.
Foto di testata di Mark Neal.
Davide Tarasconi 