Tempo fa ho organizzato un meeting su come avanzare l'uso di Scrum (leggi aumentare le chances di successo dei progetti, migliorare le prestazioni del team e realizzare sw realmente utile al business dell'azienda) in una azienda.
Nel meeting era necessario dare con trasparenza anche alcuni feedback negativi riguardo 2 cose della implementazione corrente. Mi sono letto e riletto i suggerimenti annotati nei post precedenti.
Il risultato? I feedback sono stati accolti, riconosciuti e discussi con interesse. E' stato chiesto di organizzare un altro meeting per proseguire il dialogo e approfondire gli argomenti. E alla fine del meeting invece della sottile tensione che lo aveva preceduto, ho avvertito tra i partecipanti più confidenza, coinvolgimento e curiosità. Un primo passo buono grazie alla qualità dei contenuti e al modo efficace di comunicarli.
Da questa esperienza ho imparato questa cosa. I feedback negativi su cose che non ci coinvolgono direttamente (come un consiglio che ci viene chiesto) o che sono sistematici (come i feedback in una Retrospective o una accettazione o meno di una user-story da parte di un utente) sono più semplici da dare. I feedback negativi su cose che hanno anche conseguenze dirette su di noi (in quel caso sul mio desiderio di far parte di un team di successo, iper-produttivo, che soddisfa gli utenti e genera valore evidente per l'azienda) sono più complicati e allora:
- funziona meglio distinguere bene il feedback negativo che vogliamo dare dalla situazione di conflitto personale per le conseguenze negative che ci riguardano. e funziona meglio affrontare le due cose separatamente senza confonderle
Print | posted @ sabato 3 ottobre 2009 16:15