Skip to main content

Scrum, Kanban, Lean... e ora SAFe®. Come project manager, ho lavorato in organizzazioni grandi e piccole, da imprese globali a start-up, utilizzando agile, Scrum e molti altri metodi di project management. Ho imparato che quando un'organizzazione cresce e c'è bisogno di aggiungere più team o di allinearli meglio per fornire prodotti e servizi, SAFe diventa la star della festa.

illustrazione di metodologie di project management come emoji a una festa con l'arrivo di SAFe
Metodologie e framework di project management come Kanban, Scrum e SAFe a una festa in casa.

Cos'è il Scaled Agile Framework®?

Secondo Scaled Agile, “Il Scaled Agile Framework® (SAFe) è un sistema per implementare pratiche Agile, Lean e DevOps su larga scala”. Come suggerisce, è un framework che può essere utilizzato per aiutare le organizzazioni ad adattare i propri processi e flussi di lavoro agili man mano che l'organizzazione cresce.

Può essere utilizzato da organizzazioni che già adottano framework agili come Scrum o Lean, oppure da organizzazioni che cercano un modo per scalare i propri processi DevOps per supportare tutta la struttura. SAFe può aiutare le aziende ad allineare team di sviluppo e team di progetto per fornire maggior valore ai clienti.

Unlock for Free

Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.

Step 1 of 2

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form

Perché SAFe® è utile? 

SAFe offre alle organizzazioni una linea guida (o roadmap) per accompagnarle nel loro percorso di crescita. Introduce il framework dai team a livello operativo fino al management di alto livello, ossia il portfolio o il livello di programma. 

Insieme alla roadmap, le organizzazioni possono seguire corsi di formazione dedicati. SAFe propone una solida base di conoscenza per ruoli agili specifici come Scrum Master, Product Owner, Architetti e per l'intero team agile.

Un'infografica della roadmap SAFe.
La roadmap SAFe che guida un'organizzazione nell'adozione del framework. © Scaled Agile, Inc.

SAFe® è una metodologia o un framework?

Come già suggerisce il nome stesso, SAFe è un framework altamente adattabile. Essendo attualmente utilizzato da almeno 1.000.000 di professionisti e 20.000 imprese nel mondo, difficilmente avrebbe riscosso tanto successo e diffusione globale se fosse stato una metodologia rigida.

Detto ciò, questa è una domanda molto comune, perché nel linguaggio quotidiano metodologia e framework spesso vengono usati come sinonimi. Per sostenere la mia risposta, è utile tenere a mente le parole di Michael Wood dal suo articolo su metodologie versus framework:

In generale, i framework creano una struttura di cosa fare ma lasciano a chi realizza il compito di determinare il modo migliore per portare a termine il “cosa”, mentre una metodologia dettaglia tutto: cosa fare, quando farlo, come farlo e perché.

Michael Wood
Join the DPM community for access to exclusive content, practical templates, member-only events, and weekly leadership insights - it’s free to join. <br><br>

Join the DPM community for access to exclusive content, practical templates, member-only events, and weekly leadership insights - it’s free to join.

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form

I principi di SAFe®

Poiché SAFe permette alle organizzazioni di scalare l’agilità man mano che queste crescono, le sue fondamenta si basano su agile, sviluppo prodotto snello e pensiero sistemico per offrire linee guida non solo per un team agile, ma per "team di team".

Esistono 10 principi lean-agile su cui si fonda il framework:

  1. Adottare una visione economica: Si concentra sul concetto di fornire valore ai clienti in modo tempestivo e frequente. Adottare una visione economica evidenzia anche la necessità di considerare tutti i costi (rischio, produzione, operativi, sviluppo) e di operare entro limiti di budget approvati
  2. Applicare il pensiero sistemico: Richiede la comprensione dei sistemi in cui l’organizzazione che crea la soluzione è un sistema, così come la soluzione stessa (il progetto, il prodotto) è un sistema.
  3. Assumere variabilità; preservare le opzioni: Si basa sul concetto di non decidere subito su un unico design/insieme di requisiti nelle prime fasi di sviluppo, ma piuttosto mantenere un insieme di design/requisiti e utilizzare dati reali (da esperimenti/test) per restringere le opzioni.
  4. Costruire in modo incrementale con cicli di apprendimento rapidi e integrati: Segue il concetto di consegnare il lavoro in piccole parti (più frequenti) e costruire su quanto già realizzato in precedenza.
  5. Basare le milestone su valutazioni oggettive di sistemi funzionanti: Valutare il lavoro in corso di sviluppo in diversi momenti durante il ciclo agile, per determinare se ciò che viene sviluppato fornirà beneficio economico e sarà idoneo all'uso.
  6. Visualizzare e limitare il lavoro in corso (WIP), ridurre le dimensioni dei batch e gestire la lunghezza delle code: Come suggerisce il principio, si concentra sul mettere un limite al lavoro assegnato a persone o team in un dato momento (per non sovraccaricare e garantire un flusso costante sia nel lavoro che nelle consegne).
  7. Applicare la cadenza; sincronizzarsi con una pianificazione cross-domain: Seguire uno schema di allineamento con altri per la pianificazione tra team.
  8. Sbloccare la motivazione intrinseca dei lavoratori della conoscenza: Comprendere la necessità di fornire autonomia, limiti chiari e ostacoli, e creare una cultura coinvolgente per i membri del team.
  9. Decentralizzare il processo decisionale: Per agire rapidamente e consegnare più frequentemente è necessario che le decisioni vengano decentralizzate, permettendo a chi è più vicino all'argomento di decidere.
  10. Organizzare intorno al valore: Invece di organizzare i team attorno a funzioni specifiche (esempio: design, testing, ecc.), organizza team cross-funzionali e orientati al valore per il cliente e l’impresa.

Come implementare lo Scaled Agile Framework® 

Passo 1: Avere il giusto mindset

Per iniziare a implementare SAFe, un’organizzazione deve avere il desiderio di migliorare la propria agilità aziendale e la volontà di adottare una mentalità Lean-Agile.

Lean-Agile unisce convinzioni, principi e azioni del Manifesto Agile e del pensiero Lean. È la trasformazione da una mentalità fissa a una mentalità di crescita, in cui i professionisti sono pronti a sperimentare, lasciarsi ispirare dagli altri, esplorare opportunità, affrontare sfide e abbracciare gli errori.

L'obiettivo del Lean è fornire il massimo valore ai clienti nel minor tempo possibile e alla qualità più elevata. Il pensiero Lean può essere così definito:

  • Specificare il valore del prodotto
  • Definire un value stream per ogni prodotto
  • Creare un flusso di valore senza interruzioni
  • Consentire al cliente di "tirare" il valore
  • Perseguire la perfezione

Passo 2: Definire un value stream 

Un value stream è una serie di passaggi (e componenti organizzativi) necessari per fornire valore a un cliente—dal trigger iniziale fino alla ricezione del prodotto o servizio finale. È estremamente importante nell’implementazione di SAFe.

SAFe si concentra sull’ottimizzazione del value stream per offrire un flusso continuo di valore, organizzando le persone intorno ai value stream in modo che persone e team lavorino insieme senza silos o segmenti.

Ad esempio, se un’azienda crea tazze da caffè in ceramica personalizzate e le vende sul proprio sito web, un value stream potrebbe essere così:

safe value stream example showing the flow of creating and shipping mugs
gif of the finished mug in the value stream example
Esempio di value stream, che porta alla tazza finita.

Nell’esempio sopra, tutti i processi necessari a fornire valore dal momento in cui il cliente effettua l’ordine della tazza fino a quando riceve la spedizione sono organizzati per garantire la continuità del flusso di valore.

Fase 3: Configurazione dell’Agile Release Train (ART)

Un Agile Release Train (ART) è una combinazione di più team agili. Sono costruiti attorno a un flusso di valore e sono tenuti a fornire valore in modo continuo costruendo soluzioni che apportano benefici agli utenti finali e al cliente.

SAFe ruota attorno al coordinamento di più team agili, e un ART comprende tutte le persone necessarie per sviluppare, testare e distribuire il prodotto o servizio. Di solito è composto da 50 a 125 persone, oppure da 10 a 12 diversi team agili (con una dimensione di team di 8-10 persone ciascuno).

Un ART è interfunzionale e comprende tutte le persone e le risorse organizzative necessarie per sviluppare, costruire e consegnare un insieme completo di prodotti o servizi a un cliente. A seconda delle dimensioni dell'organizzazione, possono esserci più ART (si pensi a grandi organizzazioni con oltre 500 persone).

Fase 4: Definizione dei vari ruoli in SAFe®

Come in qualsiasi struttura organizzativa, sono necessari alcuni ruoli che devono essere assegnati. In SAFe, a livello di singolo team agile, i ruoli sono simili a quelli di un piccolo team agile ma con alcuni ruoli e stakeholder aggiuntivi:

  • Scrum Master: facilita le cerimonie agile e rimuove eventuali impedimenti
  • Product Owner: è responsabile del product backlog e delle priorità degli elementi in esso contenuti
  • Membri dello Scrum Team: portano a termine gli elementi prioritari del backlog e i deliverable per generare valore per i clienti
  • Release Train Engineer (RTE): In SAFe ART, è il program manager e coordinatore dei team agili
  • System Architect/Engineers: Sia nelle organizzazioni tecniche che non tecniche, gli architect e gli ingegneri dei sistemi supportano lo sviluppo del prodotto o del software fornendo una solida base architetturale per la soluzione

Fase 5: Preparazione di un program backlog per l’Agile Release Train

Hai configurato il tuo ART e ora disponi di diversi team agili. Per aiutare a coordinare ciò che viene sviluppato o realizzato, crea un program backlog.

Un program backlog conterrà le funzionalità, gli epic, le user story, il lavoro relativo alle funzionalità e all’architettura (sistemi) necessario per supportare il flusso di valore e fornire valore ai clienti. 

Avere un backlog comune richiederà il contributo di molti ruoli dell’ART come il Release Train Engineer, i Product Owner, e altri ruoli come il product management e i leader dell’organizzazione. Un product backlog sarà inoltre utile nella fase successiva di implementazione per definire chi lavora su cosa e quando.

Fase 6: Pianificazione dell’Incremento di Programma (PI) e ART Sync

Nell’ultima fase, è necessario pianificare chi svolge il lavoro e quando. In SAFe, questo evento si chiama Program Increment (PI) Planning. Punto centrale di SAFe, viene realizzato regolarmente ed è un’opportunità di allineamento con l’intero ART.

Un PI può durare quanto desiderato dall’organizzazione, ma in genere è di 3 mesi (12 settimane). Questo consente di pianificare 6 sprint da 2 settimane ciascuno. Tipicamente questa pianificazione avviene con la partecipazione dell’intero ART (sì, tutti i team agili).

A causa della portata, la pianificazione PI è solitamente un evento di due giorni che prevede:

  • Una presentazione del contesto business, degli obiettivi strategici e della missione
  • Sessioni di pianificazione suddivise per team agili in cui ciascun team crea il proprio piano, scegliendo elementi dal backlog comune
  • Presentazione delle bozze di piano di tutti i team agili
  • Revisione da parte del management e discussioni per la risoluzione dei problemi
  • Sessioni di lavoro per adeguare e finalizzare i piani dei singoli team
  • Presentazione dei piani finali e voto di fiducia
  • Revisione dei rischi del programma e rielaborazione dei piani (se necessario)

Dopo il completamento della pianificazione PI, il coordinamento e la collaborazione sono continui. Con regolarità, durante il PI, i rappresentanti dei team agili (il PO e lo Scrum Master), insieme al RTE, si riuniscono per un ART sync per verificare l’avanzamento dei team agili e identificare eventuali dipendenze, problemi o ostacoli che richiedono coordinamento. Questa sincronizzazione può avvenire in qualsiasi momento durante il PI, ma ogni 2 settimane (o alla fine di ciascun sprint o iterazione) rappresenta una buona cadenza.

Quali sono gli strumenti utilizzati in SAFe®?

Dal momento che SAFe si avvale di altre metodologie agili come Scrum e Kanban, esistono numerosi strumenti che possono essere utilizzati per aiutare i team agili a lavorare con SAFe.

Per alcuni strumenti consigliati che possono essere utilizzati per SAFe, inizia con i nostri elenchi di Strumenti Agile e Software di Gestione Progetti Agile.

Poiché si raccomanda che la PI Planning sia un'attività in presenza (faccia a faccia), si consigliano anche i seguenti strumenti:

  • Ampio spazio per eventi in cui tutto l'ART possa riunirsi e lavorare in team
  • Lavatagne o grandi fogli da blocco per presentazioni
  • Pennarelli per lavagna
  • Post-It/Note adesive (utilizzate per rappresentare gli elementi dal backlog del team)
  • Snack & rinfreschi (perché a chi non piacciono gli snack 😊)

SAFe® & Altre Metodologie Agile

Spero che ti sia piaciuta la festa agile e che tu abbia apprezzato il nuovo arrivato, SAFe. Come avrai notato, SAFe ha in realtà molto in comune con alcuni degli altri "ospiti", come Scrum e Lean. È l'inizio di un ottimo rapporto!

Allo stesso modo, se la tua organizzazione sta crescendo e la gestione di più team agile sta diventando complicata, potresti considerare di invitare SAFe alla tua festa. Se hai domande, sentiti libero di contattarmi tramite LinkedIn o Twitter.

Per altre metodologie di project management ibride e strumenti, iscriviti alla newsletter di The Digital Project Manager. Vuoi saperne di più? Guarda la nostra membership!

®SAFe e Scaled Agile Framework sono marchi registrati di Scaled Agile, Inc.