La roadmap della trasformazione agile: 5 modelli e i loro punti in comune

Non sai quale roadmap di trasformazione agile utilizzare? Ora lo cambieremo!

Se vuoi adattare una roadmap di trasformazione agile, hai l’imbarazzo della scelta perché ce ne sono molte.

Per questo motivo abbiamo selezionato alcune delle roadmap più utilizzate, in modo che tu possa scoprire quale sia quella più adatta al tuo team o addirittura svilupparne una tua.

In questo articolo scoprirai le diverse roadmap esistenti, con brevi riassunti di ogni fase. Infine, ti presenteremo un breve modello completo che riassume gli elementi comuni a tutti i modelli in uno solo.

Poiché agile significa reagire al cambiamento, lo stesso vale per una roadmap. Qui ti spieghiamo cos’è esattamente una roadmap di trasformazione agile:

Cos’è una roadmap di trasformazione agile?

Secondo Atlassian una roadmap è un piano d’azione per il miglioramento di un prodotto o di una soluzione nel tempo. Quando viene utilizzata nello sviluppo agile, serve a dare un contesto al team. 

Risponde alle variazioni e ai cambiamenti del panorama competitivo, in modo da essere flessibile con nuovi approcci. L’obiettivo è quello di ottenere risultati aziendali migliori.

Perché usare una roadmap di trasformazione agile?

• Allineare il team per le fasi successive
• Agire in modo flessibile e fluente, senza artefatti fissi.
• Aiuta l’azienda
• Aiutare i team ad acquisire le giuste conoscenze
• Aiutare a mantenere la formazione
• Prendi decisioni più informate
• Dare priorità ai compiti

Bene, ora che ci siamo tolti questo di mezzo, ti presentiamo cinque modelli di roadmap specifici, dal Change Management di Kotter a Scale@Scrum.

A proposito, una breve nota nel contesto della trasformazione agile: vuoi assicurarti di dare le giuste priorità alla tua trasformazione agile? 

Allora fai il nostro controllo del livello di maturità per la tua trasformazione agile: ci vogliono solo 3 minuti. Riceverai anche un benchmark basato sugli oltre trecento partecipanti. Vedi il pulsante 🙂

Tabella di marcia della trasformazione agile #1: Gestione del cambiamento di Kotter

“Il cambiamento è l’unica costante”

Eraclito, filosofo greco

Abbiamo utilizzato il modello a 8 fasi di Kotter in questo contributo già presentato in dettaglio.

Per farla breve: Il modello Kotter si svolge in ordine sequenziale, ma tutte le fasi possono essere eseguite contemporaneamente. Suggerisce l’urgenza del cambiamento. Le prime quattro fasi si concentrano sulle basi del cambiamento, le fasi da cinque a sette riguardano l’introduzione di nuovi comportamenti e l’ultima fase, l’ottava, si occupa di consolidare il cambiamento. Ora le spieghiamo in modo un po’ più dettagliato:

Concentrati sulle basi del cambiamento

1. Il primo passo è che l’intera azienda si impegni nel cambiamento. Ricerca di Kotter mostrano che il 75% dei membri del team deve “supportare” il cambiamento affinché abbia successo.

2. La seconda fase riguarda la convinzione del team che il cambiamento sia essenziale per il successo. Questo porta a una “coalizione per il cambiamento” che richiede di lavorare come team per riconoscere la necessità del cambiamento.

3. Il terzo passo è l’attuazione effettiva di una visione. Una strategia è sempre necessaria. Ora è il momento di stabilire i valori per il cambiamento, ecc. 

Introduzione di nuovi comportamenti

4. Il quarto passo consiste nel comunicare questa urgenza al team. Parla della tua visione. Dimostra il comportamento desiderato per investire nel cambiamento.

5. Il quinto passo consiste nel rimuovere gli ostacoli e vedere se qualcuno si oppone al cambiamento. Tutti devono essere d’accordo perché il cambiamento avvenga.

6. Il sesto passo consiste nel creare obiettivi a breve termine piuttosto che un obiettivo a lungo termine. Come si dice? Niente motiva più del successo!

7. La settima fase consiste nell’analizzare cosa è andato storto e cosa è andato bene. Il vero cambiamento richiede una costruzione: questa è la parte in cui si guarda dove si può migliorare.

Consolidamento del cambiamento

8. L’ottavo passo significa finalmente rendersi conto che in tutte le aree dell’azienda si stanno compiendo sforzi continui per realizzare il cambiamento. Si tratta di coerenza e progresso.

Questo modello funziona bene per i team pronti a implementare il cambiamento in modo efficace e radicale. Abbiamo creato un eBook per potenziare i tuoi team: dai un’occhiata qui an.

Tabella di marcia della trasformazione agile #2: Tabella di marcia dello Scaled Agile Framework

“Se non riesci a descrivere quello che stai facendo come un processo, non sai cosa stai facendo.

W. Edwards Deming

Abbiamo già presentato il Scaled Agile Framework in dettaglio in un articolo: leggilo qui a.

La serie SAFe Implementation Roadmap è composta da 12 articoli, ognuno dei quali descrive una strategia e una serie di attività che si sono dimostrate vincenti all’interno del framework.

Esamineremo ogni “fase critica”, come definita da Dan e Chip Heath descritto in modo breve e semplice.

Iniziare nel modo giusto

1. La prima fase, nota anche come “Tipping Point”, è il punto in cui la visualizzazione e l’implementazione si incontrano. Si tratta di implementare la necessità del cambiamento e la visione del cambiamento in uno solo. La ricerca dimostra che il Tipping Point è l’inizio della formazione di una coalizione di leader. 

2. Nel secondo articolo inizia il difficile viaggio, ma non deve essere difficile. Per la seconda fase, i principali attori devono riunirsi e impostare la rotta. Si raccomandano tre passaggi: formare gli agenti Lean-Agile, formare i leader e gli altri manager e creare un Lean Agile Center of Excellence (noto anche come gruppo di lavoro). 

3. La terza fase prevede l’inizio della formazione. Perché un cambiamento possa essere implementato in modo visibile ed efficace, è necessaria una leadership forte. Con queste tre “fasi critiche”, l’azienda è ora sulla buona strada per il successo.

4. Come menzionato nella seconda fase, nella quarta fase si riunisce il LACE. LACE sta per Lean Agile Center of Excellence e si riferisce a un piccolo gruppo di persone che si dedicano alla promozione del modo di lavorare Lean-Agile. John Kotter sottolinea che le dimensioni del team dipendono dalle dimensioni dell’azienda: i cambiamenti iniziano con due o tre persone.

Iniziare a scalare

5. L’articolo cinque riguarda l’implementazione di SAFe. Ora è il momento di identificare. Identifica i flussi di valore e gli Agile Release Train (ART). 

6. Ora si tratta di fare piani dettagliati. L’articolo sei riguarda l’attuazione di un cambiamento organizzativo e l’applicazione delle nuove conoscenze acquisite durante la formazione. 

7. Fino a questo momento ci sono stati flussi di valore e un piano di implementazione. Quindi l’articolo 7 è un momento decisivo. È il momento del primo lancio dell’ARTE. Ci sono una serie di passi da considerare nel periodo che precede il lancio. Puoi trovare maggiori informazioni sul sito web di SAFe. qui. 

8. Il lancio dell’ART richiede la formazione dei team nell’articolo otto. Ora che il piano di implementazione e le parti interessate sono stati formati, il cambiamento vero e proprio può avvenire. Kotter afferma che i leader devono “plasmare il percorso”: in altre parole, ciò richiede formazione e tempo e impegno. 

9. I primi eventi importanti sono stati raggiunti. Ora, nell’articolo nove, il team viene responsabilizzato. Poiché la competenza e il potenziale si basano sul team, i team agili devono essere allenati. Se vuoi saperne di più sullo sviluppo dei team, non esitare a dare un’occhiata ai nostri utili articoli Ebook an. 

Dopo la prima ipotesi

10. L’articolo dieci riguarda la produzione di più cambiamenti e l’introduzione di più ART. Pensa a questo articolo come a un’auto che prende velocità a pieno regime in autostrada. 

11. Si avvicina la fine, SAFe è stato adottato. L’articolo undici si concentra sulla spinta e sull’implementazione di SAFe. Ora si tratta della competenza Lean Portfolio Management e dell’integrazione del nuovo approccio nella cultura aziendale. 

12. L’ultimo articolo sottolinea l’importanza del cambiamento costante. Siamo certi che hai fatto dei progressi in questo percorso di trasformazione. Ora è il momento di accelerare l’azienda verso l’agilità aziendale. 

 

Tabella di marcia della trasformazione agile #3: Scrum @ Scala

“La complessità è morte”.

Gereon Hermkes

La terza roadmap di trasformazione agile riguarda la semplificazione della scala. Scrum @ Scale significa che un singolo team Scrum è in grado di fornire un valore ottimale a una velocità dimostrabile. Secondo Scrum in scala aiuta il processo “un’organizzazione a concentrare più reti di team Scrum su obiettivi prioritari”. 

Vediamo quindi i passi che Scrum @ Scale compie nel suo modello ripetibile. Ecco i dieci passi semplificati:

1. Nella prima fase, gli Scrum Coach sviluppano un elenco di problemi dell’organizzazione.

2. Da lì, informano l’alta dirigenza e identificano gli obiettivi comuni, ecc. 

3. La terza fase prevede la formazione di un Executive Action Team (EAT), noto anche come Transformation Leadership Team.

4. Il passo successivo consiste nel selezionare un team di leadership che stabilisca le priorità di tutto il lavoro. In altre parole, il Team MetaScrum Esecutivo.

5. Dopo la formazione, si passa alla quinta fase. In questo caso, tutti i membri del team, i product owner, gli scrum master, i manager ecc. che lavoreranno all’interno del sistema operativo agile vengono formati dall’EAT.

6. Il sesto passo riguarda il backlog del proprietario del prodotto.

7. Il settimo passo passa rapidamente a un La mischia delle mischie con scrum giornalieri scalati.

8. L’ottavo passo significa consegnare presto e spesso.

9. Il passo finale è l’estensione del sistema operativo agile alla prossima serie di priorità prima del passo dieci…

10. Ripeti!

 

Roadmap di trasformazione agile n. 4: Product manager: una roadmap agile disciplinata

“La gestione dei prodotti lama di processo comprende l’identificazione e l’evoluzione della visione aziendale della tua organizzazione”.

PMI.org

Le roadmap nella gestione dei prodotti descrivono le visioni per tre periodi di tempo: a breve termine, a medio termine (3-12 mesi) e a lungo termine (un anno). Le roadmap vengono utilizzate dai product manager per dare priorità alle decisioni e per pianificare le attività. Ecco altri fattori di processo che devono essere presi in considerazione:

1. I product manager vogliono fornire prodotti che aggiungano valore all’azienda.
2. A causa di un budget limitato, c’è anche solo un numero limitato di prodotti, il che significa che è necessario dare una priorità.
3. La roadmap viene sviluppata attraverso le attività di product management.
4. Le funzionalità, chiamate anche risultati, epopee, storie e così via, devono essere assegnate ai team per l’implementazione.
5. La commercializzazione dei prodotti ai clienti è gestita dal product manager per aumentare la possibilità che i potenziali clienti vengano a conoscenza dell’esistenza del prodotto.
6. I product manager monitorano il successo dei loro prodotti in base alla soddisfazione degli utenti finali, ai tassi di accettazione del mercato, ecc.

Come puoi vedere, questo processo si concentra sullo sviluppo dei prodotti giusti al momento giusto per garantire che vengano utilizzati. 

 

Tabella di marcia della trasformazione agile #5: Scrum su larga scala

“Il desiderio su larga scala fa la storia”.

Don DeLillo

A differenza degli altri schemi di cui abbiamo parlato, non c’è un Scrum su larga scala nessuna vera e propria tabella di marcia. Al contrario, il Product Backlog di Scrum viene creato dal Product Owner e dal team. A seconda delle dimensioni, possono essere necessarie settimane o mesi di workshop di analisi e di stima delle prime release. 

Per un prodotto consolidato, non dovrebbero esserci ricerche approfondite per la prossima release, in quanto il proprietario del prodotto e il team dovrebbero creare un backlog del prodotto in ogni sprint. Pertanto, grazie allo sviluppo continuo del prodotto, una roadmap in quanto tale non è necessaria.

Scrum su larga scala conosciuto anche come il Quadro LeSS Il processo di sviluppo agile inizia con la comprensione di Scrum da parte del team. Affinché LeSS prenda piede, lo sviluppo agile con Scrum deve richiedere un profondo cambiamento organizzativo per diventare agile.

Mettiamo in pratica questa struttura organizzativa come una versione scalata di One-Team Scrum:

LeSS sovrappone due diversi framework Scrum su larga scala:

1. LeSS: otto team
2. LeSS Huge: fino a qualche migliaio di persone su un prodotto

Di seguito ci concentreremo sul quadro LeSS.

1. Pianificazione dello sprint Parte 1: coinvolge membri di tutti i team: discutono dove appartengono e quali sono le opportunità per trovare un lavoro comune.

2. Pianificazione degli sprint parte 2: ogni team li svolge in modo indipendente, anche se a volte due o più team possono svolgerli nella stessa stanza.

3. Scrum giornaliero: ogni team tiene anche questo in modo indipendente.

4. Raffinamento generale del backlog di prodotto (PBR): si tratta di una riunione tenuta da un Product Owner e da tutti i team per aumentare l’allineamento con il PO e i team. Lo scopo è decidere quali team implementeranno quali elementi e, quindi, la selezione degli elementi per un successivo PBR dettagliato del singolo team. 

5. Rifinitura del catalogo prodotti: La differenza tra questa fase e la precedente è che in LeSS è necessario un solo team alla volta, ma una variante può essere il PBR a più team, in cui diversi team vengono tenuti nella stessa stanza per aumentare l’apprendimento.

6. Riunione di sprint: include persone di tutti i team, non solo il proprietario del prodotto. Lo scopo è quello di rivedere l’incremento del prodotto e i nuovi elementi. Vedila in questo modo: Una grande stanza con molte aree occupate dai membri del team in cui vengono discussi e mostrati gli elementi sviluppati.

7. Retrospettiva complessiva: include il Product Owner, lo Scrum Master e rappresentanti a rotazione di ciascun team. Lo scopo è quello di migliorare il sistema nel suo complesso.

”La destinazione è più importante del viaggio”. 

Less.works

Tutte le roadmap di trasformazione Agile che abbiamo esaminato presentano alcuni passaggi comuni. Abbiamo riassunto i cinque passi comuni essenziali che dovrebbero essere presenti in ogni roadmap:

1. Visione: senza una visione, non può esserci azione. Come afferma Kotter nel suo libro rivoluzionario “Leading Change”, la visione e la strategia consentono di sviluppare una base per il cambiamento. Quando è presente una visione chiara e composta, il tuo team capirà perché lo stai invitando a cambiare. Potrebbe essere difficile all’inizio, ma poi il passo successivo porterà alla collaborazione. Una dichiarazione di visione può trasportare facilmente il messaggio del “perché”. 

2. Preparare la leadership: Motivare gli altri al cambiamento è fondamentale per il successo di qualsiasi ciclo. La costruzione di un team funzionante richiede la comprensione e la collaborazione della leadership prima di qualsiasi altra cosa. 

3. Organizza in base al valore: per un successo iniziale, devi organizzarti in base al valore. Ciò significa che lo sviluppo della roadmap ha metriche centrali - flussi di valore del cliente - come guida. Per implementare qualsiasi strategia, il valore del cliente deve essere al centro. 

4. Prepara e sviluppa i tuoi team attraverso gli ambasciatori: la cultura è una delle sfide più grandi nella scalabilità dei metodi agili. Per diffondere la visione e il modo di lavorare agile in tutta l’organizzazione, è necessario sviluppare team forti. Non si tratta di creare un’organizzazione diversa, ma di assicurarsi che un numero sufficiente di persone all’interno dell’organizzazione sia pronto per il cambiamento dei team. È importante ricordare che non si raggiungerà mai il numero di 100 % di personale. Raggiungerai il punto di svolta quando raggiungerai i 30% che hanno maggiore influenza. Questi 30% accelereranno il cambiamento del resto del team.

5. Incontra regolarmente ed esegui iterazioni attraverso le retrospettive: deve esserci una struttura per fornire feedback. Pertanto, è sempre importante tenere retrospettive alla fine di un ciclo per vedere cosa è andato bene e cosa non è andato bene. È anche utile per alimentare il successo di una roadmap e vedere come si sono sentiti i team e se tutti sono ancora allineati con la vision. Sì, puoi e dovresti persino iterare sulla vision!

A proposito, per aiutarti a costruire e far crescere team di successo, ti invitiamo a dare un’occhiata al nostro articolo con 4 strategie di partenza per la tua trasformazione guardare. E poi, naturalmente…