shelidonJanuary 12, 20221 Comment on #BIMtool – TeamRetro (1)

Ricordate i concetti di retrospettiva e health check? Al secondo ho dedicato l’ultima delle #BIMpill dell’anno scorso, ma li abbiamo già incontrati entrambi come compiti di un facilitatore.

Come sempre, non si tratta di attività per le quali dobbiamo necessariamente impazzire a costruire strumenti di registrazione, controllo e analisi (che di solito finiscono a essere in Excel oppure, ultimamente perché va di moda, in PowerBi): esistono piattaforme costruite appositamente per lo scopo di condurre, gestire e collezionare sia le retrospettive che gli health check. Una di queste è TeamRetro.com, di cui parliamo oggi.

È gratis?

No.
Ma potete attivare per 30 giorni una trial completa semplicemente registrandovi con il vostro indirizzo e-mail.

La piattaforma ha un funzionamento semplice: una volta effettuato l’accesso, vi troverete nel vostro hub aziendale, al di sotto del quale potrete creare i diversi team, al quale invitare gli utenti. Per ogni team sarà possibile portare avanti le due attività principali:

• la retrospettiva, intesa come analisi collettiva del team di problematiche esposte in maniera spontanea dai membri;
• l’health check, intesa come esposizione intima del proprio pensiero in relazione alle dinamiche e alle metodologie del gruppo.

1. La Retrospettiva: i Template

Per creare una retrospettiva sulla piattaforma, dopo aver impostato il team, è possibile creare un proprio template personalizzato oppure seguire uno di quelli offerti, che sono svariati.
Se vi state approcciando all’evento per la prima volta, consiglio chiaramente di seguire uno dei template, ma prima di farlo è necessario capire quali sono le implicazioni del modello scelto e quale direzione state implicitamente imprimendo alla conversazione scegliendo un framework piuttosto che un altro.

1.1. What? So What? Now What?

Il framework invita il team a domandarsi:

1. Cosa è successo (di cui vogliamo parlare)?
2. Quali sono state le conseguenze di ciò che è successo?
3. Cosa vogliamo fare adesso?

Si tratta di un ottimo framework per team che tendono a ingigantire i problemi, da una parte, perché invita ad analizzare le reali conseguenze dell’accaduto, mentre dall’altra spinge a proporre azioni concrete di risoluzione.
Insomma, un buon framework per team di lamentini cui piace piangersi addosso.

1.2. Start, Stop, Continue

Di fronte ad un set di attività che vengono portate avanti con metodologie condivise e chiare a tutti, questo metodo invita il team a proporre al facilitatore:

1. Cosa vorremmo iniziare a fare;
2. Cosa vorremmo smettere di fare;
3. Cosa vorremmo continuare a fare.

Attenzione perché questo modello di retrospettiva ha senso solo se le attività sul tavolo sono negoziabili. Non è possibile ad esempio rirtrovarsi con un team che vorrebbe smettere di portare avanti l’analisi delle interferenze se questa attività è richiesta contrattualmente.

Del metodo esiste anche un framework più semplice, con i soli Start e Stop.

Ne esiste anche una versione decisamente più raffinata che richiede di introdurre sfumature tra ciò che si vuole iniziare a fare e ciò che si vuole incrementare, ciò che si vuole abbandonare e ciò che si vuole ridurre.

1.3. Rose, Bud, Thorn

Non avevo mai sentito parlare di questo framework, ma a sentimento direi che l’intenzione è quella di individuare quali sono gli aspetti positivi del lavoro, quali sono gli aspetti che potrebbero essere positivi e che sono da coltivare ulteriormente e quali invece sono gli aspetti problematici, spinosi.
Lo consiglierei per situazioni altamente in divenire, in cui il team è parte in causa nello sviluppo del metodo.

1.4. Anchors, Engines

Adatto per situazioni in cui è facile trovarsi in stallo, il framework richiede al team di analizzare quali sono gli elementi che ci rendono veloci e quali invece ci frenano. Lo trovate meglio spiegato qui.

1.5. Mad, Sad, Glad

Avete un team tutto fatto di cappelli rossi (vedere la teoria del cappelli pensanti, per chi non se la ricorda)? Questo framework si concentra sull’aspetto emotivo del lavoro e chiede ai membri di identificare cosa li abbia fatti arrabbiare, cosa li abbia rattristati e cosa invece li abbia resi felici nelle dinamiche produttive dello sprint appena concluso.

1.6. Courage, Focus, Openness, Respect, Commitment

I più attenti tra di voi riconosceranno in questa retrospettiva i valori dello Scrum: coraggio, concentrazione, apertura, rispetto e dedizione.
Si tratta di un ottimo framework per i progetti pilota con i quali state introducendo il metodo perché si concentra, più che sul risultato contenutistico del progetto, sull’atteggiamento con cui i membri del team lo stanno approcciando. Ricordate che, come ogni progetto pilota, anche un progetto pilota per l’introduzione dello Scrum deve essere un progetto semplice e relativamente contenuto, che non presenta particolari sfide contenutistiche.

1.7. Drop, Add, Keep, Improve

Si tratta, a mio vedere, di una versione più raffinata del metodo Start, Stop, Continue, che trovo eccessivamente semplicistico oltre che rischioso per motivi che ho già parzialmente espresso.
In questo framework si richiede invece al team di proporre, dal punto di vista metodologico e del set di attività, quali sono i processi che vorrebbero abbandonare, quali sono i processi che vorrebbero aggiungere, quali vorrebbero mantenere e quali invece, di quelli in essere, sarebbe necessario migliorare.
Con una buona facilitazione, è possibile virare processi inevitabili, che il team vorrebbe abbandonare, in processi da migliorare.

1.8. Keep, Add, Less, More

Simile al precedente, ma ulteriormente emendato di elementi potenzialmente problematici, richiede al team di riflettere non solo su quali processo vorrebbe mantenere e quali vorrebbe aggiungere, senza lasciare la possibilità di eliminarne, ma anche su quali vorrebbe ridurre e quali invece vorrebbe potenziare.

1.9. Must, Should, Could, Won’t

Si tratta di una retrospettiva basata sul cosiddetto medoto MoSCoW, un metodo di analisi e prioritizzazione che mi è già capitato di consigliare nella definizione degli usi del modello. Il metodo suddivide gli argomenti, le attività o le caratteristiche del prodotto in quattro categorie:

• Must have, ovvero i requisiti che per forza devono essere inclusi all’interno del prodotto, i processi di cui non possiamo fare a meno, le richieste che dobbiamo necessariamente evadere, gli strumenti di cui abbiamo per forza bisogno;
• Should have, ovvero quei requisiti fondamentali che dovrebbero essere inclusi all’interno del prodotto ma che per cause di forza maggiore potrebbe anche essere risolto altrimenti, i desiderata dal punto di vista dei processi e che sappiamo essere problematici se esclusi, gli strumenti senza i quali le difficoltà sul lavoro diventano oggettive;
• Could have, ovvero le desiderata vere e proprie in assenza delle quali le conseguenze sono minori: si tratta di requisiti che il prodotto potrebbe avere e che saranno inclusi se consentito dal tempo e dalle risorse a disposizione, ma la cui assenza non pregiudica l’efficacia del prodotto;
• Won’t have: ciò che categoricamente è necessario abbandonare o che si desidera evitare a tutti i costi venga considerato un’opzione.

1.10. Liked, Learned, Lacked, Longed For

Un ottimo framework per i team che stanno affrontando un progetto pilota con l’obiettivo di imparare nuovi metodi e nuove tecniche oppure per team in cui il miglioramento continuo è uno dei motori principali, richiede al team di indicare ciò che è piaciuto, ciò che abbiamo imparato, ciò che è mancato e ciò che avevamo tanto desiderato e finalmente si è verificato, è stato implementato oppure ci è stato consentito. Si concentra sul concetto di team come entità dinamica in costante evoluzione e in costante crescita.

1.11. What went well? What went less well? What do we want to try next? What puzzles us?

Framework per team che operano in ambiente altamente empirico, invita i membri a concentrarsi sul risultato dei loro esperimenti metodologici:

• Cosa è andato bene?
• Cosa è andato meno bene?
  (nota: non amo gli eufemismi e i perbenismi, durante le retrospettive, perché il metodo funziona in condizioni di apertura e onestà reciproca: quando è necessario mettere di fronte il team a cosa è andato male, è vostro dovere farlo)
• Cosa vogliamo provare a fare la prossima volta?
• Cosa ci lascia perplessi?

1.12. Wishes, Risks, Appreciations, Puzzles

Simile al precedente, si posiziona in uno scenario in cui il team è meno artefice del proprio destino e quindi domanda, oltre all’analisi del rischio, quali sono i desideri del team, le sue perplessità e ciò nei confronti del quale vogliono mostrare apprezzamento. Si tratta di un framework per facilitatori che gestiscono troppi progetti, perché fornisce in modo già chiaro e strutturato una serie di azioni che il facilitatore deve intraprendere in termini di mitigazione del rischio e implementazione di nuove funzionalità.

1.13. Future Considerations, Lessons Learned, Accomplishments, Problem Areas

Si tratta di un framework che è adatto solo a team maturi, che hanno dimestichezza con i principi del project management, ed è particolarmente adatto a retrospettive di chiusura. Il suo respiro potrebbe essere considerato eccessivo per milestone minori di progetti piccoli.
Suo obiettivo è collezionare:

• considerazioni per fasi future del progetto o per progetti futuri;
• le lesson learned, ovvero ciò che abbiamo imparato durante questo progetto e che consideriamo utile registrare per progetti futuri;
• i successi conseguiti dal progetto o dalla fase di progetto;
• le aree problematiche.

2. La Retrospettiva: Fasi e Funzionamento

Una volta scelto il template per la retrospettiva, è richiesto e possibile fare un altro paio di aggiustamenti.

In particolare, oltre al nome e alla deadline, è possibile impostare il livello di anonimato che si vuole garantire a chi partecipa alla retrospettiva. L’utilizzo degli alias mantiene l’anonimato ma consente di confrontare tra loro le risposte date dalla stessa persona (senza sapere di chi si tratta) mentre la versione anonima protegge anche da questo confronto. Tenete presente che potrebbe essere necessario proteggere i partecipanti garantendo loro l’anonimato, ma generalmente è indice di una cultura aziendale tossica, in cui difficilmente Agile e Scrum possono funzionare (ne ho parlato quando ho proposto le tre categorie di cultura aziendale secondo DevOps).

Tra le opzioni è poi possibile decidere se si vuole richiedere un’analisi di ritorno sul tempo investito oppure se si vuole consentire ai partecipanti di aggiungere reazioni alle proposte dei compagni.

Le fasi proposte per la retrospettiva in questa piattaforma sono sei:

1. Brainstorm, durante la quale ciascun membro del team inserisce voci all’interno delle categorie proposte dal facilitatore durante la scelta del template;
2. Group, in cui gli argomenti simili possono essere raggruppati e membri del team possono proporre raggruppamenti al facilitatore;
3. Vote, in cui vengono identificati i punti di vista che il team condivide (di base vengono consentiti cinque voti per ogni membro del team, incluso il facilitatore se lo si desidera);
4. Discuss, destinato all’approfondimento degli argomenti che il team ha trovato maggiormente condivisibili;
5. Review, in cui si identificano e valutano le azioni concrete proposte dal team a valle della discussione e si genera un vero e proprio piano d’azione;
6. Share, in cui è possibile generare un report.

Le azioni individuate durante la retrospettiva vengono memorizzate dalla piattaforma e proposte in home page per il monitoraggio continuo da parte del team e del suo facilitatore.

Il prossimo mercoledì vedremo la parte della piattaforma destinata all’health check.