Agile Scaling: Best Practice SAFe per gli Scrum Master

Questo articolo è la seconda parte della serie di ridimensionamento Agile di Toptal, progettata per guidare i project manager negli sforzi di espansione del team. Leggi la prima puntata, "5 framework di Scaling Agile a confronto: quale dovresti usare?" per una panoramica approfondita delle opzioni più popolari.

Man mano che i prodotti crescono e diventano più complessi, crescono anche i team che li producono. Quando è il momento di scalare, molte aziende passano da Scrum allo Scaled Agile Framework (SAFe), un sistema che viene implementato a livello aziendale e consente alle aziende di gestire prodotti multipli e complessi che richiedono lo sviluppo di team di team.

Uno Scrum master che entra in un framework SAFe entrerà in un ambiente che è allo stesso tempo familiare e nuovo. Gli artefatti, i ruoli e le cerimonie sono basati su Scrum. Ma operare su una scala più alta comporta alcune responsabilità aggiuntive, specialmente per gli Scrum Master che scelgono di passare al ruolo di Release Train Engineer (RTE), una traiettoria comune. L'RTE funge da Scrum master dell'intero treno di rilascio. Invece di guidare un team Scrum da 9 a 11 persone, gli RTE diventano servant-leader di team di team che si trovano a cavallo di più dipartimenti e organizzano eventi di dimensioni e portata maggiori.

Le basi: da Scrum a SAFe

SAFe consente a un'azienda di applicare approcci, valori e principi Agile a più team. Il risultante "team di squadre" è noto come agile release train (ART). I singoli team continuano a impiegare uno Scrum Master per fare affari come al solito, mentre il ruolo di Scrum-master su un ART è svolto da un RTE. L'RTE applica i meccanismi generali e la governance di Scrum, ma a livello organizzativo, piuttosto che di team. Anche altri ruoli e artefatti di Scrum tradizionali a livello di team cambiano di conseguenza. Ad esempio, il “product owner” ART diventa un product manager; un “product backlog” diventa il program backlog; uno "sprint backlog" è un backlog di iterazioni; e l'"incremento del prodotto" è ora l'incremento del programma (PI).

Esistono quattro configurazioni di SAFe—Essential, Large Solution, Portfolio e Full—e quella che utilizzi dipende da quanto ampiamente la tua azienda adotta il framework. Le configurazioni consentono l'implementazione a più livelli, che vanno da più team che lavorano insieme all'integrazione completa del portafoglio e all'agilità aziendale a livello aziendale. Ma ad ogni livello, l'obiettivo rimane quello di scalare le pratiche Agile e Scrum, non sostituirle.

Scrum Master in SAFe

Gli Scrum Master che lavorano in un framework SAFe a livello di team scopriranno che i loro lavori non sono significativamente differenti. Rimarranno un leader di servizio per un team Agile, responsabili del coaching e dell'istruzione, della rimozione degli impedimenti e della promozione di un ambiente in cui i membri del team si sentano al sicuro per dare il meglio e migliorare continuamente.

Tuttavia, ci saranno alcune nuove responsabilità. Un SAFe Scrum master supporta l'RTE nell'evento di pianificazione PI e nell'esecuzione del programma e rappresenta il proprio team nelle riunioni di sincronizzazione ART. Quando ci sono impedimenti che vanno oltre la capacità di rimozione del team, lo Scrum master li inoltra all'RTE.

Uno Scrum master che decide di diventare un RTE scoprirà che il suo ruolo viene con decisamente più considerazioni. L'ART può includere team nuovi per te o nuovi per Agile, come analisi aziendali, hardware o conformità. E poiché le configurazioni superiori di SAFe includono operazioni di programma o di portafoglio, il management sarà direttamente e regolarmente coinvolto in modi che non sarebbero in Scrum, assicurandosi che tutto sia allineato con gli obiettivi a livello di impresa e/o di portafoglio.

L'RTE è responsabile della rimozione degli impedimenti che esulano dalle capacità di una singola squadra. Comunicano con le parti interessate e promuovono il miglioramento continuo a livello ART. L'RTE allena non solo le squadre, ma anche i leader di queste squadre, aiutando tutti i livelli dell'ART a muoversi verso l'auto-organizzazione e l'autogestione.

Eventi sicuri

Proprio come uno Scrum master facilita gli eventi a livello di team, un RTE facilita gli eventi a livello di ART: la pianificazione PI, la sincronizzazione ART, la demo del sistema e l'ispezione e l'adattamento. In qualità di RTE, ti impegnerai con una più ampia varietà di stakeholder rispetto a come eri come Scrum master e gestirai più team con interessi in competizione. Ci sono più partecipanti, e più vari, a ogni evento ed è necessario allineare le priorità e ottenere il consenso per le iniziative con largo anticipo.

Pianificazione PI

L'evento di pianificazione PI è una cerimonia essenziale per SAFe, una gigantesca sessione di due giorni per allineare gli obiettivi di tutte le squadre all'interno dell'ART per le prossime 8-12 settimane creando il piano PI. È come un evento di pianificazione di uno sprint, ma si estende su più sprint su più team.

Ingressi

• Visione aziendale
• Elenco delle prime 10-15 funzionalità da implementare
• Dettagli sulla capacità di ogni squadra

Uscite

• Piano PI (un piano di consegna per i prossimi cinque o sei sprint)
• Obiettivi PI
• Elenco dei potenziali rischi

Suggerimenti generali per l'evento di pianificazione PI

• Ottieni l'adesione degli stakeholder. Prima dell'incontro, gli RTE dovrebbero stabilire chi sono gli stakeholder chiave e condividere i loro input con il gruppo.
• Allinea le priorità. Prima della sessione, pianifica una riunione di un giorno con il team di gestione del prodotto per concordare una visione di alto livello di quali funzionalità dovrebbero essere fornite, nonché delle priorità future. Ci sarà molto da risolvere durante l'evento, come rischi e dipendenze, ed è bene avere un accordo direzionale di base in atto.
• Provare! La pianificazione del PI è un grande evento. Potrebbe non essere utile passare due giorni interi a provare, ma una sessione di due o quattro ore con i team leader dell'ART che crea un'esperienza il più vicino possibile sarà di grande aiuto. Crea una versione semplificata dell'agenda dell'evento e condividila prima delle prove in modo che la pratica possa iniziare da un luogo ben informato.
• Preparati per la missione creep. L'obiettivo della pianificazione PI è fornire un piano a lungo termine in un periodo di tempo relativamente breve. A volte le persone vorranno approfondire i dettagli su tutto, che non è lo scopo dell'evento. Spiegalo ai capigruppo durante le prove e durante la sessione; ricordare ai team che l'obiettivo è fornire piani di alto livello e creare allineamento, non pianificare ogni minuto dei prossimi tre mesi.
• Preparare le informazioni sulla capacità del team. Chiedi ai tuoi Scrum master di fornire i calcoli della capacità per le prossime 8-12 settimane. Aspettati qualche respingimento o domande; per esempio, uno Scrum master potrebbe non sapere esattamente quante assenze avrà il suo team nei prossimi due mesi. In questi casi, chiedi preventivi e sii flessibile nel rispondere ai limiti di capacità durante il PI stesso.
• Condividi l'agenda di pianificazione PI. Distribuisci il programma almeno due settimane prima dell'evento e preparati a rispondere a molte domande. Ci saranno molti partecipanti e se SAFe è nuovo per te e la tua azienda, probabilmente lo è anche per molti altri membri del team. Secondo la mia esperienza, al secondo o terzo evento di pianificazione PI, la pressione sui facilitatori diventa molto meno intensa man mano che i team acquisiscono familiarità con l'evento e sanno cosa aspettarsi.
• Gestione sicura delle presenze. Spesso è difficile per manager o senior manager partecipare a un evento di due giorni, ma la presenza del management è un must per garantire un allineamento di alto livello. Confermare la loro presenza almeno due settimane prima della pianificazione del PI e organizzare qualsiasi supporto di cui avranno bisogno. Lo stesso vale per gli imprenditori, che devono firmare gli obiettivi PI.

Sincronizzazione ART

L'evento ART sync è un incontro settimanale in cui l'RTE può ottenere informazioni dettagliate sui progressi dei team e identificare i rischi del programma e i blocchi stradali. Sebbene non sia l'unica occasione per un RTE di valutare gli impedimenti e determinare se richiedono un'escalation, è un evento importante che fornisce una sede regolare per sollevare queste questioni.

Ingressi

• I progressi delle squadre
• Registro degli impedimenti
• Il piano PI (per identificare eventuali deviazioni importanti tra il piano e l'andamento effettivo)

Uscite

• Escalation (se necessario)
• Decisioni su eventuali modifiche al piano PI

Suggerimenti generali per l'evento ART Sync

• Incoraggiare una comunicazione regolare. Poiché l'ART Sync è settimanale, invece che quotidiano come gli stand-up di Scrum, l'RTE dovrebbe chiarire che i team possono sollevare problemi urgenti immediatamente e non dovrebbero aspettare la prossima sincronizzazione ART.
• Preparati con i dati. Chiedi a Scrum Master e Product Owner di portare metriche di progresso quantificabili, come burndown o flusso cumulativo, per avere una conversazione informata sui progressi.
• Vai oltre una revisione settimanale dello stato. L'ART sync vuole essere un evento in cui le priorità vengono allineate e i problemi vengono risolti, non un semplice check-in.

Demo di sistema

La demo di sistema ha lo scopo di mostrare l'intero ambito del lavoro creato durante un'iterazione precedente. In questo evento, il product manager e il loro team mostrano agli imprenditori e alle altre parti interessate il progresso integrato dell'ART nella sua forma attuale.

Ingresso

• Lo stato attuale del lavoro basato sull'output di tutti i membri del team Agile nel corso dell'iterazione precedente

Uscite

• Feedback sull'idoneità del sistema allo scopo
• Modifiche all'arretrato (se necessario)

Suggerimenti generali per l'evento demo di sistema

• Provare! Dedica dai 30 ai 45 minuti a settimane alterne a lavorare con i presentatori per definire i loro segmenti.
• Elimina le diapositive. Presentare il vero lavoro integrato. Se stai lavorando su un prodotto software, chiedi ai relatori di mostrare alle parti interessate un incremento del prodotto funzionante anziché una presentazione. Se possibile, dimostra il tuo prodotto in un ambiente di staging. Vuoi che la demo assomigli accuratamente all'esperienza dell'utente finale. Se non sei in grado di presentare un sistema integrato ogni due settimane, esamina la pipeline di distribuzione e fai un brainstorming con i team su come adottare la cultura CI/CD e DevOps.
• Concentrati sul valore aziendale. La tua presentazione è per gli imprenditori e le parti interessate; condividere ciò che è più importante per loro.
• Mantieni il feedback concentrato. Il feedback degli stakeholder che riceverai sarà importante, ma questo evento non è il momento per cambiamenti drastici alla visione del prodotto o alla roadmap. Preparati a riportare la conversazione su feedback di alto livello che i team possono trasformare in azioni in un secondo momento.
• Tienilo breve. Gli stakeholder sono persone impegnate; una riunione di 45-60 minuti si tradurrà in una partecipazione più frequente e coinvolta.
• Concedi tempo per domande e risposte. Sii trasparente nelle tue risposte. Ricorda che a volte "non lo so, ma possiamo scoprirlo" è la risposta migliore.

Ispeziona e adatta

L'ispezione e l'adattamento è una mega sessione retrospettiva che si svolge al termine di un PI. La sessione è divisa in tre parti,

• La demo del sistema PI: una vetrina per l'intera uscita integrata del PI. È simile alla demo del sistema principale, ma invece di un'iterazione, questo evento mostra il lavoro integrato nell'intero PI.
• Misure quantitative e qualitative: un'opportunità per la RTE di presentare le metriche raccolte nel corso del PI. Queste metriche includono (ma non sono limitate a) velocità del team, storie degli utenti accettate, copertura di unit test o difetti aperti.
• Workshop retrospettivo e di risoluzione dei problemi: un'opportunità per i partecipanti di guardare indietro al PI, riflettere su ciò che ha funzionato e non ha funzionato, identificare problemi sistematici e proporre modi per risolverli.

Ingressi

• I progressi delle squadre
• Lo stato attuale del lavoro integrato dell'ART, inclusi tutti i risultati dell'incremento del programma

Produzione

• Elenco dei potenziali miglioramenti

Suggerimenti generali per l'evento Ispeziona e adatta

• Dare un preavviso agli imprenditori. Fornire un preavviso di almeno due settimane prima dell'evento. Incontra tutti i product manager e gli imprenditori presenti prima della sessione per allinearti alla presentazione dei risultati qualitativi.
• Assicurare la partecipazione degli stakeholder senior. La loro presenza è molto importante alla demo del sistema PI quando mostri il lavoro del team e il prodotto in evoluzione. Molti dei suggerimenti per la normale demo del sistema si applicano qui: prova in anticipo, evita le diapositive della presentazione e mostra i risultati finali effettivi.
• Evita la colpa. Durante tutta la sessione, assicurati che nessuno si senta minacciato dai dati presentati o dai problemi individuati nella retrospettiva. Alcune squadre possono sentirsi gelose o sulla difensiva se i numeri di un'altra squadra sono più alti, o sentirsi esclusi se un problema ha avuto origine con la loro squadra. Abbraccia una cultura dell'intero team per prevenire tali problemi.
• Concentrati su questioni sistematiche. Cerca di non prestare troppa attenzione a problemi sporadici, offri al tuo team lo spazio di cui ha bisogno per fare brainstorming e lascia correre l'immaginazione per le soluzioni proposte.
• Crea proposte attuabili. Alla fine dell'evento, dovresti avere elementi di backlog che i team possono implementare. Identificare i problemi non aiuta se non si prendono provvedimenti per risolverli.

La tabella seguente confronta gli eventi SAFe con i loro equivalenti Scrum e descrive la frequenza e l'esecuzione delle cerimonie a livello aziendale:

Aumentare e aumentare

Il passaggio da Scrum a SAFe può essere intimidatorio. Operare su una scala più alta presenterà sempre nuove sfide e nuovi modi di pensare anche alle pratiche più familiari. Se scegli di diventare un RTE, scoprirai che il lavoro dipende maggiormente dalle competenze che già possiedi. Un RTE è un agente di cambiamento e un servant-leader, proprio come uno Scrum master, e il lavoro ti dà la possibilità di ricoprire questo ruolo a livello aziendale, elevando le tue competenze insieme ai tuoi prodotti.