SAFe: Complessità e Sfide nell’Agile Scaling

Uno dei più diffusi framework in ambienti particolarmente complessi che scalano l’agilità, come può essere quello dell’automotive, è SAFe, acronimo di “Scaled Agile Framework”.

Come tutti i framework, SAFe ha i suoi lati positivi e negativi, sta a noi saper sfruttare al meglio quello che abbiamo a disposizione ed utilizzarlo nella maniera più efficace possibile.

Fare un’analisi di tutto il framework è impensabile in uno solo articolo, ci vorrebbe un libro composto da alcune centinaia di pagine.

Vorrei, però, provare a parlare delle critiche più frequenti che ho sentito muovere nei confronti di SAFe e spiegare il motivo di determinate scelte che sono state fatte dagli ideatori del framework.

Prima di andare nello specifico, vediamo cosa significa “scalare l’agilità”.

Cos’è Agile@Scale

Per gestire la comunicazione fra persone di uno stesso team in modo efficace è necessario che la numerosità del gruppo sia tenuta bassa: questo fa sì che le informazioni circolino correttamente fra tutti i membri del team.

Al crescere del numero di persone le interconnessioni crescono esponenzialmente e diventa davvero difficile la loro gestione.

Il consiglio che alcuni agile framework danno (ma che derivano da studi fatti da sociologi) è di non oltrepassare le dieci unità per team.

Se, però, il prodotto sul quale dobbiamo lavorare è tanto complesso da richiedere più di dieci persone per lo sviluppo o produzione come possiamo organizzarci?

Abbiamo bisogno di scalare l’agilità, di gestire e coordinare, cioè, più di un team di piccole dimensioni. Non è pensabile, per i motivi appena evidenziati, far crescere di numero un solo gruppo.

Lo scopo di Agile@Scale è esattamente questo, e negli anni sono stati concepiti e sviluppati diversi framework che ci possono aiutare nell’organizzare il lavoro di decine di persone attorno ad un unico prodotto.

Andiamo adesso nello specifico di SAFe e delle critiche che più frequentemente ho sentito argomentare nei confronti di questo framework.

SAFe è troppo complesso e prescrittivo rispetto ad altri framework

Due dei più famosi Scaled framework sono Nexus e LeSS.

Se pur più semplici essi hanno delle limitazioni che SAFe cerca di superare.

Vediamoli in breve:

Nexus

Nexus è un framework che può essere utilizzato per gestire da tre a nove Scrum Team, cioè team che usano a loro volta Scrum come framework; i ruoli previsti sono:

• Product Owner: un solo prodotto quindi un solo Product Backlog e di conseguenza un solo PO
• Scrum Master: lavora a livello di framework non di team, anche se può ricoprire il ruolo di Scrum Master di uno o più team
• Uno o più membri del Nexus Integration Team: sono responsabili della guida degli Scrum Team in un Nexus durante l’acquisizione, l’implementazione e l’apprendimento di pratiche e strumenti specifici del framework
• Eventi: sono previsti gli stessi eventi di Scrum ma gestiti in maniera un po’ diversa in modo da coordinare il lavoro dei singoli team e da rilasciare un singolo prodotto.

LeSS Scrum

Large-Scale Scrum (LeSS) è un framework che può gestire al massimo otto team; anche in LeSS come in Nexus abbiamo un solo Product Owner che gestisce un unico Product Backlog:

• Product Owner: è l’owner del prodotto, è una sola persona e gestisce il prodotto con un massimo di otto team
• Scrum Master: sono responsabili dell’adozione di LeSS e il loro focus non è su un unico team ma sull’intero sistema organizzativo; è un lavoro full-time e uno SM può servire fino a tre team
• Manager: in LeSS i manager sono opzionali, ma se ci sono il loro ruolo non è più quello di gestire il lavoro giorno per giorno, ma quello di supervisionare il sistema e di migliorare lo sviluppo del prodotto aiutando gli SM a rimuovere gli impediment

LeSS Huge

Se è necessario avere più di otto team per uno stesso prodotto allora si parla di LeSS Huge. In questa situazione c’è un solo PO che coordina gli Area Product Owner (APO), i quali continuano a svolgere il proprio ruolo con un massimo di otto team e sono “proprietari” di un Area Product Backlog.

Come si evince da questa breve descrizione, entrambi i framework hanno una struttura manageriale piuttosto semplice.

La filosofia che c’è dietro SAFe, invece, prevede che esso possa essere utilizzato a tutti i livelli aziendali, a partire da un prodotto con un solo Value Stream ed un solo Agile Release Train (ART)…

…fino a coprire l’intera azienda col suo Portfolio e i suoi manager, compresa la Governance.

Agile Release Train

Un Agile Release Train è una struttura virtuale organizzata attorno ad un flusso di valore; esso può essere formato da cinque a dodici Agile Team.

Se un prodotto è tanto complesso da prevedere più di un Value Stream è possibile creare più ART che lavorano sullo stesso prodotto o solution: in questo caso si parla di Large Solution.

Si può notare come le limitazioni di SAFe per numero di team da coordinare sono ben al di sopra di quelle proposte sia da Nexus sia da LeSS.

Ogni azienda ha un organigramma definito in base alle proprie esigenze (o a quelle che si credono tali perché spesso si tende a “sovra-strutturare” e a complicare le cose pensando di migliorare), mentre SAFe prevede una serie di ruoli propri, diversi da quelli classici, necessari al buon funzionamento del framework.

Come introdurre SAFe

Per evitare che l’introduzione di SAFe sconvolga la struttura dall’oggi al domani ed evitare resistenze da parte del management dovute soprattutto al preconcetto che “cambiare significa perdere il potere o la posizione acquisita”, si parte dalla situazione così com’è e si crea una sorta di mappatura fra quelli che sono gli attuali ruoli aziendali e quelli che servono per avviare una trasformazione e favorire la partenza di un ART: viene così introdotto un secondo sistema che John P. Kotter nel suo libro “Accelerate” chiama “Sistema Operativo Duale”.

Inoltre, per poter dare supporto ad un’intera azienda o anche soltanto ad un ART potrebbe essere necessaria la creazione di System Team, un gruppo, cioè, che aiuta nei momenti di integrazione del lavoro svolto, di sviluppo e aggiornamento dell’architettura sottostante.

È vero che in SAFe abbiamo tante regole, ma non è detto che debbano essere applicate tutte.
Infatti, dipende molto:

• dal livello di adozione del framework
• dal contesto in cui ci troviamo
• dalla maturità e dalla conoscenza aziendale del mindset Agile.

Quel che è certo è che SAFe offre un percorso formativo e di evoluzione a tutti i livelli aziendali che fornisce un supporto soprattutto all’inizio, quando si hanno molti dubbi su cosa fare e da dove iniziare.

Il PI Planning impone una pianificazione lunga tre mesi

Il PI Planning è il cuore pulsante di SAFe, dà una cadenza ed un ritmo all’organizzazione e al lavoro.

Esso è un meeting di circa due giorni che avviene ogni fine Planning Interval (PI) e che vede coinvolto l’intero ART: Business Owner, Stakeholder interni ed esterni, Management, Agile Team, RTE, Architetti e System Team.

Ciò che si contesta a questo evento è di essere anti-Agile a causa della lunga pianificazione prevista.

In realtà non è esattamente così.

Partiamo dal fatto che uno Scrum Team che lavora da solo in linea di massima oltre allo Sprint corrente pianifica in maniera più o meno raffinata uno/due Sprint futuri, ed ipotizzando una lunghezza di Sprint di due settimane (valore molto comune ma non obbligatorio) parliamo di una pianificazione di tre Sprint pari a sei settimane.

Cosa si fa?

Un PI dura dalle otto alle dodici settimane, cioè quattro/sei Iteration (in SAFe lo Sprint è chiamato Iterazione o Iteration). Il framework considera l’ultima Iterazione come una “Iterazione speciale” chiamata IP Iteration (Innovation and Planning Iteration) dove non si fa sviluppo vero e proprio ma piuttosto si fa:

• Completamento di alcuni task o bug urgenti rimati appesi dall’ultima iterazione
• Conclusione della preparazione del prossimo PI Planning
• Sperimentazione per innovazione
• Organizzazione di hackathon
• Corsi di formazione
• Inspect & Adapt del PI che si sta completando
• PI Planning del prossimo PI

Se, dunque, togliamo la IP Iteration dalla pianificazione ce ne restano da tre a cinque: ecco che siamo tornati pressappoco alla pianificazione di un unico Scrum Team.

Il contesto in cui è calato il nostro business e la velocità con cui mutano le condizioni del mercato ci possono guidare nel dimensionamento corretto della durata del PI. Inoltre, in tutto questo ragionamento non dobbiamo dimenticare quattro punti fondamentali:

1. Sullo stesso prodotto lavorano più team che molto probabilmente avranno delle dipendenze: trovarle e sapere in anticipo che esistono ci dà la possibilità di gestirle
2. Durante il PI Planning non c’è tempo di fare una pianificazione dettagliata di tre/cinque iterazioni: è importante dettagliarne bene una o due e completare la pianificazione durante gli Iteration Planning (siamo consapevoli che comunque facciamo le nostre previsioni, le condizioni possono cambiare)
3. In Agile non è importante completare tutte le Storie ma raggiungere gli obiettivi prefissati, perché il nostro scopo è rilasciare valore non funzionalità: focus, dunque, sugli obiettivi individuati durante il PI Planning
4. Una Roadmap ed un Planning di massima a medio e lungo termine li dobbiamo sempre fare, sia che abbiamo un piccolo prodotto sia che ne abbiamo uno più complesso: il PI Planning non fa altro che raffinare il Planning a breve/medio termine, soprattutto pensando al punto 1 (dipendenza fra team)

Da quanto scritto risulta chiaro che SAFe è molto più agile di quanto si crede e non impone lunghe e rigide pianificazioni.

La presenza di un Product Management indebolisce la figura del Product Owner

La figura del Product Owner nel framework Scrum è molto importante e la quantità di lavoro che tale ruolo svolge è davvero rilevante anche con un solo team.

Se proviamo a pensare di quanto possa crescere tale mole di lavoro con un prodotto più grande e complesso, col fatto che il PO deve avere continui contatti con gli stakeholder e contemporaneamente essere disponibile per tutti i team, risulta chiaro che una sola persona non può continuare a fare da sola tutto il lavoro, deve iniziare a delegare; ricordiamo che anche in LeSS esiste un PO ed un APO.

La figura del Product Manager ha esattamente questo ruolo: aiutare i PO nel loro lavoro quotidiano di affiancamento allo sviluppo e di Continuous Exploration con i customer.

Non solo; come mostrato nella Fig. 6 i PM devono avere contatti con tanti altri ruoli, dentro e fuori l’azienda, e sono affiancati quotidianamente dai PO per far arrivare le informazioni a tutte le persone coinvolte nello sviluppo del prodotto.

Il framework SAFe prevede che ogni team abbia il suo PO proprio per i motivi appena descritti, mentre il numero dei Product Manager può variare a seconda delle dimensioni dell’ART; si parla, infatti, di Product Management.

Per facilitare la comunicazione fra PO e PM una regola suggerita nella versione 5 (ma non obbligatoria) era quella di prevede un PM ogni due/quattro PO; nella versione 6 non ci sono suggerimenti espliciti.

Conclusione

In un unico breve articolo non si possono approfondire tutte le tematiche legate ad un framework come SAFe.

Quello che si è fatto è provare a chiarire gli aspetti più controversi, o almeno quelli che, come detto inizialmente, sono ritenuti più critici.

SAFe è un framework complesso? Forse sì, ma anche le grosse aziende lo sono e SAFe cerca di aiutarle a semplificarne l’organizzazione.

È il framework più diffuso fra le big company proprio perché riesce a coniugare anche le esigenze del management, mette insieme il mindset Agile dei piccoli team con quello del Lean Thinking proprio del manufacturing.

È perfetto come strumento? Sicuramente no, e per questo è in continua evoluzione e cerca di soddisfare le esigenze che man mano si vengono a creare in un mondo sempre più complesso e che gira sempre più velocemente.

Autore: Nicola Lobusto – PSM | PSPO | SPC 6.0 | ICP-ATF | KSD | KSI

‎

Contattaci