Scrum su larga scala (LeSS): Una panoramica e un confronto

Immagina di avere 3 team agile che lavorano secondo Scrum e ora vuoi scalare: Scrum non è più sufficiente. Come si procede? Esistono diversi framework, tra cui SAFe Nexus e molti altri. Oggi diamo un’occhiata più da vicino a LeSS.

LeSS è SCRUM (definizione)

Il Quadro LeSS cerca di applicare i principi e gli ideali di Scrum nel contesto di una grande azienda nel modo più semplice possibile attraverso regole e linee guida definite. Grazie alla sua semplicità, LeSS ha ricevuto la definizione, ovvero l’etichetta, di framework “appena sufficiente”, ma questo non deve metterlo in cattiva luce.

7 Vantaggi del quadro LeSS

L’obiettivo fondamentale di LeSS non è quello di creare una nuova struttura. Al contrario, i principi di Scrum vengono applicati a molti team.

Alcuni dei vantaggi che derivano da LeSS possono essere raggiunti sono:

1. Costi di implementazione inferiori implementando le pratiche che i team già utilizzano in Scrum
2. Un proprietario di prodottoche comprende il quadro di riferimento e i principi e poi colma il divario tra l’azienda e i team tecnici.
3. Per il Consegna di un prodotto, meno persone necessario. LeSS non aggiunge altri ruoli e spese generali in modo esponenziale.
4. Offre un vista completa del prodotto nell’area di interesse
5. Il I team sono in contatto diretto con il cliente e le altre parti interessate 
6. Miglioramenti continui sono facilitati da regolari riunioni di retros e di altro tipo, che sono processi fondamentali del Manifesto Agile.
7. Per molte aziende, l’approccio LeSS per la scalabilità dei team Scrum potrebbe essere il passo successivo e logico sulla strada della scalabilità agile.

Come è strutturato LeSS? Una definizione

Per definizione, Large Scale Scrum si basa su principi, strutture, linee guida ed esperimenti. L’illustrazione (fonte: Sito web di LeSS) lo mostra. Spieghiamolo con un esempio: 

Principi: il team X sviluppa un telefono cellulare. Per loro è importante agire in modo trasparente. Pertanto, da un lato lavorano in modo trasparente e tengono dei daily meeting regolari. Inoltre, vogliono scoprire esattamente da dove provengono i materiali importanti per la produzione del telefono cellulare, per poterlo comunicare in seguito ai clienti in modo trasparente. Trasparenza a tutti i livelli, quindi.

condizioni quadro: Allo stesso tempo, lavorano continuamente per creare le condizioni quadro che rendano il framework SCRUM ideale con il valori agili definisce: Apertura, Coraggio, Rispetto, Concentrazione e Impegno.

Principi guida: i principi guida per lo sviluppo sono la visione del prodotto, i requisiti tecnici del prodotto, ma anche il modo di lavorare del team.

Esperimenti: Quando sorgono delle incertezze, ci troviamo nell’area degli esperimenti, dove si tratta di testare e provare. Ad esempio, se vogliamo sviluppare una nuova funzionalità o raggiungere un gruppo target completamente nuovo. (Fonte: Sito web di LeSS)

I 10 principi LeSS

LeSS definito 10 Principi. Aiutano a sviluppare, restando nel nostro esempio, un telefono cellulare che corrisponda il più possibile ai valori e alle idee del cliente. Di seguito è riportato un elenco dei 10 principi in sintesi:

1. Scrum su larga scala è Scrum: Il telefono cellulare può essere sviluppato non solo da uno, ma da più team, in modo che il cliente sia soddisfatto e i tempi di sviluppo siano ragionevoli.
2. Controllo empirico dei processi: Sulla base dell’esperienza a breve termine, le singole funzioni del telefono cellulare vengono continuamente adattate e riviste.
3. Trasparenza: Il nostro Team X decide di condividere apertamente gli obiettivi settimanali del team sulla sua piattaforma interna. Questo aiuta enormemente a capire su cosa ognuno sta effettivamente lavorando.
4. Di più con meno: In sostanza, si dovrebbero sperimentare nuove idee e imparare da esse prima di stabilire regole inerti e quindi aggiungere “zavorra”.
5. Focus sull’intero prodotto: I team hanno una tendenza ancora maggiore a non ottimizzare i propri obiettivi rispetto ai singoli individui. Pertanto, la sfida più grande per i team è quella di integrare il loro lavoro in un prodotto. Lo “scopo” dell’intero prodotto deve quindi essere il più chiaro possibile. I team e i singoli individui sono quindi autorizzati a definire autonomamente i sotto-obiettivi appropriati, se necessario.
6. Centralità del cliente: Solo i team che lavorano direttamente con il cliente possono massimizzare il valore reale del prodotto. Purtroppo le organizzazioni hanno la tendenza a scollegare i team dal cliente non appena iniziano a crescere. Per contrastare questo fenomeno, i clienti vengono regolarmente invitati alle riunioni dei team per fornire un feedback, ad esempio.
7. Miglioramento continuo verso la perfezione: LeSS è un cambiamento profondo per molte organizzazioni. Tieni presente che questo non significa automaticamente un miglioramento. LeSS mette in condizione l’organizzazione di iniziare a migliorare e, da quel momento in poi, si dovrebbe continuare a ottimizzare costantemente. LeSS è un processo!
8. Il pensiero snello: LeSS enfatizza soprattutto la visione del luogo stesso dell’evento (Gemba), il concetto di apprendimento in tre fasi ShuHaRi (Shu = imitare, Ha = variare, Ri = definire le proprie regole) e il rispetto per le persone.
9. Il pensiero sistemico: Tutte le azioni, i cambiamenti e i miglioramenti devono essere sempre pensati in modo sistemico o conforme al sistema per raggiungere gli obiettivi. Esempio: se in un team offro teoricamente dei bonus economici, cosa significa questo per altri team (ovvero, per il resto del sistema organizzativo)?
10. Teoria delle code: L’idea di base è che nel mondo del software creiamo molte code invisibili (ad esempio documenti sui requisiti, software non testato) e non ci preoccupiamo quasi mai del trattamento ottimale di queste code. Ad esempio, sapevi che quando l’utilizzo di una risorsa passa da 50% a 90%, il tempo di attesa per le nuove attività non raddoppia, ma si moltiplica? Quindi definisci i limiti di WIP (work-in-progress), evita il multitasking e i pacchetti di lavoro di grandi dimensioni. 

I quadri LeSS

LeSS offre due configurazioni: LeSS di base per Da due a otto squadre (da 10 a 50 persone) e LeSS Enorme per Più di otto squadre (da 50 a 6.000 persone e oltre).

Fonte: Less.works

Si consiglia di iniziare con LeSS Basic per sperimentare, acquisire esperienza e ottenere feedback prima di passare direttamente a LeSS Huge. Ci sono due approcci suggeriti per introdurre LeSS Huge:

• Inizia con un’area di requisiti alla volta all’interno del prodotto più ampio e concentrati solo su quella all’inizio.
• Oppure ampliare gradualmente l’ambito di lavoro del team, la Definizione di Fatto e la Definizione di Prodotto.

In questo modo, un’azienda può acquisire esperienza di team con LeSS, espandersi in un’area di prodotto, ottenere i primi successi e quindi ottenere il supporto del management prima che LeSS venga scalato in tutta l’azienda.

A proposito, una breve nota nel contesto della trasformazione agile: vuoi essere sicuro di stabilire le giuste priorità nella tua trasformazione agile? 

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

Ruoli e pianificazione in LeSS

LeSS di base si concentra sul team e sui ruoli più importanti di Scrum:

1. Il Product Owner di Scrum, che è responsabile della visione e della direzione del prodotto.
2. i team di sviluppo Scrum responsabili della creazione e della consegna dei prodotti
3. Lo Scrum Master, che supporta il team nel miglioramento continuo.
4. Il ruolo del manager e il modo in cui supporta il team nella rimozione degli ostacoli o “impedimenti” al miglioramento continuo e all’autonomia (estensione di SCRUM).

Huge LeSS integra Basic LeSS con i seguenti ruoli:

1. Il Product Owner regionale di LeSS Huge supporta i Product Owner ed è fondamentale per collegare i requisiti aziendali (finanza, ecc.) con i team di sviluppo.
2. L’Area Product Owner è specializzata in attività orientate al cliente e agisce come product owner per i team di funzionalità orientate al prodotto.

Gli incontri PBR estendono la pianificazione degli sprint alle varie aree di interesse attraverso una serie di esecuzioni parallele degli sprint LeSS. La cadenza continua di questi incontri è necessaria in ogni sprint per comprendere, discutere e perfezionare gli elementi e prepararsi per gli sprint futuri. Le attività principali delle riunioni PBR sono: 

1. Creazione di Epic, ovvero raggruppamento di grandi aree tematiche coerenti; nel nostro esempio, si tratterebbe della fusione degli sprint del team Design & Usability
2. Chiarimento e risposta alle domande aperte: tutti devono avere la stessa comprensione del prodotto e delle idee del cliente e dei colleghi.
3. Stima delle dimensioni della user story, dei rischi e delle dipendenze: Quasi la derivazione e la pianificazione dettagliata dei singoli temi

Il Recensione di Sprint

Equivalente a Scrum: la revisione dello sprint è un incontro alla fine di uno sprint per valutare il lavoro svolto in relazione all’obiettivo dello sprint. Si tratta del prodotto stesso. I progressi vengono resi visibili e vengono identificate nuove aree di intervento. Rende trasparenti i progressi rispetto al prodotto e all’obiettivo.

Il Retrospettiva 

Simile a Scrum: la retrospettiva è una riunione che riguarda la cooperazione del team. Si tratta di migliorare la collaborazione all’interno del team e quindi di migliorare i processi e i contenuti. Riguarda anche l’interazione tra i singoli sviluppatori, il lavoro dello Scrum Master e la comunicazione con il Product Owner. Questo rende la retrospettiva una parte importante del processo di miglioramento continuo (CIP).

In Large Scale Scrum si consiglia talvolta di eseguire una “Retro of Retros”, ovvero a un livello superiore di molti team.

Large Scale Scrum - Rapporto Scrum Master

Quanti team dovrebbe avere uno Scrum Master? Si potrebbe sostenere che uno Scrum Master per team sia la soluzione migliore, anche se questo Svantaggi ha. Di norma il rapporto Large Scale Scrum Master è compreso tra 1:1 e 1:3: uno Scrum Master ha da uno a un massimo di tre team.

Quando Large Scale Scrum LeSS è il metodo Agile giusto?

Large Scale Scrum può essere utilizzato se stai già lavorando con SCRUM e vuoi scalare Scrum. Ma anche per trovare l’equilibrio tra auto-organizzazione e regole. 

Bas Vodde una volta ha detto che lui e Craig Larman Ritengo che LeSS sia un approccio molto valido perché riesce a raggiungere il punto di equilibrio tra la guida necessaria e il minimo indispensabile. 

Come Scrum stesso, si tratta solo di un framework di processo che può essere progettato in modo molto individuale e diversificato dai team che lo utilizzano. Questa argomentazione sembra plausibile e in effetti distingue Large Scale Scrum (LeSS) da altri framework di scaling.

Illustrazione: Punto di forza 

Confronto: Scrum su larga scala contro Scrum

LeSS si basa su Scrum per supportarne l’uso in un contesto più ampio e per scalarlo in organizzazioni più grandi e al di là del singolo team. Non c’è quindi una questione di “o” o “o”. LeSS è l’estensione di SCRUM. Quindi per introdurre LeSS è sempre necessario SCRUM. Ha senso introdurre prima SCRUM e poi passare a LeSS.

Confronto: Scrum su larga scala e Scaled Agile Framework SAFe

Sebbene LeSS stia diventando sempre più popolare nelle aziende con grandi team di sviluppo software, anche altri framework agili scalati come Scrum of Scrum o Scrum @ Scale hanno acquisito importanza. Uno dei principali framework è il Scaled Agile Framework® (SAFe).

Ci sono molte similitudini tra Large Scale Scrum e lo Scaled Agile Framework SAFe®. Ad esempio, entrambi partono dalla scalata di un team Scrum e dall’incorporazione di principi come il pensiero snello, il miglioramento continuo e l’attenzione al cliente. 

3 Differenze fondamentali tra Large Scale Scrum e Scaled Agile Framework SAFe®.

1. Organizzazione: LeSS si concentra sulla semplificazione della struttura organizzativa rimanendo flessibile e adattabile.
2. Ruoli: SAFe prevede ulteriori ruoli (alcuni dicono più “overhead” per questo motivo), tra cui il Release Train Engineer (RTE), il Solution Train Engineer (STE) e gli Epic Owner.
3. Implementazione: Lo Scaled Agile Framework SAFe® contiene processi, artefatti e cambiamenti organizzativi che alcune organizzazioni potrebbero non essere in grado di adottare. Quindi devi sempre valutare quale sia il framework più adatto a te e alla tua organizzazione.

Per un’introduzione di successo di Scrum su larga scala

L’introduzione di successo di Large Scale Scrum richiede di rompere con ipotesi consolidate e di modificare la struttura aziendale, con tutto il potenziale esplosivo a livello di “dirigenza” e la “perdita di immagine” che un cambiamento del genere comporta. 

La base è quindi che tutti siano pronti per questo cambiamento: vedi anche il Modello di gestione del cambiamento secondo Kotter o il nostro articolo sul Tabella di marcia della trasformazione agile .

Crea una visione interessante verso cui lavorare e avvia molti progetti di cambiamento contemporaneamente, nel senso della sperimentazione. 

Quando l’obiettivo originario viene raggiunto, il cambiamento è concluso e l’organizzazione si adegua a un nuovo status quo fino al prossimo cambiamento. 

Questo approccio classico è simile all’approccio sequenziale e “Approccio Big Batch (vedi Figura) dello sviluppo del software, dove le modifiche sono un’eccezione, rigorosamente gestita da organismi di controllo.

Nelle adozioni di LeSS non ci sono change initiatives, quindi nessun change manager. In LeSS il cambiamento è continuo attraverso la sperimentazione e il miglioramento: il cambiamento è lo status quo.

Quali sono le fasi per un’implementazione di successo?

1. cambiare, adattare o modificare la cultura del team

Consigliamo di iniziare prima con un team Scrum, fino a quando il team e l’organizzazione non avranno acquisito un’esperienza sufficiente della nuova cultura agile e i decisori responsabili avvieranno il passo successivo. In questo modo si riduce anche il rischio di uno sviluppo sbagliato.

2. migliorare la cooperazione all’interno dei team

Il lavoro in scala di più team su un unico prodotto richiede l’introduzione di pratiche agili. Sono particolarmente importanti le pratiche che facilitano il coordinamento tra i team. I primi team devono ancora sperimentare molto come pionieri per il resto dell’organizzazione. 

Se i team sono davvero disaccoppiati dal resto dell’organizzazione, possono compiere progressi altrettanto rapidi. Questo può essere fatto più velocemente e con meno rischi all’interno di un contesto gestibile.

3. cambiamenti nella struttura aziendale

Un’ulteriore crescita dell’organizzazione agile significa una ristrutturazione a tutti i livelli. Al più tardi ora, l’iniziatore del cambiamento deve coinvolgere il management. Tutti i livelli tra i team e il vertice aziendale vengono messi in discussione e la struttura organizzativa diventa molto snella. Questa è probabilmente la parte più “dolorosa” del processo, soprattutto per il management.

4. cambiamento della cultura aziendale

Applicando i framework Scrum e LeSS e le pratiche agili appropriate in tutte le aree dell’azienda, si ottiene un apprendimento della cultura agile in tutta l’organizzazione. Il processo non si arresta mai, poiché non esiste un’organizzazione agile ottimale.

Una transizione Agile con Scrum, LeSS e LeSS Huge richiede una strategia lungimirante. Per questo motivo deve essere accompagnata da una consulenza e da una formazione adeguate.

Se sei ancora alla ricerca di una lavagna retrò adatta a te, il nostro articolo può aiutarti a risolvere il problema: Le migliori tavole retrò a confronto.