Casi di studio SAFe: note di trasformazione dal campo

Questo articolo è la terza parte della serie di scalabilità Agile di Toptal, progettata per guidare i project manager negli sforzi di espansione del loro team. Assicurati di leggere la prima parte, "5 framework di ridimensionamento agile a confronto: quale dovresti usare?" e la seconda parte, "Agile Scaling: Safe Best Practices for Scrum Masters".

L'agilità è praticata in qualche modo dal 94% delle aziende, secondo il 15° rapporto annuale sullo stato dell'agile . Ma la ricerca suggerisce anche che il 90% delle organizzazioni ha difficoltà con l'implementazione Agile a livello aziendale. In genere, è il lavoro degli allenatori Agile, degli Scrum Master e di altri professionisti della gestione dei progetti guidare e organizzare questi sforzi. Spesso lavorano con team o dipartimenti resistenti al cambiamento, in una cultura aziendale difficile da comprendere.

In questa tavola rotonda, tre project manager di Toptal discutono delle sfide delle principali trasformazioni Agile. Poiché le loro soluzioni sono coerenti con lo Scaled Agile Framework (SAFe), abbiamo anche parlato con Dean Leffingwell, creatore di SAFe. Le loro intuizioni collettive illustrano la necessità per i professionisti di SAFe di preparare una visione chiara di cosa sia l'agilità e un piano di leadership che possa coinvolgere i team recalcitranti.

Parlare in sicurezza con il creatore del framework

SAFe, un framework formalizzato da Scaled Agile, risale solo al 2014. Ma per Leffingwell il lavoro è iniziato quando ha incontrato per la prima volta i team Agile nei primi anni 2000. In qualità di metodologo dello sviluppo software, è rimasto colpito dai risultati delle pratiche Agile sui team di sviluppo e ha immediatamente iniziato a esplorare come applicare la mentalità a un'intera azienda. Se un team Agile potesse produrre risultati, cosa potrebbe produrre un team di team Agile allineati? Come potrebbero essere utilizzate le pratiche Agile per progetti di trasformazione su vasta scala presso aziende nazionali o internazionali? Come dice Leffingwell, “Amo lo sviluppo di software. Amo Agile. Voglio solo che sia grande ".

Negli anni successivi, le aziende hanno riconosciuto i vantaggi di SAFe, tra cui consegne più brevi, maggiore qualità del prodotto, maggiore efficienza e dipendenti più coinvolti. Nel 2021, più di un terzo delle organizzazioni in tutto il mondo utilizzava SAFe e tra i suoi aspetti più importanti ci sono i processi condivisi e il linguaggio unificato che fornisce. Ad esempio, se una squadra pensa che uno sprint duri due settimane e un altro pensa che duri 30 giorni, crea quello che Leffingwell descrive come un "problema della Torre di Babele". È difficile per i team discutere quali funzionalità aggiungere se non riescono nemmeno a mettersi d'accordo sul significato di "caratteristica". "Hai [bisogno] di persone che lavorino in modo comune se vuoi costruire grandi soluzioni", dice. “Non c'è un termine nel nostro settore che non sia sovraccarico, come 'iterazione' o 'sprint' o 'arretrato'. Questo non è utile se stai cercando di lavorare oltre i confini di squadra e regionali".

Storie di successo agili

Far sì che tutti in un'azienda adottino un modo unificato di parlare e svolgere il lavoro è un compito arduo anche quando c'è un'enorme urgenza di cambiamento. Nelle società consolidate, può essere più difficile. Leffingwell spiega: “Stai guardando le più grandi aziende del mondo che stanno facendo molti soldi, stanno andando incredibilmente bene e competono, e devono cambiare. Ebbene, la domanda per loro è perché dovrebbero?" I project manager di Toptal presenti qui hanno incontrato domande come questa durante le proprie attività di ridimensionamento e hanno trovato il proprio modo di lavorare attraverso le trasformazioni Agile utilizzando SAFe.

Dimostrare valore

Alvaro Villena, project manager di Toptal a Santiago, Cile, ha recentemente completato una transizione SAFe per un portafoglio che sviluppa una piattaforma cross-business. "La prima pietra miliare nella mia transizione è stata la conduzione di un workshop sul flusso di valore", afferma. In parole povere, un workshop sul flusso di valore è un incontro preliminare per identificare l'intero processo aziendale, dall'ideazione alla consegna e tutti i passaggi, gli utenti, i sistemi e i punti critici nel mezzo.

Far entrare i rappresentanti dell'intera azienda nell'officina ha aiutato Villena a capire la cultura aziendale e quali sarebbero stati i suoi ostacoli. "Prima di implementare il workshop, esisteva una struttura in cui un'azienda aveva il suo team, un'altra azienda aveva il suo team e l'azienda successiva aveva il suo team: i tre non si parlavano".

Villena ha scoperto che, sebbene tutte le squadre condividessero punti deboli simili, non c'era collaborazione sulle soluzioni. Ad esempio, sebbene ogni azienda nel portafoglio spedisse prodotti, solo una aveva sviluppato un sistema di tracciabilità. Non c'era motivo per cui non potessero usarlo tutti, tranne per il fatto che nessuno aveva condiviso la conoscenza. Una volta che il workshop li ha fatti parlare, la conoscenza ha iniziato a fluire tra team, aziende e proprietari di prodotti. “Quel tipo di conversazione è stato davvero molto potente per il programma. È stato un bel punto di partenza", dice Villena. Quando DevOps, progettazione e prodotto sanno cosa stanno facendo gli altri team, vedono che ci sono soluzioni nell'azienda che possono essere utilizzate. “Cominciano a chiedersi: 'Come posso averlo?' Ed è qui che intervieni e dici: 'Segui questo processo'".

“Nessuno vuole cambiare finché non sa perché. Quindi inizi con un perché e dai loro un futuro migliore". Dean Leffingwell, creatore di SAFe

Leffingwell sa che le squadre a volte sono resistenti. "Nessuno vuole cambiare finché non sa perché", dice a Toptal. "Quindi inizi con un perché e dai loro un futuro migliore". Dare ai team un'idea di quanto possono essere più efficienti è un potente strumento per cambiare la leadership.

Anche quando tutti sono entusiasti a bordo, dovresti comunque aspettarti inizi rocciosi. I team che sono abituati allo sviluppo tradizionale di Waterfall e ai grandi rilasci, ad esempio, potrebbero avere difficoltà a passare a un processo di sviluppo più iterativo e agile, anche se ne vedono il valore. "Il primo incremento del programma che abbiamo fatto è stato un disastro per i team", afferma Villena. “E sapevamo che sarebbe stato; abbiamo detto al cliente di aspettarsi che i primi tre mesi potrebbero essere difficili”. Per compensare ciò, ha creato un'iterazione di una settimana alla fine del primo incremento del programma (PI) in cui i team potevano valutare i propri progressi. Ha organizzato uno sprint dedicato esclusivamente ai miglioramenti e alle valutazioni dei processi che sarebbero andati oltre il solito controllo e adattamento. Ha trovato utile applicare una mentalità Agile non solo al prodotto, ma anche alla transizione aziendale, prendendosi il tempo per fare un passo indietro, vedere cosa ha funzionato e cosa no e adattarsi di conseguenza.

Creare piccole vittorie

È importante essere preparati per ostacoli imprevisti nell'adozione di SAFe. Alcuni anni fa, il project manager di Toptal, Miroslav Anicin a Belgrado, in Serbia, stava trasferendo una società di telecomunicazioni a SAFe. La società aveva esternalizzato tutto lo sviluppo del software. Incorporare un team fuori sede non è stato un compito particolarmente oneroso: i problemi coinvolti erano principalmente logistici. Ma lo sforzo ha creato sfide impreviste nella transizione dell'azienda stessa. "Stavo cercando le competenze di cui abbiamo bisogno nel treno di rilascio", dice. "E tutte le persone tra cui dovevo scegliere provenivano dal marketing, dall'ufficio legale, dai prodotti, dalla finanza, completamente prive della mentalità Agile o addirittura di qualsiasi esperienza in Agile".

È diventato evidente che il management non aveva esperienza nella gestione dei team Agile. Il processo decisionale distribuito richiede ai manager di rinunciare a un certo controllo, un fatto che la leadership può esitare se non hanno esperienza con i framework Agile. Per risolvere questo problema, Anicin ha dovuto allenarsi dal basso verso l'alto e dall'alto verso il basso, allenando i leader insieme alle loro squadre.

Tale passaggio a un processo decisionale più decentralizzato richiede "cambiare il modo di lavorare dal comando e controllo, attraverso la leadership di servizio, a questa cultura potenziante dell'apprendimento e della cultura dell'Agile e la capacità di tollerare gli errori", afferma Leffingwell.

Anicin ha avviato il processo di ridimensionamento in modo incrementale, con piccoli progetti Agile eseguiti all'interno di singoli team, non all'interno di un framework SAFe, in modo che i singoli team potessero sviluppare un'esperienza pratica. Questi progetti dovevano essere non essenziali e sufficientemente piccoli da non danneggiare l'azienda se qualcosa fosse andato storto al primo tentativo, ma sufficientemente utili da mostrare al team cosa si poteva ottenere con l'approccio. Ad esempio, il team di marketing ha creato una campagna di marketing interna, durante la quale Anicin ha insegnato loro le basi di Scrum. Simile al workshop di Villena, questi progetti più piccoli dimostrano il valore di Agile in termini reali, in modo che i membri del team e la leadership possano vedere i vantaggi di brevi rilasci e miglioramento continuo prima della transizione su vasta scala.

Soddisfare le esigenze dei tuoi team

Quando Imane Marouane, una project manager di Toptal con sede a Parigi, ha guidato una trasformazione per un grande istituto finanziario multinazionale, è entrata in un ambiente caotico in cui i singoli team hanno prodotto un lavoro solido ma non condividevano la visione dell'intera azienda. “Ogni squadra aveva la propria priorità. Ogni product manager voleva che il proprio prodotto fosse consegnato per primo".

La soluzione di SAFe a questo problema può essere trovata nel modello WSJF (Weightest Short Job First). WSJF fornisce uno standard per la definizione delle priorità del lavoro, quindi quando è il momento di decidere quale dovrebbe essere l'attività successiva, il primo passaggio non comporta controversie su come classificare l'importanza. In un sistema Agile basato sul flusso, non devi preoccuparti di consegnare tutto in una volta perché, come afferma Leffingwell, “la cosa più importante è quale lavoro fare dopo. E questa è una domanda molto più facile a cui rispondere rispetto a quale sia il lavoro più prezioso. SAFe fornisce un modo per risolvere le dipendenze tra i team: ordinare le attività è essenziale per questo risultato.

Il percorso di Marouane verso la risoluzione delle dipendenze è diventato incerto: "Dopo due sprint, prima del primo ispezione e adattamento, abbiamo notato che alcuni team non stavano seguendo il nostro piano PI". Le dipendenze definite nel piano PI non venivano seguite, quindi il lavoro di un team non poteva iniziare perché il contributo di un altro team non era pronto.

"Dato che si trattava della prima iterazione e i team non erano abituati a questo tipo di lavoro, abbiamo deciso di organizzare una cerimonia in più, un incontro settimanale per discutere i progressi sulle dipendenze", afferma Marouane. "Una persona per ogni squadra è venuta per aggiornare i progressi sui propri contributi". In questo modo, se il Team A ha dichiarato di non essere in grado di fornire, il Team B potrebbe sapere in anticipo e pianificare di conseguenza, invece di aspettare contributi che non si sarebbero concretizzati all'inizio del loro sprint.

Leffingwell predica cautela quando si effettuano questi tipi di aggiustamenti a SAFe: “SAFe è un sistema di responsabilità. ... Puoi adattarlo, ma devi stare molto attento. " Sebbene il quadro sia destinato ad essere adattabile, le modifiche tendono a essere integrate se non rivalutate. La configurazione Essential SAFe esiste per assicurarsi che eventuali modifiche soddisfino i criteri di base.

La cerimonia extra di Marouane è stata inclusa di nuovo nel secondo PI e nel terzo era stata gradualmente eliminata. Le squadre non avevano nulla da riferire che non fosse già stato comunicato. Un po' di flessibilità in più ha permesso a Marouane di riportare le squadre su un percorso di processo più tradizionale. Ha scoperto che la transizione stessa richiedeva una mentalità agile per ottenere il massimo dai team dell'istituto finanziario. E, soprattutto, il cambiamento che ha apportato, attraverso il suo impegno per il miglioramento continuo, alla fine è servito ai principi Lean-Agile che sono alla base di Essential SAFe. La sua soluzione ha dato all'azienda la visione unificata che le mancava e ha permesso ai team di lavorare insieme verso le stesse priorità.

Adattarsi per il futuro

Qualsiasi struttura che opera su larga scala si presenterà con delle sfide. Il numero di parti mobili e interessi in competizione è immenso. Ma i guadagni sono ugualmente grandi e una transizione ben eseguita fornirà ai team gli strumenti di cui hanno bisogno per lavorare verso obiettivi comuni. Gli ostacoli che incontrerai in un'implementazione così ampia saranno imprevedibili e una mentalità agile ha aiutato Villena, Anicin e Marouane ad adattarsi a sfide inaspettate. Dopotutto, è a questo che serve la consegna continua: potenziare il tuo processo con gli strumenti per adattarsi all'imprevisto.

Scaled Agile si adatta anche alle nuove tecnologie e agli standard di settore in evoluzione, introducendo nuovi strumenti e capacità, se necessario. Tutti devono rimanere agili e prepararsi per gli imprevisti. "Non abbiamo la sfera di cristallo", dice Leffingwell. "Corriamo velocemente, guidiamo duro e seguiamo duro e scriviamo il più velocemente possibile".