#BIMtool – TeamRetro (2)

Lo scorso mercoledì abbiamo visto alcune funzionalità della piattaforma TeamRetro.com, in particolare quelle relative alle retrospettive. Chiudiamo la panoramica della piattaforma vedendo come funziona la parte relativa all’health check, cui avevo dedicato l’ultima #BIMpill dell’anno scorso. Ma quelli di TeamRetro ti pagano? No. Ma la piattaforma è gratuita? No, ma potete attivate una trial di […]

Lo scorso mercoledì abbiamo visto alcune funzionalità della piattaforma TeamRetro.com, in particolare quelle relative alle retrospettive. Chiudiamo la panoramica della piattaforma vedendo come funziona la parte relativa all’health check, cui avevo dedicato l’ultima #BIMpill dell’anno scorso.

Ma quelli di TeamRetro ti pagano?

No.

Ma la piattaforma è gratuita?

No, ma potete attivate una trial di 30 giorni registrandovi con il vostro indirizzo e-mail.


1. Health Check: i Template

Come per le retrospettive, la prima cosa da fare nella creazione di un health check è la scelta del template. E, come per la retrospettiva, le molte opzioni a disposizione ci consentono di fare un ragionamento circa la scelta degli indicatori e gli obiettivi impliciti che il facilitatore si pone nella scelta di uno specifico set di indicatori.
Anche in questo caso è possibile creare health check con indicatori personalizzati, ma iniziamo vedendo quelli offerti dalla piattaforma.

1.1. Team Health Check

Ownership, Value, Goal Alignment, Communication, Team Roles, Velocity, Support and Resources, Process, Fun

Come già avevo mostrato parlando dell’health check in generale, alla fine dell’anno scorso, la verifica di salute può essere fatta in relazione alll’allineamento con specifici indicatori di progetto che in questo caso vengono circoscritti a:

  • i membri del team hanno senso di ownership, ovvero percepiscono come proprio ciò che stanno producendo?
  • viene percepito il valore di ciò che si sta facendo?
  • siamo allineati rispetto agli obiettivi di progetto (es: gli usi del modello)?
  • gli strumenti e i modi di comunicazione vengono considerati adeguati alle necessità?
  • i ruoli all’interno del team sono sufficientemente chiari? Sono adeguati alle necessità?
  • il passo tenuto dalla produzione in termini di velocità è adeguato? Troppo rapido? Troppo lento?
  • vi è sufficiente supporto in caso di necessità? Come si valutano le risorse a disposizione?
  • qual è la posizione del singolo rispetto al processo utilizzato?
  • lavorare a questo progetto / con questo metodo / all’interno di questo team è un piacere?

Scegliendo il template “radar”, questi stessi indicatori sono sovrapposti health check dopo health check, consentendo al facilitatore di vedere il miglioramento (o il peggioramento) degli indicatori nel tempo.

1.2. Squad Health Check

Delivering Value, Easy to Release, Fun, Health of Codebase, Learning, Mission, Pawns or Players, Speed, Suitable Process, Support, Teamwork

Rispetto al precedente, l’approccio di questo template è maggiormente concentrato sul prodotto e i suoi indicatori sono relativi a:

  • la percezione di stare generando e consegnando pacchetti di valore al cliente;
  • la loro facilità di rilascio;
  • il divertimento, come nel precedente caso, perché non è possibile lavorare in Agile con gente che ritiene il lavoro debba essere solo dolore e sofferenza;
  • la salute del codice sorgente, che nel nostro caso potrebbe essere definita l’integrità della struttura dati del modello;
  • l’apprendimento continuo del team;
  • l’allineamento del progetto rispetto alla missione aziendale;
  • il senso di autonomia e autodeterminazione dei membri del team: si sentono pedine oppure sentono di poter incidere significativamente sulla definizione dei processi?
  • il passo di produzione, come nel caso precedente;
  • un feedback relativo al processo: è adatto a ciò che stiamo facendo oppure no?
  • il livello di supporto a disposizione, come nel caso precedente;
  • la qualità del lavoro di gruppo.

1.3. Remote Team Happiness

Role Clarity, Autonomy, Impact, Engagement, Support, Connectedness, Psychological Safety, Personal Well-Being

Particolarmente rilevante in questo periodo complicato, si concentra sui punti che possono risultare maggiormente problematici nell’improvvisa o graduale virtualizzazione dei team di lavoro, ovvero:

  • i ruoli sono sufficientemente chiari?
  • c’è il giusto livello di autonomia?
  • i membri si sentono di poter avere il giusto impatto sul lavoro del progetto o si sentono a margine, irrilevanti?
  • qual è il loro livello di coinvolgimento?
  • com’è il supporto a loro fornito, come nei casi precedenti?
  • qual è il livello di connessione che percepiscono con gli altri membri del team e con gli stakeholder di progetto?
  • si sentono psicologicamente sicuri?
  • qual è il loro livello di salute e benessere personale?

Si tratta probabilmente del mio framework preferito e in particolare risulta cruciale il concetto di sicurezza psicologica, che peraltro è alla base dei nuovi framework LEGO® SERIOUS PLAY® per la gestione del cambiamento di cui ho parlato mentre ero alla conferenza in Danimarca lo scorso autunno.

1.4. Scrum Ceremonies

Backlog Grooming, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective

Impostato per poter generare un radar comparativo e storicizzato nel tempo come il precedente, questo framework è impostato strettamente sulle attività dello scrum e in particolare sull’efficacia percepita degli eventi (chiamati anche, come in questo caso, cerimonie). Gli indicatori diventano quindi:

  • Backlog Grooming (espressione non felicissima) ovvero quanto sono efficaci le attività di revisione, pulizia e affinamento del backlog;
  • Sprint Planning, ovvero le sessioni di pianificazione dello sprint;
  • Daily Scrum, la stand-up giornaliera in cui si pianificano le attività della giornata e si identificano gli ostacoli di cui lo Scrum Master si dovrà occupare;
  • Sprint Review, ovvero le revisioni del prodotto al termine dello Sprint;
  • Sprint Retrospective, ovvero le revisioni sul metodo e sui processi.

Si tratta di un health check spersonalizzato, che mira a verificare l’efficacia percepita del metodo, attività che a mio parere sarebbe più appropriata in una retrospettiva.

1.5. Scrum Values Radar

Commitment, Focus, Openness, Respect, Courage

Gli indicatori proposti sono i valori tradizionali dello Scrum, già visti nella retrospettiva. Anche l’efficacia di questo metodo è dubbia: quanti membri del team pensiate possano ammettere di non essere stati sufficientemente aperti o rispettosi? Più probabile quindi che si trasformi, anziché nell’analisi intima sul singolo, in una distruttiva sessione di j’accuse. Eviterei.


2. Health Check: passaggi e funzionamento

Una volta scelto il template e gestite le ultime impostazioni, che sono analoghe a quelle della retrospettiva, i passaggi proposti sono quattro:

  1. Survey, durante il quale i membri del team espongono la propria posizione circa l’indicatore mettendo dei numeri o degli smiley a seconda del template scelto;
  2. Discuss, in cui è possibile visionare i risultati, ad esempio, sul grafico radar proposto;
  3. Review, in cui viene sviluppato il piano d’azione;
  4. Share, in cui è possibile pubblicare il risultato.
Il grafico radar proposto allo step 2 (se si è scelto il template corrispondente)

È importante sottolineare che, per quanto mi riguarda, l’health check deve essere un momento intimo e riservato in cui i singoli membri del team, uno alla volta, si confidano con lo Scrum Master e anche eventuali azioni dovrebbero scaturire da una conversazione individuale in un ambiente sicuro. Per questo, la piattaforma potrebbe risultare in usi inappropriati e invito alla cautela.

Da TeamRetro.com è tutto, trovate ulteriore materiale nella loro knowledge base.

Quale strumento vorreste veder discusso il prossimo mercoledì?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.