Scalare l'Agile Senza SAFe: Approcci Leggeri per le Organizzazioni d'Ingegneria in Crescita
Ecco un pattern che ho visto svolgersi almeno una dozzina di volte. Una startup cresce da un team a tre o quattro. Il coordinamento diventa caotico. Qualcuno propone SAFe (Scaled Agile Framework) come soluzione. Sei mesi dopo, l'organizzazione d'ingegneria sta annegando in cerimonie di PI Planning, Agile Release Train e definizioni di ruoli che nessuno riesce a tenere a mente. Gli ingegneri trascorrono più tempo in riunioni di allineamento che a scrivere codice.
SAFe risolve un problema reale. Ma per la maggior parte delle organizzazioni d'ingegneria tra 20 e 50 ingegneri, è la soluzione sbagliata — un framework progettato per aziende con centinaia di ingegneri, compresso in un'organizzazione di media scala.
Il Vero Problema che SAFe Cerca di Risolvere
Siamo giusti con SAFe nominando ciò che affronta. Quando si passa da un team a più team, si incontrano problemi di coordinamento che prima non esistevano:
- Dipendenze tra team. Il Team A non può consegnare la sua funzionalità finché il Team B non completa l'API di cui ha bisogno. Nessuno lo scopre fino all'ultimo giorno dello sprint.
- Priorità conflittuali. Il team prodotto dice allo Squad 1 che la funzionalità X è urgente, mentre lo Squad 2 sta lavorando sull'infrastruttura da cui dipende la funzionalità X — ma nessuno ha collegato i punti.
- Codebase e servizi condivisi. Più team che fanno deploy sugli stessi servizi, a volte sovrascrivendo le modifiche degli altri o causando regressioni inattese.
- Allineamento strategico. Ogni team ottimizza per il proprio backlog senza capire come il loro lavoro si connette agli obiettivi trimestrali dell'azienda.
Questi sono problemi reali. Li ho vissuti tutti. La domanda non è se devi affrontarli. È quanta burocrazia è giustificata per la dimensione della tua organizzazione.
Perché SAFe Manca il Bersaglio a Media Scala
SAFe introduce una struttura massiccia: Program Increment, Agile Release Train, Release Train Engineer, System Demo, Solution Train e tutta una tassonomia di ruoli e cerimonie. Per un'organizzazione da 200 ingegneri in sanità o finanza, forse giustificato. Per una startup da 30 ingegneri con quattro squad? Ecco perché è assurdo:
Il sovraccarico cerimoniale è brutale. Il PI Planning da solo è un evento di due giorni ogni 8-12 settimane. Aggiungete preparazione, follow-up e cerimonie continuative, e avete aggiunto giorni di riunioni per trimestre al calendario di ogni ingegnere.
La proliferazione dei ruoli aggiunge costi senza valore. Release Train Engineer, Solution Architect, Epic Owner — in un'organizzazione da 30 persone, questi ruoli o non esistono o sono ricoperti da persone già sotto pressione.
Ottimizza la prevedibilità rispetto alla velocità. Bloccarsi in impegni PI di 10 settimane danneggia attivamente la tua capacità di rispondere ai feedback del mercato.
Scoraggia la comunicazione informale. "È un argomento per lo Scrum of Scrums" diventa un pretesto per non mandare un messaggio Slack alla persona che può sbloccarti adesso.
L'Alternativa Leggera: Cosa Funziona Davvero
Ho visto i seguenti approcci funzionare bene per organizzazioni nel range 20-50 ingegneri. Risolvono gli stessi problemi di coordinamento con una frazione del sovraccarico.
Sync Inter-Team Settimanale (30 minuti)
Un rappresentante di ogni team si unisce a una riunione settimanale. L'agenda è semplice:
- Cosa stai consegnando questa settimana? (2 minuti per team)
- Cosa ti blocca da un altro team? (far emergere le dipendenze)
- Cosa sta cambiando che gli altri dovrebbero sapere? (servizi condivisi, modifiche API, aggiornamenti infra)
Tutto qui. Nessun report di stato. Nessuna percentuale di avanzamento. Se qualcosa necessita di una discussione più approfondita, programmate un follow-up. Il sync serve per far emergere, non per risolvere.
Workshop Trimestrale di Mappatura delle Dipendenze (mezza giornata)
Una volta al trimestre, i tech lead e i product manager mappano il lavoro pianificato per il trimestre successivo su una board condivisa. Non un piano dettagliato — una mappa approssimativa delle dipendenze. Cercate: due team che modificano lo stesso servizio, funzionalità che dipendono da lavoro non prioritizzato, infrastruttura condivisa che nessuno possiede.
Questo è il nucleo utile del PI Planning, spogliato dalla cerimonia. Mezza giornata invece di due giorni. Scrivete le dipendenze su una board Miro, assegnate i proprietari, andate avanti.
Sprint Review Congiunte
Invece che ogni team faccia la propria sprint review in isolamento, fate una sessione demo condivisa ogni due settimane (o mensilmente, a seconda della vostra cadenza). Ogni team mostra cosa ha consegnato. Il pubblico sono gli altri team.
Questo fa tre cose:
- Costruisce comprensione condivisa. Gli ingegneri vedono su cosa stanno lavorando gli altri team e come il prodotto si connette.
- Crea coordinamento informale. "Oh, state costruendo quello? Abbiamo un'esigenza simile — parliamone dopo."
- Eleva la qualità. Quando sai che altri ingegneri vedranno il tuo lavoro, sei più intenzionale su cosa consegni.
Tenetela stretta. 10 minuti per team, massimo. Se le demo si allungano, smettono di essere utili.
Backlog Condivisi per il Lavoro di Piattaforma
Se più team dipendono da infrastruttura condivisa, create un backlog di piattaforma a cui qualsiasi team può contribuire. Non hai ancora bisogno di un team di piattaforma dedicato. Ma hai bisogno di una lista visibile e prioritizzata del lavoro di piattaforma in modo che non si perda nel backlog di funzionalità di ogni team. Assegna un proprietario — di solito un ingegnere senior o un tech lead — per prioritizzare e garantire che il lavoro venga raccolto.
Rituali Inter-Squad
Due pratiche leggere che pagano dividendi sproporzionati:
Tech talk. Ogni due settimane, un ingegnere presenta qualcosa per 20-30 minuti. Un nuovo strumento, una decisione architetturale, un incidente di produzione. Diffonde la conoscenza e costruisce relazioni inter-team.
Partner di review rotativi. Assegna reviewer inter-team per le PR che toccano i servizi condivisi. Questo cattura i problemi di integrazione presto e costruisce familiarità inter-team.
Quando SAFe ha Davvero Senso
Non sono categoricamente contro SAFe. Ci sono contesti in cui il sovraccarico è giustificato:
- Organizzazioni molto grandi (100+ ingegneri) dove il coordinamento informale fisicamente non può scalare
- Industrie regolamentate dove le audit trail, la tracciabilità e la pianificazione documentata sono requisiti di conformità
- Aziende multi-prodotto dove diverse business unit devono coordinare i rilasci
- Organizzazioni con bassa maturità d'ingegneria dove i team hanno bisogno di più struttura, non meno
Ma se sei una startup o scale-up con 20-50 ingegneri e 3-6 team, quasi certamente non ne hai bisogno.
Il Principio alla Base di Tutto Questo
Il principio sottostante è semplice: il coordinamento dovrebbe essere tanto leggero quanto richiede la complessità e non più pesante. Inizia con il processo minimum viable. Se si rompe, aggiungi struttura. Se regge, lascialo stare.
La domanda giusta non è "quale processo dovremmo adottare?" È "qual è la quantità minima di coordinamento che ci permette di consegnare senza rompere il lavoro degli altri?"
In Conectia, i team che costruiamo per startup europee e americane spesso si uniscono esattamente in questa fase di crescita — tre o cinque squad che capiscono come coordinarsi. I nostri ingegneri senior LATAM hanno esperienza di lavoro in configurazioni distribuite multi-team, e portano pattern pratici di coordinamento che non richiedono l'adozione di un framework enterprise per funzionare.
Stai espandendo la tua organizzazione d'ingegneria e hai bisogno di ingegneri che sappiano lavorare tra team? Parla con un CTO — i nostri ingegneri senior si integrano in configurazioni multi-squad e portano esperienza di coordinamento fin dal primo giorno.
