Retrospettive Agile PDF

retrospettive  PARTE V RETROSPETTIVE AGILI Pierluigi Pugliese ScrumMaster...

retrospettive  PARTE V RETROSPETTIVE AGILI Pierluigi Pugliese ScrumMaster #satellite Metafore Facilitatore #planet #planet tipi di metafore #satellite ruolo #satellite focalizzazione consigli pratici #satellite #satellite tattiche di “sabotaggio” tipi di futuro #satellite Solution-focused Fallimento della retrospettiva #satellite #planet #planet domande sistemiche #satellite ruoli scale di valutazione #satellite #satellite dinamiche di gruppo # satellite Retrospettive organizzazione #star system #satellite cambiamento bibliografia su retrospettiva #satellite #satellite Il gruppo #planet Miglioramento continuo struttura e processo #planet #satellite  Parte 5 Il sistema Retrospective Cosa leggi? Un libro di carta? In attesa di arrivare nel sistema Retrospective, ho rispolverato questo manuale che parla del tema centrale del nostro prossimo viaggio: le retrospettive appunto… Ah bene… E stai trovando qualcosa di interessante? Certamente sì… il concetto di “retrospettiva” è molto importante per l'agilità. In questo manuale viene addirittura presentata come un elemento essenziale per il processo di miglioramento di una team, di una azienda o, più genericamente, di una organizzazione. Sì è corretto… Il Continuous Improvement, il miglioramento continuo che è elemento cardine delle metodologie agili, non può esistere senza la sperimentazione, prima, e la verifica, poi, dei risultati di tali sperimentazioni. La retrospettiva è il modo con il quale il gruppo cerca di comprendere l’efficacia della sperimentazione, valutando i risultati ottenuti, e provando a definire una soluzione alternativa. Questi cicli di sperimentazioni e successive verifiche permettono di avere il maggior numero di feedback e di limitare i danni nel caso si sia intrapresa la strada sbagliata. il Continuous Improvement è quindi una specie di cammino in cui di tanto in tanto si guarda indietro per capire se la strada è quella giusta.  Quindi una retrospettiva è un momento in cui il team valuta i propri errori e definisce una strategia per non commetterli nuovamente. Una retrospettiva è un modo per definire un piano d’azione, corretto? Diciamo che lo scopo della retrospettiva è anche questo. Forse è però più corretto considerare la retrospettiva come un momento di riflessione in cui il gruppo, più che sforzarsi nel cercare per forza di uscire con un lista di cose da fare, dovrebbe arrivare a conoscersi meglio. La presenza di un bravo facilitatore, in questo senso, è di grande aiuto: egli deve sapere quando è utile stimolare il gruppo affinché arrivi a formulare un piano d’azione, e quando invece è preferibile lasciare che la discussione fluisca in maniera naturale, senza troppi schemi e obiettivi imposti. Quindi una retrospettiva è una specie di brain storming libero? Non proprio… Il brain storming è solo uno degli strumenti utilizzati in alcune retrospettive e comunque è solo una parte del lavoro. A volte Il facilitatore utilizza tecniche in libertà (la discussione in stile storming), altre invece segue schemi predefiniti o fa uso di strumenti presi in prestito da altre discipline, come le metafore, i giochi di ruolo e altro ancora. Da quello che mi par di capire, il mestiere del facilitatore richiede una forte preparazione e molta competenza. Si è vero. Guidare una retrospettiva è un tipico esempio del lavoro di un coach: egli deve far emergere i punti di discussione, non suggerire gli obiettivi né tantomeno fornire soluzioni, rispettando il pensiero che emerge dalla discussione. A volte però, quando il gruppo brancola nel buio, deve aiutarlo, magari forzando un po’ la mano o suggerendo la strada.  Il gruppo è un concentrato di esigenze, capacità, desideri e obiettivi differenti, ai quali si sommano poi quelli dell’organizzazione o di un cliente. Uno dei compiti del coach è quello di aiutare a trovare un equilibrio fra queste differenti dinamiche. in tal senso, c’è una metafora interessante che aiuta a comprendere meglio questa cosa. In un acquario popolato da pesci differenti, è necessario trovare un equilibrio in modo che i pesci non si divorino fra loro. Analogamente, affinché un gruppo “funzioni”, è necessario trovare un equilibrio fra i differenti pesci-obiettivi delle persone: il coach deve stimolare la crescita del gruppo affinché si trovi un equilibrio, in modo che l’obiettivo di alcuni non prevarichi quello degli altri.  Il gruppo, in tal senso, è un organismo che evolve seguendo un modello formalizzato negli anni Sessanta da Tuckman, uno psicologo americano. Questo modello, il ciclo di Tuckman appunto, è composto da 4 fasi, corrispondenti ai 4 passi nella crescita del gruppo. Un’altra metafora interessante è lo “Shark Model”, utile per descrivere in quale fase si trova un gruppo: si vuole uscire da una situazione per andare verso una meta, ma a volte i dubbi e le incertezze, gli ostacoli e i pericoli possono frenare o bloccare del tutto questo cammino A seconda della situazione, il coach deve aiutare il gruppo applicando strategie differenti: da motivare a supportare, dall’aiutare a definire meglio l’obiettivo a stimolare la discussione nei momenti di incertezza e oscillazione  …il “computer”: il super-razionale. È l’atteggiamento di chi analizza minuziosamente ogni aspetto di una questione riconducendo la discussione in una chiave esclusivamente razionale, spesso aggiungendo moltissimi dettagli che non apportano un reale contributo. Questo atteggiamento non solo non aiuta a far scorrere le idee, a creare quel giusto clima “creativo”, ma spesso porta al blocco della discussione annoiando o disturbando il gruppo. Il “distractor”, il distrattore, infine agisce introducendo elementi di disturbo di vario tipo: dalla battuta che distrae, all’ironia sempre e comunque, all’aggiunta continua di nuovi argomenti non inerenti al tema della riunione.  Una cosa che mi ha sorpreso è l’approccio basato sulla soluzione, il “solution focus” appunto. Nella retrospettiva basata sul solution focus si suggerisce di orientare l’attenzione alla soluzione, di guardare avanti invece che analizzare il passato cercando le cause di quanto accaduto. Ma non è una contraddizione? presente futuro Diciamo che un processo di retrospettiva che guarda al passato per individuare un problema e ipotizzare una soluzione spesso funziona bene se si tratta di affrontare un problema tecnico o comunque qualcosa legato a un processo “meccanico”. Quando si deve intervenire su aspetti legati alle dinamiche di gruppo, alle persone, ossia più genericamente ai sistemi complessi, spesso anche il solo sforzo di individuare la causa di un problema non porta a nulla. Trovare la soluzione così alle volte è quindi un obiettivo improbo. Quando si usa il Solution Focus è importante la presenza di un facilitatore che guidi la riunione agevolando lo sblocco di energie e rimuovendo gli impedimenti che si credevano insormontabili. non sappiamo cosa è successo qua futuro momento in cui presente ci accorgiamo del cambiamento, già avvenuto Per questo, nella tecnica del Solution Focus si tralascia il “cosa si è” e “perché lo si è”, preferendo immaginare quello che il gruppo o la singola persona vuole essere. Bello… non vedo l’ora di andare a vedere queste cose sul campo… Sì, ancora qualche giorno di viaggio e poi entreremo su Retrospective1 il sistema stellare dedicato alle retrospettive agili…  Capitolo 1 Titolopanoramica Una capitolo sulle retrospettive bibliografia su retrospettiva #satellite Miglioramento continuo struttura e processo #planet #satellite Introduzione Parliamo un po’ di retrospettive: voi le fate? Se sì, funzionano? E come capite se fun- zionano? Le retrospettive sono uno degli strumenti più importanti dell’Agilità, ma tra quelli meno capiti: in questa parte analizzeremo in dettaglio cosa sono le retrospettive e come si possano utilizzare in maniera proficua in un’organizzazione agile. Nei primi capitoli vedremo quali sono gli elementi strutturali di una retrospettiva e anche quali sono i comportamenti in grado di farla fallire; poi continueremo con capi- toli che illustrano alcuni metodi molto efficaci — anche se purtroppo ancora poco co- nosciuti — da utilizzare nelle retrospettive; concluderemo infine con una serie di con- sigli su come moderare una retrospettiva, consigli che sono utili, in realtà, per modera- re qualsiasi tipo di meeting. Retrospettive e Continuous Improvement Il primo tema che affrontiamo è la relazione fra retrospettive e continuous improve- ment: come sono collegati i due concetti? Retrospettive Il termine retrospettiva viene introdotto nella letteratura del project management grazie al libro di Norman Kerth Project Retrospectives. Il libro propone la necessità di effettuare riflessioni regolari sull’andamento del progetto, in modo da correggerne il funzionamento prima che esso sia concluso. Il concetto di retrospettiva diviene subito parte dell’Agilità: il principio 12 del Mani- festo Agile è totalmente dedicato alla riflessione in team. “Ad intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.” Nei progetti tradizionali Questo è in contrasto con le cosiddette Post-Mortem Reviews effettuate nei proget- ti tradizionali: anche quando vengono fatte, di solito molto raramente, danno informa- zioni che possono essere utilizzate solo in progetti seguenti e non aiutano a raggiunge- re il successo nei progetti in corso. Nelle varie metodologie agili Nonostante il principio 12 dichiari apertamente che la retrospettiva è una pratica di base delle metodologie agili, solamente Scrum trova un posto chiaro alla retrospettiva e la piazza alla fine dello sprint. In Extreme Programming (XP), nonostante il concetto di feedback sia uno dei valo- ri fondamentali integrato in maniera pervasiva nelle varie pratiche, non viene utilizza- to in maniera esplicita per il miglioramento del processo. Inoltre il feedback in XP vie- ne descritto più da un punto di vista di prodotto che di processo: feedback sulla qualità Capitolo 1 – Una panoramica sulle retrospettive 19 del codice, feedback sul prodotto dal cliente, feedback del team al cliente sui requisiti. Il processo di sviluppo del software sembra migliorarsi più in maniera indiretta come ri- sultato del feedback sul prodotto che per riflessione diretta: questo per quanto menzio- nato dalla letteratura su XP. Di fatto, le implementazioni di XP che ho avuto modo di osservare includono comunque un concetto di retrospettiva o similare. Tra le pratiche agili meno note, Crystal promuove l’idea delle riflessioni periodiche per migliorare il funzionamento del team, ma lascia al team stesso la decisione di come e quando effettuarle. Continuous Improvement Il Continuous improvement (“miglioramento continuo”) è un concetto simile, ma molto più anziano: il termine è stato coniato da Walter Shewhart , il padre del con- trollo di qualità statistico, e popolarizzato da Edward Deming , statistico america- no, famoso per la sua filosofia di management basata su “14 punti”, uno dei quali è cen- trato sul miglioramento costante del sistema. Nonostante Deming si riferisse molto di più alla produzione di massa che allo sviluppo dei prodotti, le sue idee vengono “impor- tate” in Giappone dalla Toyota e contribuiscono a trasformare quella che era una pic- cola casa automobilistica di portata nazionale nel gigante che conosciamo oggi. Il lavo- ro fatto da Toyota in questo campo viene adesso “reimportato” nel mondo occidenta- le con il nome di Lean. Figura 1 – Il ciclo di Shewhart. 20 Guida galattica per agilisti Plan–Do–Check–Act Shewhart sviluppa per primo il concetto di un ciclo di miglioramento continuo ba- sato su quattro fasi: Plan, Do, Check, Act. Plan: pianificare il lavoro da fare, nel modo migliore attualmente possibile. Do: eseguire il piano. Check: analizzare il risultato e confrontarlo con quanto pianificato. Act: modificare il processo in maniera opportuna in modo che nella prossima itera- zione funzioni meglio. L’obiettivo è di capire e dare significato alla realtà attorno a noi, quello che in gergo si chiama Grasp (“afferrare”), comprendere la complessità del sistema. Il ciclo di Shewhart viene adottato da Deming e da lui pubblicizzato, tanto che è or- mai noto come il ciclo di Deming. Retrospettive vs. Continuous Improvement In cosa differiscono i due concetti di retrospettiva e continuous improvement? La differenza è anzitutto culturale, con il termine retrospettiva utilizzato nell’agili- tà e continuous improvement in Lean e nel Total Quality Management. Di certo, a Figura 2 – Un miglioramento graduale e costante, a “gradini” è quello che ci aspettiamo, ma è poco realistico. Capitolo 1 – Una panoramica sulle retrospettive 21 Figura 3 – Una rappresentazione schematica dei miglioramenti in relazione alle retrospettive: questo andamento è più realistico e riflette maggiormente i casi con cui possiamo confrontar- ci nella realtà. mio parere, continuous improvement descrive meglio quello che vogliamo ottenere in un’organizzaione moderna: un processo che si migliora nel tempo. La retrospettiva è un’azione per raggiungere lo scopo, ma io personalmente trovo più utile descrivere l’o- biettivo di quel che facciamo, piuttosto che il particolare metodo utilizzato. Ma come e quando miglioriamo? Nell’analizzare come le varie organizzazioni evolvono, ho notato però che i migliora- menti non sono sincronizzati con le retrospettive, o comunque siano chiamate le azioni per migliorare il processo. Ci aspetteremmo una situazione del tipo rappresentato in fi- gura 2, dove ogni “gradino” di miglioramento corrisponde a una retrospettiva. E invece troviamo qualcosa di simile a quanto rappresentato in figura 3, dove i mi- glioramenti non sembrano legati a eventi particolari. Cosa succede? Semplicemente accade che le retrospettive sono un modo per riflette- re sul processo, ma come e quando le riflessioni generino risultati concreti non è sempre facilmente prevedibile, anche quando in retrospettiva vengono decise azioni concrete. Una retrospettiva, prima ancora che un modo per decidere cambiamenti di processo, è un modo per dare un significato a quanto avviene attorno al team: il Grasp del ciclo di 22 Guida galattica per agilisti Deming o, con termine più moderno, il sensemaking , ossia il processo con cui si ri- esce ad attribuire significato alle esperienze fatte. Le nuove conoscenze generate durante una retrospettiva — che possono essere esplicitamente documentate, o esperienze impli- cite dei singoli — maturano progressivamente fino a diventare modi diversi di lavorare. Inoltre, molto del lavoro di continuous improvement si basa su esperimenti, e non sempre siamo in grado di prevederne il risultato. Qualche volta l’efficacia del team po- trebbe anche temporaneamente decrescere: stiamo imparando per poterci migliorare ancora di più in seguito. Quando e come fare retrospettive? Se consideriamo la retrospettiva come un modo per fare del sensemaking, cioè per dare un significato all’esperienza fatta, allor confinarla al solo lavoro del team e alla fine dell’iterazione è senza dubbio un tarpare le ali allo strumento. Vediamo un po’ in quali maniere potremmo applicare le retrospettive. Alla fine dell’iterazione Come abbiamo visto, questo è il modo in cui per esempio in Scrum si propone di usare una retrospettiva. Di fatto implementa bene il concetto del manifesto agile: “a in- tervalli regolari…”. Dal mio punto di vista questo è un buon punto di partenza, ma cer- tamente non il punto di arrivo di un buon team. Meglio alla fine dello sprint che mai, ma qualche volta serve riflettere anche in altri momenti e in altre configurazioni. Durante l’iterazione Nel mio lavoro di coach spesso interrompo un meeting o, più in generale, un’attività di team, perché mi rendo conto che c’è un particolare aspetto di processo da discutere e vale la pena affrontarlo immediatamente piuttosto che aspettare la fine dello sprint. Ad esempio, un’interazione fra persone che fa presupporre un conflitto latente, o una de- cisione di team che, a mio parere, non considera tutti gli aspetti necessari e quindi po- trebbe portare a un fallimento. In questo caso, interrompo il meeting e faccio riflettere il team. Nonostante non la chiami retrospettiva, di fatto è una riflessione su come il team sta procedendo, con l’intenzione di dare un significato a delle osservazioni che possiamo fare in quel preci- so istante e in quella situazione specifica. Nella mia esperienza, queste riflessioni sono estremamente utili perché la loro vicinanza all’evento ne amplifica l’efficacia. Con una parte del team Talvolta può essere utile riflettere con solo una parte del team. Tipici esempi sono si- tuazioni di conflitto locale fra alcuni membri del team, o riflessioni su problemi di cui solo una parte del team ha competenza; sì, è vero, il team dovrebbe essere cross-funzio- nale, ma a volte la realtà è ben diversa… Ovviamente preferisco coinvolgere tutto il team dove possibile, ma tra una riflessione con tutto il team dove una parte di esso considera Capitolo 1 – Una panoramica sulle retrospettive 23 tale lavoro come una perdita di tempo e una focalizzata ed efficiente, sia pur con solo una parte del team, preferisco la seconda possibilità. Con il team e altri ancora Questo è un modo di fare retrospettiva a mio parere estremamente importante ed estremamente sottovalutato: quello che noi chiamiamo team è, in realtà, un’astrazione. Il team non è un’isola staccata dal resto dell’organizzazione. Il team è un sistema all’in- terno del sistema dipartimento IT, del sistema azienda, del sistema delle persone che si interfacciano con il team e così via. Riflettere con il solo team vuol dire lavorare con un’astrazione della realtà utile, ma non necessariamente la più utile in tutti i contesti: talvolta vale la pena di far parteci- pare alla retrospettiva anche persone coinvolte nel lavoro con il team, in modo da fare continuous improvement anche al di fuori di tali confini. Di solito sono retrospettive tematiche: vengono convocate per discutere di un tema particolare. Casi tipici sono: comunicazione/collaborazione tra il team e il suo management; comunicazione/collaborazione tra il team e il marketing; comunicazione/collaborazione tra il team e le persone dell’assistenza clienti; comunicazione/collaborazione tra il team e product management; discussione su determinati aspetti di progetti con i vari gruppi aziendali coinvolti. Tra team In organizzazioni con più team, vale la pena fare delle retrospettive comuni tra team che lavorano sulle stesse aree del prodotto, in modo da favorire una comunicazione in- ter-team più orientata al processo che al progetto. Sto dando per scontato che una co- municazione operativa sui contenuti del progetto sia già esistente, cosa che purtroppo è tutt’altro che garantita in molti casi… Nell’organizzazione La differenza forse più rilevante tra il concetto di retrospettiva e quello di continuous improvement è che la retrospettiva è dichiarata dal manifesto agile come un lavoro di team, mentre il continuous improvement avviene a tutti i livelli. A mio parere è vitale, per un’organizzazione moderna, che il lavoro di sensemaking avvenga a tutti i livelli. L’attività di riflessione sui processi è alla base di un’organizzazio- ne che impara, e ne fa crescere il livello di maturità. Per questo, delle retrospettive rego- lari nel management, tra i vari dipartimenti, tra vari livelli gerarchici, etc. permettono la creazione di importantissimi cicli di feedback all’interno dell’organizzazione il cui va- lore è, di solito, chiaramente e immediatamente visibile. Qual’è l’output di una retrospettiva? Nella maniera usuale di vedere le retrospettive da parte degli agilisti, la retrospet- tiva finisce con una serie di azioni di miglioramento concrete, da applicare durante 24 Guida galattica per agilisti l’iterazione successiva. Nonostante questo sia un nobile obiettivo, non è l’unico, e non è neanche indispensabile. Non è l’unico in quanto, come abbiamo visto in precedenza, per me l’obiettivo prima- rio di una retrospettiva è il sensemaking dell’esperienza fatta. Peter Drucker diceva, riferendosi alla leadership, che il loro compito è di creare un’allineamento di forze. Pe- ter Senge, nel suo The Fifth Discipline , chiarisce come una visione condivisa sia alla base del successo di un’azienda. Creare questo allineamento, questa visione condivisa, è da sempre un’operazione tita- nica, ancora più complessa in un sistema di team agili e auto-organizzati: la retrospetti- va è un metodo per creare, in maniera emergente, un tale allineamento. Da questo pun- to di vista la retrospettiva è molto più utile dei vari action items che genera! L’ottenere azioni concrete di miglioramento non è neppure indispensabile: molto spesso ho visto il facilitatore “torturare” il team nel tentare di raggiungere un risultato concreto… e in tutto ciò l’unico vero risultato è l’aver alienato i partecipanti. L’aver cambiato il modello mentale delle persone tramite la riflessione è già un ri- sultato estremamente importante ed estremamente utile. Chris Argyris ha conia- to il concetto di apprendimento in ciclo doppio (Double-Loop Learning), spiegando come, senza un cambiamento dei modelli mentali che usiamo per decidere sul da farsi, continueremo ad avere sempre lo stesso tipo di risultati. Da questo punto di vista, una retrospettiva che ha come risultato l’ampliamento del modello mentale delle persone coinvolte è un successo, indipendentemente da quali azioni concrete vengono decise. Una cosa che osservo molto di frequente è come il team cambi i suoi processi senza averlo deciso in maniera esplicita: per una sorta di accordo non dichiarato uno o più membri del team cominciano a lavorare in maniera diversa grazie al modello mentale “espanso” dalle riflessioni della retrospettiva. Spesso vengono seguiti dal resto del team, creando così un cambiamento naturale, che è anche molto stabile visto che viene non dal seguire una regola, sia pur autoimposta, ma a seguito di un’atto emergente del team. Mettere in pratica Le retrospettive sono uno strumento importante a vostra disposizione, e il fatto di applicarle “ad ampio spettro” all’interno di un’organizzazione è una tattica importan- te nel processo di adozione della filosofia agile di un’azienda in quanto la fa comunica- re e maturare a tutti i livelli. Per questo vi invito a provare a fare delle retrospettive diverse, coinvolgendo colleghi che finora non sono stati esposti: vedrete che i risultati non mancheranno! Retrospettive: la letteratura corrente Le retrospettive sono entrate a far parte del body of knowledge dell’agilità e sono le- gate al continuous improvement. Occupiamoci adesso della letteratura corrente sulle retrospettive, analizzandone la validità e l’applicabilità sul campo. Capitolo 1 – Una panoramica sulle retrospettive 25 Il tutto comincia con… …il libro di Norman Kerth Project Retrospectives del 2001, un testo importante sia perché presenta per la prima volta il termine “retrospettiva”, sia perché introduce il con- cetto di condurre riflessioni sui progetti, presentando al contempo una serie di attivi- tà specifiche da utilizzare. Una parte interessante affrontata da Kerth è il come vendere le retrospettive in azien- da, aspetto importante in quelle organizzazioni — e purtroppo non sono poche — dove il fatto di fermare la “produzione” per riflettere su come funziona il sistema è una cosa culturalmente poco apprezzata. Un’altra parte a mio parere molto importante del lavoro di Kerth, riguarda il ruolo del facilitatore: dal gestire i conflitti al creare un’ambiente sereno per la riflessione, al gestire la “resistenza” al cambiamento. I concetti presentati nel libro sono interessanti, anche se, a mio parere, nell’insieme il contenuto è ormai superato da altre fonti che di- scuteremo di seguito. La “prime directive” La parte oggi più conosciuta del lavoro di Kerth, e forse anche la più contestata, è la cosiddetta Prime Directive (vedi sotto), un principio da discutere all’inizio di una re- trospettiva per stabilire i principi fondamentali di come il gruppo dovrebbe operare: “Indipendentemente da quello che scopriremo nella retrospettiva, dobbiamo comprendere e credere sinceramente che tutti quanti abbiano svolto il lavoro al meglio possibile per loro, sulla base di quello che si conosceva in quel momento del processo, sulla base delle loro capacità, delle risorse disponibili e della situazione che si presentava”. Ci sono vari commenti in rete, dove molte persone apprezzano una tale affermazione di principi e altre la considerano assolutamente sbagliata. La posizione più veemente- mente contraria che abbia trovato, e che mi trova in buona parte d’accordo, è quella di Tobias Mayer. Secondo lui la Prime Directive è irrispettosa nei confronti delle per- sone e, invece di aiutare, in realtà non fa altro che tentare di forzare le persone a lavorare in un modo politically correct, indipendentemente da cosa pensino veramente. Critiche alla “prima direttiva” Pur non arrivando alle posizioni estreme di Tobias Mayer, io personalmente non uso la Prime Directive per vari motivi. Anzitutto, il “dobbiamo” è un controsenso: nella retrospettiva vogliamo creare un’ambiente dove le persone sono libere di dire le loro opinioni e con questa Prime Di- rective gli diciamo cosa devono fare. Se fanno quello che vogliono, violano la prima di- rettiva; se fanno quello che dice la prima direttiva non hanno la libertà di dire la pro- pria: a tutti gli effetti un paradosso! 26 Guida galattica per agilisti Poi c’è quel “credere sinceramente”: e se sono dubbioso su qualcosa, ci credo lo stes- so? Se penso che qualcuno non abbia fatto il lavoro al meglio, non posso esprimerlo? Di nuovo: un controsenso! E l’enunciazione “sulla base di quello che si conosceva in quel momento, sulla base delle loro capacità, delle risorse disponibili e della situazione che si presentava” sembra quasi un catalogo di dove andare a cercare scuse: una delle caratteristiche dell’agilità è quella di voler creare dei team che si prendono la responsabilità del loro lavoro e del loro funzionamento interno; qui, invece, apriamo una porta a fattori esterni che “dan- neggiano” il team. Per carità, situazioni del genere esistono veramente, ma io chiedo al team di cercare anzitutto soluzioni al suo interno e, solo dopo, di passare il problema a entità esterne: altri team, management, risorse e così via. Agile Retrospectives La fonte probabilmente più conosciuta di materiale sulle retrospettive è il libro di Diane Larsen ed Esther Derby Agile Retrospectives. Scritto nel 2009, quindi di 8 anni più “giovane” di Project Retrospectives, questo lavoro codifica le retrospettive nella forma in cui le vedo più spesso implementate nelle varie organizzazioni. Consiglio caldamente la lettura di questo libro, e anzi, di averlo come manuale di ri- ferimento per le vostre retrospettive in quanto presenta: un concetto globale su come affrontare il tema; un processo logico (che descriverò fra poco) su come organizzare una retrospettiva; una serie di attività di semplice implementazione e con un valore pratico molto alto. Il processo in cinque fasi di Agile Retrospectives Larsen e Derby propongono che una retrospettiva sia composta da cinque fasi di- stinte, ognuna con un suo obiettivo: Set the stage Gather data Generate insights Decide what to do Close the retrospective Vediamole in dettaglio nei paragrafi successivi. Set the stage Il Set the stage è una fase di apertura della retrospettiva, un modo per creare un team che sia in grado di lavorare assieme e produrre risultati. Dal mio punto di vista, questa è una fase molto importante, specialmente se è una re- trospettiva organizzata per un gruppo di persone che non lavora assieme ogni giorno: business + IT, comunità di ScrumMasters o di Product Owners, e così via. Parleremo più avanti di dinamica dei gruppi in una retrospettiva; per ora vi basti sa- pere che un Set the stage fatto bene è un elemento fondamentale di una retrospettiva Capitolo 1 – Una panoramica sulle retrospettive 27 funzionante. Vi banalizzo un po’ la cosa: come quando degli animali si incontrano e si annusano per capire qualcosa dell’altro, così anche noi umani abbiamo il bisogno di ca- pire chi abbiamo di fronte e per capirlo aiuta avere un processo che dia a tutti i parteci- panti un’idea di base sull’atteggiamento degli altri partecipanti. Check in L’attività che io uso più spesso per questa fase, presa dal libro di Larsen e Derby, è il cosiddetto Check In: chiedere ai presenti una domanda cui rispondere in maniera mol- to breve e senza bisogno di giustificazioni ulteriori, in modo tale che ognuno abbia la possibilità di rispondere dicendo la sua opinione. Domande tipiche sono: “Se dovessi riassumere l’ultimo sprint / questa fase del progetto / … in una parola (o in tre o in cinque o …), quale sarebbe?” “Se dovessi riassumere in una parola il tuo atteggiamento nei confronti di questa re- trospettiva, quale sarebbe?” Lo scopo di questa attività non è quello di raccogliere informazioni dettagliate, ma semplicemente di far parlare tutti, in modo da leggere i segnali verbali e non verbali dei presenti e capire “l’umore” del meeting. ESVP Un’altra attività simile da usare in casi in cui temiamo che l’atteggiamento delle per- sone potrebbe essere tale da far fallire il meeting, è il cosiddetto ESVP , con cui an- diamo a vedere lo stato d’animo delle persone presenti in maniera molto più diretta che con il check-in presentato sopra. In questo caso chiediamo ai partecipanti con che atteggiamento si presentano all’in- contro: sono per caso degli Esploratori (E), attivamente in cerca di nuove possibilità? O sono degli Shopper (S) occasionali: se vedono un’idea che a loro piace la prendono, ma non la cercano attivamente. O magari sono in Vacanza (V), non veramente inte- ressati alla retrospettiva ma a cui fa piacere stare via dal computer per un paio d’ore. O magari si sentono Prigionieri (P) del processo e sono lì, ma preferirebbero non esserlo. Chiarire la posizione dei partecipanti, se espressa chiaramente, aiuta a farsi un’idea di come procedere con la retrospettiva. Gather data, Generate insights, Decide what to do Dopo l’apertura, il nucleo centrale della retrospettiva si basa su tre fasi che le autrici del libro separano da un punto di vista logico: in modo da evitare di saltare a conclusio- ni affrettate, è utile dividere la fase di raccolta dati (Gather data), che deve rimanere più obiettiva possibile, da quella in cui interpretiamo e diamo un significato ai dati (Gene- rate insights), a quella in cui, viste le informazioni raccolte e il loro significato, decidia- mo cosa fare e cambiare nelle prossime iterazioni (Decide what to do). La suddivisione proposta da Larsen e Derby ha un suo significato, che io però pren- do con le molle: innanzitutto molte attività che propongono spaziano su una o più fasi, 28 Guida galattica per agilisti come vedremo più avanti in questo capitolo; inoltre il processo presentato vuole con- figurarsi come un modo di procedere puramente razionale, che è ottimo per problemi principalmente tecnici, ma che, nella mia esperienza, fallisce più o meno miseramente nel momento in cui, e sono la maggioranza dei casi, andiamo a parlare di fattori umani. Figura 4 – Un esempio di timeline come ricostruzione visiva e collaborativa degli elementi sa- lienti su un periodo. Figura 5 – Una timeline “arricchita” di considerazioni riguardanti determinati eventi. Capitolo 1 – Una panoramica sulle retrospettive 29 Figura 6 – Un esempio di Mad–Sad–Glad: ciò che è andato male, che è andato così e così, e che è andato bene. Tra le attività proposte per raccogliere dati, la più nota è la timeline : il ricostruire in maniera visiva e collaborativa gli elementi salienti dell’iterazione. È un’attività che a me piace applicare a retrospettive che riflettono su periodi più lunghi di un’iterazione: retrospettive di release/progetto, retrospettive trimestrali tra dipartimenti, e così via, poiché i partecipanti necessitano spesso di un riassunto di quanto successo nel periodo sotto analisi prima di poter ragionare su cosa migliorare. Oltre alla pura raccolta di informazioni sugli eventi del periodo, spesso viene chie- sto ai partecipanti di riportare anche uno o più parametri più “soft”, tipo il grafico della loro motivazione durante il periodo, o il loro umore, o più semplicemente definire tra- mite Post-it cos’è andato bene o male (vedi Mad–Sad–Glad di seguito), in modo da ve- dere se ci siano stati periodi particolarmente motivanti o frustranti per diverse persone e capire cosa è successo in quei casi. Un’altra attività molto nota e molto utile è il Mad–Sad–Glad cui accennavamo so- pra. Al partecipante viene chiesto di raccogliere quello che nello sprint è andato bene (Glad), così così (Sad) o proprio male (Mad). In una prima fase di lavoro individuale o svolto in piccoli gruppi, i partecipanti scri- vono il loro input su Post-it, uno per argomento e utilizzando un codice di colori prede- finito: sui cartellini verdi (Glad) si scrive qualcosa riferita a una cosa piacevole, un suc- cesso, qualcosa che è andata bene; sui cartellini gialli (Sad) si scrive una cosa che ha rat- tristato, che non è piaciuta, un fallimento; sui rossi, infine (Mad), qualcosa che ha fatto arrabbiare qualcuno nel team, un evento o una situazione che ha creato dei “maldipan- cia” e che anche a distanza di tempo provoca un ricordo sgradevole. 30 Guida galattica per agilisti Dopo aver posizionato i cartellini su una parete, di solito viene fatta una votazione per decidere quali sono gli argomenti più importanti, che vengono poi affrontati in or- dine di priorità. Questa attività viene presentata da Larsen e Derby nella sezione Gather data, ma in realtà è un processo che copre tutte e tre le fasi, in quanto una tale attività termina con un’elenco di cose da fare per migliorare la situazione attuale. Nel libro sono presentate molte altre tecniche interessanti utili per gestire una retro- spettiva: ecco perché è un testo che consiglio caldamente. Close the retrospective L’ultima fase è la chiusura (Close the retrospective). Da un lato ha il significato di “cerimonia”, dall’altro ha lo scopo di capire se la retrospettiva ha creato valore. La mia attività preferita è il cosiddetto “ROTI: Return Of Time Invested”, dove viene chiesto ai partecipanti di valutare, su un flip chart o semplicemente con un pollice verso l’alto o verso il basso, qual è stato il ritorno del tempo che hanno investito nella retrospettiva. Un ritorno basso può voler dire che occorre migliorare le skill di facilitazione, ma an- che che i problemi discussi non sono sotto il controllo del team o che il team non vuole prendersi la responsabilità di risolverli. In ogni caso, è un’indicazione che c’è lavoro da fare per rendere le retrospettive veramente efficaci per il team. Figura 7 – Un esempio di ROTI: qual è stato il ritorno del tempo investito nella retrospettiva? Capitolo 1 – Una panoramica sulle retrospettive 31 Altre fonti Un buon libro apparso di recente è quello di Patrick Kua The Retrospective Handbo- ok : in un formato molto compatto affronta temi complementari ad Agile Retrospec- tives, in particolare discutendo i problemi specifici delle retrospettive distribuite, tema sempre più rilevante per molte aziende. Ovviamente non dimentichiamoci di Google: una semplice ricerca di attività per re- trospettive vi fornisce centinaia di risultati, sui cui spicca, a mio parere, il sito Tasty Cup Cakes dove c’è una raccolta molto completa e ben documentata per attività, per team, per retrospettive, ma non solo. Se da un lato c’è un’inondazione di materiale disponibile, a mio parere molti di questi siti si focalizzano su un problema sbagliato: il descrivere attività per retrospettive sen- za considerare come queste si incastrano nel concetto globale del continuous impro- vement. Qual è l’obiettivo di queste attività? Come si incastrano in un processo di re- trospettiva? Quali sono i limiti e quando queste attività non funzionano? Che tipo di briefing va fatto al team affinché funzioni? Che tipo di debriefing ha senso fare per in- tegrare quanto appreso? Questi sono tutti aspetti che raramente trovo discussi sui vari siti, ma che sono a mio parere vitali per la riuscita del processo. Riferimenti bibliografici Argyris C. – Schon D. (1978). Organizational Learning: A theory of action perspective. Reading MA: Addison-Wesley Senge P.M. (1990). The Fifth Discipline. Doubleday/Currency Shewhart W.A. (1980). Economic Control of Quality of Manufactured Product. 50th Anniversary Commemorative Issue, American Society for Quality Deming W.E. (1986). Out of the Crisis. MIT Center for Advanced Engineering Study Kerth N.L. (2001). Project Retrospectives: A Handbook for Team Reviews, Dorset House La voce “sensemaking” su Wikipedia http://en.wikipedia.org/wiki/Sensemaking La voce “Peter Drucker” su Wikipedia http://en.wikipedia.org/wiki/Peter_Drucker  Capitolo 2 Gestire la dinamica del gruppo in una retrospettiva dinamiche di gruppo # satellite organizzazione #satellite cambiamento #satellite Il gruppo #planet Introduzione: dinamiche di gruppo e retrospettive Una retrospettiva efficace si basa sul fatto che le persone del team siano in grado di comunicare in maniera aperta e produttiva, senza vincoli di ruolo o di posizione nell’organizzazione, affrontando anche temi che possono “far male”. Discutere tali temi, con la conseguente generazione di comportamenti alternativi, è esattamente il modo con cui le retrospettive migliorano il funzionamento di un’azienda. Vista l’importanza del buon funzionamento della dinamica di un gruppo, in questo capitolo vediamo i modi con cui possiamo, nel ruolo di facilitatore, supportare il “siste- ma umano” della retrospettiva. Che cosa vogliamo ottenere? È chiaro che puntiamo ad avere un team funzionante: dobbiamo pertanto identifi- care alcuni aspetti che distinguono un team funzionante da un gruppo che invece fun- ziona male. Caratteristiche del team funzionante Che cosa vuol dire una dinamica di team funzionante? Ci sono tutta una serie di pa- rametri “osservabili” che distinguono un team funzionante: disponibilità ad affrontare un tema, per quanto scomodo; la discussione procede in maniera aperta e le divergenze vengono risolte in manie- ra non emotiva; le parole degli altri vengono valutate per quello che è il messaggio razionale e sen- za “dietrologie”; le decisioni vengono prese rapidamente e apparentemente senza sforzi; anche se le decisioni non piacciono a tutti, è possibile comunque raggiungere un ac- cordo che tutti sostengono; la direzione complessiva del team è chiara ed è la base per le decisioni che vengo- no prese. Caratteristiche del team non funzionante Ci sono ovviamente anche parametri osservabili che identificano un team che, inve- ce, non funziona: la discussione su un tema dura all’infinito (almeno così viene percepito dalle perso- ne!) e senza arrivare a risultati concreti; il team genera più proposte di quante sia possibile analizzarne nel tempo a disposi- zione; i termini della discussione rimangono generici; anche quando sembra che si vada nel dettaglio, un’analisi giusto un po’ più approfon- dita dei termini e delle frasi usate rivela concetti fumosi e non chiari; è la non-chiarezza dei termini che permette di raggiungere un’accordo apparente, ma nella pratica inutilizzabile; Capitolo 2 – Gestire la dinamica del gruppo in una retrospettiva 35 si tenta di ricondurre la discussione a dei principi o a una visione a più ampio respi- ro, ma senza successo; le parole delle persone vengono prese come attacchi personali e impera un atteggia- mento di chiusura mentale nei confronti delle idee e delle opinioni degli altri; c’è un continuo rifarsi ai fatti negativi accaduti nel passato e, nei casi più disfunzio- nali, a darsi a vicenda le colpe di quanto accaduto nel passato; i problemi importanti da discutere e risolvere sono messi implicitamente da parte e il team discute invece di problemi secondari o magari pure importanti, ma in un fu- turo così remoto da essere irrilevanti al momento attuale. Buona parte di queste “tattiche” sono in realtà metodi per evitare di discutere sui problemi importanti da risolvere, deflettendo l’attenzione su cose/aspetti/problemi di secondaria importanza. Quindi a tutti gli effetti sono dei modi per evitare un conflitto aperto, spesso e volentieri perché diventerebbe ad alto contenuto emotivo. Ovviamente questi parametri sono rilevanti per qualsiasi attività di team e non solo durante una retrospettiva: anche in fase di meeting con stakeholders, planning di itera- zione, demo, e così via, questi parametri sono facilmente osservabili! Un po’ di dinamica dei gruppi… Per capire cosa succede nei casi di team disfunzionali andiamo a vedere cosa dice la psicologia quando parliamo di dinamica di gruppi. Ci sono diverse teorie e diversi modelli su come funziona un gruppo. Il modello che descriverò qua è il famosissimo ciclo di Tuckman, sviluppato attorno agli anni Ottan- ta. Nonostante ci siano altri modelli più recenti, preferisco presentare questo per la sua semplicità e perché, per quanto concerne l’applicazione alle retrospettive, è perfetta- mente adeguato a descrivere cosa vediamo in pratica. Gli obiettivi dei componenti del team L’idea di base del modello è che, quando ognuno di noi, spontaneamente o perché ci viene richiesto, si unisce a un gruppo, porta con sé tutti i suoi obiettivi. Quando vado a far parte di un team mi interessa lavorare in un certo modo, imparare delle tecnologie, poter lavorare assieme ad una persona che so essere in gamba, … Una parte di questi obiettivi li formuliamo in maniera chiara; altri rimangono nel nostro cervello non chiaramente espressi, ma contribuiscono comunque a determinare il modo in cui agiamo in team. Quando entriamo a far parte di un team, i nostri obiettivi vengono messi assieme a quelli degli altri. La metafora che uso è che i nostri obiettivi individuali sono come dei pesci in un acquario che, quando entriamo a far parte di un team, vengono messi in un acquario più grande assieme ai “pesci-obiettivi” degli altri membri del team: alcuni sono compatibili fra di loro, anzi, magari fanno volentieri gruppo; altri sono incompa- tibili e fanno una vita isolata; altri addirittura sono in contraddizione tra di loro e uno potrebbe finire per mangiarsi l’altro! 36 Guida galattica per agilisti Come funzioneranno questi pesci-obiettivi nell’acquario comune è difficile da dir- si: di sicuro, c’è una fase di auto-organizzazione dell’acquario prima di raggiungere una qualche forma di nuova stabilità. Il ciclo di Tuckman Ritornando al nostro team, la dinamica di quello che succede dipende da come i vari obiettivi personali interagiscono fra di loro. Come dicevo, Tuckman, negli anni Ottan- ta, ha descritto il modo in cui un team di nuova formazione attraversa una serie di quat- tro fasi caratterizzate da modi diversi con cui le persone interagiscono fra di loro, dette Forming, Storming, Norming, Performing. Tali fasi avvengono solitamente in questo ordine, tanto da considerarle un ciclo che ogni team percorre in tale ordine. Nei paragrafi seguenti, vediamo in maggiore dettaglio le quattro fasi e cosa possiamo fare nei vari casi come facilitatori del team. Fase di Forming Il team è appena formato: i “pesci-obiettivo” sono appena arrivati nell’acquario co- mune. Questa è una fase di osservazione e di attesa: non sappiamo come si comporte- ranno gli altri, non li conosciamo a sufficienza. Ci limitiamo a osservare e ad avanzare qualche timida proposta, più che altro per capire come reagiscono gli altri e non vera- mente perché pensiamo che verrà accettata. Figura 8 – Il ciclo di Tuckman e le quattro fasi della dinamica di un gruppo: forming, storming, norming, performing. Capitolo 2 – Gestire la dinamica del gruppo in una retrospettiva 37 In questa fase il team sarà in grado di produrre meno della somma degli individui, poiché una buona fetta delle energie del team viene utilizzata per conoscersi. Ruolo del facilitatore Dare struttura, visione, guida: il team ha bisogno di cominciare a parlare, di comin- ciare a confrontarsi e di definire un modo comune di lavorare. Un caratteristica della facilitazione è un rispetto estremo per le persone e le loro po- sizioni, in modo da garantire che tutti abbiano uno spazio per poter parlare. Spesso in questa fase è necessario pianificare attività che favoriscano la socializzazio- ne delle persone. Fase di Storming Nella fase di storming gli obiettivi individuali che contrastano fra di loro provocano conflitti tra le persone. I conflitti possono essere aperti e dichiarati o latenti. Un con- flitto latente si ha quando le persone coinvolte negano che ci sia un conflitto, fatto sal- vo poi criticare o attaccare l’altro quando non è presente. In questa fase la produttività del team nel suo insieme è estremamente ridotta in quanto i conflitti tra le persone utilizzano la maggioranza delle energie del team. Ruolo del facilitatore Lavorare in modo da evidenziare i conflitti e fare in modo che vengano risolti, evi- denziando i diversi obiettivi delle varie persone. Un conflitto aperto è già riconosciuto come tale dai partecipanti, quindi il ruolo del facilitatore è quello di tentare di far sedere i partecipanti attorno a un tavolo e di farli parlare, dando una struttura al lavoro che permetta di discutere sia degli aspetti razio- nali che di quelli emotivi alla base del conflitto. Diverso è il caso del conflitto latente: prima di poterlo risolvere deve essere eviden- ziato e quindi il facilitatore ha il compito di trovare una struttura di lavoro che permet- ta di cominciare a discutere del conflitto tra le persone, facendo attenzione che, una vol- ta messo in luce, il conflitto non degeneri e diventi ingestibile. La messa in luce del conflitto latente va provata solo se pensate di essere in grado di gestire il conflitto che ne potrebbe uscire! Una volta sono andato molto vicino a di- struggere un team perché il conflitto messo in luce è salito di temperatura molto più di quanto pensassi! Fase di Norming Superata una buona parte dei conflitti, il team è finalmente in grado di discutere del- la sua organizzazione: che ruolo hanno le varie persone, quali sono i limiti dei ruoli. In generale è la fase in cui il team si accorda su un “contratto” per lavorare assieme. Tale contratto può essere esplicito come ad esempio un team charter come quello spesso usato in un team agile per chiarire chi fa cosa e quali sono le regole di base del gruppo. 38 Guida galattica per agilisti Ma una buona parte rimane comunque implicita: chi e come agisce su cosa? Chi sono i leader nelle varie situazioni in cui il team deve operare? In questa fase il team ricomincia a produrre, anche se la mancanza di “regole del gio- co” ne diminuisce l’efficacia potenziale. Ruolo del facilitatore In questa fase il ruolo principale del facilitatore è quello di supportare la definizio- ne di regole chiare e funzionali per il team. Non è necessario che tutto venga messo per iscritto, anzi, ma la chiarezza delle regole discusse è la chiave di una fase di norming ef- ficace. Ci potrebbero anche essere dei conflitti residui da risolvere con le tecniche vi- ste al punto precedente. Fase di Performing Superati i conflitti e scritte le regole del gioco, il team può finalmente funzionare! Se, nelle fasi precedenti, è stato fatto un lavoro di definizione delle regole appropria- to, la produttività di un tale team può andare ben oltre quella della somma dei singoli! Ruolo del facilitatore In linea di massima, il ruolo principale del facilitatore è quello di… lasciarli lavora- re! Occasionalmente potrebbe essere necessario ri-discutere alcuni temi visti durante le fasi di storming e norming. Alcune note sulle fasi del ciclo di Tuckman Ci sono alcuni dettagli da tener presenti in questo tipo di modello. Sovrapposizione delle fasi Attenzione che le varie fasi di un team spesso si sovrappongono, quindi mentre per certe caratteristiche il team potrebbe essere già in performing, per altre potrebbe essere necessario fare ancora un po’ di norming. Quello che spesso possiamo definire in maniera abbastanza chiara è però la “media” del team e dire, ad esempio, che il team è nel complesso in fase di norming, con ancora dei residui significativi di storming fra le persone X e Y e con una parte del team già ab- bondantemente in performing. Reinnesco del ciclo Una cosa fondamentale da tener presente nell’utilizzare il modello è che qualsiasi cambiamento nella struttura del team (persone nuove, qualcuno che lascia il team, un nuovo manager…) o nel lavoro assegnato (nuovo progetto, nuova tecnologia…) pro- voca un rimescolamento nel rapporto tra gli obiettivi individuali e, di conseguenza, l’i- nizio di un nuovo ciclo Forming–Storming–Norming–Performing. Se le modifiche sono limitate, ci sono buone probabilità che il ciclo di assestamento si risolva in poco Capitolo 2 – Gestire la dinamica del gruppo in una retrospettiva 39 tempo; se sono radicali, potrebbe durare anche molto a lungo. Questo è uno dei motivi per cui in agilità raccomandiamo di tenere i team stabili. Ciclo incompleto Tenete anche presente che non è detto che il team esca dalla fase di storming: ho vi- sto più di qualche team continuare con i suoi conflitti interni invece di produrre. In questo caso è vostro compito valutare se valga la pena di continuare a investire sul team o se sia meglio cambiarne la composizione. Conflitti latenti residui Un caso abbastanza tipico di molti team è che la fase di storming non ha risolto tut- ti i problemi interpersonali, che rimangono presenti in forma più o meno latente. Ecco che in tal caso il risultato sarà un team che sembra essere in performing, ma il cui rendi- mento è decisamente inferiore alla somma dei singoli. Il diagramma di figura 9 descri- ve il rendimento del team nelle varie fasi. Il punto di partenza al tempo zero è la somma del rendimento dei singoli. Ciclo di Tuckman e retrospettive La fase del ciclo di Tuckman in cui il team si trova è importante per poter pianificare le attività della retrospettiva. Come abbiamo visto in precedenza, le necessità del team sono diverse ed è vostro compito servire al meglio il vostro team-cliente. Figura 9 – Quanto è efficace la fase di storming? Il team renderà più della somma delle parti? 40 Guida galattica per agilisti Se siete lo ScrumMaster del team ovviamente siete già in grado di stimare in che fase sia il team, e il mio consiglio è di considerare la retrospettiva come un’opportunità per far muovere il team verso il performing: essendo la retrospettiva un’attività “diversa” dalla “solita” attività produttiva del team, certi temi più organizzativi sono più discuti- bili in una tale sede rispetto ad altri meeting. Se siete un facilitatore esterno e vi trovate a dover gestire una retrospettiva per un team che non conoscete, la vostra capacità di percepire la situazione del team è cruciale per la riuscita del meeting. Nell’incertezza, meglio “giocare al ribasso” e considerarlo come se fosse in Forming: in tale fase tipicamente è necessaria un spiccata attitudine alla facilita- zione, cosa che in genere risulta utile anche se il team è in Storming o in Norming; non appena li vedrete all’azione potrete sempre cambiare modo per facilitare, se serve. Verso una dinamica funzionale Senza una dinamica di team funzionante, la retrospettiva vi darà risultati miseri: sta a voi, come facilitatori in gamba, gestirla in maniera opportuna per ottenere il meglio del continuous improvement per il vostro team. Il gruppo e il cambiamento: migliorarsi continuamente… sì, ma… In questa parte del libro abbiamo parlato varie volte di miglioramento continuo e abbiamo visto come non sia una cosa regolare e costante ma piuttosto un percorso fat- to di alti e bassi, dove la tendenza generale è (o dovrebbe essere…) verso “l’alto”, verso una situazione globalmente migliore. Una delle possibili ragioni per un tale comportamento “oscillante” è senza dubbio la dinamica del gruppo, come abbiamo visto nelle pagine precedenti, un gruppo che non è in performing non sarà probabilmente in grado di decidere modi per migliorarsi, o quantomeno non riuscirà a farlo con la dovuta efficienza. Ma anche un gruppo in performing potrebbe avere difficoltà a cambiare. E questo per altri motivi che non hanno nulla a che vedere con la dinamica e sono relativi al con- testo in cui il team opera e a qual è il suo compito al momento. Nei prossimi paragrafi analizzeremo proprio questi problemi. Dinamiche del cambiamento Miglioramento vuol dire cambiamento. Cambiamento vuol dire una decisione, con- scia o inconscia che sia, di abbandonare il “vecchio” per raggiungere un “nuovo”. Pur- troppo non sempre le cose sono così semplici: c’è decisione e decisione. Pensate alla vo- stra esperienza; talvolta una decisione è per voi scontata: “just do it!”. Altre volte decide- re è una cosa sofferta, dove ponderate per ore, settimane o addirittura mesi se cambiare o no. Talvolta non vi sembrava neppure di dover prendere una decisione, finché vi è ap- parso chiaro che era necessario prenderne una. Tali dinamiche, che tutti abbiamo sperimentato prima o poi nella nostra vita, sono presenti anche nella vita di un team, anche nelle retrospettive. Se, in qualità di facilitatori Capitolo 2 – Gestire la dinamica del gruppo in una retrospettiva 41 di una retrospettiva, vogliamo supportare questo processo di cambiamento, dobbiamo essere in grado di capire come avviene una decisione ed essere in grado di utilizzarne i momenti salienti. Il tetralemma Il modello che presenterò di seguito è il tetralemma applicato a una decisione di cambiare; si tratta di un modello poco noto e, da quanto mi risulta, pressoché scono- sciuto nella letteratura agile, ma a mio parere è cruciale per capire la logica con cui un team decide di migliorarsi. Il modello originale del tetralemma proviene dalla logica tradizionale indiana, dove viene introdotto il concetto che, in una scelta fra due opzioni, A e B, queste non sono le uniche due opzioni possibili. Potrebbe essere possibile scegliere anche una qualche for- ma di combinazione di A e B oppure qualcos’altro che non sia né A né B. Ovviamente non parliamo di logica binaria in questo caso, ma del modo in cui noi esseri umani so- litamente prendiamo decisioni e in cui una tale modalità operativa è comune. Due studiosi tedeschi, Insa Sparrer e Matthias Varga von Kibed, hanno ripreso que- sto modello e lo hanno integrato e applicato alla terapia e al coaching. Per la versione Figura 10 – La rappresentazione grafica del nostro modello per individuare le situazioni del cam- biamento: “via da…”, “ma dove?”, “ostacoli”, “verso…”, “oscillazione / ambiguità”. 42 Guida galattica per agilisti che vi riporto in questo capitolo, ho provveduto a dare al modello una rappresentazio- ne grafica semplice da ricordare. Ogni elemento grafico rappresenta una delle situazioni in cui un team si trova nel de- cidere un cambiamento. Nei prossimi paragrafi andremo a discutere le varie situazioni. Situazione 1: Ma l’iceberg non c’è… Supponiamo di essere in una situazione A e di essere perfettamente soddisfatti di A: non sentiamo alcun bisogno di cambiare. La situazione potrebbe anche essere esplosiva, ma finchè non ce ne rendiamo conto non avremo alcun interesse e alcun stimolo a cam- biare: in figura 10, la situazione esplosiva è rappresentata dalla bomba. Il fatto che venga vista da qualcuno come una situazione “esplosiva” e da cambiare, non vuol dire che il team la veda come tale. Anche sul Titanic non erano preoccupati fino a che non hanno visto l’iceberg… Questa situazione si può riconoscere facilmente perché i membri del team sono convinti di essere sulla strada giusta. Quando il team è in questa situazione, i suoi componenti non saranno certamente in grado di prendere decisioni di cambiamento. Il modo migliore con cui potete accompagnarli è quello di stare al loro fianco, in- troducendo dissonanza, cioè evidenziando come i comportamenti che stanno seguen- do a lungo andare non funzionano più o che potrebbero esserci modi migliori di pro- cedere. Ma non fatevi illusioni: non sono pronti a decidere di cambiare e non cambie- ranno. Almeno per ora. Situazione 2: Vogliamo andare via da… Quando finalmente sarete riusciti a far capire al team che la situazione attuale non è adeguata, sarete in grado di far raccogliere al team le energie per muoversi via dalla si- tuazione attuale. Il team si rende conto che deve andare via dalla situazione attuale, sen- za però necessariamente sapere che direzione prendere. Nel gergo della psicologia della motivazione siamo nella situazione in cui abbiamo una chiara motivazione “via da” che per certe persone è un motivatore fondamentale. Quando il team è in questa situazione, il vostro miglior contributo come facilitato- ri è quello di supportare il gruppo a usare questa motivazione “via da”: create consenso sul fatto che bisogna cambiare, discutete cosa succede se il team non cambia, generate la consapevolezza che il team ha le risorse necessarie per cambiare. Certo, la motivazione “via da” è importantissima, ma non sempre quando vogliamo andare via da una certa situazione sappiamo dove andare… Situazione 3: Siamo nella nebbia! Ok, vogliamo cambiare, andiamo via da una situazione che non ci va più bene. Ma verso dove? Quali sono le nostre opzioni? Pensate a quante volte avete visto un team, o magari anche una o più persone che conoscete al di fuori della vostra vita lavorativa, che non sanno verso quale direzione muoversi e cosa vogliono veramente. Capitolo 2 – Gestire la dinamica del gruppo in una retrospettiva 43 Questa è una situazione molto comune nel mondo aziendale: c’è un problema, vo- gliamo risolvere il problema (ossia andare via dal problema) ma non sappiamo qual è l’alternativa. A peggiorare la situazione a volte diverse persone hanno idee differenti su quale sia il percorso per andare “via dal problema”. Il gruppo è nebbia. In figura 10, le onde agitate rappresentano proprio questa situazione: qual è la direzione in cui andare? Come facilitatori, il nostro miglior contributo in questa situazione è quello di aiutare il team a tematizzare e discutere le varie opzioni, valutando pro e contro, impostando insieme a loro degli esperimenti che ci permettano di capire quale delle strade possibili è la più utile. Inoltre ogni decisione e cambiamento coinvolge sia aspetti logici che emo- tivi: diamo spazio ad entrambi, facciamo parlare il team non solo della decisione come cosa razionale, ma anche come processo che impatta le emozioni dei singoli. Situazione 4: Voglio… ma non voglio Molto spesso quando la nebbia comincia a diradarsi, il team comincia a oscillare tra due o più posizioni: voglio cambiare… ma non voglio cambiare. Belle le nuove possibi- lità… ma anche dov’eravamo prima non si stava poi così male, e così via. In questa situazione il lavoro migliore che un facilitatore possa fare è quello di evi- denziare questo effetto ricordando al team quanto avevano deciso, metterli a confron- to con la loro oscillazione e le loro ambiguità in modo da farli decidere per una qualche opzione. Nella figura 10, abbiamo rappresentato con una linea oscillante questa fase in cui si è fatta la scelta per il nuovo, ma si torna anche a guardare indietro. Ovviamente il gruppo potrebbe anche prendere una decisione diversa da quelle di- scusse precedentemente: un compromesso o magari un’alternativa totalmente nuova. Il pericolo di questa situazione è che il team continui ad oscillare tra il vecchio e il nuovo, in una perenne indecisione che, alla lunga, può portare a conflitti e divisioni. Situazione 5: Ma è dura: ci sono ostacoli! Una volta “scoperto” in che direzione andare, il cammino è più chiaro, ma spesso e volentieri ci sono ostacoli e la strada è difficile. Questo è il caso tipico in cui il team ha capito in che direzione andare ma, per vari motivi, non ha le energie per procedere. In figura 10, lo squalo che nuota nelle stesse acque in cui ci troviamo rappresenta metafo- ricamente proprio gli ostacoli che si frappongono sulla nostra rotta verso il cambiamen- to compiuto. Tipico esempio è, nella mia esperienza, la creazione di un sistema di continuous inte- gration su una base di codice legacy: è chiaro che serve, è chiaro quali siano i vantaggi, ma per essere utile è necessario avere una certa copertura di test che al momento manca e serviranno energie rilevanti per arrivare a un qualcosa di utile. In questo caso il vostro ruolo di facilitatore è più vicino a quello di motivatore: riba- dite quali sono gli obiettivi che il team si era dato, ribadite l’importanza di tali obiet- tivi, ricordate l’energia positiva che il team aveva quando hanno deciso un tale cambia- mento, ribadite cosa cambierà quando avranno raggiunto il risultato! 44 Guida galattica per agilisti Situazione 6: Ci siamo quasi! In questa situazione il team ha in vista l’obiettivo e sa come raggiungerlo. Ci siamo quasi. Potrebbe essere necessario ancora un po’ di tempo, ma il team ha tutte le risor- se per portare a casa il risultato, non ci sono ostacoli rilevanti da superare. In figura 10, l’isola tranquilla verso cui ci si dirige rappresenta l’obiettivo in vista: non è ancora rag- giunto, ma è chiaro dove è e quale sforzo occorre compiere per coprire l’ultimo tratto che ci separa da esso. In questa situazione il team è di solito auto-motivato: la vicinanza all’obiettivo e la re- lativa linearità nel raggiungerlo fa sì che l’altro tipo di motivazione in psicologia, la “verso a” diventi rilevante. Il team non ha più bisogno di voi: lasciateli semplicemente lavorare. L’arte del facilitatore Per me l’arte del facilitatore è quella di capire in quale delle situazioni precedenti si trova il team e agire di conseguenza. Purtroppo vedo di frequente situazioni in cui il coach o lo ScrumMaster agiscono diversamente. La comprensione delle dinamiche di gruppo resta una chiave fondamentale per qualsiasi intervento. Nella “mitologia” del coaching agile viene posta molta enfasi sull’aspetto motivazio- nale del cambiamento: per cambiare serve “solo” la volontà. Ecco che anche autori co- nosciuti puntano molto sul motivare il team. Ma se il team è nella situazione di neb- bia, in cui il problema è trovare una strada adeguata, l’intervento motivazionale ottie- ne l’unico risultato di frustrare persone già frustrate per conto loro per la situazione in cui si trovano. Ho visto spesso coach far pressione su un team, ma anche su un’intera organizzazio- ne, per cambiare qualcosa che per loro era importante, ma l’organizzazione era nella “si- tuazione 1”, dove non si riesce a vedere o comprendere il problema. Inutile dire che è fiato sprecato: se il coach si intestardisce sul tema, rischia anche di farsi dei nemici, cre- ando così resistenza al cambiamento e ritardandolo. Ho visto dei casi di team che sapevano dove voler arrivare e come: la strada era in di- scesa, quindi una “situazione 6”, e lo ScrumMaster li frenava chiedendo al team se fos- sero sicuri, quali fossero vantaggi e svantaggi della scelta fatta. In una tale situazione il team ha deciso e stanno lavorando per l’obiettivo. Se dove vogliono arrivare è sub-otti- male, ci lavoreremo in futuro, ma per adesso non blocchiamo la motivazione a raggiun- gere il risultato comunque buono. Riconoscere la situazione Curiosamente, riconoscere la situazione in cui il team si trova è una cosa relativa- mente semplice. Nonostante un minimo di sbilanciamento cognitivo, buona parte de- gli ScrumMaster e dei coach che usano questo modello sono in grado, dopo un breve periodo di esercizio, di riconoscere dove si trova il team. A quel punto ci sono ben po- che classi di interventi applicabili ad ogni situazione ed è facile trovare un modo per supportare il team. Capitolo 2 – Gestire la dinamica del gruppo in una retrospettiva 45 Situazione Si riconosce da… Tipi di intervento Introdurre dissonanza Il problema non esiste 1. Non serve Evidenziare i limiti del metodo Ha sempre funzionato così cambiare attuale Abbiamo ragione a fare così Far vedere alternative Creare consenso sul fatto che bisogna cambiare Volontà concreta di andare Discutere cosa succede se il team 2. Vogliamo via dal problema, anche non cambia cambiare senza sapere dove Generare la consapevolezza che il team ha le risorse necessarie per cambiare! Volontà di andare via dal Tematizzare e discutere le varie problema ma… opzioni, valutando pro e contro …incertezza su quale Impostare esperimenti che 3. Andare via, ma opzione scegliere permettano di capire quale delle verso dove? Nebbia… La valutazione delle varie strade possibili è la più utile alternative necessita di Dare spazio agli aspetti logici ma moltissima energia anche a quelli emotivi del tema Non c’è accordo su quale trattato direzione prendere Evidenziare l’oscillazione Il team alterna fra 4. Ambiguità Far vedere come decisioni prese muoversi verso il futuro e oscillazione in passato vengano rimesse in e ritorni al passato discussione Il team è frenato, anche Supporto motivazionale moralmente, dagli ostacoli Richiamare alla memoria i motivi che ci sono sulla strada per cui il team ha voluto 5. Ostacoli! La motivazione ci sarebbe, raggiungere quell’obbiettivo ma c’è frustrazione perché la Ridiscutere quali sono i vantaggi strada è complicata di raggiungere l’obbiettivo Il team lavora con energia al raggiungimento 6. Ci siamo quasi! dell’obbiettivo Lasciateli in pace e fateli lavorare! Sanno cosa vogliono rag- giungere e come Tabella 1 – Uno schema riassuntivo delle situazioni di dinamiche del cambiamento, con le carat- teristiche che permettono di individuarle e gli interventi suggeriti. 46 Guida galattica per agilisti Verso un quadro più completo Come si è avuto modo di dire nella prima parte di questo capitolo, la dinamica del team è molto importante; ma, nell’ottica di implementare un percorso di continuous improvement, è altrettanto importante saper contestualizzare dove si trova il team nel processo decisionale del cambiamento. A mio parere, questa capacità è fondamentale per ogni facilitatore di retrospettiva e, visto in maniera più ampia, per ogni ScrumMa- ster, così come per ogni manager che voglia supportare l’auto-organizzazione del team. Comprendere le dinamiche del gruppo e capire in quale situazione si trova nel pro- cesso che porta al cambiamento sono quindi fattori fondamentali per avere un quadro completo della situazione. Ma c’è un altro aspetto da imparare a capire: come, quando e perché una retrospettiva può fallire: ne parliamo nel prossimo capitolo. Riferimenti Ferrari E. (2011). Wege aus dem Dilemma. Ferrari Media  Capitolo 3 Come far fallire una retrospettiva tattiche di “sabotaggio” #satellite Fallimento della retrospettiva #planet ruoli #satellite Fallimento? Passiamo ora a trattare qualcosa di controintuitivo: come far fallire una retrospetti- va. Sembra strano, in effetti, che in un testo dedicato a questo valido strumento, si ana- lizzino proprio i modi per renderlo inutile. Ma il fatto è che conoscere le ragioni e i me- todi con cui far fallire una retrospettiva può aiutarci, da un lato a non mettere in atto determinati comportamenti, dall’altro a individuarli nelle dinamiche dei gruppi di lavo- ro che si affidano alla retrospettiva. Ci possono essere svariati metodi per far fallire una retrospettiva, molti dei quali hanno come “principio attivo” il fatto di bloccare o addi- rittura distruggere la dinamica con cui funziona o potrebbe funzionare il team. 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 potreb- be 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à contra- stando 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 busi- ness: 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 que- sta marmaglia in t-shirt. Quando il team discute dei suoi problemi, fategli capire, verbalmente e non, che tan- to, qualsiasi proposta di soluzione possano pensare, dovrà essere comunque passata al vostro vaglio. Capitolo 3 – Come far fallire una retrospettiva 51 Se poi il team discute di problemi di interazione con altri team o dipartimenti, ta- gliate 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, pos- sono sempre parlare di come aumentare il numero di righe di codice che ognuno di loro scrive ogni giorno: è 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 ve- nire in mente idee non conformi agli standard aziendali. O quantomeno ai vostri… Il senso di colpa In ogni caso, date a loro la colpa di ogni fallimento, così imparano a voler fare di te- sta propria. Siate energici nel farlo e accusate pure a volontà! Questa strategia ha l’effet- to collaterale che, in caso di un fallimento del progetto, potrete sempre andare dal vo- stro capo dicendo che la colpa è del team di sviluppo e che voi avete fatto tutto il possi- bile per “motivarli”. Virginia Satir, una psicoterapeuta per gruppi familiari, ha individuato quattro “cate- gorie” di comportamenti che sono alla base della maggior parte dei conflitti, e un com- portamento che può essere usato per ridurre i conflitti. Questo comportamento, consistente nel dare la colpa a qualcuno, ricade nella categoria del blamer. Figura 11 – Tipi di reazione allo stress secondo Virginia Satir: il “blamer”, colui che rinfaccia e attribuisce le colpe. 52 Guida galattica per agilisti Motivazione Visto che parliamo di motivazione: andateci giù pesanti con gli interventi motivazio- nali. Meglio calcare la mano sull’importanza del progetto per l’azienda, su come i mi- gliori verranno premiati e i peggiori puniti e cose di questo tipo. Se qualcuno vi fa nota- re che ci sono diversi studi che dimostrano il contrario, ad esempio se qualcuno tira fuo- ri la legge di Yerkes-Dodson — aumentare stress, motivazione ed eccitamento per il lavoro oltre un certo livello non fa aumentare i risultati, anzi li peggiora — fategli nota- re 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 retrospet- tiva: 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 maga- ri vorrebbero scrivere più test automatici durante lo sviluppo, cosa che voi non sapete o volete fare e che preferireste lasciare a un team di test separato. Forse la ragione più comune però è che il team sta cercando di aumentare la traspa- renza 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 cam- biamento: se state seguendo un certo processo da così tanti anni, c’è di sicuro una ra- gione 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 simi- li modifiche non hanno funzionato per tutta una serie di motivi che farete sembra- re 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 contrastare le vostre argomentazioni. Siate super-razionali! 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 distractor di ). 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 dovre- te affrontare fra parecchi mesi. Se vogliono discutere di un problema che ha danneg- giato l’ultimo sprint, fategli notare come ogni sprint ha avuto problemi di tipo diver- so e che avrebbe senso trovare una soluzione “olistica”, anche se sapete già che non sarà possibile trovarne una. Capitolo 3 – Come far fallire una retrospettiva 53 Figura 12 – Quello che nelle Satir Categories è detto il “computer” , ossia il super-razionale, che usa argomentazioni piene di dettagli, numeri, logiche causa–effetto. Figura 13 – Il “distrattore”, che svicola dal cuore della questione e porta il discorso su percor- si collaterali. 54 Guida galattica per agilisti Se poi riescono ad arrivare a votare una proposta di cambiamento e vi mettono in mi- noranza, fategli notare come queste cose non si possono decidere a maggioranza sem- plice, 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 in- finite), siete a posto. Invece di supportare il processo e dichiarare di accettare qualsiasi decisione a maggio- ranza, mettete in dubbio tutto quello che viene detto e suggerite al team che la decisio- ne che state prendendo è importante, va ponderata bene e va presa con una maggioran- za 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 falli- re 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 vo- stro, 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 tec- nici, 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. 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. Capitolo 3 – Come far fallire una retrospettiva 55 Figura 14 – Per la situazione, noi ci creiamo un modello di questo tipo… Figura 15 – …ma la realtà è molto più complessa di come la modelliamo, specialmente quando consideriamo sistemi di esseri umani! NOTA. In passato ho avuto una discussione accesa su un gruppo LinkedIn. La domanda ini- ziale era 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 molto spesso a cambiare il formato “in corsa”. Per mia esperienza diret- ta, nonostante lo sforzo per pianificare al meglio una retrospettiva, in una buona metà dei casi bisogna adattare o cambiare completamente il formato, per andare incontro alle esi- genze del team. Come facilitatore siete al servizio del team, e se il formato che avete scelto non funziona, è vostro dovere cambiarlo: siate flessibili. Molti facilitatori si mantengono neutrali (o meglio, “parziali multidiretti” ): per far fallire una retrospettiva intervenite invece con le vostre opinioni e tentate di 56 Guida galattica per agilisti forzare il vostro punto di vista. Se siete lì a facilitare è perché ne sapete più di loro, giusto? Un’altra possibilità interessante è quella di supportare apertamente o nei fatti, la po- sizione 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 disaccor- do, 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 con- flitti, o meglio, che conflitti latenti diventino espliciti. I conflitti latenti è meglio lasciarli stare come tali: il team non avrà la possibilità di funzionare al meglio, ma al- meno 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 in- flessibili. Ci sono diversi studi che dimostrano che lavorare sotto pressione del tem- po riduce la creatività delle persone. Se 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 quin- di 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, penna- relli che non scrivono più, e così via: questo farà crescere la frustrazione del team an- che 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 rende- ranno conto che è colpa vostra. Dare troppo spazio a 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 com- menti 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! Per concludere con il fallimento… Come ogni attività di persone, la retrospettiva è soggetta ai principi fondamen- tali della dinamica dei gruppi. Se ignoriamo tali principi nella nostra facilitazione, Capitolo 3 – Come far fallire una retrospettiva 57 diminuiamo la probabilità che la riflessione in team funzioni. Per questo abbiamo ana- lizzato nel capitolo precedente i gruppi e le loro dinamiche, e il modo in cui essi si rela- zionano al cambiamento. E per questo abbiamo voluto dedicare specificamente questo capitolo anche alle “tattiche” più comuni che qualcuno potrebbe mettere in atto per far fallire una retrospettiva. Con queste premesse, possiamo passare ad analizzare nei prossimi capitoli le modali- tà e i formati con cui, in pratica, svolgere le retrospettive. Riferimenti Satir Categories http://sourcesofinsight.com/satir-categories/ La legge di Yerkes-Dodson http://en.wikipedia.org/wiki/Yerkes-Dodson_law 5-Whys http://blog.connexxo.com/2009/12/the-whys-of-why-not-why.html Parzialità multidirezionale http://bit.ly/1kSzaWe Wehr P., Manifest and Latent Conflict http://www.colorado.edu/conflict/peace/example/wehr7489.htm Kelly J.R. – Karau S.J., Entrainment of Creativity in Small Groups http://sgr.sagepub.com/content/24/2/179.abstract Kelly J.R. – Futoran G.C. – Mcgrath J.E., Capacity and Capability. Seven Studies of Entrainment of Task Performance Rates http://sgr.sagepub.com/content/21/3/283.abstract  Capitolo 4 Retrospettive “solution-focused” tipi di futuro #satellite Solution-focused #planet domande sistemiche #satellite scale di valutazione #satellite Introduzione In questo e nel successivo capitolo ci occupiamo di illustrare alcuni “formati” di re- trospettiva, concentrandoci in particolare sulla cosiddetta tecnica “solution-focused” vale a dire “incentrata sulla soluzione” (Capitolo 4) e sulle retrospettive basate su me- tafore (Capitolo 5). Nel primo caso, invece di interrogarsi come di solito sulla natura dei problemi che si sono incontrati, si prova a concentrarsi su cosa cambierebbe e su come andrebbero le cose nel caso in cui le soluzioni ai problemi fossero già state trovate. Nel secondo caso si utilizzano le metafore come base per condurre retrospettive fruttuose e coinvolgenti: quello della metafora è uno strumento potente e utile, che però va usato nel modo giu- sto e nella corretta misura per non rischiare di minarne l’efficacia. Ricercare le soluzioni Negli anni Ottanta, presso un gruppo di psicologi che si occupava di terapia di fa- miglia a Milwaukee, negli Stati Uniti, si cominciò quasi per caso a usare questa manie- ra operare: invece di domandare ai propri clienti quale fosse la natura dei loro problemi, si domandava al loro che cosa sarebbe stato diverso nel caso i problemi fossero stati ri- solti. Il fatto interessante fu che le reazioni ottenute dai pazienti furono sorprendente- mente positive e quindi gli operatori cominciarono a strutturare questa tecnica e a usar- la sempre di più: era l’inizio di quello che oggi conosciamo sotto il nome di approccio “solution-focused”, vale a dire incentrato sulla soluzione. L’idea è molto semplice: fare domande sui problemi ci fa guardare indietro, al pas- sato e magari ci costringe a discutere di argomenti come gli errori commessi e l’attribu- zione della colpa. Però, per quanto si continui a ribadire ai partecipanti coinvolti che lo scopo di una retrospettiva non è l’attribuzione di colpa, guardare al passato finirà co- munque per richiamare tutti i fantasmi di ciò che è andato male e, cosa ancor più im- portante, farà ricercare l’autore di quegli sbagli: non proprio il modo di condurre una proficua discussione. E allora, perché non chiedere qualcosa a riguardo alle soluzioni? Come cambierebbero le cose in assenza del problema? Che situazione si verrebbe a cre- are? Cosa succederebbe se avessimo risolto il problema? Che cosa sarebbe differente? Un mutamento di prospettiva Ci si muove nell’ambito del cambiamento, con l’intento di superare i problemi, ma il linguaggio e l’atteggiamento che utilizziamo sono diretti a progettare un’alternativa nuo- va e migliore: lo facciamo pensando alle soluzioni piuttosto che scavando nel passato. Questo approccio può apparire contro-intuitivo: viviamo nel mondo dei “5-Whys” e degli approcci alle analisi di problemi basate sulla ricerca di una root-cause. Tutto que- sto è concentrato sull’analisi passato e sulla ricerca di miglioramenti basati su tale ana- lisi; ma non appena affrontiamo un problema che non sia esclusivamente tecnico, tipi- camente quando il problema coinvolge il comportamento di esseri umani, diventa più produttivo un approccio solution-focused. Capitolo 4 – Retrospettive “solution-focused” 61 Un esempio Prendiamo in considerazione il caso di un gruppo di persone che interagiscono fra loro in maniera disfunzionale, con cattiva comunicazione, conflitti, mancanza di moti- vazione e così via. Se si chiede a chiunque tra loro quale sia la causa di tutto questo, molto probabilmen- te avranno opinioni differenti e daranno la colpa a qualcun altro nel gruppo per lo stato delle cose. Se li si costringe a sedersi intorno a un tavolo per individuare la causa prima- ria alla base del loro comportamento, finiranno per trovare qualcosa che assomiglia più a una spiegazione “politically correct” che alla realtà effettiva dei fatti. E come si fa a sapere che ci sia solamente una causa all’origine di tutto questo? La te- oria dei sistemi ci insegna che ci sono diverse cause che interagiscono per generare un determinato effetto: come si affronta questa complessità? Mettiamo comunque che sia possibile individuare una causa iniziale. E se venisse fuori che è qualcosa del tipo “Lui mi ha trattato molto male… cinque anni fa!”, che facciamo? In che misura questo tipo di informazione può aiutarci a cambiare la situazione? Capire la ragione passata dello sta- to attuale non è necessariamente un aiuto per trovare una soluzione futura. Chiaramente non dobbiamo neanche dimenticare che c’è un effetto catartico nel discutere sul passato; ma concentrarsi su quello che dovrebbe essere differente nel fu- turo è decisamente meglio: le persone escono maggiormente motivate dal discutere un futuro migliore piuttosto che un presente e un passato negativi. Oltretutto, i ri- sultati della discussione possono essere immediatamente usati e sono già un piano di azione concreto. L’approccio solution-focused Specialmente se usato in maniera iterativa, per consentire una comprensione sempre più dettagliata di cosa significhi “un futuro migliore”, l’approccio incentrato sulla solu- zione può risultare molto più produttivo di quelli basati sull’analisi. Il “trucco” nella tecnica solution-focused sta nel mantenere il gruppo di lavoro in uno “stato di soluzione”: “Immaginate che il problema sia risolto… Che cosa c’è di dif- ferente?”. Nella mia esperienza mi sono reso conto che questo può diventare un compito di enorme portata per molte persone che appartengano all’ambito IT