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:

269 febbraio
, anno 2021

Vita da Scrum Master

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

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

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

Giovanni Puliti

Giovanni Puliti

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

L’importanza della facilitazione

In questa lunga serie dedicata al mestiere dello Scrum Master, da qualche puntata stiamo concentrando l’attenzione sul tema della facilitazione, ossia su quel vasto insieme di competenze e di strumenti necessari per rendere efficace una conversazione o un meeting.

Una riunione è efficace se consente di raggiungere lo scopo della riunione o della conversazione: condividere informazioni, proporre una soluzione per un problema, trovare nuove idee, impostare un piano di lavoro. Dopo aver parlato nelle puntate precedenti di comunicazione efficace, passiamo  ad analizzare un tema differente ma strettamente collegato: come impedire il sabotaggio della comunicazione o del meeting per consentire di arrivare allo scopo dell’incontro

Negli articoli pubblicati su questo magazine prima, e sul libro Guida Galattica per Agilisti poi, abbiamo già parlato di facilitazione e sabotaggi; per questo non vorremmo nuovamente ripetere quanto già ottimamente descritto a suo tempo da Pierluigi Pugliese, limitandoci a fare qui qualche esempio e a fornire una visione di alto livello. Per ogni approfondimento rimandiamo al capitolo 5 del libro (disponibile solo nella versione online gratuitamente scaricabile [1].

Come si sabota una riunione

Nel capitolo 5 del libro Guida Galattica per Agilisti, Pierluigi fa riferimento ad alcuni archetipi di sabotaggio (pattern comportamentali) che possono essere ricondotti al tema del sabotaggio; si tratta di modalità di conduzione della conversazione che le persone mettono in atto (volontariamente o meno) le quali, intervenendo sui vari livelli della comunicazione, bloccano lo scambio di informazioni.

In questo articolo riprenderemo brevemente i concetti presentati in quel testo, per fornire qualche esempio e inserire il tema gestione del sabotaggio fra le competenze dello Scrum Master.

Archetipo del sabotatore iperrazionale

L’archetipo dell’iperrazionale utilizza una strategia che è la composizione dei seguenti atteggiamenti:

  • è apparentemente favorevole alle idee degli altri, però pone sempre un “ma” per “verificare bene”;
  • di fronte a una nuova idea riporta sempre l’attenzione sui casi in cui non ha funzionato;
  • sposta la discussione su catene causa–effetto;
  • cerca di trovare il perché delle cose eAffoga la discussione con moltissimi dettagli, 
  • Interviene nella conversazione con la scusa di contribuire con un ragionamento logico e ben documentato.

Vediamo un esempio di questo comportamento con una conversazione che si potrebbe avere fra due colleghi che valutando come evitare il ripetersi di un problema accaduto:

Beatrice: Potremmo provare a introdurre un altro sistema di logging.

Alberto: Sì, l’idea mi piace, ma non è una cosa banale… abbiamo scritto tonnellate di codice sul vecchio logger… converrebbe prima provare a fare un po’ di indagini…

Beatrice: Non ce la faremo mai a vedere tutti i casi possibili. Alcune parti del sistema non le abbiamo nemmeno scritte noi…

Alberto: Ascolta… ho un po’ di esperienza sulle spalle, ho visto un sacco di volte in cui la sostituzione del tool non ha funzionato. Direi che prima dobbiamo valutare bene la cosa e semmai chiedere al PM che ne pensa.

Beatrice: E cosa dovremmo valutare?

Alberto: Vedi (scrivendo alla lavagna) ti elenco una serie di aspetti che dobbiamo considerare: 

  • Il meccanismo di sicurezza.
  • La reflection.
  • Il porting del version control.
  • Il login centralizzato.
  • La policy sui Cookie per compliance con il GDPR

Beatrice: Che c’entra GDPR?

Alberto: Come che c’entra… ti ricordi quando siamo andati in produzione l’altra volta? Dobbiamo prima di tutto capire gli impatti. Dovremmo fare una matrice di causa/effetto. Che ne dici se proviamo a coinvolgere l’ufficio legale?

Beatrice: Ah interessante, non li conosco benissimo… dici che potremmo consultarli?

Alberto: Eh… non so… dovremmo prima di tutto fare un passaggio con i responsabili di progetto, vedere il budget, valutare le implicazioni sullo steering team e poi parlare coi manager…

Beatrice: Mi arrendo… Troppe campane da mettere d’accordo. Alberto, partendo con un approccio aperto al confronto, finisce per sommergere di punti di discussione la povera Beatrice. Probabilmente i due si fermeranno e nulla verrà fatto vista l’ampiezza del contesto che ha allargato Alberto.

Alberto, partendo con un approccio aperto al confronto, finisce per sommergere di punti di discussione la povera Beatrice. Probabilmente i due si fermeranno e nulla verrà fatto vista l’ampiezza del contesto che ha allargato Alberto.

Archetipo del sabotatore distrattore

Un’altra tecnica di sabotaggio molto comune è quella messa in atto dal distrattore. La sua strategia consiste in:

  • Spostare il tema della discussione verso altre direzioni.
  • Aggiungere sempre nuovi aspetti.
  • Depistare su problemi minori o enormi.
  • Proporre sempre una soluzione omnicomprensiva, senza specificare cosa significhi o senza preoccuparsi se sia concretamente realizzabile.

Vediamo un esempio:

Alfredo: Anche a questo sprint non siamo riusciti a finire quello che ci eravamo proposti di fare… Sarebbe il caso di capire il motivo.

Rachele: Be’ il motivo è piuttosto semplice, anche questa volta abbiamo passato molto tempo a lavorare per risolvere i bug in produzione.

Alfredo: Sì, vero, come tutte le altre volte. Cosa possiamo farci?

Rachele: Fino a che i capi non si rendono conto di questo problema, non faremo progressi 

Alfredo: Ma tanto loro non se ne preoccupano.

Rachele:Dovrebbero cambiare approccio alla gestione del cliente.

Alfredo: Già ma il cliente tanto segue quello che c’è scritto nel contratto.

Rachele: Eh… il contratto andrebbe cambiato, non possiamo mica sempre dire di sì a tutto.

Alfredo: Sì vero, ma tanto “loro” non ci sentono su questo canale. Tanto poi noi siamo a spalare i bug.

Rachele: Effettivamente da quando abbiamo introdotto il nuovo contratto di assistenza i tempi si sono ridotti, e gli SLA non ci permettono di stare al passo.

Alfredo: Hai visto poi con che richieste se ne arrivano, come se noi poi potessimo rispettare le scadenze di sprint, dovendo anche risolvere i bug in tempi ridottissimi. Hai visto il secondo paragrafo del contratto? Parla addirittura del tipo di documentazione da allegare alla scheda tecnica.

Rachele: Che poi se mettiamo quel livello di commento perdiamo troppo tempo, è veramente una perdita di tempo.

Alfredo: Si ma se ci mettiamo a scrivere in meta doc, magari poi si compila da solo.

Rachele: Si l’ho visto. Non so perché l’Account abbia proposto una cosa del genere.

Alfredo: Perché come al solito Account e Sales fanno il conto senza l’oste.

Rachele: Be’ allora se vogliamo dirla tutta, l’intera azienda, da quando siamo cresciuti, non ci sta minimamente supportando.

Alfredo: Già e noi che dovremmo fare? Secondo loro basta fare Scrum che tutto si risolve.

Rachele: Sì, ma tanto è sempre la solita storia.

Alfredo: Sì… vabbé andiamo a prenderci un caffè vai…

Quando a sabotare… è il facilitatore

Come abbiamo accennato in precedenza anche il facilitatore potrebbe cadere in fallo e, violando lo scopo principale del suo lavoro, potrebbe finire per sabotare la conversazione. Spesso di tratta di errori (quindi del tutto involontari), ma a volte egli è tutt’altro che inconsapevole.

Eccesso di influenza

In questo caso il facilitatore potrebbe essere affetto da un eccessivo protagonismo,  dal desiderio di apparire, essere la rockstar della riunione. Potrebbe voler influenzare l’opinione dei partecipanti per pilotare le decisioni o le azioni finali. 

Ricordate che non è necessario dire “ottima questa cosa che ha detto adesso Mario” per influenzare la discussione. Basta un “Ah!” associato a un sorriso o a una faccia stupita per far capire la nostra opinione rispetto a quello che ha detto Mario. In fondo, ricordiamoci che il primo assioma della comunicazione ci dice che “non è possibile non comunicare” (vedi puntate precedenti).

Cercare la causa

Se la riunione è stata organizzata per cercare di risolvere un problema che si è verificato a causa di un errore o di imprevisto, fate attenzione a come impostate la conversazione.

Il rischio è quello di  aprire una sessione di indagine e giocare a fare i detective, o peggio a cercare colpe per quanto successo. 

Se il facilitatore è anche lo Scrum Master del team, dovrebbe aiutare il gruppo a perseguire un miglioramento più che trovare colpe e colpevoli: non è detto che sapere chi ha fatto cosa eviti che accada di nuovo.

Ricordatevi inoltre che, quando si ha a che fare i sistemi complessi (un team, un gruppo o l’intera organizzazione), causa/effetto non sono strettamente collegate fra loro. Mettersi in modalità detective può essere utile per il vostro carisma, non è detto che lo sia per il gruppo.

Sabotaggi che agiscono sul format

Ogni incontro dovrebbe avere una struttura (come si inizia, come si prosegue, come si chiude), tempistica (quanto tempo dedicare a ogni fase) e un tono (che ritmo dare a ogni fase).

Un modo piuttosto semplice per far fallire una riunione potrebbe essere quello di non rispettare la struttura del format scelto o di non averne alcuno. Parleremo approfonditamente di questi temi più avanti.

Anche il formato che sceglierete per la riunione dovrebbe essere pensato per il contesto specifico: tenete ben presente il tema della discussione (una retrospettiva, un’envisioning, un brain-storming sono eventi che dovrebbe essere organizzati con formati di facilitazione completamente differenti), le persone con cui avete a che fare (operativi o top-managers), la logistica (stanza piccola, plenaria, auditorium).

Per questo non dovreste pianificare le attività e scegliere il formato a vostro piacimento e non dovreste forzare il gruppo ad adattarsi alle vostre scelte, ma pensare e progettare bene prima in funzione dello scopo della riunione e adattarvi in base a quello che accade in quel momento.

Cercate sempre di fissare la tempistica della riunione progettando e pianificando molto bene prima, (quanto tempo dedicare a ciascuna fase – esplorazione, analisi, sintesi), ma non rimanete schiavi del timeboxing. A volte un po’ di sana improvvisazione è indispensabile.

Ricordate quindi infine che il vostro ruolo sarà quello di bilanciare gli spazi e i tempi da dedicare alle persone: potreste involontariamente far fallire la riunione dando troppo spazio ad una persona, perdendo il controllo della discussione, non considerando le voci di minoranza (per numero o per timidezza), non moderare il tono mantenendo la conversazione su toni di rispetto reciproco. Viceversa un atteggiamento troppo invadente con una facilitazione meccanica, invadente, pedissequa, noiosa potrebbe far perdere interesse nelle persone.

Alcune tecniche di sabotaggio (avanzate) per il facilitatore

Quelli che seguono sono tipiche tecniche di sabotaggio molto efficaci (risultato garantito con poco sforzo). Di fatto si tratta di atteggiamenti in totale contrasto con la missione di un facilitatore (e di uno Scrum Master); non è raro purtroppo vedere anche facilitatori navigati commettere qualcuno di questi errori.

  • Quando viene fatta una proposta, dire che lo si era già pensato prima.
  • Quando lo staff è riunito, dire qualcosa che lo staff non può comprendere.
  • Dire che un problema non può essere separato dagli altri: significa dire che questo problema è inaffrontabile finché non sono risolti gli altri.
  • Far sentire colpevole chi fa presente un problema (nessuno più porterà sul tavolo problemi).
  • Far finta di non capire una domanda: se la domanda è chiara, far perdere tempo in inutili ulteriori spiegazioni.
  • Influenzare la platea banalizzando una proposta (p.e.: dire cose del tipo “quel problema ce l’hanno tutti e quindi non ha senso parlarne adesso”, oppure “questo problema lo tirate sempre in ballo, ma poi non si fa nulla”).
  • Spiegare e chiarire ulteriormente e inutilmente una cosa che si è già detta.
  • Dire che una cosa non è in agenda e quindi se ne parlerà più avanti.
  • Bloccare una discussione in modo da  consultare un esperto (di fatto come facilitatore non dovreste prendere posizione: se il team pensa di voler affrontare la questione supportatelo, non castratelo).
  • Dire che si sono chiariti tutti gli aspetti di un problema, anche se non si è trovato un modo per risolverlo.

Conclusioni

Abbiamo quindi detto che un facilitatore dovrebbe  lavorare per rendere efficace una conversazione o un meeting.

Un bravo facilitatore dovrebbe quindi bloccare i sabotaggi che di fatto impediscono il raggiungimento di questo scopo: per questo diventa indispensabile imparare a riconoscerli.

Per chi fosse interessato ad allargare il tema, uno spunto interessante potrebbe essere quello di riconsiderare quanto visto in merito agli assiomi della comunicazione (puntata precedente) per capire meglio come noi funzioniamo e come ci comportiamo quando vogliamo comunicare (o parimenti quando invece vogliamo bloccare ogni forma di scambio).


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: alla scoperta della robotica spaziale in Giappone

I parte: Verso mondi lontanissimi

Il Technical Repository INAIL

I parte: I principi Agili applicati allo sviluppo software del repository

Tic-tac-Jolie

V parte: Porte e importazione di file esterne

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

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

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