Cos'è lo "Squad Health Check Model" di Spotify?
Molte aziende sperimentano le più svariate possibilità per valutare e visualizzare a che punto si trovano i loro team. Normalmente ciò avviene con l’aiuto dei cosiddetti Maturity Model, ovvero modelli di maturità, che rappresentano l’evoluzione attraverso diversi livelli.
Le intenzioni dietro questi modelli sono generalmente positive – ad esempio quando manager, responsabili della leadership o coach in organizzazioni più grandi vogliono avere una migliore percezione di dove dovrebbe essere il loro focus in termini di miglioramenti e problemi, o quando vogliono aiutare i loro team a essere più riflessivi per concentrarsi meglio sui propri miglioramenti.
Prefereriamo tuttavia chiamarlo “Health Check Model” (modello di controllo della salute) piuttosto che “Maturity Model”, poiché quest’ultimo... beh... suona un po’ paternalistico. Inoltre, la maggior parte dei nostri modelli non comprende l’evoluzione attraverso diversi livelli. Il pubblico principale è inoltre il team stesso e non il management.
Migliorare l’organizzazione assomiglia spesso a un gioco di indovinelli (come si fa a sapere cosa deve essere migliorato? E come si fa a sapere se qualcosa è migliorato?). Un approccio sistemico con una visualizzazione chiara può ridurre al minimo questo gioco di indovinelli.
Ok, ma questi modelli funzionano davvero?
Dipende. In alcuni casi questi modelli possono essere davvero utili. A volte è più un “meh” – le persone adempiono ai loro obblighi e partecipano a workshop, sondaggi ecc., ma i dati risultanti vengono ignorati.
Ma fate attenzione. Abbiamo visto come tali modelli siano diventati dei veri e propri mostri in alcune aziende; uno strumento sistemico di oppressione che genera subottimizzazione e paura. I manager usano il modello di maturità per valutare i team e metterli gli uni contro gli altri, e i team nascondono i loro problemi per fare bella figura. E questo non va assolutamente bene!
Sebbene il danno potenziale sia più probabile del potenziale vantaggio, un potenziale vantaggio ESISTE e ci sono modi per evitare un disastro.
In Spotify ho sperimentato per alcuni anni e ho trovato modi che funzionano abbastanza bene (quindi più vantaggi che svantaggi) – nel migliore dei casi sono “utili”, nel peggiore “meh” e finora non sono mai stati un “disastro”. Abbiamo introdotto questo Health Check Model anche in alcune altre aziende con risultati simili, quindi ho pensato che fosse il momento di scrivere un articolo al riguardo.
A chi è destinato l’Health Check Model?
Nell’Health Check Model di uno Squad (il nostro termine per un piccolo team di sviluppo interdisciplinare e auto-organizzato) ci sono principalmente due stakeholder:
1) Lo Squad stesso
Discutendo i singoli indicatori, i membri dello Squad possono comprendere meglio cosa funziona e cosa no. L’ampia gamma di domande li aiuta ad allargare i propri orizzonti. Magari sono consapevoli dei problemi di qualità del codice, ma non hanno davvero riflettuto sul valore dal punto di vista del cliente o sulla velocità con cui possono imparare. Inoltre, vengono evidenziati sia gli aspetti positivi che quelli negativi.
2) Persone che supportano lo Squad.
Manager e coach che lavorano al di fuori del team (o almeno in parte al di fuori del team) ottengono una panoramica di tutte le cose che funzionano e che non funzionano. Inoltre possono riconoscere pattern tra diversi Squad. Quando si hanno dozzine di team e non si può parlare con ognuno di tutto, un tale riepilogo può aiutare a capire come utilizzare al meglio il proprio tempo e con chi parlare di cosa.
Essere consapevoli del problema è il primo passo per risolverlo. Questo tipo di visualizzazione rende molto più difficile ignorare un problema.
Come lo facciamo in Spotify
Principalmente facciamo tre cose:
Conduciamo workshop in cui i membri di uno Squad discutono e valutano la loro situazione attuale in base a diversi aspetti (ad es. qualità, divertimento, valore ecc.)
Creiamo un riepilogo grafico del risultato
Aiutiamo gli Squad a migliorare
Abbiamo diverse varianti. Una la chiamiamo semplicemente “Squad Health Check Model”, altre si chiamano ad esempio “Fluent@Agile Game” o “Quarterly Reflection”. L’“Health Check Model” è una versione migliorata dell’indagine trimestrale “Autonomous Squads” menzionata nel 2012 nell’articolo Scaling Agile @ Spotify.
Ecco un esempio reale dell’Health Check Model di un “Tribe”:
Qui è rappresentato come 7 diversi Squad valutano la propria situazione. I colori mostrano lo stato attuale (verde=bene, giallo=alcuni problemi, rosso=molto male). Le frecce indicano il trend (sta migliorando o peggiorando?).
Se osservate il diagramma attentamente per qualche minuto, noterete alcune cose interessanti:
Nelle colonne potete riconoscere le principali differenze tra i vari Squad. Lo Squad 4 è soddisfatto di praticamente tutto. Lo Squad 2 ha molti problemi, ma c’è un trend positivo in quasi tutti i punti.
Nelle righe potete riconoscere pattern sistemici. Ogni Squad si diverte al lavoro (e il trend sale ancora!). La motivazione non sembra essere un problema. Tuttavia, il processo di rilascio è problematico e anche la codebase non ha un bell’aspetto. Col tempo questo influenzerà sicuramente anche il fattore divertimento al lavoro.
Nel quadro complessivo si può vedere che quasi tutte le frecce puntano verso l’alto, nell’intero diagramma ci sono solo 2 frecce verso il basso. Questo significa che il processo di miglioramento (il processo più importante in assoluto) sembra funzionare.
Questa è naturalmente solo un’approssimazione della realtà (“Tutti i modelli sono sbagliati, ma alcuni sono utili.” – George Box). Pertanto è una buona idea verificare tutto prima di intraprendere azioni concrete.
Va davvero tutto così bene nello Squad 4 o sono solo ottimisti e non vedono i loro problemi? La maggior parte degli Squad pensa di fornire valore ai propri clienti – ma come lo sanno? Questa affermazione si basa su un desiderio o su un reale feedback dei clienti?
Lo Squad 4 del nostro esempio era stato effettivamente formato solo una settimana prima dell’Health Check. Erano quindi definitivamente ancora nella fase di orientamento (chiamata anche fase di Forming o fase luna di miele). Per questo motivo sia lo Squad 2 che lo Squad 4 necessitavano di molto supporto.
La facilità di rilascio era un grosso problema. Quindi ci si è concentrati maggiormente su cose come il Continuous Delivery (consegna continua) e presto si è potuto notare un netto miglioramento.
Ricordate che questo è un modello di autovalutazione basato sull’onestà e sull’opinione soggettiva dei membri dello Squad. Funziona quindi solo in un ambiente di fiducia, dove le persone possono essere sicure che i loro manager e colleghi agiscono nel loro interesse. Raccogliere i dati è abbastanza semplice – si tratta quindi principalmente di non avere motivi concreti per non farlo.
Fortunatamente in Spotify esiste questo ambiente di fiducia e i manager e i coach sono molto attenti a comunicare che questo è uno strumento di supporto e non di valutazione degli Squad.
Come raccogliamo i dati
Abbiamo scoperto che i sondaggi online per questi scopi sono pessimi. Principalmente perché non permettono la conversazione, e questa è la parte più preziosa. Mentre i membri dello Squad parlano tra loro, si ottengono ulteriori intuizioni, e il coach scopre come aiutare efficacemente gli Squad. I dati da soli mostrano solo una piccola parte del quadro complessivo, il che può essere fuorviante.
Quindi noi (di solito agile coach) organizziamo workshop con gli Squad e stimoliamo una conversazione diretta sui diversi indicatori dell’“Health Check Model”. Una o due ore di solito sono sufficienti.
Per la facilitazione utilizziamo un set delle cosiddette “Awesome Cards”. Ogni carta rappresenta uno degli indicatori e include sia un “Example of Awesome” (esempio di qualcosa di fantastico) sia un “Example of Crappy” (esempio di qualcosa che va male).
Il set è normalmente composto da circa 10 carte. Ecco l’esempio di un set completo:
Per ogni domanda, agli Squad viene chiesto se si vedono più vicini ad “Awesome” o a “Crappy”. Per facilitare l’accordo su un colore per gli indicatori e il rispettivo trend (stabile, tendenza al rialzo/al ribasso), utilizziamo metodi di workshop molto basilari come il Dot Voting.
Qui trovate le carte in download PDF
Manteniamo le cose semplici con tre livelli (verde/giallo/rosso). La definizione esatta della codifica colore può variare, ma si basa sulle seguenti affermazioni:
Verde non significa necessariamente che tutto sia perfetto. Significa solo che lo Squad è soddisfatto e al momento non vede un grande bisogno di miglioramenti.
Giallo significa che ci sono alcuni problemi che dovrebbero essere risolti ma non sono un disastro.
Rosso significa che qualcosa va davvero storto e deve essere migliorato.
Sì, questi sono dati soggettivi. In teoria ogni Squad è libero di includere anche dati oggettivi (tempo di ciclo, numero di difetti, Velocity ecc.). Molto pochi lo fanno però. Questo perché gli Squad devono anche interpretare i dati oggettivi e decidere se significano che c’è un problema o no. Alla fine della giornata, quindi, tutto è comunque soggettivo. Se qualcosa sembra un problema, è un problema.
A volte combiniamo tutto questo con le retrospettive, ad esempio scegliendo una carta e poi pensando a misure di miglioramento per essa.
Quali domande bisognerebbe porre?
Se guardate gli esempi sopra menzionati, noterete che le domande non sono sempre le stesse. Ecco una buona linea guida:
Le domande devono coprire un’ampia gamma di prospettive diverse.
Queste domande sono solo un punto di partenza, una selezione esemplificativa. Gli Squad sono liberi di rimuovere, aggiungere o modificare le domande se ritengono che sia sensato.
Cercate di limitare il numero di domande a circa 10. Con più domande possono verificarsi rapidamente sovrapposizioni, motivo per cui possono essere rimosse.
Bisogna fare attenzione che le domande si riferiscano all’ambiente in cui lavora uno Squad e non a dati rigidi (come ad esempio la Velocity). In questo modo il tutto diventa meno minaccioso e viene sottolineato ancora una volta che si tratta di supporto e miglioramento – e non di valutazione.
La nostra assunzione (vera o no) è che uno Squad abbia una motivazione intrinseca ad avere successo e a fornire le migliori prestazioni possibili nelle circostanze date.
Quanto spesso misuriamo la salute degli Squad?
Come detto abbiamo diversi modelli a cui facciamo riferimento, quindi varia molto. Non abbiamo ancora trovato un determinato “intervallo di tempo perfetto” per queste cose (e probabilmente non lo troveremo mai).
Trimestralmente sembra essere un buon punto di partenza. Mensilmente è probabilmente un po’ troppo frequente (alle persone diventa presto noioso e i dati non cambiano abbastanza velocemente). Due volte all’anno sembra troppo poco (in sei mesi può succedere troppo). Ma come detto, varia sempre.
Conclusione – Cosa tenere a mente se volete provarlo
Un tale modello PUÒ aiutare a guidare i miglioramenti. Ma può anche capovolgere un’intera cultura aziendale se non lo si fa correttamente! Pertanto bisogna sempre procedere con cautela.
Ecco alcune linee guida che aumentano la probabilità di successo:
Siate chiari sulle motivazioni per l’introduzione del modello. Dovrebbe sempre riguardare il miglioramento, non la valutazione.
Dovreste raccogliere i dati principalmente attraverso la comunicazione personale, non tramite sondaggi online. Questo processo dovrebbe essere interessante e divertente.
Coinvolgete i team nell’applicazione del modello e lasciate che facciano adattamenti secondo le loro esigenze.
L’accettazione del team è più importante della coerenza dei dati. Se il Team A sceglie un set di domande leggermente diverso dal Team B, va bene (anche se il riepilogo diventa un po’ meno ordinato).
Fate attenzione che non ci siano incentivi a barare. Non dovrebbero esserci motivi per un team di presentarsi meglio di quanto sia in realtà.
Trovate un modo semplice per visualizzare i dati. Più è ovvia e intuitiva la visualizzazione, più alta è la probabilità che venga utilizzata.
Cercate di non confrontare i team tra loro. Se il Team A valuta i punti principalmente con verde e il Team B per lo più con rosso, non significa automaticamente che il Team A sia “migliore”. Potrebbe anche significare che il Team A ha un contesto più semplice, è più ottimista o che il Team B è più onesto riguardo alle difficoltà. Qualunque sia la ragione, significa semplicemente che il Team B ha bisogno di un po’ più di supporto. L’atteggiamento del manager dovrebbe essere “Come posso aiutare?” e non “Perché siete così tanto peggio degli altri?”.
Fate un follow-up. Ponete domande come: “Questo modello vi aiuta?”, “Se non facessimo più Health Check, vi mancherebbero?” o “Come potremmo rendere questo modello ancora più utile?”. Il modello (e il modo in cui lo applicate) deve essere migliorato continuamente.
