Retrospettiva: un lusso per team agili (e non solo)

Quando oltre dieci anni fa ho sentito parlare per la prima volta di metodologia Agile, ho subito notato che tutto ruotava attorno a tre termini: product backlog, sprint e retrospettiva. Stiamo certamente parlando del framework Scrum, e ricordo che fu quasi immediato, per me, comprendere il significato dei primi due concetti, mentre molto meno capivo l'importanza del terzo. Pur avendo all'attivo numerose esperienze di lavoro di gruppo, animazione non formale, utilizzo di tecniche di facilitazione e raccolta di feedback, ammetto di non aver colto immediatamente il nesso con lo sviluppo software.

Ad intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.

Si tratta del dodicesimo principio dell'Agile Manifesto, oserei dire "ultimo ma non meno importante".

In poco tempo ho avuto chiaro che niente del bagaglio di soft skills che avevo costruito in anni di volontariato come formatrice, educatrice e animatrice andava lasciato fuori dalla porta dell'ufficio, men che meno quelle bellissime tecniche per la verifica di gruppo che adesso potevano trovare una nuova collocazione: il momento della retrospettiva. La cosa che ancor più mi ha entusiasmato (e continua a farlo) è stato riuscire ad accrescere la competenza nella gestione del gruppo e dei momenti formativi proprio grazie alla conoscenza delle metodologie agili (ma questa è un'altra storia).

Se dovessi spiegare meglio il concetto di retrospettiva, magari ai non addetti ai lavori, andrei a scomodare gli antichi greci e l'esortazione: conosci te stesso, che suggerisce all'uomo di conoscersi e comprendere i propri processi di pensiero per pervenire a un sé migliore. Ecco, in qualche modo la retrospettiva attiva dei meccanismi per conoscere meglio se stessi e le persone con cui si lavora a stretto contatto, nonché far emergere modalità comunicative e relazionali, processi, prassi e dinamiche che si sono instaurate, al fine di individuare gli elementi "di disturbo" per poi proporre e scegliere soluzioni che permettano di superarli, per fare bene e fare meglio. La retrospettiva mi ricorda anche il bisogno di guardarsi allo specchio prima di uscire di casa per aggiustare il trucco o sistemare il vestito, se serve.

Ma la retrospettiva è una prassi dei team agili (e non solo) o è un lusso che non tutti possono/sanno permettersi? Potrei lanciare un sondaggio - sarei curiosa di sapere cosa avviene realmente nei team più o meno agili - ma per il momento mi fermo a condividere alcune riflessioni e provocazioni, partendo da alcune domande: a cosa serve investire del tempo nella verifica di un lavoro svolto? Se il lavoro è stato addirittura consegnato, chiuso, e se il team di lavoro molto probabilmente è destinato a sciogliersi, è necessario investire energie in un lavoro di retrospettiva? Perché, poi, guardare "indietro"? Non è forse "avanti" che dobbiamo e vogliamo andare? Come dicevo, si tratta di provocazioni, perché personalmente sono convinta che l'unico investimento che ha come ritorno il miglioramento continuo sia proprio l'investimento nel lavoro di retrospettiva. Tuttavia, so per esperienza che tutto questo lavoro "sulla persona" a volte è più difficile addirittura del proprio compito operativo e/o tecnico.

A seguito di alcuni episodi che mi hanno indotta a chiedermi cosa serva per migliorare la comunicazione in un gruppo di lavoro e cosa renda possibile nonché efficace un lavoro di verifica, ho voluto trascrivere (e condividere) una serie di indicazioni da cui partire.

• Se non si è definito un obiettivo, non ci si può lamentare di non aver raggiunto l'obiettivo (quale?!). Va definito a priori il risultato da raggiungere al termine di un lavoro di retrospettiva, che in linea di massima dovrebbe essere quello di identificare ciò che è andato bene, ciò che non è andato bene e con quali azioni concrete migliorare il processo. Tuttavia, il bisogno imminente di un team potrebbe variare, ecco perché bisogna aver chiaro con quale risultato concreto si vuole concludere l'attività, ed è meglio renderlo noto anche ai componenti del team.
• Non è vero che si apprende dall'errore, soprattutto se fatto "in buona fede". Si apprende dall'errore se questo viene rielaborato, magari mettendo a confronto vari punti di vista. Ecco perché è essenziale invitare le persone a condividere tutto ciò che per loro è importante, soprattutto ciò che impedisce di affrontare serenamente il lavoro di squadra.
• Non basta arrivare volenterosi alla retrospettiva, bisogna preparare il terreno. Bisogna creare un ambiente sicuro, accertarsi che tutti i partecipanti abbiano adeguato spazio, impedendo o quantomeno mitigando la prevaricazione e la monopolizzazione del discorso, avvalendosi di tecniche che rendano maggiormente gestibili questi aspetti.
• In perfetta sintonia con i principi del manifesto agile, nessuno deve calare le soluzioni dall'alto, né erigersi a "salvatore della patria": è il team, con la sua intelligenza collettiva, a individuare e scegliere le soluzioni, che nella migliore delle ipotesi non vengono votate a maggioranza ma tengono conto delle esigenze e dei punti di vista di tutti.
• Lavorare su di sé è stancante, ecco perché un lavoro di verifica deve rientrare in un tempo adeguato (a mio avviso, 60-90 minuti). Non si può sperare di analizzare e risolvere tutti i problemi di svariata natura in un'unica sessione, ecco perché i team dovrebbero svolgere queste sessioni a intervalli regolari. In ogni sessione è bene focalizzarsi solo su alcuni aspetti, trattarli ed esaurirli (o, ad esaurirsi, saranno le energie e la voglia).
• Bisogna affrontare la retrospettiva con una mentalità aperta, onesta e costruttiva. Ma questa caratteristica non la si acquisisce nel tempo di una riunione: è un lavoro continuo, che va facilitato nel tempo, ed è anche per questo che bisogna iniziare "a piccole dosi".
• Nessuno vuole "perdere tempo" a formulare un feedback o a trovare una soluzione che rischia di perdersi nel nulla: lo scambio di feedback richiede un adeguato approfondimento, le soluzioni individuate meritano di entrare in un piano di azione concreto. La chiusura è essenziale tanto quanto l'apertura.

Il processo che traccio per eseguire una buona retrospettiva prevede, quindi, i seguenti passi:

1. Definire l'obiettivo da raggiungere e i tempi di lavoro.
2. Convocare il team condividendo obiettivo e tempi.
3. Curare l'esecuzione della retrospettiva mediante tecniche e modalità partecipative.
4. Concludere con un piano di azione chiaro e condiviso.

Ma a chi spetta il compito di provvedere a tutto questo? Nei team agili, solitamente allo Scrum Master. Per fare in modo che il team viva i valori della metodologia Agile, lo Scrum Master si avvale anche dei momenti di retrospettiva e li facilita.

E i team non agili? Penso che ogni team debba eleggere o ingaggiare qualcuno che curi questi aspetti, o organizzarsi perché ci si alterni nel farlo di volta in volta.

Tornando ancora a circa 10 anni fa, oltre a spiegarmi cos'è un product backlog, mi si propose di diventare lo Scrum Master in un progetto, e per farmi comprendere meglio il lavoro da svolgere, venne utilizzata la seguente metafora: lo Scrum Master è un po' come una mamma, deve curare e proteggere i componenti del team in modo "materno". Al di là di quanto possa essere azzeccata questa metafora, mi piace ricordarla perché credo che in maniera molto semplice esprima un concetto fondamentale: se si ha a cuore e si cura la salute dei componenti del team, si può lavorare bene e sempre meglio.

-----------------------------------------------------------------------------------------------------

Se ti sei imbattuto in questo articolo senza aver mai sentito parlare di metodologie agili ti suggerisco di consultare il Manifesto Agile e ti lascio questo articolo in cui si spiega la metodologia agile ai non addetti ai lavori, sfruttando il parallelismo con il mestiere del sarto.