Nel precedente articolo abbiamo visto un certo numero di utili consigli per chi svolge la funzione di facilitatore nell’ambito della retrospettiva. In questo articolo, basandoci sull’esperienza accumulata negli anni, aggiungiamo ulteriori indicazioni utili a far davvero funzionare le nostre retrospettive, affrontando altri argomenti collaterali, che spesso, proprio per questo, non vengono sufficientemente trattati e possono invece risultare di notevole importanza. Nel prossimo numero, concluderemo la serie.

Impiegare nella retrospettiva quello che emerge dal gruppo

Spesso la dinamica del gruppo di lavoro genererà delle “offerte” provenienti dal team, relative ad aspetti che a loro interessa discutere e spesso anche ad aspetti che… non vogliono discutere. Nella maggior parte dei casi, il team non è consapevole della dinamica che i diversi componenti hanno creato ed è necessario che questa dinamica sia mostrata loro dal facilitatore, che sfrutterà un “effetto specchio”, ossia farà in modo da far apparire la dinamica chiara al gruppo, in maniera che poi ci si possa lavorare sopra.

Una volta stavo svolgendo attività di coaching presso un gruppo che mostrava un evidente problema di cooperazione con il Product Owner e che però non ne era consapevole. Durante una retrospettiva, stavamo parlando della qualità delle storie-utente quando, all’improvviso, uno dei presenti cominciò a parlare di come il materiale che ricevevano dal Product Owner non fosse sufficientemente buono. Questo discorso in effetti andava fuori-tema rispetto alla discussione che stavamo facendo ma un altro componente del team rinforzò il messaggio, e notai segnali non verbali provenienti dal resto del gruppo che sembravano suggerire accordo rispetto al tema che stava venendo a galla. Chiaramente io stavo solo facendo delle supposizioni, ma a quel punto cercai di riflettere la situazione con il metodo dello specchio e dissi loro che avevo l’impressione che ci fossero segnali di un problema diverso di cui volevano parlare. Quindi chiesi loro se intendessero continuare a parlare dell’argomento precedente o se preferissero passare a lavorare su questo nuovo problema che stava emergendo: decisero di cambiare. Ebbene, il risultato fu uno dei migliori chiarimenti sui diversi ruoli coinvolti nel progetto che mi sia mai capitato di vedere in una retrospettiva!

Il succo del discorso è che, quando il team offre queste opportunità, è bene prenderle al volo e contribuure a risolvere i problemi a cui il gruppo fa velatamente riferimento, ma che non ha il coraggio di affrontare direttamente.  A volte, basterà un piccolo stimolo da parte del facilitatore per spingere la retrospettiva molto avanti, principalmente perchè il team è pronto a partire già di per sè e ha semplicemente bisogno di sentirsi dare il “via!”.

Attenzione però, anche alle possibili controindicazioni di questo via libero: se siamo in presenza di  situazioni con conflitti latenti potrebbe succedere di scatenare un processo a valanga nel gruppo, che potrebbe esploderci tra le mani! Si potrebbe, in pratica, dare inizio a una fase di storming: se non siamo ragionevolmente sicuri di avere la capacità di contenere quest’esplosione, è probabilmente meglio evitare di far partire questa fase.

Attenzione al ROTI…

Con ogni probabilità, un gruppo che non apprezza particolarmente le retrospettive non si impegnerà nelle discussioni con molto coinvolgimento e i risultati che si otterranno serviranno a ben poco. È pertanto importante essere consapevoli del feedback che arriva dai partecipanti per migliorare la propria opera di facilitazione all’occasione successiva: il modo migliore per farlo è di effettuare una valutazione del ROTI.

ROTI è l’acronimo di Return On Time Invested, liberamente traducibile come indice di redditività del tempo investito. Il ROTI ci consente di capire ciò che serve ai partecipanti: questo è sempre di capitale importanza, dal momento che la retrospettiva riguarda anzitutto loro, e deve apportare i maggior benefici a loro e non ai facilitatori!

Il Return On Time Invested (ROTI) descritto nel libro “Agile Retrospectives” [1] è un modo per chiudere la retrospettiva chiedendo ai partecipanti quanto valore hanno ricevuto rispetto al tempo che hanno investito.

Ovviamente, qui si applicano tutti i vari metodi utilizzati per raccogliere feedback: per esempio, va benissimo il perfection game ossia quel metodo di valutazione in cui i partecipanti giudicano il meeting appena concluso indicando:

• che voto danno al “prodotto/servizio” su una scala da 1 a 10;
• che cosa hanno apprezzato;
• che cosa c’è da fare per renderlo perfetto.

Ricordiamoci sempre che il miglioramento continuo si applica anche a noi come facilitatori, non solo al lavoro del team con cui stiamo facendo le retrospettive!

…ma attenzione anche prima del ROTI!

Che si faccia o non si faccia una valutazione del ROTI alla fine, occorre comunque sempre stare attenti al feedback dei partecipanti, valutando ad esempio le loro impressioni alla fine di una riunione o durante la pausa caffè. A volte basta guardare in viso le persone quando viene conclusa la retrospettiva per rendersi conto, almeno in parte, di ciò che pensano.

In ogni caso, è importante ricevere feedback positivo sul parametro ROTI e questo nell’interesse del gruppo: una retrospettiva che non fornisca abbastanza valore al gruppo potrebbe ridurre l’impegno del team nelle riflessioni successive, scatenando un circolo vizioso auto-rinforzato, con incontri che andranno sempre peggio, riunione dopo riunione. Il bravo facilitatore non deve consentire questo peggioramento della retrospettiva; ci sono varie strategie per evitarlo:

Semplicemente, chiedere al team che cosa si sarebbe aspettato rispetto a ciò che ha ricevuto: in genere le persone lo sanno…

Fare riunioni più brevi: banalmente, il ritorno rispetto al tempo investito può essere migliorato diminuendo il tempo investito. Questo vale specialmente per i gruppi di lavoro molto impegnati all’interno di organizzazioni che lavorano molto: saranno maggiormente “spaventati” da retrospettive lunghe, ed è quindi meglio manternerle un po’ più brevi.

Cambiare il formato adottato: magari li avete solo annoiati a morte…

Valutare se non si stia parlando troppo: nella retrospettiva devono essere soprattutto i componenti del gruppo a parlare, non solo il facilitatore!

Valutare se non si stia svolgendo il ruolo di docenti: anche se a volte occorre insegnare qualcosa, il ruolo di facilitatore è diverso da quello di docente. Il docente fornisce contenuti, il facilitatore gestisce al meglio la riunione.

Consolidare i risultati raggiunti in precedenza

Appare piuttosto chiaro che, se tutto quanto è stato prodotto nella retrospettiva precedente viene dimenticato, sarà difficile che il team tiri fuori nuove idee… Pertanto, fate un favore a voi stessi e al team e aprite le retrospettive con uno sguardo allo stato dei lavori e agli argomenti discussi in precedenza; decidete se alcuni di essi dovranno essere discussi nuovamente nell’incontro che vi accingete a tenere. E, ancora meglio: rendete queste informazioni visibili nella stanza, usando mappe, cartelli e altri strumenti visuali.

Concentrarsi sul “qui e ora”… e su un passo più avanti

Può esserci la tentazione di discutere problemi e argomenti che arriveranno nel futuro, che so, nei prossimi sei mesi. Sebbene questo possa avere anche delle buone ragioni, spesso si tratta di un segno che il gruppo intende far slittare la discussione dai problemi attuali facendo però sembrare che la retrospettiva abbia un valore: alcuni gruppi sono davvero bravi in questo tipo di inganno…

Se il team però se ne esce con alcuni argomenti che riguardano azioni a lungo termine, la cosa da fare è chiedere loro di suddividere questi elementi in parti più piccole e mettere in pianificazione nel breve termine solo le parti che cronologicamente arrivano per prime. Se questo viene ritenuto impossibile, allora è bene chidere quali miglioramenti possano essere apportati nella iterazione successiva.

Attenzione alla nebbia dell’indefinitezza

È facile concordare tutti quanti su affermazioni quali “vogliamo un miglioramento continuo per le nostre pratiche”; ma questa è una affermazione così generica che non ci dice nulla sulla reale messa in pratica del concetto. Esiste certamente un valore nell’essere d’accordo su alcuni principi generali,  poichè un accordo generico e di alto livello su qualcosa potrebbe essere un necessario passaggio intermedio per raggiungere qualcosa di migliore più avanti, una retrospettiva è utile se gli elementi di azione che ne scaturiscono sono specifici ed eseguibili.

In qualità di facilitatori, dovremmo sempre sforzarci di far modo che il gruppo scriva delle azioni chiare che siano applicabili nella realtà e che possano essere tracciate… e che si impegni a metterle in pratica. Se il gruppo non è in grado di mettersi d’accordo su elementi di azione sensati, potrebbero essere svariate le ragioni a cui guardare.

Conflitti latenti

Potrebbero esserci conflitti latenti in grado di impedire alle persone di raggiungere accordi fin quando tale conflitto non è risolto. Senza risolvere il conflitto latente, non si sarà mai in grado di ottenere elementi di azione decenti su quel tema!

Problemi sistemici

Un problema importante può essere rappresentato da criticità sistemiche presenti nell’organizzazione come una pressione esterna dall’esterno del team (imposizioni del managment, opinioni dominanti, etc.) o barriere organizzative che il gruppo sa o pensa di non riuscire a superare. Sebbene sia facile dire al team “siate più coraggiosi!”, si dovrebbe essere consapevoli che non si tratta di un obiettivo facile da raggiungere, visto il livello di maturità e di “fierezza” che il gruppo deve necessariamente raggiungere prima di poter mettere in questione le autorità.

Problemi di competenza e di maturità

Ci sono poi i casi in cui alcuni team semplicemente non hanno competenza sufficiente rispetto agli argomenti di cui devono discutere, così come accade che ci siano team non sufficientemente maturi per condurre una retrospettiva e quindi lavorano svogliatamente. Anche in questi casi, vale in genere la pena di investire nel lavoro di retrospettiva, anche perchè spesso si resta sorpresi del risultato e della crescita del gruppo!

Azioni pertinenti solo per un futuro lontano

Un altro caso che ricade nella stessa categoria è rappresentato dalle situazioni in cui le azioni da intraprendere potrebbero essere ben definite e tracciabili, ma fanno riferimento solo a un futuro lontanto e quindi non possono essere intraprese nelle iterazioni immediatamente a venire.

Anche questo è un segnale che ci sono uno o più problemi a intralciare lo svolgimento delle attività: sicccome il gruppo non trova il modo di risolvere un problema, ritiene più facile mettersi d’accordo su qualcosa da fare in futuro e che non deve essere cominciato immediatamente: il problema così è evitato, almeno per ora…

Accordi su aspetti minori

Simile a questo approccio è anche quello in cui il gruppo trova facilmente un accordo, ma su cose che:

• non sono molto importanti;
• hanno una priorità bassa;
• sono impossibili da implementare, anche se magari a prima vista non sembra così;
• non ricadono nelle loro responsabilità;
• non ricadono sotto la loro autorità;
• dipendono da altre entità che svolgeranno il loro lavoro;
• dipendono da altri eventi improbabili se non impossibili.

Le soluzioni

Quando siamo in presenza delle dinamiche che abbiamo appena descritto, ci sono comunque alcune scelte creative percorribili:

• Far continuare il gruppo nei suoi comportamenti e “inchiodarlo” alle sue responsabilità alla retrospettiva successiva, quando non avranno messo in pratica quello che si erano ripromessi, qualunque sia stata la ragione.
• Fare al gruppo domande riguardo la fattibilità, l’accessibilità di risorse, mettendo così efficamente in discussione la qualità delle azioni che si ripromettono di intraprendere. Usate domande aperte e approfondite, dal momento che il gruppo potrebbe tentare di “svicolare” evitando uno scrutinio dettagliato della situazione.
• Per le azioni proiettate in un futuro molto lontano, chiedere al gruppo di fornire lumi riguardo a miglioramenti che possono raggiungere ne breve termine: “OK, ma invece, al prossimo sprint, cosa potreste cambiare?”.
• Cercate di far emergere il problema che blocca il gruppo. Chiaramente questa è la maniera migliore di rimuovere l’ostacolo una volta per tutte, ma occorre fare attenzione che, quando un conflitto latente diviene evidente, potrebbe esplodere (si veda anche quanto detto sopra in “Impiegare nella retrospettiva quello che emerge dal gruppo”).

Attenzioni ai dati generici

A volte, gli argomenti che emergono in una retrospettiva sono generici… molto generici… troppo generici. Pertanto diventano inutili!

È un effetto che noto sempre in molti gruppi di lavoro, anche in quelli di buon livello: quando si discute su come è andata l’ultima iterazione, la gente racconta alcuni eventi concreti, ma poi li generalizza in qualcosa di più astratto che risulterà di scarsa utilità per le fasi successive del progetto.

Un esempio tipico: in un team una persona ha sviluppato una storia nel modo sbagliato perchè ha potuto raggiungere il PO solo via email per avere una spiegazione, e la risposta era sbagliata o è stata interpretata in maniera sbagliata. Nella retrospettiva, questa persona scriverà “Problemi di comunicazione” su una carta Sad. La persona poi spiegherà il fatto al team, ma quello che ne rimane è solo il titolo, piuttosto astratto. A questo punto il gruppo comincia a discutere ad alto livello filosofico dei problemi di comunicazione tra di loro, invece di affrontare lo specifico problema, vale a dire i limiti della comunicazione in posta elettronica e i metodi per renderla più chiara e affidabile.

Questo non è sbagliato in modo assoluto: parlare dei problemi di comunicazione può essere comunque utile, specie se molte persone hanno votato per farlo perchè hanno problemi simili. Però nel nostro caso il risultato non è focalizzato e la conversazione non risulta produttiva.

In questi casi, suggeriscao di raccogliere maggiori informazioni (contesto) nella scheda di descrizione e di chiedere se altre persone hanno hanno avuto problemi simili. Si potrebbe anche lasciare che le schede siano raggruppate ricevendo un titolo più generico, ma comunque vale la pena di avere informazioni dettagliate disponibili sulla parete.

L’idea fondamentale alla base di tutto questo è di cercare di mantenere le informazioni che si ricevono quanto più concrete possibile, invece di generalizzarle in qualcosa che poi non si può effettivamente utilizzare.

Raggruppamenti inutili

Un problema simile di dati generici si verica spesso quando si raggruppano schede e cartellini: alcuni di questi vengono messi nello stesso gruppo, ritenendo che ricadano nella stessa categoria. Ma quali sono i criteri di appartenenza per il raggruppamento?

Spesso mi accorgo che ci sono schede raggruppate in gruppi cui poi vengono dati titoli come “Qualità”, “Miglioramento del processo”, “Lavoro di squadra”… Chiaramente queste categorie forniscno una utile interpretazione logica di quel che è stato scoperto, ma votarle come macrocategorie non fa altro che spostare il problema a un livello superiore: se in tanti votano “Miglioramento del processo”, vuol dire che il tema è importante, ma i molti e variati aspetti che ricadono sotto questa etichetta generica non saranno probabilmente tutti importanti alla stessa maniera…

L’indicazione è di fare raggruppamenti con argomenti che siano o veri e propri duplicati oppure davvero simili. Altrimenti è meglio lasciarli separati.

Mantenere la retrospettiva una conversazione di gruppo

Le retrospettive sono processi di gruppo e quindi dovrebbero svolgersi come conversazioni di gruppo. Se un piccolo sottogruppo del team tende a sabotare la retrospettiva e si appropria dei tempi per utilizzarli come momenti per il loro “spettacolo”, questo va tenuto sotto controllo. In tal senso, aiuta molto una adeguata politica di “timeboxing”, nonchè una sistema di feedback incrociato da parte di tutti nei confronti dei “dirottatori”.

Ricordiamoci sempre che il modo in cui percepiamo lo scorrere del tempo è molto soggettivo, quindi anche il modo in cui usiamo i nostri tempi nelle retrospettive è molto soggettivo. Questo è un caso in cui una buona facilitazione viene in aiuto, poichè è in grado di far parlare le persone il più possibile senza però togliere tempo e voce agli altri, ma anzi lavorando affinchè tutti abbiano i tempi e i modi per esprimere il loro punto di vista.

“È colpa loro!”

Un “antipattern” tipico di svariate retrospettive è di focalizzarsi su ciò che può essere cambiato… dagli altri! Può infatti instaurarsi nel gruppo quel meccanismo per cui loro sono le vittime di problemi che si trovano altrove nell’organizzazione. Nel coaching singolo, uno a uno, questo meccanismo psicologico è conosciuto come “la posizione della vittima”, in cui loro non possono fare nulla per cambiare.

Il mio approccio come facilitatore in questi casi è di dare due opzioni, in maniera gentile ma molto ferma:

• Se il team non può cambiare la situazione, è inutile discuterne. Se serve qualche azione drastica che spinga al cambiamento, occorre discutere questa azione e procedere. Se l’azione drastica che può cambiare la situazione non serve, si va comunque avanti…
• Il team, in effetti, può fare qualcosa per cambiare la situazione. Pertanto è bene smettere di parlare delle colpe altrui e passare invece a decidere azioni concrete che possano risolvere almeno quello che, all’interno dell’organizzazione, è di loro competenza.

Una retrospettiva comincia prima dell’inizio della riunione

Quando comincia una retrospettiva? Abbiamo già visto che, per il facilitatore, la retrospettiva comincia ben prima della riunione: le attività di preparazione dovrebbero iniziare già durante lo sprint, attraverso l’osservazione di ciò che accade, e con la decisione su quale formato adottare su quali attività dovrà contenere quella retrospettiva.

Ma, di fatto, la retrospettiva comincia ancor prima pure per il team: durante l’iterazione al facilitatore potrebbe capitare di osservare alcuni aspetti che sarebbe il caso di discutere nella retrospettiva successiva. Una possibilità è quella di affermarlo palesemente: “Oh, questo è un aspetto di cui dovremmo discutere alla prossima retrospettiva. Cominciate a raccogliere dati!”, spingendo così il team a focalizzarsi su quello che è accaduto e preparandolo per la discussione a venire. Se poi il problema verrà affrontato e risolto da loro durante la retrospettiva o se li aiuterete voi, è un altro discorso.

Esiste però anche un modo più raffinato e meno palese per richiamare l’attenzione dei componenti del gruppo su aspetti importanti da discutere alla prossima retrospettiva: mostrando chiare reazioni non verbali alle azioni del gruppo di sviluppo (espressioni facciali, posture corporee non usuali, toni di voce differenziati), si potrebbe segnalare che si è in presenza di qualcosa di inusuale, focalizzando la loro attenzione su questi aspetti. In tal modo certi argomenti potranno emergere da loro nel corso della retrospettiva, altrimenti sarete voi a farli emergere.

Conclusioni

Anche in questo articolo abbiamo riportato una serie di consigli e suggerimenti derivanti dall’esperienza, che affrontano temi “collaterali” della retrospettiva ma che si rivelano utili nella pratica reale.

Nel prossimo e ultimo articolo della serie, concluderemo la nostra discussione con gli ultimi consigli per la facilitazione e con una riflessione sul ruolo dello Scrum Master, a cavallo tra membro del team di sviluppo e facilitatore.