5 framework Agile Scaling a confronto: quale dovresti usare?

Immagina questo: all'inizio di un progetto, riunisci un unico team efficace e interfunzionale di individui impegnati a raggiungere gli obiettivi del prodotto. Per migliorare le prestazioni, assicurati che il team sia esperto in Agile. La domanda per il prodotto cresce, aumentando i requisiti e ampliando l'arretrato. Tu e le altre parti interessate vi rendete conto che il team deve essere ridimensionato. Suona familiare?

Il ridimensionamento consente a più team di collaborare per mantenere la propria agilità. Se c'è più lavoro da fare di quello che il tuo team può gestire in un periodo di tempo ragionevole, è tempo di scalare. Per fare ciò, tuttavia, è necessario selezionare il framework giusto e ce ne sono diversi tra cui scegliere. Scegliere male e l'implementazione potrebbe fallire, interrompendo la produttività e con conseguenti ripercussioni finanziarie significative.

La struttura più adatta al tuo team varia a seconda di fattori quali i finanziamenti disponibili, l'approccio organizzativo e la complessità del prodotto.

Quando dovresti scalare?

Ci sono una serie di criteri chiave da soddisfare prima di prendere in considerazione il ridimensionamento:

Riesci a gestire lo sviluppo con un solo team?

L'implementazione di framework Agile scalati può essere complessa e richiedere molto tempo, quindi non ridimensionare se non è necessario. Quando il carico di lavoro del tuo team supera le sue capacità, è necessario ridimensionare.

La tua squadra è agile?

Forse il criterio più importante è la competenza del tuo team negli approcci Agile. Se il tuo team non ha esperienza in Agile, il ridimensionamento creerà più problemi.

Le pratiche di sviluppo del tuo team hanno bisogno di miglioramenti?

Se le pratiche ingegneristiche del tuo team non sono efficienti, il ridimensionamento potrebbe non produrre i risultati desiderati. Pratiche come la corretta implementazione di DevOps e una pipeline CI/CD sono vitali per la coerenza tra i team. Inoltre, senza una garanzia di qualità standardizzata, potrebbe essere difficile testare nuove funzionalità.

Il tuo team fornisce incrementi integrati?

Il ridimensionamento implica l'integrazione di più team che collaborano sullo stesso prodotto, in cui ogni team produce funzionalità che funzionano insieme. La tabella seguente descrive in dettaglio le quattro possibili configurazioni di team e prodotti. Si noti che solo uno richiede il ridimensionamento.

Scelta di un framework di ridimensionamento

Esistono numerosi framework di scaling Agile tra cui scegliere, ma ci concentreremo su cinque delle soluzioni più utilizzate: Scaled Agile Framework (SAFe), Nexus, Large-Scale Scrum (LeSS), Scrum@Scale e Disciplined Agile (DA) . Ho scoperto che questi sono i framework più efficaci e possono essere applicati a una vasta gamma di scenari e organizzazioni. Le sezioni seguenti ti forniranno le informazioni necessarie per fare la scelta migliore per il tuo contesto di ridimensionamento unico.

1. Framework agile scalato (SAFe)

SAFe è il framework più popolare per il ridimensionamento Agile. Un sondaggio del 2021 ha rilevato che il 37% dei professionisti Agile lo utilizza, in gran parte a causa delle sue molteplici configurazioni, tutte incentrate sui flussi di valore e dotate di guide e procedure ben definite.

Poiché SAFe viene utilizzato per fornire soluzioni complesse che richiedono più di 50 persone, organizza i team in Agile Release Train (ART). Per sincronizzare i team in un ART, SAFe utilizza le iterazioni di incremento del programma, simili agli sprint di Scrum, e ciascuna iterazione dura in genere da 8 a 12 settimane. Questo approccio consente ai product manager di rimanere concentrati sugli obiettivi generali e di supervisionare in modo efficiente una roadmap di prodotti complessa senza introdurre modifiche eccessive.

SAFe si basa sul framework Scrum ma con un paio di differenze fondamentali: l'adozione di SAFe avviene a livello aziendale piuttosto che a livello di team; e mentre Scrum concede al proprietario del prodotto l'autorità esclusiva sulla definizione delle priorità, SAFe incoraggia un approccio più democratico.

SAFe ha quattro livelli di implementazione:

SICUREZZA ESSENZIALE

Essential SAFe è il fondamento di SAFe e deve essere padroneggiato prima di passare a una qualsiasi delle configurazioni successive. Utilizza ruoli Scrum consolidati come Scrum master, product manager e product owner, e introduce anche un nuovo ruolo: release train engineer. Questa persona agisce come un leader del servizio e un allenatore ART, guidando i team ad allineare i propri obiettivi. Ci possono essere da cinque a 12 squadre in un ART, con ogni ART in grado di fornire una soluzione completa.

Grande soluzione

Questa configurazione si trova in cima a Essential SAFe e introduce un concetto chiamato "treno delle soluzioni". Viene utilizzato quando si creano soluzioni grandi e complesse che richiedono il coordinamento di più ART, potenzialmente centinaia o addirittura migliaia di persone, che lavorano sullo stesso flusso di valore. Ad esempio, se lavori in Microsoft e hai tre team separati che programmano Excel, Word e PowerPoint, tutti contribuiscono allo stesso flusso di valore: Microsoft Office.

Portafoglio

Il portfolio è costituito da più ART che lavorano su diversi flussi di valore. Continuando con l'esempio Microsoft: team separati che lavorano sui prodotti Office, Skype o Xbox dell'azienda.

Completamente sicuro

Questa configurazione combina tutti i livelli (Essential, Large Solution e Portfolio) per coordinare la gestione del team a livello aziendale.

2. Nesso

Anche il framework Nexus è basato su Scrum ma è più leggero di SAFe, richiedendo solo piccoli aggiustamenti che facilitino la collaborazione tra da tre a nove team. L'implementazione di Nexus non richiede ruoli aggiuntivi. Piuttosto, un rappresentante di ogni team si unisce a un team di integrazione centrale che allinea il lavoro verso un unico obiettivo. Simile a Scrum, tutti i team si riuniscono per una sessione di pianificazione dello sprint, i cui risultati formano il product backlog condiviso. Per verificare i progressi, ogni team tiene una riunione quotidiana simile a una stand-up e anche il team di integrazione si riunisce per segnalare i progressi del proprio team.

Durante uno sprint, i team partecipano a una sessione di perfezionamento per stabilire la priorità e stimare il backlog. Poiché la complessità della gestione del backlog aumenta con il numero di team, Nexus richiede sessioni di perfezionamento. Le squadre si riuniscono per revisioni e retrospettive dopo ogni sprint.

3. Scrum su larga scala (meno)

LeSS è quasi identico a Nexus, ma presenta piccole differenze, come le convenzioni di denominazione e sessioni di pianificazione dello sprint aggiuntive specifiche per il team. Si differenzia anche per la sua capacità di essere esteso con la sua seconda configurazione, LeSS Huge, che supporta la collaborazione di più di otto team.

LeSS Huge adotta un approccio incentrato sul cliente per organizzare lo sviluppo. Per gestire in modo efficace il lavoro, è necessario che il product owner suddivida il product backlog di alto livello in "arretrati di area" più piccoli di articoli più granulari e poi li ordini ulteriormente, in aree di fabbisogno.

Queste aree dei requisiti sono gestite dagli APO (Area Product Owner). Gli APO sono specializzati nei campi relativi a ciascuna area e lavorano con diversi team su soluzioni per la loro area. Ogni requisito memorizzato nel backlog appartiene solo a un'area dei requisiti e ogni area è gestita da un solo APO. Insieme, il Product Owner e gli APO formano un team responsabile della definizione delle priorità con una visione dell'intero prodotto.

4. Scrum@Scale

Scrum@Scale è un'estensione di Scrum e probabilmente il framework più semplice da imparare e comprendere. Si scala da una squadra a una squadra di squadre.

Un componente fondamentale del framework è Scrum of Scrums (SoS). Ogni squadra sceglie un individuo che la rappresenti nelle riunioni SoS, che di solito si svolgono ogni giorno dopo che la singola squadra si è alzata in piedi. L'obiettivo della riunione SoS di ogni giorno è favorire il coordinamento e la comunicazione tra i team e facilitare la facile gestione di eventuali dipendenze o sovrapposizioni.

I ruoli unici all'interno di questo framework includono il master SoS, essenzialmente una versione in scala di uno Scrum master, e il chief product owner, che lavora con i product owner del team per formare un backlog congiunto per il SoS.

Scrum@Scale è meno prescrittivo di altri framework, consentendo alle organizzazioni di scalare al proprio ritmo. Se il numero di team continua a crescere e le riunioni SoS diventano troppo grandi, le organizzazioni possono intensificare il framework in uno Scrum of Scrum of Scrums (SoSoS).

5. Agile disciplinato (DA)

DA differisce dagli altri framework in quanto agisce più come una cassetta degli attrezzi da cui è possibile scegliere le strategie di ridimensionamento più appropriate, piuttosto che un framework rigido con regole a cui devi obbedire. È un ibrido guidato dal contesto di vari framework, inclusi Scrum e Kanban, che può essere adattato alle esigenze di ogni progetto, incentrato sul principio "La scelta è buona". La DA si basa sull'idea che ogni team e organizzazione è unico per dimensione, distribuzione e dominio, e anche ogni membro del team è unico, con le proprie capacità ed esperienze.

Può essere applicato a livello di team di sviluppo software o a livello aziendale. Per quest'ultimo, il toolkit DA identifica ciò che le varie funzioni aziendali, come finanza, operazioni IT e gestione dei fornitori, dovrebbero affrontare e presenta una gamma di opzioni per farlo.

DA distingue tre fasi del progetto - Inizio, Costruzione e Transizione - e ciascuna comprende obiettivi di processo orientati alla consegna. Poiché questo framework si concentra sull'intero ciclo di vita della consegna, anziché solo sulla build, introduce più ruoli rispetto agli altri framework. I ruoli principali, presenti in ogni team DA, sono stakeholder, membro del team, team lead, product owner e architecture owner. Ci sono anche cinque ruoli di supporto, spesso utilizzati su base temporanea per facilitare la scalabilità: specialista, esperto di dominio, esperto tecnico, tester indipendente e integratore.

DA può essere utilizzato sopra gli altri framework per scalare ulteriormente.

Scegli con attenzione e ridimensiona lentamente

Ridimensionare i team Agile e integrare perfettamente il loro lavoro è difficile, ma può essere semplificato selezionando il framework migliore. Utilizza il diagramma di flusso riportato di seguito come primo passo per guidare il processo decisionale.

Sono certo che troverai il framework di ridimensionamento adatto all'esperienza, all'approccio, al budget e ai prodotti della tua organizzazione tra quelli presentati qui. Qualunque sia il framework scelto, è fondamentale non avere fretta: scalare in modo incrementale per ridurre al minimo le interruzioni e pianificare le modifiche con largo anticipo.

Hai utilizzato questi framework in una delle tue attività di ridimensionamento? Raccontaci le tue esperienze nella sezione commenti.