Quando un’azienda ha il proprio team di sviluppo in Full Remote Working, occorre curare l’intesa tra i componenti del team con maggiore attenzione: è difficile che si organizzino tra loro per un calcetto o una pizza, specie se uno vive a Milano, uno in Calabria e l’altro a Singapore.

Chiunque abbia gestito un team di sviluppo sa che c’è una mezza giornata lavorativa alla settimana che è un’eclissi: il venerdì pomeriggio:

• Di venerdì non si analizzano nuove funzionalità, si rimanda sempre al lunedì
• Di venerdì non si rilascia mai, è una legge non scritta dettata dall’esperienza
• Di venerdì si è stanchi del carico di lavoro settimanale, e proiettati verso il weekend

Non esiste quindi momento migliore per fare team building senza influire sulle performance di sviluppo.

Questa settimana ho avuto a che fare con un nuovo team, che lavora bene ed è abbastanza in sintonia. La settimana lavorativa è andata avanti compiutamente senza aver mai task bloccati in kanban.

Il team è molto eterogeneo e a compartimenti stagni, questo non favorisce l’integrazione perché sul lavoro hanno poche occasioni di confrontarsi.

Ieri, alla prima occasione di team building, mi sono inventato un hackaton con delle regole non dette dall’inizio e un sistema di punteggi.

Ho scelto un linguaggio di programmazione che nessuno nel team padroneggiava: si sarebbero dovuti affidare alla documentazione ed all’improvvisazione.

Con uno strumento di lavoro condiviso, lavorando sullo stesso codice, il team ha ricevuto dei task da completare entro 15 minuti: se riusciti davano dei punti positivi (il tempo avanzato) se sforati dei punti negativi (il tempo in più).

Il task iniziale era scegliere un pokemon a caso dalle Pokemon Api e visualizzarlo.

In seguito si sono susseguiti dei task per migliorare l’applicazione: ogni turno sceglievo un componente del team a caso, e questi stabiliva il task successivo.

Siamo arrivati in meno di 3h ad avere un combattimento di base tra pokemon, certo graficamente molto semplice e lontano da quello del videogioco, ma lo scopo non era quello.

Che cosa si è ottenuto realmente?

• I ragazzi hanno lavorato tutti sullo stesso codice, si sono ostacolati tra loro, hanno riso, scherzato, dialogato, trovato un metodo.
• Anche i più ansiosi e riflessivi si sono trovati liberi dal pensiero analitico e, visti i tempi, a improvvisare.
• La mancanza di esperienza sul linguaggio Dart, che ho usato in questo esperimento, metteva tutti allo stesso livello.
• Nel lavoro di gruppo si sono comunque evidenziate le personalità dotate di leadership.
• Dopo l’esperimento si delineava tra loro cosa era andato bene e cosa male, cosa migliorare la prossima volta. (L’esperimento quindi ha fissato un codice che ci si aspetta naturalmente sia ripetuto)
• Si è pensato di fare un Grand Prix di hackaton e di dare dei premi al raggiungimento di una somma ingente di punti. Denaro dell’azienda che sarà speso bene visti i risultati sul team.

Ovviamente le occasioni e i modi di fare team building anche in remoto sono innumerevoli, e le modalità infinite, l’unico errore da commettere è non farlo.

E voi come costruite fiducia e collaborazione nel vostro team remoto?