Guida alla retrospettiva

III parte: Come far fallire una retrospettivadi

Nei primi due articoli abbiamo cominciato a vedere alcuni degli elementi importanti di una retrospettiva e negli articoli futuri vedremo altri modi per impostare una retrospettiva. In questo articolo ci focalizzeremo invece su come farla fallire!

Introduzione

In questo articolo vedremo qualcosa di controintuitivo: come far fallire una retrospettiva. Sembra strano, in effetti, che in una serie di articoli dedicati a questo valido strumento, si analizzino proprio i modi per renderlo inutile. Ma il fatto è che conoscere le ragioni e i metodi con cui far fallire una retrospettiva può aiutarci, da un lato a non mettere in atto certi comportamenti, dall'altro a individuarli nelle dinamiche dei gruppi di lavoro che si affidano alla retrospettiva. Vediamo quindi di seguito un breve manuale del bravo sabotatore di retrospettive.

Perchè voglio farla fallire?

Ci sono molti motivi per cui potreste voler far fallire una retrospettiva ed è difficile elencarli tutti; certo molto dipende dal ruolo con cui partecipate al meeting: mentre il membro del team potrebbe aver interesse a fare le scarpe al collega, il manager potrebbe aver l'interesse che il team la smetta di sprecare tempo in attività anarchiche invece di premere tasti sulla tastiera. Per classificare correttamente i vari modi per far fallire una retrospettiva analizzeremo quindi i ruoli coinvolti.

Come manager del team

Come manager di un team siete senza dubbio già stufi di sentir parlare di tutte queste pratiche che non hanno niente a che vedere con lo sviluppo software vero: Scrum, Agile, TDD, BDD, XDD, e così via, sono solo una moda che state già contrastando da anni. Il fatto che qualche incravattato al quartiere generale vi abbia imposto di lavorare con queste pratiche cosiddette agili non vuol dire che vi piacciano: tutta questa visibilità e trasparenza sta danneggiando la vostra immagine. Prima avevate tutto sotto controllo, adesso il vostro capo parla direttamente con il team e il team direttamente con il business: se va avanti così perderete il vostro lavoro. Inaccettabile!

E che cos'è questo continuous improvement di cui si parla così tanto? Tanto come migliorare il funzionamento del reparto lo sapete fin troppo bene voi: non c'è bisogno che il team ne discuta. La frusta ci vorrebbe, per questi scansafatiche!

Tattiche di sabotaggio per il manager

Ecco che avete a disposizione tutta una serie di tattiche per far fallire la retrospettiva:

  • Andate al meeting e definite voi l'agenda: siete voi il capo!
  • Anche se c'è un moderatore, dite voi di cosa parlare. Siete voi il manager, non questa marmaglia in t-shirt!
  • Quando il team discute dei suoi problemi, fategli capire, verbalmente e non, che tanto, qualsiasi proposta di soluzione possano pensare, dovrà essere comunque passata al vostro vaglio.
  • Se poi il team discute di problemi di interazione con altri team o dipartimenti, tagliate corto e chiarite che tanto non è compito loro occuparsi di queste cose: sono cose di management, quindi vostre!
  • Certamente, se proprio vogliono sprecare tempo a discutere di miglioramenti, possono sempre parlare di come aumentare il numero di righe di codice che ognuno di loro scrive ogni giorno: e questa la cosa importante!
  • E infine: se vedete che si stanno mettendo in testa di poter decidere, fategli pure una ramanzina, alzate la voce se serve: questo eviterà che la prossima volta si facciano venire in mente idee non conformi agli standard aziendali. O quantomeno ai vostri standard…

Il senso di colpa

In ogni caso, date a loro la colpa di ogni fallimento, così imparano a voler fare di testa propria. Siate energici nel farlo e accusate pure a volontà! Questa strategia ha l'effetto collaterale che, in caso di un fallimento del progetto, potrete sempre andare dal vostro capo dicendo che la colpa è del team di sviluppo e che voi avete fatto tutto il possibile per "motivarli".

Virginia Satir, una psicoterapeuta per gruppi familiari, ha individuato quattro "categorie" di comportamenti che sono alla base della maggior parte dei conflitti, e un comportamento che può essere usato per ridurre i conflitti [1]. Questo comportamento, consistente nel dare la colpa a qualcuno, ricade nella categoria del blamer.

 

 

Figura 1 - Tipi di reazione allo stress secondo Virginia Satir: il "blamer".

 

Motivazione

Visto che parliamo di motivazione: andateci giù pesanti con gli interventi motivazionali: meglio calcare la mano sull'importanza del progetto per l'azienda, su come i migliori verranno premiati e i peggiori puniti e cose di questo tipo. Se qualcuno vi fa notare che ci sono diversi studi che dimostrano il contrario, ad esempio se qualcuno tira fuori la legge di Yerkes-Dodson [2], fategli notare che il management è una disciplina per uomini duri, non per mammole!

Come membro del team

Anche come membro del team ci sono molti motivi per voler far fallire una retrospettiva: magari il team vuole mettervi in minoranza e cambiare quel tool che state usando da dieci anni solo perchè dicono che ci siano altri modi migliori di lavorare. O magari vorrebbero scrivere più test automatici durante lo sviluppo, cosa che voi sapete essere compito di un team di test separato. Forse la ragione più comune però è che il team sta cercando di aumentare la trasparenza del processo di sviluppo e voi non capite cosa ci sia da dire di nuovo ogni giorno allo standup sulla vostra storia: voi lo sapete comunque che avrete bisogno di almeno due mesi di sviluppo; perchè non vi lasciano a lavorare in pace?

Tattiche di sabotaggio per membri del team di sviluppo

Qualsiasi siano le vostre ragioni, ci sono svariati modi per far fallire la retrospettiva "dall'interno del team":

  • Piantate il muso ad ogni proposta dei colleghi, siate inflessibili su ogni forma di cambiamento: se state seguendo un certo processo da così tanti anni, c'è di sicuro una ragione e non c'è motivo di rimettere ogni volta tutto in discussione.
  • Quando i vostri colleghi propongono un cambiamento, dite di essere a favore, ma di voler esseri sicuri che la novità introdotta funzionerà, menzionate casi in cui simili modifiche non hanno funzionato per tutta una serie di motivi che farete sembrare una catena di logiche causa-effetto, anche se non lo sono. Se date tanti dettagli e il tutto sembra più o meno logico, nessuno sarà in grado di capire come rompere le vostre argomentazioni. Siate super-razionali!

 

 

Figura 2 - Quello che nelle Satir Categories è detto il "computer" [2], ossia il super-razionale.

 

  • In alternativa, potete tentare di spostare il tema della discussione verso altre direzioni che hanno ben poco a che fare con il tema. Siate dei distrattori! (il distracter di [2]). Ci sono vari modi per distrarre i vostri colleghi: ad esempio, se vogliono cambiare qualcosa già dal prossimo sprint, fateli parlare di un problema secondario che dovrete affrontare fra parecchi mesi. Se vogliono discutere di un problema che ha danneggiato l'ultimo sprint, fategli notare come ogni sprint ha avuto problemi di tipo diverso e che avrebbe senso trovare una soluzione "olistica", anche se sapete già che non sarà possibile trovarne una.

 

 

Figura 3 - Il "distrattore".

 

  • Se poi riescono ad arrivare a votare una proposta di cambiamento e vi mettono in minoranza, fategli notare come queste cose non si possono decidere a maggioranza semplice, serve l'unanimità, e che voi non siete d'accordo.

Incapacità decisionale

Se il vostro team è uno di quelli in cui le decisioni sono comunque difficili perchè i membri vogliono evitare conflitti e negoziano fino a che non c'è una chiara unanimità sul tema (sintomo: le decisioni durano settimane o addirittura mesi con discussioni infinite), siete a posto. Invece di supportare il processo e dichiarare di accettare qualsiasi decisione a maggioranza, mettete in dubbio tutto quello che viene detto e suggerite al team che la decisione che state prendendo è importante, va ponderata bene e va presa con una maggioranza tale da non escludere nessuno in modo da tenere unito il team. Questo vi garantisce che non verrà mai deciso niente e potrete continuare a fare quello che volete!

Come facilitatore della retrospettiva

Il ruolo di facilitatore è quello che vi dà le maggiori possibilità creative per far fallire una retrospettiva. I motivi per cui volete farla fallire sono, anche in questo caso, i più svariati:

  • Sapete già quale deve essere il risultato della retrospettiva. La fate perchè il processo lo vuole, ma tanto è chiaro cosa deve essere cambiato nel modo di operare nel team.
  • Il vostro manager vi ha inviato a facilitare il meeting, ma vi ha anche detto cosa si aspetta come risultato. E di sicuro non volete fallire…
  • Oppure, semplicemente, vi piace l'emozione del palcoscenico e la retrospettiva vi fa sentire un po' come il presentatore di un talk show: li fate parlare, ma lo show è il vostro, non il loro.

Tattiche di sabotaggio per il facilitatore

Qualsiasi sia il vostro motivo, ecco un po' di modi per far fallire la retrospettiva:

  • Andate a cercare il colpevole. Fate il detective e discutete con il team per colpa di chi le cose sono andate male nell'ultimo sprint.
  • Più in generale: andate a cercare la causa fondamentale dei problemi non solo tecnici, ma anche umani. Applicate tecniche tipo 5-Whys alle interazioni in team, in modo da creare un'atmosfera di sospetto e di caccia alle streghe all'interno del team [3].

 

 

Figura 4 - Per la situazione, noi ci creiamo un modello di questo tipo…

 

 

Figura 5 - …ma la realtà è molto più complicata di come la modelliamo, specialmente quando consideriamo sistemi di esseri umani!

 

  • Pianificate le attività della retrospettiva come piacciono a voi: potete provare un nuovo gioco o un'attività che di solito non usate. Se non è quello che serve al team… fa niente, si adatteranno.
  • Se avete pianificato un formato per la retrospettiva e capite che al team non serve, continuate comunque imperterriti sulla vostra strada: anche in questo caso è il team che deve adattarsi! [NOTA 1]
  • Molti facilitatori si mantengono neutrali (o meglio, parziali multidiretti [4]): per far fallire una retrospettiva intervenite invece con le vostre opinioni e tentate di forzare il vostro punto di vista. Se siete lì a facilitare è perchè ne sapete più di loro, giusto?
  • Un'altra possibilità interessante è quello di supportare apertamente o nei fatti, la posizione di una parte del team contro un'altra. Se scegliete di supportare il partito che propone la posizione del vostro capo, la promozione è assicurata!
  • Se notate che il linguaggio non verbale di alcuni membri del team indica disaccordo, ignorateli pure: se la maggioranza è ok, si adatteranno. Se tentate di farli entrare nella discussione e capire il loro punto di vista c'è il rischio che si verifichino dei conflitti, o meglio, che conflitti latenti diventino espliciti [5]. I conflitti latenti è meglio lasciarli stare come tali: il team non avrà la possibilità di funzionare al meglio, ma almeno non perderete tempo!
  • A proposito di tempo: visto che siamo in un mondo agile, fate tutto tramite timebox. Decidete che la discussione va chiusa entro 5 minuti, impostate un timer e siate inflessibili. Ci sono diversi studi che dimostrano che lavorare sotto pressione del tempo riduce la creatività delle persone [6] [7]. Se li limitate il tempo a disposizione, non saranno in grado di trovare modi per migliorare veramente e la retrospettiva fallirà!
  • Un modo certo per far quantomeno degenerare la qualità della retrospettiva e quindi farla fallire è quello di trovare un posto non adatto: stanze molto piccole, con poca luce, con molti disturbi esterni (persone di passaggio, strada rumorosa, …) sono tutti elementi che interferiscono nel funzionamento della retrospettiva.
  • Se invece, purtroppo, nella vostra azienda avete solo stanze grandi e tranquille, un modo per rovinare comunque la retrospettiva è quello di avere poco materiale di cancelleria o scadente: con la scusa di risparmiare, utilizzate post-it riciclati, pennarelli che non scrivono più, e così via: questo farà crescere la frustrazione del team anche quando l'ambiente sarebbe adatto.

Tattiche evolute per il fallimento

Per un facilitatore, ci sono poi modi molto più sottili per far fallire una retrospettiva e anche distruggere un team, una sorta di "retrospettivicidio perfetto": pochi si renderanno conto che è colpa vostra.

  • Dare troppo spazio ad una persona o non moderare chi parla troppo.
  • Non considerare le voci di minoranza.
  • Ammettere che le persone si insultino a vicenda o quantomeno non reprimere commenti negativi nei confronti del colleghi.
  • Far annoiare tutti con la vostra facilitazione.
  • Moderare e limitare tutte le azioni che il team vorrebbe intraprendere ma che per voi sono troppo radicali: fateli ragionare questi ragazzi!

Conclusioni

Come avete visto ci sono molti modi e molti motivi per far fallire una retrospettiva e in ogni ruolo avete a disposizione tantissimi modi per farlo. Il limite è la vostra creatività!

Mi auguro però che il vero motivo per cui leggete questa serie non sia quello di far fallire una retrospettiva ma, al contrario, quello farla funzionare bene: vi rimando pertanto al prossimo articolo, dove parlerò di dinamica dei gruppi e di come gestirla in una retrospettiva.

Come ogni attività, la retrospettiva è soggetta ai principi fondamentali della dinamica dei gruppi. Se ignoriamo tali principi nella nostra facilitazione, diminuiamo la probabilità che la riflessione in team funzioni.

Note

[NOTA 1]: In passato ho avuto una discussione accesa su un gruppo LinkedIn. La domanda iniziale è se il facilitatore di retrospettiva può o deve cambiare il formato della retrospettiva "in corsa". Con mio profondo stupore, molti commenti indicavano che, una volta pianificato, il formato della retrospettiva non si cambia. Nella mia esperienza, specialmente facilitando retrospettive di team di cui non ho tante informazioni (caso del facilitatore esterno al team) mi sono ritrovato a cambiare il formato "in corsa" molto spesso. Per mia esperienza diretta, nonostante lo sforzo per pianificare al meglio una retrospettiva, in una buona metà dei casi bisogna adattare o cambiare completamente il formato, per andare in contro alle esigenze del team. Come facilitatore siete al servizio del team, e se il formato che avete scelto non funziona, è vostro dovere cambiarlo: siate flessibili!

 

Riferimenti

[1] Satir Categories

http://sourcesofinsight.com/satir-categories/

 

[2] La legge di Yerkes-Dodson

http://en.wikipedia.org/wiki/Yerkes-Dodson_law

 

[3] 5-Whys

http://blog.connexxo.com/2009/12/the-whys-of-why-not-why.html

 

[4] Parzialità multidirezionale

http://bit.ly/1kSzaWe

 

[5] Paul Wehr, "Manifest and Latent Conflict"

http://www.colorado.edu/conflict/peace/example/wehr7489.htm

 

[6] Janice R. Kelly - Steven J. Karau, "Entrainment of Creativity in Small Groups"

http://sgr.sagepub.com/content/24/2/179.abstract

 

[7] Janice Kelly - Gail Clark Futoran - Joseph E. Mcgrath, "Capacity and Capability. Seven Studies of Entrainment of Task Performance Rates"

http://sgr.sagepub.com/content/21/3/283.abstract

 

 

 

Condividi

Pubblicato nel numero
196 giugno 2014
Dopo aver realizzato software e gestito team di sviluppo per molto tempo nel settore delle telecomunicazioni, da svariati anni Pierluigi Pugliese è coach agile e consulente IT che fornisce sostegno alla aziende affinché diventino più produttive grazie all‘adozione di metodologie agili per lo sviluppo del software. Tra le sue competenze,…
Articoli nella stessa serie
Ti potrebbe interessare anche