Con questo numero cominciamo una serie sulle retrospettive, potente strumento delle pratiche agili, troppo spesso sottovalutata, trascurata o, peggio, mal compresa nelle sue potenzialità e nei suoi molteplici aspetti. Nel corso dei vari articoli, sviscereremo questo tema con l’aiuto di un vero esperto, presentando casi provenienti dal mondo reale. si approcci.
Introduzione
Parliamo un po’ di retrospettive: voi le fate? Se sì, funzionano? E come capite se funzionano? Le retrospettive sono uno degli strumenti dell’agilità più importanti, ma meno capiti: in questa serie di articoli analizzeremo in dettaglio cosa sono le retrospettive e come si possano utilizzare in maniera proficua in un’organizzazione agile.
Nei primi articoli vedremo quali sono gli elementi strutturali di una retrospettiva, poi continueremo con dei metodi molto efficaci, anche se purtroppo ancora poco conosciuti, da utilizzare nelle retrospettive, per finire con una serie di consigli su come moderare una retrospettiva, consigli che sono utili, in realtà, per moderare qualsiasi tipo di meeting.
Retrospettive e Continuous Improvement
Il primo tema che affrontiamo è la relazione fra retrospettive e continuous improvement: 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” [5]. Il libro propone la necessità di effettuare riflessioni regolari sull’andamento del progetto, in modo da correggerne il funzionamento prima che sia finito. Questo in contrasto con le Post-Mortem Reviews effettuate nei progetti tradizionali: anche quando vengono fatte, di solito molto raramente, danno informazioni che possono essere utilizzate solo in progetti seguenti e non aiutano a raggiungere il successo nei progetti in corso.
Il concetto di retrospettiva diviene subito parte dell’agilità: il principio 12 del manifesto agile è totalmente dedicato alla riflessione in team.
“Ad intervalli regolari il team riflette su come diventare più efficace, dopodiche’ regola e adatta il proprio comportamento di conseguenza.”
Nonostante il principio 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 valori fondamentali, integrato in maniera pervasiva nelle varie pratiche, non viene utilizzato in maniera esplicita per il miglioramento del processo. Inoltre il feedback in XP viene descritto più da un punto di vista di prodotto che di processo: feedback sulla qualità 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 risultato del feedback sul prodotto che per riflessione diretta. Questo per quanto menzionato 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 è un concetto simile, ma molto più anziano: il termine è stato coniato da Walter Shewhart [3], il padre del controllo di qualità statistico, e popolarizzato da Edward Deming [4], statistico americano, famoso per la sua filosofia di management basata su “14 punti“, uno dei quali è centrato 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 “importate” in Giappone dalla Toyota e contribuiscono a trasformare quella che era una piccola casa automobilistica di portata nazionale nel gigante che conosciamo oggi. Il lavoro fatto da Toyota in questo campo viene adesso “reimportato” nel mondo occidentale con il nome di Lean.
Shewhart sviluppa per primo il concetto di un ciclo di miglioramento continuo basato 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 iterazione funzioni meglio.
L’obbiettivo è di capire e dare significato alla realtà attorno a noi: Grasp.
Figura 1 – Il ciclo di Stewhart.
Il ciclo di Shewhart viene adottato da Deming e da lui pubblicizzato, tanto che è ormai noto come il ciclo di Deming.
In cosa differiscono i due concetti di retrospettiva e continuous improvement? La differenza è in realtà più culturale, con il termine retrospettiva utilizzato nell’agilità e continuous improvement in Lean e nel Total Quality Management. Di certo, a 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’obbiettivo 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 miglioramenti non sono sincronizzati con le retrospettive (o come vengono chiamate le azioni per migliorare il processo). Ci aspetteremmo una situazione del tipo rappresentato in figura 2, dove ogni “gradino” di miglioramento corrisponde ad una retrospettiva.
Figura 2 – Un miglioramento graduale e costante, a “gradini” è quello che ci aspettiamo, ma è poco realistico.
Ed invece troviamo qualcosa di simile a quanto rappresentato in figura 3, dove i miglioramenti non sembrano legati a eventi particolari.
Figura 3 – Una rappresentazione schematica dei miglioramenti in relazione alle retrospettive: questo andamento è più realistico e riflette maggiormente i casi con cui possiamo confrontarci nella realtà.
Cosa succede? Semplicemente accade che le retrospettive sono un modo per riflettere 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 Deming o, con un termine più moderno, il sensemaking [6], ossia il processo con cui si riesce ad attribuire un significato alle esperienze fatte. Le nuove conoscenze generate durante una retrospettiva, che possono essere esplicitamente documentate, o esperienze implicite 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’effettività del team potrebbe 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, confinarla al 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 dello sprint
Come abbiamo visto, questo è il modo in cui Scrum propone di usare una retrospettiva. Di fatto implementa bene il concetto del manifesto agile: “a intervalli regolari…”. Dal mio punto di vista questo è un buon punto di partenza, ma certamente 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 lo sprint
Nel mio lavoro di coach spesso interrompo un meeting o, più in generale, un’attività di team, perche’ 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 decisione di team che, a mio parere, non considera tutti gli aspetti necessari e quindi potrebbe 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 questo preciso istante e in questa situazione specifica. Nella mia esperienza queste riflessioni sono estremamente utili perche’ 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 situazioni 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-funzionale, 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 un 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 ed 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’interno 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 utile della realtà, ma non necessariamente la più utile in tutti i contesti: talvolta vale la pena di far partecipare 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 ed il suo management;
- comunicazione/collaborazione tra il team e il marketing;
- comunicazione/collaborazione tra il team e le persone di assistenza clienti;
- comunicazione/collaborazione tra il team e product management;
- discussione su degli 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 inter-team più orientata al processo che al progetto. Sto dando per scontato che una comunicazione 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’organizzazione che impara e ne fa crescere il livello di maturità. Per questo, delle retrospettive regolari 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 valore è, di solito, chiaramente e immediatamente visibile.
Qual’è l’output di una retrospettiva?
Nella modo usuale di vedere le retrospettive da parte degli agilisti, la retrospettiva finisce con una serie di azioni di miglioramento concrete, da applicare durante l’iterazione successiva. Nonostante questo sia un nobile obbiettivo, non è ne’ l’unico, ne’ necessario.
Non è l’unico in quanto, come abbiamo visto in precedenza, per me l’obbiettivo primario di una retrospettiva è il sensemaking dell’esperienza fatta. Peter Drucker [7] diceva, riferendosi alla leadership, che il loro compito è di creare un’allineamento di forze. Peter Senge, nel suo “The Fifth Discipline” [2], chiarisce come una visione condivisa sia alla base del successo di un’azienda. Creare questo allineamento, questa visione condivisa, è da sempre un’operazione titanica, ancora più complessa in un sistema di team agili e auto-organizzati: la retrospettiva è un metodo per creare, in maniera emergente, un tale allineamento. Da questo punto di vista la retrospettiva è molto più utile dei vari action items che genera!
L’ottenere azioni concrete di miglioramento non è neppure necessario: molto spesso ho visto Scrum Master “torturare” il team nel tentare di raggiungere un risultato concreto, in cui l’unico vero risultato è l’aver alienato i partecipanti.
L’aver cambiato il modello mentale delle persone tramite la riflessione è già un risultato estremamente importante ed estremamente utile. Chris Argyris [1] ha coniato 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
Come sono le vostre retrospettive? Quante delle possibili variazioni menzionate in questo articolo state già usando e quali potreste ancora usare?
Le retrospettive sono uno strumento importante a vostra disposizione, e il fatto di applicarle “ad ampio spettro” all’interno di un’organizzazione è una tattica importante nell’agilizzazione di un’azienda in quanto la fa comunicare e maturare a tutti i livelli.
Per questo vi invito a provare a fare delle retrospettive diverse, coinvolgendo colleghi che finora non ne sono stati esposti: vedrete che i risultati non mancheranno!
Nel prossimo articolo…
…andremo a riassumere la letteratura corrente sulle retrospettive, andando a vedere il processo più conosciuto e le possibili variazioni.
Riferimenti bibliografici
[1] Argyris C. – Schon D. (1978). “Organizational Learning: A theory of action perspective”. Reading MA: Addison-Wesley
[2] Senge P.M. (1990). “The Fifth Discipline”, Doubleday/Currency
[3] Shewhart W.A. (1980). “Economic Control of Quality of Manufactured Product. 50th Anniversary Commemorative Issue”, American Society for Quality
[4] Deming W.E. (1986). “Out of the Crisis”, MIT Center for Advanced Engineering Study
[5] Kerth N.L. (2001). “Project Retrospectives: A Handbook for Team Reviews”, Dorset House
[6] La voce “sensemaking” su Wikipedia
http://en.wikipedia.org/wiki/Sensemaking
[7] La voce Peter Drucker su Wikipedia
http://en.wikipedia.org/wiki/Peter_Drucker
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, ci sono le metodologie agili, Scrum, la gestione di progetto e il coaching su progetti per singoli professionisti o gruppi di lavoro, lo sviluppo del software. Pratica un approccio all‘Agile Coaching orientato alle soluzioni.