Capire i problemi dei teams.
Prima di tutti grazie Pierluigi Pugliese per le cose che ci insegni e ci trasmetti ogni volta che partecipiamo ad un tuo intervento o Meetup.
Come ogni buon settembre ci facciamo dei buoni propositi, uno dei miei è di tenere traccia e ricondividere su Agile For Italy quanto apprendo nei vari Meetup ed eventi. Ho la fortuna di vivere a Milano, città di cui si possono dire tante cose negative ma non che non ci siano opportunità di partecipare ad eventi. La ormai sterminata presenza di Meetup richiede una certa capacità di scrematura, ma soprattutto far tesoro di quanto si ascolta e si condivide. Ho una bella memoria ma vorrei mettere ordine al cervello partendo dal buon “Verba volant, scripta manent”. Sicuro di avervi impressionato con il mio latino, andiamo avanti, sempre sobriamente come piace a noi.
Pierluigi Pugliese ci ha raccontato di questa ricerca decennale di alcuni ricercatori tedeschi, poco conosciuta ma molto potente. Ahimè solo in tedesco e come avete visto io sono bravo in latino. Ho cercato in tutti i modi di trovare “sull’internet” informazioni a riguardo, ma niente. Nei miei appunti avevo segnato “Syst”, prego chiunque abbia materiale non verbale di arricchire quanto sto scrivendo.
Cosa possiamo fare con teams disfunzionali?
Questa la domanda che spesso ci facciamo quando siamo di fronte ad un team che non ingrana. Le proviamo tutte e non funzionano. In questa ricerca sono stati ricondotti i vari problemi a 4 categorie molto chiare, riconducibili a 4 principi che di fatto compongono le regole sociali e comportamentali dei teams.
1° principio: l'appartenenza
Il senso di appartenenza ad una squadra è senza dubbio una marcia in più. Accende qualcosa in noi che ci aiuta a creare una nostra identità all’interno di un gruppo sociale. Non è detto che porti solo vantaggi (ad esempio essere troppo tifosi di una squadra di calcio o di una corrente politica può portare ad una certa perdita di lucidità).
PROBLEMA: all’interno di un team non si capisce chi ne faccia davvero parte.
Se ci pensate possono essere veramente tanti gli indizi, da persone che apparentemente sembra non fregargliene niente a membri del team che lavorano X% del loro tempo perché fanno anche altro. Ma cosa possiamo fare?
CURA
Soltanto definendo in maniera chiara chi fa parte di un team possiamo perimetrare il sistema e quindi agire correttamente. Una volta deciso chi fa parte del team avremo in parte risolto il problema, ma non basta. La prima cosa da fare è riconoscere l’esistenza del problema, ad esempio: “Caro Mario, capiamo che c’è questo problema, partecipi poco alle attività di team visti i tuoi ulteriori impegni con altri team.”. La trasparenza è fondamentale.
Se qualcuno si sente estraneo o si auto-esclude è necessario capire cosa lo renda tale. Possiamo avere due approcci.
Da Agilista: lasciamo che il team risolva in autonomia il problema
Visione Sistemica: la persona coinvolta diventa SME ed esce dal team. Le sue interazioni con il team saranno in questo modo non tanto più semplici, ma più chiare per lui e per tutti gli altri. La chiarenza delle relazioni abbassa la tensione.
2° principio: cronologia
In questo caso ci poniamo una domanda: chi è più importante all’interno di un team?
A molti di voi sarà capitato di vedere un nuovo elemento entrare in un team, magari in un team con dei problemi. Oppure un nuovo membro entra in un team per potenziarlo in previsione di nuove e più impegnative attività. In questo caso la cronologia di ingresso crea una sorta di “gerarchia temporale” in cui spesso gli “anziani” sentono criticato il proprio lavoro, mentre “i giovani” vorrebbero cambiare tutto.
Chi entra è quindi in qualche modo rifiutato da un gruppo storico che sente giudicato ed attaccato. La persona entrante toglie quindi spazio al team storico che vede il tutto come una violazione.
SOLUZIONI
– è il team a scegliere la nuova persona
– dare importanza al team storico per il lavoro svolto con onore e fatica.
– dire in maniera trasparente che ci sarà questo sbilanciamento in modo che tutti possano essere un po’ più consapevoli dei propri bias cognitivi.
Di sicuro è molto importante riconoscere il lavoro svolto fino ad ora, in generale, ma soprattutto in occasioni di questo tipo.
Dal punto di vista di chi entra c’è questo sentimento di dover in qualche modo dimostrare di essere capace. Il classico “qui è tutto da rifare!” è un modo per cercare di dire di essere oltremodo capaci in modo da essere accettati. Il problema è che solitamente scatena l’effetto contrario, ovvero sembra un attacco verso il team storico. In questo caso è molto importante far capire a chi entra quanto sia stato importante il lavoro del team storico e quanto sia “fastidioso” un comportamento di questo tipo.
3° principio: il ruolo
Il ruolo, ufficiale o percepito, è molto importante. Attenzione però: non esistono solo i ruoli canonici (Head of… , Tech Leader, ecc) ma anche ruoli sociali (magari non è un supercampione ma crea l’atmosfera giusta).
Ogni attacco ad un ruolo è visto come un’aggressione non solo alla professionalità, ma anche alla storia che ognuno di noi si porta dietro.
Ruolo chiari e trasparenti sono sani e allontanano il rischio di sovrapposizioni. I ruoli vanno anche rispettati, ad esempio un PO o uno SM. Il classico esempio è che il PO non entra in affari tecnici ed il team sa che l’ultima parola in termini di valore è del PO.
Solitamente i problemi legati ai ruoli sono direttamente alla fase di performing di Tuckman, ovvero in questa fase questi problemi non esistono più.
4° principio: performance
Questo principio è inquietantemente vero: solitamente diamo precedenza a chi contribuisce di più. Solitamente pensiamo che chi lavora di più in termini di tempo è meglio di altri. Purtroppo però questo scatena non pochi problemi ed apre la strada ad orti, orticelli e malumori. Il problema più grosso è che è abbastanza autoalimentante soprattutto se unito ai precedenti punti. Ad esempio mi sbatto di più perché appena arrivato in un team e voglio dimostrare agli altri che valgo e fanno riferimento a me perché mi sbatto tanto. Nelle nostre teste è difficile da sradicare il concetto che chi fa mezzanotte a lavorare lavora quanto uno che fa otto ore ma peggio. In più queste persone le chiamiamo a qualsiasi ora perché : “tanto starà lavorando”. All’interno di questo insieme di persone aggiungerei soprattutto “chi spiccia”, ovvero la persona che ,davanti ad una qualsiasi richiesta, molla quello che sta facendo per far contento il rompipalle di turno. Inutile dire che ai nostri occhi sono dei grandi (risolvono sempre i nostri problemi), ma se guardiamo la cosa a livello di team o sistema creano non pochi problemi. Pensate ad esempio un comportamento di questo tipo in un team che sta iniziando Scrum. Un minuto dopo il planning avremo gente che sta facendo tutt’altro rispetto a quanto pianificato.
Priorità dei principi
Questi principi hanno una gerarchia e davanti ad un problema devono essere analizzati in cascata, ovvero l’appartenenza ad un team è qualcosa di più “distruttivo” rispetto alle performance. Nel dubbio fate un check su tutti i principi.
Conclusioni
Sentire questi principi, così semplici e pratici, hanno reso chiaro tutta quella serie di comportamenti che vediamo tutti i giorni ma ai quali spesso cerchiamo di trovare soluzioni complicate o macchiavelliche. Provatelo da domani fateci sapere come va!