###### tags: `teamwork` `opinions`

# Divide et Impera!
> Stanchi di lunghe e infruttuose call di "brainstorming"? Provate il potere delle breakout rooms!

Quale voto date all'ultima retrospective alla quale avete partecipato? O all'ultima code review?

Come technical coach, mi ritrovo spesso a partecipare a sessioni di brainstorming o planning (code review, sessioni architetturali, retrospectives, backlog refinement, etc) con tante persone, dev e non.
Una delle conseguenze che la pandemia di COVID-19 ha portato nel nostro lavoro è che tutte queste sessioni sono per forza di cose remote; siamo insomma diventati - volenti o nolenti - degli animali da videocall, e passiamo con *nonchalance* da una call Zoom/Teams/Google Meet/... all'altra.

Uno degli effetti più negativi che ho notato passando da sessioni co-localizzate a sessioni remote è la difficoltà di partecipazione di tutte le persone: vuoi per postura spesso passiva che assumiamo, stando tutti seduti davanti ad un monitor, vuoi per la facilità con la quale possiamo eclissarci, vuoi per altre distrazioni che ci arrivano dal nostro pc o dall'ambiente esterno, spesso noto che nelle sessioni remote intervengono sempre i "soliti noti", o quelli molto sicuri di sè, o quelli estroversi, o quelli che si sentono in dovere di intervenire perché sono i "technical leaders", lasciando nell'ombra i molti altri.

Non voglio con questo articolo proporre niente di rivoluzionario né in grado di risolvere tutti i problemi dovuti al lavoro da remoto (che poi ha anche molti vantaggi, ben inteso).
Vorrei solo proporre una semplice tecnica che ho visto funzionare, che già adottavo nelle sessioni colocalizzate ma che ho tardato ad introdurre anche in quelle remote: la suddivisione dei partecipanti in piccoli gruppi.

Per farvi capire, vi racconto come si è svolta l'ultima sessione a cui ho partecipato come facilitatore: si trattava di un incontro per discutere di alcune scelte architetturali che avrebbero avuto impatti su tutti i team dell'organizzazione.

Innanzitutto ho cercato di non limitare la discussione solo ai senior dei vari team, ma di coinvolgere quanti più membri di tutti i team, per essere sicuro di averli tutti "a bordo", attivi propositori del loro destino piuttosto che meri esecutori o "implementatori di specifiche". Il numero dei partecipanti non ci spaventava, anche perché lavorando per gruppi è facile suddividere un grosso numero di persone in tanti piccoli gruppi.

Per la call abbiamo usato Zoom, che è dotato dell'essenziale funzionalità di "breakout rooms" (le stanze virtuali nelle quali far lavorare i vari gruppi). Per fortuna tale feature è ora disponibile anche in Microsoft Teams e in Google Meet.
Abbiamo poi predisposto una board online (nel mio caso ho usato [MetroRetro](https://metroretro.io/), ma ottime alternative sono Miro, Mural o Google Jamboard), assicurandomi che tutti avessero accesso alla board.

Dopo aver speso i primi 15 minuti a spiegare i motivi e gli obiettivi della sessione, per assicurarmi che tutti avessero le idee chiare su come contribuire, abbiamo diviso i partecipanti in gruppi di 4 persone (3-4 persone è il numero giusto in questi casi, non di più).

Nella successiva mezz'ora, ogni gruppo ha potuto confrontarsi, discutere e raccogliere le proposte e idee provenienti da ognuno.
Nel frattempo la board si è popola di post-it, segno che i gruppi stavano lavorando bene.


Il facilitatore può in questi casi saltare da una stanza all'altra, per assicurarsi che il gruppo non sia bloccato nella discussione e mantenga il focus sul tema.

Quando la board era oramai quasi totalmente invasa di post-it, abbiamo riportato tutti i gruppi nella stanza principale di Zoom.
I gruppi si sono poi confrontati tra loro per ragionare sulle opzioni emerse e sulle considerazioni raccolte, raggruppando tematiche simili avvicinando tra loro i relativi post-it (il famoso "clustering").

Quello che ho notato subito è che, nuovamente riunite, tutte le persone hanno partecipato alla successiva discussione. Questo è un primo effetto del lavoro in gruppi: le persone si "sbloccano" nel proprio gruppo, iniziano a sentirsi coinvolti e poi non si fermano più, anche una volta rientrati nella stanza plenaria.

La suddivisione in gruppi è efficace in tutte le riunioni (remote e non) dove la partecipazione e il contributo di tutti è essenziale per il successo dell'iniziativa (e faccio fatica a trovare riunioni dove questo non sia necessario...).

D'altra parte non invento nulla, il primo riferimento all'uso di questa tecnica l'ho avuto anni fa venendo in contatto con [Liberating Structures](https://www.liberatingstructures.com/), un insieme di tecniche di facilitazione molto efficaci e divertenti! Molti dei formati proposti in Liberating Structures fanno affidamento sulla divisione in gruppi, ad esempio [1-2-4-All](https://www.liberatingstructures.com/1-1-2-4-all).

Vorrei concludere con due note.

Primo: vedo la divisione in gruppi come un momento di una sessione, che deve sempre avere una parte iniziale di introduzione dove si è tutti assieme e una parte finale di chiusura dove ancora si è tutti assieme.
La stessa parte di sintesi finale può essere fatta in gruppi o tutti assieme: ad esempio il *"dot voting"* usato per prioritizzare le opzioni emerse si può fare dividendosi in gruppi (meglio se diversi da quelli adottati precedentemente) piuttosto che in modo individuale, così da "costringere" le persone a confrontarsi e a convergere sulle opzioni ritenute più valide.

Una tecnica che si può adottare qui è quella di dividere in gruppi da due persone, e dare loro 3 voti, così da costringerli a convergere con almeno un voto su una opzione condivisa.

Infine, quando non è opportuno dividere in gruppi i partecipanti ad una discussione? Quando la discussione verte su temi valoriali (ad esempio se state facendo una sessione per far emergere i valori della vostra azienda) è meglio non ricorrere troppo ai gruppi, anche perché spesso in questi casi le persone non avranno problemi a dire la loro.

Provate quindi ad adottare questa tecnica nel vostro prossimo evento remoto di team, che sia una retrospective, un backlog refinement, una code review, o altro, e fateci sapere come è andata!