Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

270 marzo
, anno 2021

Vita da Scrum Master

X parte: Lo Scrum Master come facilitatore. Dare e ricevere feedback

Avatar

Giovanni Puliti

Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.

Scrum Master Life

Vita da Scrum Master

X parte: Lo Scrum Master come facilitatore. Dare e ricevere feedback

Giovanni Puliti

Giovanni Puliti

  • Questo articolo parla di: Lean/Agile, Organizzazione aziendale, Processi di sviluppo, Project Management, Scrum, Soft skills

Che cosa è il feedback

Da termine tecnico e scientifico indicante la retroazione — effettuo un’azione su un sistema (meccanismo, circuito, organismo…), ottengo come risultato un effetto, e questo effetto risultante “rientra” nel sistema stesso variandone o correggendone il funzionamento — la parola feedback si è ormai trasferita stabilmente nell’ambito della psicologia e della comunicazione. Del resto, i gruppi di persone che interagiscono rappresentano spesso uno degli esempi più evidenti di sistemi complessi.

Il feedback è uno strumento di comunicazione usato per fornire un punto di vista, una valutazione nei confronti di un soggetto — una persona, un team, un gruppo, un’organizzazione — con lo scopo di aiutare il ricevente a introdurre un miglioramento. Il feedback non dovrebbe quindi esprimere un giudizio, ma fornire informazioni complementari a quelle che il ricevente già possiede.

Soggettività del feedback

Il feedback non può e non deve essere oggettivo: se io vedo questa cosa di te e la condivido, per definizione si tratta di un punto di vista soggettivo. La soggettività non deve essere vista quindi come una limitazione (“Mi piacerebbe darti un feedback oggettivo, ma non riesco”), ma come un dato di fatto che caratterizza questo strumento.

La soggettività del feedback è un elemento importante: chi osserva riporta il suo punto di vista e solo il suo. Un feedback quindi non può essere riportato, ma deve essere diretto. Solo chi vive una certa esperienza dovrebbe avere il diritto di parlare; se, per esempio, dicessimo “Mi ha detto Carlo che ti ha osservato in azione e ha pensato questa cosa”, di fatto non stiamo riportando un feedback soggettivo, ma stiamo certamente interpretando, modificando, alterando quello che Carlo ha visto.

Fornire feedback: elementi fondamentali

Detto questo, per evitare di entrare in ambiti “rischiosi”, è importante imparare a dare feedback nel modo migliore. Il feedback dovrebbe essere sempre concentrato sul comportamento e non sulle persone. È bene quindi limitarsi a riportare i fatti, senza cercare le cause o le motivazioni di un determinato comportamento: possiamo osservare e riportare le azioni e i loro effetti, ma non le intenzioni e le motivazioni. Se lo facessimo, di fatto staremmo interpretando, giudicando, valutando.

Il feedback dovrebbe essere circostanziato e meno generico possibile: da evitare frasi del tipo “Ho osservato che ti sei comportato male”oppure “Ogni volta che fai questa cosa sbagli”. Cerchiamo invece di portare nella discussione fatti concreti e descrivibili in modo comprensibile: per esempio “Quando hai risposto quella cosa al cliente — se possibile, riportando le parole esatte —, lui si è arrabbiato. Da quel momento non sei più riuscito a comunicare con lui”. Notare che frasi come “Hai risposto quella cosa” dovrebbe sempre essere preferito a espressioni del tipo “Hai risposto in quel modo” che è vago e potrebbe dar adito a interpretazioni o fraintendimenti.

Il feedback poi deve essere tempestivo, in modo che la persona abbia ancora la memoria fresca dell’accadimento e possa comprendere cosa è accaduto, rivivere le dinamiche e trovare quindi un modo per migliorare la prossima volta.

Il feedback deve poi essere costruttivo: questo non vuol dire che non possiamo mai riportare aspetti negativi, ma, piuttosto, che dovrebbe in ogni caso stimolare aree di miglioramento. Per esempio, se mi venisse detto “Quando spieghi quell’argomento non si capisce nulla; fai un gran casino”, potrei certamente dire di aver ricevuto un feedback negativo; ma questa cosa come potrebbe aiutarmi? In cosa non sono comprensibile? Come potrei migliorare la prossima volta?

Supponiamo invece mi venga detto “Ho notato che le persone fanno fatica a seguirti quando parli velocemente e non riescono a star dietro al filo logico della spiegazione se metti sul tavolo molti argomenti diversi e complicati”; in questo caso il feedback negativo mi fornisce informazioni utili a migliorare. La volta successiva, potrei provare a rallentare l’esposizione, a distribuire meglio gli argomenti e a usare una tecnica di visualizzazione dei temi e del percorso che verrà impostato.

Ricevere feedback

Se è importante imparare a dare un feedback, è altrettanto importante saperlo ricevere: la prima regola, quando ci viene dato un feedback, è di capire che non importante cercare le cause di un determinato comportamento o dare giustificazioni.

Per prima cosa cerchiamo di capire cosa è successo e cosa ci stanno dicendo gli altri. Quindi non si dovrebbe mai replicare quando ci viene detto cosa gli altri hanno visto: al nostro interlocutore probabilmente non interessa conoscere i motivi del nostro comportamento, partendo dal presupposto che tutti noi abbiamo sempre un motivo per agire come abbiamo agito.

Non siamo qui per creare un’altra area di confort. Vogliamo guardare avanti

 

L’area cieca

Ognuno di noi, quando agisce, parla o semplicemente sta fermo in una stanza, ha una propria percezione di quello che sta facendo o di cosa sta comunicando (IO SO). Al tempo stesso ci sono cose delle quali non ci rendiamo conto (IO NON SO).

Analogamente ci sono cose che gli altri vedono di noi (LORO SANNO) perché sono pubbliche e altre che non possono conoscere perché sono private (LORO NON SANNO).

Tutto questo si può sintetizzare nello schema di figura 1.

Figura 1 – Le aree di “visibilità” in base a ciò che dall’interno e dall’esterno si conosce.

 

La parte visibile agli altri e pure a noi è detta area pubblica. Un feedback che abbia come oggetto le cose che ricadono in questo ambito è poco utile: se mi viene detto una cosa che già so, probabilmente potrò trarne poco beneficio in ottica di miglioramento.

Quello che solo noi sappiamo e gli altri non possono sapere si chiama invece area privata. Qui ricadono le informazioni riservate che non possono arrivare agli altri a meno che non siamo noi a rivelarle. Un feedback non può avere come oggetto questa area, sulla quale si possono fare solo delle congetture.

La parte che noi non conosciamo e che gli altri non vedono si chiama area sconosciuta: lasciamo questa sfera alle discipline mediche o alla psicoterapia, perché il feedback non può e non deve entrare in questo contesto.

Infine, la parte che noi non conosciamo ma che gli altri vedono si chiama area cieca. L’utilità di un feedback sta proprio nel fatto che ci aiuta a conoscere meglio questa parte.

Figura 2 – Area pubblica, area privata, area sconosciuta e area cieca: è in quest’ultima che si concentra l’attività di feedback in un’ottica di miglioramento possibile.

 

Il feedback quindi dovrebbe operare per l’area cieca spostandola verso la parte pubblica: dovrebbe aiutare il ricevente del feedback a migliorare aspetti di cui non ha percezione.

 

Parte negativa e positiva

Dato che un feedback dovrebbe sempre fornire spunti di miglioramento, alcuni sono portati a pensare che non dovrebbe contenere commenti troppo negativi o perlomeno che siano bilanciati da una parte positiva, che permetta all’altro di avere qualcosa di buono con cui confortarsi.

Questa interpretazione poggia su un concetto di fondo corretto, ma ne fornisce un’interpretazione forse un po’ superficiale.

Dato che il feedback deve lavorare sull’area cieca, è corretto dire che dobbiamo riportare al nostro interlocutore quello che noi vediamo ma lui no, raccogliendo sia le cose buone che quelle meno  buone: lo scopo non è tanto quello di “indorare la pillola”, ma di fornire al nostro interlocutore il maggior numero di strumenti con il quale possa provare a cambiare qualcosa.

Evidenziare aspetti positivi del comportamento altrui è un modo per suggerire i punti forza da usare per ridurre quelli che funzionano meno bene.

Facciamo un esempio: “Ieri, quando ho assistito alla tua spiegazione in aula, ho notato che hai una grande energia e che sei riuscito a entrare in contatto profondo con i partecipanti che erano fortemente coinvolti da quello che dicevi. Ho notato anche che, in alcuni passaggi, qualcuno ha fatto fatica nel seguire le molte nozioni che hai passato. Forse la tua grande capacità nell’entrare in relazione con le persone potrebbe aiutarti nel ridurre le difficoltà di alcuni momenti?”.

Attenzione però a non suggerire troppo la soluzione: in fondo il lavoro di miglioramento è una cosa personale che dovrebbe scaturire da azioni proprie della persona con la quale stiamo parlando.

 

Come fare?

Se quindi imparare a dare e ricevere feedback è uno strumento importante per agevolare la crescita del gruppo e se tale crescita è uno dei compiti dello Scrum Master, in che modo si può creare un contesto dove le persone sappiano dare e ricevere feedback?

La cosa può apparire complessa: si deve creare un contesto di fiducia, lavorare sullo spirito di gruppo, sull’amicizia fra le persone, sulla condivisione degli obiettivi, all’interno del gruppo e con il resto dell’organizzazione.

Il mio suggerimento è quello di partire con la semplicità: provate a spiegare cosa è e a cosa serve il feedback. Spiegate quali debbano esserne le caratteristiche e imparate a riconoscere quando qualcuno più o meno volutamente le viola; riprendete le regole qui esposte e osservate attentamente se sono rispettate da tutti.

In tal senso, lo Scrum Master dovrebbe osservare i comportamenti e dare feedback lui stesso al gruppo: sia sui comportamenti generali dei membri del team che sul modo con il quale il gruppo si scambia feedback.

 

Riferimenti

[1] Guida galattica per Agilisti

https://www.guidagalatticaperagilisti.com/download.html

 

Facebook
Twitter
LinkedIn
Avatar

Giovanni Puliti

Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.

Giovanni Puliti

Giovanni Puliti

Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.
Tutti gli articoli
Nello stesso numero
Loading...

Blast from the past: Enterprise Microblog per il Project Management

Condividere informazioni di progetto con strumenti simili a Twitter

Il Technical Repository INAIL

II parte: Iteration 0 e gli elementi del progetto

Tic-tac-Jolie

VI parte: Appendice

Nella stessa serie
Loading...

Vita da Scrum Master

XV parte: Cosa deve saper fare uno Scrum Master, in sintesi

Vita da Scrum Master

XIV parte: La facilitazione e la struttura di un meeting

Vita da Scrum Master

XIII parte: Punti di attenzione nella facilitazione

Vita da Scrum Master

XII parte: Lo Scrum Master come facilitatore. Gli stili relazionali manipolativo e assertivo

Vita da Scrum Master

XI parte: Lo Scrum Master come facilitatore. Gli stili relazionali passivo e aggressivo

Vita da Scrum Master

IX parte: Lo Scrum Master come facilitatore. Gestire il sabotaggio nella comunicazione

Vita da Scrum Master

VIII parte: Lo Scrum Master come facilitatore. I cinque assiomi nella facilitazione

Vita da Scrum Master

VII parte: Lo Scrum Master come facilitatore. Assiomi della comunicazione

Vita da Scrum Master

VI parte: Lo Scrum Master come facilitatore. L’ascolto attivo

Vita da Scrum Master

V parte: L’arte della facilitazione. Introduzione e sommario

Vita da Scrum Master

IV parte: Supporto all’organizzazione

Vita da Scrum Master

III parte: Tra tradizione e innovazione. Meccaniche di base, sperimentazione e metriche

Vita da Scrum Master

II parte: Lo Scrum Master come Agile Coach

Vita da Scrum Master

I parte: Una panoramica sui compiti e sulle responsabilità dello SM

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte