Estendere le retrospettive al resto dell'azienda

Il team di sviluppo prodotti di Driftrock utilizza da tempo le retrospettive da poco più di un anno e ci sono state davvero utili. In questo periodo abbiamo apportato numerosi miglioramenti e cambiamenti al nostro modo di lavorare. Questi cambiamenti vanno da piccole modifiche al nostro processo a grandi idee incerte che sperimentiamo per un periodo limitato. Il nostro processo per una retrospettiva è abbastanza tipico (secondo la mia esperienza); le facciamo ogni due settimane e ruotiamo il ruolo del facilitatore che conduce la sessione come meglio crede. È importante sottolineare che facciamo del nostro meglio per assicurarci di ottenere alcune azioni ben comprese (pensate a 1-4) con responsabili chiari e l'aspettativa che queste vengano completate o almeno portate avanti in modo significativo entro la prossima retrospettiva.

Ciò che ci ha colto di sorpresa è stato il crescente interesse dimostrato dal resto dell'organizzazione, al di fuori del reparto di sviluppo software, nel capire in che modo le retrospettive potessero essere loro d'aiuto. A tal punto che ora organizziamo regolarmente delle retrospettive con il nostro team di crescita, composto da addetti alle vendite, account manager e performance marketer. Abbiamo anche tenuto una retrospettiva a livello aziendale, incentrata in particolare sulle valutazioni delle prestazioni e su come migliorarle.

La cronologia

Quando sono entrato a far parte di Driftrock, come ogni nuovo arrivato in qualsiasi team, avevo alcune idee su come avremmo potuto fare le cose in modo diverso, ma non c'era modo di proporle e discuterne con il team. L'unica vera opzione era sottoporre un'idea al nostro responsabile e cercare l'approvazione dei superiori, cosa che in un piccolo team di ingegneri esperti e pieni di idee sembrava un po' superflua.

Ed ecco la retrospettiva. Abbiamo iniziato in modo semplice: abbiamo provato a fare una sola retrospettiva e poi abbiamo proseguito da lì. In qualità di facilitatore, ho cercato di fornire il maggior numero possibile di spiegazioni mentre affrontavamo la nostra prima retrospettiva. Per non sovraccaricare il resto del team, abbiamo mantenuto anche questa semplice, concentrandoci su tre aspetti principali:

• Non si tratta di attribuire colpe. È importante creare un ambiente che promuova la sicurezza psicologica e l'attribuzione di colpa la distrugge. Le cose vanno male, lo sappiamo, quindi parliamo apertamente di come possiamo migliorare come squadra ed evitare quegli stessi errori.
• Questa non è l'ennesima riunione in cui ci scambiamo qualche parola di cortesia senza che cambi nulla. Le azioni concrete sono un risultato fondamentale della nostra discussione, così come lo è portarle a termine.
• Siamo tornati alle basi e abbiamo strutturato la sessione attorno alle quattro domande chiave.

L'iniziativa ha avuto un esito abbastanza positivo e da quel momento abbiamo deciso di impegnarci a svolgere retrospettive regolari. Era più facile a dirsi che a farsi: c'era comunque bisogno di almeno una persona che garantisse lo svolgimento della retrospettiva successiva, che seguisse i responsabili delle azioni e che portasse avanti quel processo di formazione. Col tempo abbiamo trovato un buon ritmo con retrospettive bisettimanali, abbiamo iniziato a tenere traccia delle nostre azioni e, una volta che il team ha iniziato a coglierne il valore, questa pratica ha cominciato a funzionare in modo autonomo.

Si sono susseguite altre retrospettive e il team è cresciuto con ogni piccolo miglioramento, così come l'interesse da parte di chi non ne faceva parte. Ciò ha portato a una breve presentazione rivolta a tutta l'azienda sulle retrospettive e su come le stavamo utilizzando. Ne è seguito un leggero cambiamento nel mio ruolo, che mi ha permesso di dedicare un po' di tempo ad aiutare il team Growth a muovere i primi passi con le retrospettive.

Cosa ho imparato

Condurre delle retrospettive per team che non si occupano di sviluppo software è stata un'esperienza nuova per me. Forse l'osservazione più evidente è stata che il team di crescita, nonostante la sovrapposizione dei ruoli, opera in modo piuttosto indipendente. Pertanto è molto più difficile trovare un terreno comune quando si riflette su un arco di tempo specifico. È molto più probabile che agiscano su una serie di attività in modo indipendente rispetto ai membri di un team di sviluppo, che generalmente lavorano per ottenere gli stessi risultati, magari sullo stesso problema, e i cui ruoli sono molto simili. Abbiamo invece scoperto che era molto più utile concentrarsi su un tema. Ad esempio, in precedenza abbiamo tenuto retrospettive incentrate sulla gestione degli account e un'altra su ruoli e responsabilità.

Essendo una persona esterna al team, le tue possibilità di intervento sono piuttosto limitate. È molto più difficile organizzare un'iniziativa del genere senza avere qualcuno all'interno del team che ci creda davvero e che si assuma parte della responsabilità. Oltre a questo, il team deve voler migliorare, deve rendersi conto fin dall'inizio del valore dell'iniziativa, ma deve anche trovare la propria strada.

Guardando con un po' di distanza all'intero percorso, anche alla parte apparentemente semplice dell'introduzione delle retrospettive in un team di sviluppo, mi vengono in mente alcune altre lezioni:

• Facilitazione - Cercare di fungere da facilitatore imparziale all'interno del proprio team non è un ruolo facile da ricoprire. Per questo motivo preferiamo che il facilitatore sia una persona esterna al team. Ciò offre l'ulteriore vantaggio di migliorare la comunicazione e la condivisione delle conoscenze tra i team, fornendo al contempo un controllo esterno nel caso in cui la discussione diventi troppo approfondita.
• Valorizzate gli aspetti positivi - È davvero fondamentale che tutti possano rendersi conto dell'impatto di un'azione portata a termine o di una conversazione importante. Esaminate le azioni intraprese all'inizio di ogni retrospettiva, parlatene durante le riunioni quotidiane, rendetele visibili e valorizzate gli esempi migliori.
• Ci saranno sempre degli scettici: è naturale che le persone mettano in dubbio il valore di qualcosa, è comprensibile e va bene così. Le critiche sono uno strumento utile per migliorare.
• Sii tenace: se ci credi, continua a provarci. Ma sii rispettoso degli altri, cerca di capire come si sente la squadra e adattati di conseguenza.
• Date l'esempio: quando partecipate a queste sessioni, date il tono giusto. Siate presenti e partecipate attivamente.

Cosa è andato bene

Per il team Growth, questa sessione bisettimanale rappresenta un'occasione per staccare dalla frenesia e dallo stress quotidiani legati alla gestione delle campagne e dei clienti. Durante la sessione hanno il tempo di individuare le tendenze che emergono dai vari tipi di attività in corso. Possono quindi adeguare il loro approccio di conseguenza e valutare i risultati nella sessione successiva.

Per quanto mi riguarda, mi sono reso conto che la retrospettiva può essere uno strumento efficace per promuovere l'autonomia. Quando funziona bene, è un'ottima occasione per consentire a ciascuno di esprimere le proprie preoccupazioni, proporre cambiamenti e portarli a termine.

Più in generale, questa retrospettiva ha contribuito a far emergere un aspetto fondamentale della cultura di Driftrock, che era sempre stato presente ma di cui si parlava raramente. Poiché ultimamente ci stiamo occupando dei valori fondamentali della nostra azienda (restate sintonizzati), è emerso chiaramente che parte integrante del tessuto di questa organizzazione è proprio quella volontà di imparare e di cercare di migliorare, che questa pratica incarna appieno.

Se hai commenti, domande o hai fatto qualcosa di simile, non esitare a contattarmi @dan_badge.

Alcuni link utili:
Wiki sulla retrospettiva - tante idee pratiche per la facilitazione
Retromat - Combina diverse sessioni
Retrospettive Agile - Trasformare i buoni team in team eccellenti
50 idee veloci per migliorare la tua retrospettiva

‍