Wave 2: partono altri team, si parla di scaling

Abbiamo lanciato il primo team, è l’ora di verificare i criteri di successo e fallimento che ci siamo imposti, in base alle metriche che abbiamo scelto e monitorato. Non c’è niente di più sbagliato che perseverare su un errore, dovremo quindi decidere in accordo con il Transition Team: il primo team è stato un successo e possiamo continuare con la strategia di agilizzazione su nuovi team, oppure è il caso di pivotare modificando le condizioni?

Nel secondo caso, ci troveremo ad dover valutare le motivazioni del fallimento del team ed effettuare una root cause analysis: uno strumento base per questo tipo di attività e lo Hishikawa diagram (o fishbone diagram), che potremo utilizzare in collaborazione con diversi attori (il leader team, il Transition Team, i coach, gli altri reparti). Al termine dell’analisi potremo concordare su diverse tipologie di azione: da una nuova formazione del leader team, alla rimozione di impedimenti chiave per modificare il contesto. In ogni caso sarà necessario iterare nuovamente con il leader team, eventualmente aggiornando i criteri di successo e fallimento e le relative metriche.

Qualora, invece, il leader team avesse raggiunto gli obiettivi settati, sarà arrivato il momento di lanciare nuovi team: in base alla strategia iniziale avremo deciso probabilmente quanti team lanciare, ma la composizione del team sarà definita solo in base ai feedback raccolti durante la wave 1 e, soprattutto, solo adesso potremo decidere se e quale framework di scaling è opportuno utilizzare. Come avrete notato, ci capita spesso di consigliare di rimandare scelte importanti, come la composizione dei team e la definizione del framework di scaling; qualora vi foste domandati come mai tendiamo a rimandare queste scelte fino all’ultimo momento utile, potreste approfondire il principio di Last Responsible Moment.
In base allo stato nel quale si trova l’entità che si sta agilizzando, potremo scegliere di fare scelte più conservative nella composizione dei nuovi team, o più ardite: il cambiamento si troverà probabilmente ancora sotto giudizio e dovremo capire se il mood in questo momento è guidato dall’entusiasmo o dalla diffidenza. In entrambi i casi sarà necessario non perder di vista il Value Stream e il Transition Team ci potrà aiutare in questo. Inoltre i team della wave 2 saranno comunque composti in modo da massimizzare la cross-funzionalità e l’auto-organizzazione. Per ogni team imposteremo success e failure criteria e metriche in base ai loro scope e agli obiettivi: alcuni di essi potranno avere un percorso impegnativo per la gestione del knowledge sharing e sarà quindi opportuno impostare un piano di formazione adeguato.
La vicinanza del Transition Team è ancora fondamentale e un buon modo per non perdere contatto con i team sarà quello di usare il principio del Gemba Walking.

Ci troviamo ora con più team che dovranno coordinarsi, sullo stesso prodotto o su prodotti distinti, probabilmente sullo stesso value stream e, quindi, quali e quanti responsabili del prodotto abbiamo identificato? Fare questa scelta in base alle competenze che l’entità ha a disposizione potrebbe rivelarsi un errore fatale, valutiamo invece quale configurazione può portare più valore all’entità e minimizzare il waste e i livelli di riporto: la comunicazione è tanto più efficace quanto meno sono le indirezioni. Inoltre: quale architettura sottosta al nostro prodotto o servizio e, soprattutto: qual è la vision dell’entità su questo fronte? Abbiamo a che fare con uno o più prodotti/servizi? Quale forma stiamo dando ai backlog: sono fra loro indipendenti o vincolati? Sulla base di queste valutazioni dovremo scegliere, insieme al Transition Team, quale framework di scaling utilizzare, tenendo bene a mente che la scelta che faremo condizionerà non solo i risultati dell’agilizzazione, ma anche l’architettura, i processi e le prestazioni dell’entità.

I framework di scaling Agile sono molti, ne citiamo solo alcuni: Scaled Agile Framework, Less, Nexus, Scrum@Scale: ognuno ha le sue peculiarità e può essere più adeguati di altri in determinate condizioni, ma quello che non dobbiamo mai dimenticare è la vision: il cambiamento, come sappiamo, è un processo molto faticoso e lo strumento di scaling che vogliamo utilizzare potrebbe facilitarlo o rallentarlo, per questo consigliamo di fare questa scelta non tanto sulla base delle condizioni correnti, ma sulla visione che l’entità ha di se stessa nel futuro.