Nel corso della serie, abbiamo introdotto i principi e i metodi su cui basare le retrospettive in un orizzonte di applicazione delle metodologie agili ai progetti. In questo articolo e nel prossimo, vogliamo concludere la serie con un certo numero di consigli ‘in libertà’ rivolti a tutti i facilitatori, augurandoci che essi possano contribuire a far funzionare al meglio la retrospettiva.

Consigli ai facilitatori

In questo articolo vogliamo riportare una serie di consigli molto pratici e molto puntuali rivolti ai facilitatori e incentrati su alcuni aspetti particolari del processo di retrospettiva. Dopo aver visto infatti i principi basilari e i diversi tipi di approccio che si possono avere nel condurre una retrospettiva, riportiamo un insieme di suggerimenti, “trucchi”, accorgimenti che affrontano punti specifici del “mestiere” di facilitatore. Concluderemo il nostro elenco di consigli nel prossimo articolo, a chiusura della serie.

Cambiare, cambiare, cambiare

Dal momento che la retrospettiva è in genere l’ultima cosa che si fa prima di “archiviare” una iterazione, in genere il team è molto stanco; per questo, rendere interessante la retrospettiva è nella maggior parte dei casi di primaria importanza per il suo successo. Da qui scaturisce la necessità di introdurre il cambiamento: usare format differenti, variare le tecniche, sorprendere il team sono le parole d’ordine. Nulla è più noioso che usare lo stesso modello di retrospettiva tutte le volte; ciò nonostante, molti Scrum Master fanno invece proprio questo: ripetere sempre i soliti vecchi schemi.

Cambiare il modo in cui la retrospettiva è condotta contribuisce inoltre a introdurre nuove prospettive e, di conseguenza, accresce la probabilità che nel processo scaturiscano nuove idee creative.

Il posto giusto

Un importante aspetto della retrospettiva è rappresentato dal luogo in cui la si svolge: ho visto molte retrospettive che non hanno raggiunto risultati ottimali semplicemente a causa delle caratteristiche della stanza. La maggior parte delle retrospettive si svolgono nella stanza del team e, se questa ha le giuste caratteristiche, è anche la scelta migliore poichè lì già ci sono tutti gli artefacts, i “manufatti” relativi al progetto; e poi tutte le informazioni eventualmente necessarie saranno già a portata di mano se, come è auspicabile, il gruppo di lavoro utilizza degli information radiators, ossia lavagne, pannelli, grafiche e testi esposti e ben visibili che aiutano nel condividere e tenere presenti informazioni varie sul progetto.

Consigli per la scelta della stanza

Tuttavia, in vari casi le retrospettive vengono tenute in luoghi diversi dalla stanza del team, sia per cambiare intenzionalmente, sia per altre ragioni contingenti, e quindi potrebbe essere necessario trovare un luogo adatto, tenendo in considerazione alcuni aspetti importanti.

Il primo, e più evidente, è la dimensione della stanza: molte retrospettive vengono condotte in locali che, banalmente, sono troppo piccoli. La gente deve avere spazio a disposizione per muoversi, nel mio modo di vedere le cose, la retrospettiva dovrebbe essere piuttosto dinamica, con la gente in grado di muoversi e di interagire; per questo occorre dimensionare lo spazio in maniera generosa. Lo spazio non è mai abbastanza, a meno che questo non faccia sorgere problemi di acustica.

Altri aspetti da non sottovalutare sono rappresentati dalla luce/illuminazione, dalla rumorosità del luogo, dall’eventualità di interruzioni (ad esempio, se si tratta di una stanza in cui passano altre persone), dall’acustica (se la stanza è troppo grande e ci sono reverberi che non consentono una buona intelligibilità del parlato), dalla sicurezza del luogo di lavoro, dalla disponibilità di spazi per fare delle pause durante il processo.

Come con altri elementi, il cambiamento è sempre fondamentale!

Spiegare le cose da fare

In che modo è possibile presentare le varie attività che saranno svolte in una retrospettiva? In che maniera è possibile spiegarle al team? Ecco alcuni aspetti da tener presenti, relativamente al gruppo.

Livello di attenzione

Quando si parla, il quantitativo di informazioni che i nostri ascoltatori trattengono dipende dal loro livello di attenzione. Semplificando, il livello di attenzione può essere scomposto in due stati: una fase “accesa” in cui gli ascoltatori capiscono quello che stiamo dicendo, e una fase “spenta” in cui non ascoltano semplicemente perchè sono impegnati ad elaborare quanto hanno appena ascoltato. La cosa interessante è che i tempi di fase “accesa” e “spenta” variano da persona a persona: pertanto, in un gruppo, questa alternanza è ovviamente asincrona. Questo significa che il gruppo recepirà il nostro messaggio in maniera diversa a seconda dei processi di comprensione ed elaborazione individuali di ciascun singolo componente del gruppo. Proprio per questa ragione è necessario essere ridondanti nel comunicare i concetti al team. Può inoltre aiutare molto qualche sistema per visualizzare quel che si intende dire.

Memoria di gruppo

Il gruppo ha una memoria più corta rispetto a quella della singola persona. In alcuni casi, qualcuno nel gruppo farà domande riguardo a concetti e informazioni che ha dimenticato: è normale. Per questo ribadiamo che è buona pratica quella di avere un promemoria visuale delle cose che chiediamo di fare al nostro gruppo, tipo, ad esempio, rendere visibili le istruzioni per eseguire l’attività proposta scrivendole sulla lavagna.

Contestualizzare le informazioni

Le varie persone elaborano le informazioni in modo differente, quindi, quando si spiega qualcosa, e non necessariamente a proposito delle retrospettive, può fare molta differenza il modo in cui si collocano le informazioni all’interno di una cornice, vale a dire come le si contestualizzano. Un modo semplice per farlo consiste nel catalogare l’informazione suddividendo il tema in tre semplici aspetti:

• qual è l’argomento;
• perchè è importante;
• quando e in quale contesto tale argomento è importante.

Con l’informazione declinata su questi tre semplici punti, i nostri ascoltatori avranno a disposizione una modalità più semplice per catalogare le informazioni che ascolteranno.

Superare i blocchi

Nulla è più frustrante di rimanere bloccati in una discussione che, con gli elementi di conoscenza disponibili al momento, non può essere risolta. In genere, al facilitatore è consigliato di non aggiungere contenuto, vale a dire di lasciare che il gruppo trovi un modo per risolvere i suoi problemi. Ciò nonostante, ho notato svariate volte che potrebbe trattarsi di un caso in cui il team non ha informazioni sufficienti a procedere: in questi casi, potrebbe valere la pena di interrompere la retrospettiva e cercare un esperto in quel dominio che possa fornire le informazioni necessarie per “sbloccare” il gruppo.

L’esempio tipico è quello in cui il team non sa prendere la decisione migliore su un elemento del processo. In questa situazione, lo ScrumMaster può fermare temporaneamente la retrospettiva, “cambiare cappello” (vedi sotto), spiegare alcune cose, ad esempio buone pratiche implementate in altri contesti, e poi far ripartire la retrospettiva. Sebbene sia personalmente più propenso a far decidere il team, una discussione inutile che va avanti per tanto tempo è frustrante per il team molto più che la necessità di chiedere un piccolo aiuto esterno.

Rispondere al cambiamento più che seguire un piano

Il Manifesto per lo sviluppo agile di software recita “Rispondere al cambiamento più che seguire un piano”: è un concetto valido anche per le retrospettive. Il nostro ruolo è di supportare il gruppo con il quale stiamo svolgendo opera di facilitazione, quindi è di primaria importanza che ciò che si fa per loro risulti effettivamente utile per il gruppo.

Sebbene pianificare una retrospettiva sia una attività fondamentale che ciascun facilitatore deve svolgere, spesso la situazione che si evolve in una determinata direzione finisce per richiedere qualcosa di diverso rispetto a quanto pianificato: se il nostro piano prestabilito non supporta le reali necessità del gruppo, allora va cambiato, adattato e reso a misura di ciò effettivamente serve al gruppo.

L’aspetto di “discrezionalità” della nostra facilitazione è in questo caso un elemento cardinde: è possibile reimbastire una retrospettiva utile se quanto inizialmente pianificato non funziona? Di seguito presentiamo alcuni esempi che spiegano meglio questo concetto.

Conflitto tra persone

Mentre si sta discutendo un certo argomento, vi rendete conto che tra due persone c’è un evidente conflitto, anche se poi entrambi non vogliono affrontare la questione. In questo caso è possibile:

• continuare a seguire il piano prefissato oppure
• cambiare argomento e inserire questo conflitto nel giusto contesto, mettendolo in luce e moderandolo una volta che sia emerso.

Mancanza di visione globale

Si sta svolgendo una attività del tipo “Mad-Sad-Glad”, ma diventa chiaro che il gruppo non ha una chiara visione globale degli eventi di quella iterazione. A questo punto si può:

• continuare a far svolgere il compito del “Mad-Sad-Glad” con il rischio di generare risultati incompleti o imprecisi oppure
• effettuare una veloce ricapitolazione temporale degli eventi per generare i dati necessari prima di riprendere l’attività “Mad-Sad-Glad” o similare che si stava conducendo.

Gruppo stanco

Mentre si svolge una retrospettiva, ci si rende conto che il team è stanco, dopo uno sprint molto impegnativo. È possibile:

• continuare comunque con la retrospettiva oppure
• trasformarla in un evento “sociale” con l’opportunità di svolgere un po’ di attività di team building.

Ovviamente, la decisione che si prenderà in ciascuno di questi casi è strettamente legata al contesto e dipende molto dal vostro stile, dalla vostra strategia e anche da quello che è il vostro ruolo all’interno dell’organizzazione: in qualità di coach potreste scegliere qualcosa di diverso rispetto alla situazione in cui siete ScrumMaster o a quella in cui siete facilitatore esterno. Un importante fattore è rappresentato anche dalla conoscenza della storia recente degli eventi che hanno portato il team a quella retrospettiva.

Il punto su cui voglio insistere è che dovreste essere pronti a cambiare il format della retrospettiva se questo è ciò che rende il servizio migliore al gruppo. La maggior parte delle retrospettive in cui faccio il facilitatore richiedono in qualche modo un certo cambiamento di direzione, anche solo minimo. In certi casi, ho dovuto cambiare il format in maniera piuttosto radicale, e anche questo va bene se si è preparati a gestire questa situazione con flessibilità e scioltezza. È di grande aiuto l’essere onesti con le persone, dicendo chiaramente che ci si sta rendendo conto che quanto era stato pianificato non corrisponde alle loro esigenze e… fornendo loro, molto semplicemente, una struttura più adatta: resterete sorpresi delle reazioni positive che riceverete!

Aspetti positivi e negativi

Un limite tipico delle persone che cominciano a fare retrospettive senza averne precedente esperienza è il concentrarsi sugli aspetti negativi, su quello che deve essere cambiato. Certo, è vero che vogliamo capire che cosa si dovrebbe migliorare: tuttavia, è importante mettere sul tavolo anche ciò che ha funzionato e quello che il team ha fatto bene.

Un aspetto che faccio notare a molti team, e che li sorprende molto nonostante l’ovvietà, è che perfino il peggior gruppo di lavoro nell’organizzazione riesce comunque a fare molto di più di quello che farebbe un numero analogo di persone prese a caso dalla strada e messe a svolgere quel lavoro.

Come facilitatori, dobbiamo sempre ricordare che il gruppo sta svolgendo un’attività molto complessa, che non molti altri potrebbero fare e, soprattutto, dobbiamo rammentarlo al team: per quanto il gruppo possa avere tanti problemi da risolvere, essere dove sono loro richiede comunque una certa dose di successo pregresso che è una risorsa molto importante su cui costruire, sia da un punto di vista emozionale che razionale.

Pertanto, si rende un servizio al proprio team anche chiedendo loro di elencare ciò che di positivo ha funzionato, e ciò che sulla base di questo si dovrebbe ulteriormente ripetere in futuro.

Mantenere “accesa” la retrospettiva

A volte una retrospettiva si blocca: ci sono degli argomenti riguardo ai quali un team non riesce a procedere veramente in maniera autonoma. Ci possono essere varie ragioni per questi blocchi, e ne riportiamo qui alcune.

Mancanza di “giurisdizione”

Ci possono essere dei problemi su cui il team non ha autorità, non ha “giurisdizione”: pensiamo ad esempio a un processo dell’azienda che magari il team vorrebbe cambiare, ma che non può modificare perchè non ne ha autorità e c’è qualche “cane da guardia” dell’azienda che ne è invece responsabile e dovrebbe dare il suo consenso al cambiamento.

Errata struttura della discussione

In certi casi, la discussione impiega una struttura sbagliata. Per esempio, può succedere di discutere di un argomento affrontandolo in termini di dicotomia (bianco/nero, acceso/spento, attivo/disattivo, facciamo A oppure B, …), quando invece siamo effettivamente in presenza di un continuum e le opzioni a disposizione sono, veramente, tutti i valori di grigio presenti tra le opzioni considerate.

Manca la conoscenza specialistica

Potremmo cominciare a discutere di scienza aerospaziale ma, a meno che qualcuno di noi non abbia una conoscenza specialistica dell’argomento, non faremo grandi progressi. Si tratta di una situazione molto comune: ho visto molti team discutere di argomenti come il posizionamento del prodotto sui mercati, la strategia per penetrare il loro mercato di riferimento, o anche di tecnologie di cui nessuno era esperto, con il risultato che la discussione non arrivava ad alcun risultato. Questo succede quando nel meeting manca la conoscenza specialistica o un esperto di un determinato argomento.

Discussione bloccata su un aspetto secondario o su problemi personali

Capita che la discussione si avviti su un elemento secondario oppure che essa si focalizzi su aspetti personali, con il rischio di finire in una situazione conflittuale.

Si tratta di casi diversi ma, il sintomo è simile: la discussione non sta producendo valore, ma anzi sta consumando il tempo a disposizione. Oltre a ciò, questa situazione può condurre il team a una modalità negativa e improduttiva che danneggerà l’intera sessione e, in alcuni casi, finirà addirittura per mettere a rischio le retrospettive future, poichè esse saranno considerate inutili.

Pertanto, il ruolo del facilitatore è di riportare la riunione a uno stato di produttività: la cosa da fare è rompere questo meccanismo negativo che si è instaurato e, per farlo, ci sono diverse possibilità.

• Un primo comportamento potrebbe essere quello di mostrare (come uno “specchio”) quello che sta succedendo e lasciare poi al team la decisione su come continuare.
• Il facilitatore può anche riformulare quello che ha compreso e verificare se il gruppo vuole continuare a parlare dello stesso argomento.
• Altra possibilità è quella di chiedere al gruppo se l’argomento di discussione può essere risolto veramente qui e ora: in caso negativo, chiedere quali azioni si possano intraprendere per risolverlo, dopo la retrospettiva.
• In casi estremi: spiegare la situazione di conflitto, decidere di cambiare argomento e… farlo. È chiaro che un po’ di “command and control” ci farà fare un passo indietro nella strada all’auto-organizzazione, ma diventa un piccolo prezzo da pagare se l’alternativa deve essere una negatività del gruppo nei confronti delle retrospettive.

Ovviamente, se la discussione si blocca, c’è una ragione: occorre cercare di capirla e di affrontarla e, nella mia esperienza, questo potrebbe richiedere più tempo di quello che abbiamo a disposizione in una tipica retrospettiva, quindi rimanderei queste azioni a una fase successiva.

Un invito alla cautela per il facilitatore esterno: dal momento che spesso non si è perfettamente a conoscenza dei problemi del team, queste situazioni potrebbero non risultare immediatamente evidenti: questo è uno dei pochi casi in cui una comprensione del contenuto del meeting risulta essere un asset.

“Incorniciare” la discussione

Quando si descrivono le attività che vorremmo fossero svolte dal gruppo, è molto importante spiegare in maniera corretta in cosa consistono e come funzionano. In un gruppo formato da diverse persone, ci sono sempre idee e opinioni differenti su ogni argomento; quindi, più si è precisi, meglio è.

I significati di “precisione”

Quando parliamo di precisione, intendiamo diverse sfumature di significato per questa parola.

Anzitutto, la precisione nella terminologia che si usa. Occorre cercare di corrispondere al gergo del gruppo in maniera più aderente possibile: vanno usati i loro termini tecnici e va adattato il nostro linguaggio alla loro realtà. Più lo si fa, meglio è.

C’è poi una precisione a livello semantico: cosa esattamente volete che facciano i componenti del gruppo? Immaginiamo di chiedere loro di parlare della “qualità”: che cosa significa veramente “qualità”? Se chiediamo di parlare della “qualità dei test di unità automatici nella porzione back-end del sistema” potremo avere maggiori possibilità che il team discuta realmente del problema invece di stare solo a girarci intorno. Dal momento che state lavorando nella realtà del gruppo, spesso termini come la “qualità” dell’esempio appena visto derivano dal gruppo stesso: è importante per il facilitatore rendersi conto delle imprecisioni di significato, chiedere al team qual è il significato effettivo che danno a quel termine e poi farglielo usare nella discussione che si affronta.

Framing

Questo sforzo di descrivere adeguatamente l’attività al gruppo ricade sotto il nome di framing (“incorniciare”, “inquadramento”) ed è di fondamentale importanza quando si lavora con gruppi di persone

Un buon formato per inquadrare un argomento è il seguente:

• di cosa si tratta (cosa?);
• qual è lo scopo (per cosa?);
• quando è importante (quando? in quale contesto?).

Un esempio completo basato sul termine “qualità”, rispetto all’esempio riportato sopra, potrebbe essere il seguente: “Vorrei invitarvi ora a parlare della (cosa?) qualità dei test di unità automatici nel lato back-end del sistema. Avete stabilito che è molto importante (per cosa?) poichè vi sta costringendo a fare troppi test manuali e siete convinti che questi sforzi sarebbero meglio indirizzati a sviluppare più codice.  Ma, al fine di garantire una buona qualità generale, tutto questo processo di testing dovrebbe essere fatto automaticamente. (Quando?) Alcuni di voi ritengono che questa esigenza dovrebbe essere affrontata, altri pensano che ciò impatterà negativamente sulle prestazioni del team nei prossimi sprint”.

Si può notare come gli elementi dell’esempio sopra riportato vengano tutti da quanto “prodotto” nella discussione del gruppo. Come ho già affermato altre volte, si sta lavorando nella loro realtà, e quindi quel che si usa per il framing dovrebbe anch’esso provenire da loro.

Sottogruppi

Diverse attività della retrospettiva richiedono che le persone producano dei “lavori”: con la timeline vengono riepilogati i diversi eventi dello sprint; con la tecnica Mad-Sad-Glad vengono raccolti e valutati diversi argomenti, e così via.

Queste attività possono essere svolte individualmente, con le singole persone che lavorano da sole, e poi i risultati saranno presentati al gruppo. In effetti, però, trovo molto interessante anche che le persone lavorino in piccoli sottogruppi, in maniera tale che possano confrontare le loro idee con alcuni colleghi e “raffinarle” prima di esporle all’intero gruppo.

In questo caso, ci sono alcune possibilità creative per creare i sottogruppi sulla base delle esigenze del gruppo con cui si sta lavorando, che andiamo a vedere di seguito.

Sottogruppi per affinità di attività svolta

Si possono raggruppare le persone mettendo insieme alcuni colleghi che abbiano svolto lavori e attività simili durante l’iterazione o il periodo presi in considerazione nella retrospettiva. Questo fornirà al facilitatore il massimo dell’informazione sui vari argomenti specifici, ma potrebbe portare anche a un “pensiero settoriale” per il sottogruppo. Oltre a ciò, se il team ha già dei profili molto specializzati, questo tipo di sottogruppi potrebbe condurre a risultati che solo una parte del team sarà in grado di comprendere.

Sottogruppi per diversità di attività svolta

Si può fare l’esatto contrario di quanto appena visto, ossia raggruppare persone che, durante lo sprint, abbiano svolto attività piuttosto diverse. Questo garantirà al facilitatore una differenziazione a livello di sottogruppi e condurrà il piccolo insieme di persone a sviluppare idee interessanti, anche se a volte risultano un po’ superficiali. Da un punto di vista delle dinamiche di gruppo, questa configurazione del gruppetto ha il vantaggio di favorire la creazione di nuovi legami tra i membri del team, migliorando così il lavoro di squadra.

Proteggere le voci minori

Nelle organizzazioni ci sono naturalmente persone meno portate a parlare in pubblico e più introverse, e persone più estroverse che si esprimono apertamente in un gruppo, giungendo a volte addirittura a prevaricare inconsapevolmente le “voci minori”. Può essere una buona pratica quella di “proteggere” chi è più timido e introverso, scegliendo per loro sottogruppi in cui possano interagire in un ambiente tranquillo, senza la presenza nello stesso gruppo delle personalità estremamente estroverse che potrebbero metterli in ombra. In questo modo si favorirà l’espressione di opinioni che normalmente non emergono dal team proprio perchè sono bloccate dalla presenza delle opinioni manifestate dai più chiacchieroni.

Evitare le “tempeste”

Evitare gli scontri, collocando in sottogruppi differenti le persone che abbiano tra loro conflitti latenti. Ovviamente, una volta che i risultati saranno condivisi nella discussione dell’intero gruppo, potrebbe esserci la necessità di gestire il conflitto, ma almeno questo non si verificherà in una discussione che il facilitatore non può controllare.

Favorire le “tempeste”

Può invece essere il caso di favorire gli scontri, collocando persone con un conflitto latente nello stesso sottogruppo. Questo potrebbe portare a generare l’energia necessaria per una franca e aperta discussione successivamente. Questa opzione (e la precedente) sono scelte “creative” che si può decidere di mettere in atto basandosi su una sensata valutazione del conflitto: se si ritiene che il conflitto possa esplodere nel sottogruppo, meglio evitare questa opzione e scegliere la precedente. In ogni caso… è una scommessa.

Favorire i sottogruppi “naturali”

Se ci sono dei gruppi “naturali” (persone che lavorano sulla stessa attività all’interno del team di sviluppo, persone dell’organizzazione provenienti da diversi gruppi ma che affrontano argomenti comuni, persone con problemi comuni etc.), si potrebbe prendere in considerazione di lasciarli in sottogruppi omogenei in maniera che possano discutere tra di loro dei loro problemi; occorrerà tuttavia trovare un modo per poi riportare l’informazione all’intero gruppo e convergere su una soluzione su cui l’intero gruppo possa concordare.

Evitare i sottogruppi “naturali”

Come avrete intuito, potrebbe invece essere il caso di scomporre deliberatamente i gruppi naturali favorendo l’inserimento delle persone all’interno di altri sottogruppi, in maniera da promuovere una discussione tra gruppi. La nostra retrospettiva sarà in genere più vivace, ma si potrebbe anche rischiare qualche conflitto in ciascun sottogruppo che si sta formando.

Dot voting

Una retrospettiva svolta con un team che sia mediamente reattivo genera decine di idee su cui lavorare, e diventa quindi necessario ordinarle secondo una certa logica, sulla base di quanto certi argomenti interessano il team. La modalità tipica per farlo è di applicare una qualche forma di democrazia e votare sui vari argomenti, utilizzando il sistema del dot voting ossia ponendo un post-it o scrivendo un segno con il pennarello in prossimità della voce che si intende votare.

Il dot voting è un sistema di voto per cui ciascun partecipante ha un certo numero di voti a disposizione (tratti di pennarello i post-it) che può distribuire sulle varie voci come meglio crede. Il dot voting è una attività piuttosto semplice, ma ci sono alcuni parametri che possono essere usati in maniera creativa, ed è proprio quello che vedremo in queste righe.

Una delle domande tipiche che mi vengono poste dagli ScrumMaster all’inizio della loro attività è “ma quanti voti devo mettere a disposizione dei partecipanti?”. Secondo me non c’è un’unica risposta giusta a questa domanda: direi che un buon equilibrio potrebbe essere di avere abbastanza voti per essere in grado di scegliere da un terzo alla metà delle opzioni, con la tendenza a ridurre il quantitativo di voti al crescere delle dimensioni del gruppo, per ridurre i tempi di votazione. Ritengo che un maggior “capitale” di voti esprimibili non aggiunga valore significativo e che, d’altro canto, concedere possibilità di voto più ridotte porti i partecipanti a lamentarsi del fatto che ci sono delle opzioni per cui non sono in grado di votare perchè hanno finito i voti a disposizione.

Un’altra domanda che mi viene posta spesso è se sia il caso di vietare alle persone di “spendere” più di un unico voto per una sola scelta, oppure sia invece consentito di mettere più voti su una sola opzione. Anche qui si tratta, in effetti, di una scelta creativa: se si ritiene che ci siano alcuni argomenti che potranno essere rilevanti solo per una minoranza del gruppo, ma che per questa minoranza risultino molto importanti, al punto di causare tensione se non verranno affrontati, allora è il caso di consentire di mettere più voti su una sola scelta, in maniera che le persone possano concentrare il loro voto su aspetti magari minori, ma davvero importanti per loro.

Ecco di seguito alcune scelte creative che uso a volte se ritengo che possano aiutare a rendere un miglior servizio al gruppo.

Voto segreto

Uso il voto segreto invece che il voto palese quando siamo in presenza di temi “sensibili” ma anche quando vedo che ci sono persone che votano tardi in modo da capire dove il loro voto possa fare la differenza e far virare la votazione a loro favore.

Due tipologie di voti

Ogni persona ha a disposizione un certo numero di voti normali e un voto speciale che indica una tematica da discutere/affrontare/implementare obbligatoriamente (voto “must have“). Si tratta di un modo per dare la possibilità alle “voci minoritarie” nel gruppo di mettere un voto su un argomento che debba comunque essere discusso, indipendentemente dal numero di voti normali che riceverà.

Voti per categorie

È possibile anche stabilire un certo quantitativo di voti per ciascuna categoria di elementi, in maniera che sia possibile individuare gli elementi più importanti in ciascuna categoria.

Una nota su flessibilità e attenzione ai dettagli

In tutta la nostra trattazione sulle retrospettive, abbiamo più vote fatto riferimento alla flessibilità: flessibilità di scegliere quello che meglio si adatta al gruppo presso cui svolgiamo l’attività di facilitatori. La maggior parte delle decisioni su quel che fare dipende dalle reazioni che si ricevono agli individui del gruppo.

Normalmente siamo anche esperti del contenuto che viene condiviso durante una riunione. Si tratta di un aspetto importante da considerare, ma decisamente non del più importante e, in veste di facilitatori, potrebbe addirittura risultare un ostacolo sulla nostra strada. Pensate, ad esempio, quante volte durante la facilitazione di una retrospettiva ci capita di “cambiare cappello” e metterci nei panni dell’esperto di dominio che comincia a lavorare con il team per risolvere i loro problemi fornendo soluzioni e indicazioni direttive. Sebbene ciò possa essere necessario in alcuni casi, e lo abbiamo visto all’inizio, nella maggior parte dei casi non si tratta di una cosa positiva. Di fatto, essere ignoranti riguardo a certi aspetti tecnici del contenuto della retrospettiva potrebbe rendere la situazione più semplice, poichè solleva il facilitatore da questa incombenza e lo aiuta a concentrarsi sulle necessità del team.

Dettagli importanti

Ci sono, tuttavia, altri aspetti dell’interazione che di solito non prendiamo in considerazione o che consideriamo solo in maniera poco attenta. Questi sono invece quelli su cui dovremmo concentrare l’attenzione, perchè ci forniscono uno sguardo maggiormente approfondito su quel che sta succedendo e su ciò di cui il team ha veramente bisogno.

Vediamo ad esempio alcuni aspetti non verbali: qual è la voce “normale” di ciascun partecipante, e in che modo stanno parlando adesso? Se si pone molta attenzione, si noteranno dei cambiamenti nel tono della voce che dipendono dallo stato emotivo interiore delle singole persone. Questi cambiamenti cambiano da persona a persona, sebbene esistano alcuni pattern ricorrenti: i cambiamenti possono riguardare il volume, la velocità a cui si parla, la cadenza, il tono…

Quando si comincia ad ascoltare attentamente, si noteranno sicuramente le differenze. Resta, ovviamente, il problema di capire che cosa significhino queste differenze. Qui c’è un problema e dipende dal fatto che in tanti tendiamo a interpretare questi segnali in base al nostro modo di vedere il mondo: “Ecco! Ha alzato il volume della voce, quindi deve essere arrabbiato!”. Ma applicare il nostro modello di interpretazione della realtà agli altri non funziona.

Linguaggio non verbale

Ci sono due modalità per imparare a interpretare in maniera ragionevolmente corretta questi segnali, questi dettagli: uno è più difficile, l’altro è più facile.

Il modo più difficile è quello di studiare e memorizzare le caratteristiche rilevanti degli stati significativi delle persone. Per questo occorre buona memoria ed esempi della persona in quei determinati stati: per capire se una persona è arrabbiata, occorre averla vista arrabbiata diverse volte in svariate situazioni. Questo può essere una possibilità diffusa per uno Scrum Master, ma magari un facilitatore esterno non avrà questo tipo di possibilità.

La modalità facile consiste nel… chiedere. In qualità di facilitatore, per voi è possibile fungere da “specchio” e dare voce alle differenze che notate, rendendole evidenti all’intero gruppo: “Ho notato che la voce di Tommaso è cambiata, mentre stava parlando di questo argomento. Tommaso, vuoi dirci qualcosa in più riguardo a quello che stai provando?”. Questo funziona molto bene nelle retrospettive, ma va usato con moderazione e solo se si è sicuri che la persona sia disposta a condividere i suoi sentimenti. Se la persona rifiuta, va comunque bene ed è preferibile passare ad altro: magari ha semplicemente bisogno di maggiore tempo per arrivare a questo tipo di aperta condivisione delle proprie emozioni.

A dire il vero, esiste un’ulteriore possibilità: si fa un’ipotesi e la si mette alla prova, sapendo che potrebbe benissimo non corrispondere alla realtà. “Ho notato che Tommaso ha avuto una reazione non verbale che mi spinge a pensare che non sia d’accordo con quello che ha appena detto il suo collega. Tommaso, vuoi dirci qualcosa in più al riguardo?”.

Oltre alla voce, ci sono altri parametri che si possono imparare a riconoscere:

• espressioni facciali;
• gestualità e atteggiamenti del corpo; attenzione però a non adottare l’approccio meccanicistico insegnato dai libri sul linguaggio corporeo, che possono essere anche corretti nella media, ma che non è affatto detto siano esatti per la peculiare situazione con cui stiamo lavorando;
• colorito della pelle;
• tensione muscolare;
• schemi respiratori;
• e molto altro…

Imparando seriamente ad analizzare tutte queste variabili, si potranno raccogliere molte più informazioni su cui basare le proprie decisioni.

Conclusioni

Conoscere principi, strutture e metodi della retrospettiva non farà di noi dei bravi facilitatori se tali concetti non vengono integrati da un’esperienza continua, da flessibilità e adattamento alle situazioni e da un certo numero di “trucchi” del mestiere. In questo articolo abbiamo presentato appunto diversi suggerimenti derivanti dell’esperienza; concluderemo nel prossimo articolo la discussione, completando questo elenco di consigli per far funzionare al meglio le retrospettive.