di Tiziano Interlandi, Andrea Feraco

Esiste un modello che si adatta alla mia organizzazione?

Il grafico che vedete (a destra) è la distribuzione dei framework di scaling che Collabnet Versionone ha raccolto nella sua survey annuale. Ma perché un altro articolo che parla di frameworks di scaling? Nei vari eventi a cui partecipiamo come speakers o ascoltatori si è sempre alla ricerca della panacea alle disfunzioni delle nostre organizzazioni. Le domande sono sempre due: come possiamo far sì che la transizione agile attecchisca e come possiamo scalare verso altre aree. Di fatto stiamo parlando dello stesso problema. Cerchiamo di ritornare alla base cercando di porci le domande giuste prima ancora di trovare risposte. Cosa ci spinge ad adottare Agile? Vogliamo essere più competitivi, pensare prodotti migliori, avere processi più Lean, lavorare meglio, attrarre talenti. Si potrebbe andare avanti con molti altri temi. La seconda domanda è: cosa rallenta o a volte impedisce l’adozione di Agile nelle organizzazioni? La risposta è solo una: tanto più la qualità delle relazioni sociali è buona e tanto più sarà meno difficile questo cambiamento. Usiamo il termine “meno difficile”, perché sarà pur sempre difficile.

Entriamo un secondo nel dettaglio dei punti che compongono la fitta trama delle relazioni sociali all’interno di un’organizzazione. Quando mi relaziono al cambiamento, di fatto, mi pongo le seguenti domande:

• Avrò un ruolo nella nuova organizzazione? • Perderò prestigio?
• Se sono Manager di altre persone,
manterrò questo status?

Di fatto sono domande scomode, tabù, ma sappiamo che sono mosse dalla paura: è umano e normale. Il problema è che nel 99% dei casi queste domande se le pongono coloro i quali fanno parte del Middle Management, ai quali viene affidato, nella pratica, il compito di proseguire la transizione agile. Direi che forse non sono le persone più libere mentalmente per trovare il coraggio di cambiare così radicalmente. Come possiamo cambiare un’organizzazione nella quale forse in futuro non saremo più necessari? Dobbiamo capire che ogni cambiamento richiede che qualcosa venga perso a vantaggio di qualcosa di nuovo. Questo non è solo un bias cognitivo che ci spinge a sabotare cambiamenti di questa portata, ma anche un vero e proprio conflitto di interessi. Premettendo che gli scriventi fanno parte del middle management, come possiamo risolvere questo problema?

Abbiamo capito che partire dal middle management non è l’idea migliore, ci rimangono i due estremi dell’organigramma. Un cambiamento di questo tipo può essere Top Down (come volere del Top Management) o Bottom Up (come volere dei Teams).

Un cambiamento esclusivamente Top Down ha i vantaggi di avere una visione sull’argomento, un budget, una pianificazione, ma ha lo svantaggio di essere visto come l’ennesimo cambiamento imposto dall’alto.

Un cambiamento esclusivamente Bottom Up ha il vantaggio di essere genuino ma ha il problema di essere scomposto ed a volte poco pragmatico.
Adottare un framework di scaling significa fare indirettamente un cambio culturale. Senza cultura nessun cambiamento sarà efficace e duraturo. Spesso si dice cha l’organizzazione segue la cultura, ovvero che la forma della nostra organizzazione è specchio della nostra consapevolezza.

Alla luce di queste considerazioni possiamo dire che l’adozione di un framework di scaling ha le medesime difficoltà legate alle transizioni agili in generale.
Ritorniamo quindi al tema dell’articolo. Come posso scalare agile nella mia organizzazione?

Dividiamo e raccontiamo i vari framework secondo questi parametri:

• Numero di ruoli previsti
• Numero di relazioni necessarie per portare a fine un obiettivo

In un’ottica di questo tipo, oggettiva, possiamo stabilire quali siano i framework che possono aiutare di più il cambiamento dell’intera organizzazione, un cambiamento quindi culturale.
Un alto numero di ruoli implica un cambiamento soltanto in superficie non obbligando le persone ad uscire dalla propria zona di comfort ed in molti casi alimentando il conflitto di interessi espresso prima. Un alto numero di ruoli significa la perdita di prezioso tempo e poca delega nei confronti dei vari livelli aziendali. Poca delega significa limitata libertà di sperimentare. Poca sperimentazione significa limitato miglioramento olistico.

Un numero alto di relazioni per finalizzare gli obiettivi significa mancanza di cross-funzionalità ed un degradamento della qualità generale e la dilatazione dei tempi di delivery di valore verso il cliente.
Troppe regole = bassa responsabilizzazione. Le persone vogliono responsabilità e libertà di espressione.

Con questo articolo presentiamo, senza aver pretesa di essere totalmente esaustivi, alcuni framework di scaling che conosciamo. Ognuno verrà brevemente descritto come processo e ruoli. Ad ognuno daremo pro e contro, ma sta a voi sperimentare e giudicarli relativamente al vostro ecosistema organizzativo. Alcuni sono più efficaci se adottati in tutta l’azienda, altri di più sulla gestione di singole iniziative.

Oggi parleremo di:

  • SAFe
  • Nexus
  • Less
  • Spotify
  • Scrum of Scrums
  • Scrum@Scale Ma cosa dobbiamo scalare?

Ma dove effettivamente ci incartiamo? Ripartiamo da Cynefin.
Un singolo team deve affrontare la complessità legata allo sviluppo prodotto. Quando più team devono collaborare non condividono la stessa “quantità” di complessità, bensì la fanno esplodere esponenzialmente. Se volessimo fare i raffinati potremmo dire che la somma delle complessità locali non è la complessità dell’intero sistema. Quando più team collaborano dobbiamo pensare a:

Intersezioni dei vari backlog
• Priorità dei vari team non necessariamente allineate con quelle aziendali
• Presenza di tecnologia che faciliti il delivery e la qualità (Continuous Integration/Delivery)
• Roadmap condivise
• La presenza di component Teams • Architetture e sistemi legacy

Ma procediamo.

SAFe

SAFe è il framework di scaling più controverso e discusso. Ma perché tante critiche?
Sicuramente è un framework molto ben documentato. Abbiamo quattro livelli di applicazione:

  • Team Level: la reale implementazione
  • Program Level: “Treni” di team sincronizzati verso un obbiettivo comune
  • Large Solution Level: “Treni” di “Treni” di Teams
  • Portfolio Level: come gestiamo budget e la visione strategica aziendale

Intorno a questi livelli abbiamo OGNI pratica che avete sentito in Agile. In questo disegno potete osservare la centralità del cliente (è quello piccolino definito Customer). Forse però nella versione 5 di prossima uscita al cliente sarà data più enfasi! Ogni pratica è ben documentata ed obbligatoria. Ma come possiamo raccontarlo brevemente? Proviamoci.
Un gruppo di persone del Top Management si incontrano di frequente per definire le strategie aziendali. Il budget non è legato a piccoli progetti, ma bensì a Treni. Il Top Management si interroga e quando ha trovato le risposte che cercava dà il via ai treni, ogni treno un prodotto o iniziativa. Ogni Treno è formato da Teams cross-funzionali seguiti da un Capo Treno ed aiutato da un architetto di sistema e da una sorta di super mega PO. Ogni Treno deve pianificare le proprie attività attraverso un PI Program in cui tutti le persone dei team si incontrano per “prendere” le attività, sviscerarle e scoprirne i rischi. Ogni attività ha un valore di business. I Team a questo punto hanno 4 Sprints per finire le attività pianificate ed uno Sprint per completare attività, per integrare quanto sviluppato dai singoli team, e per attività di miglioramento e stabilizzazione del sistema. Super mega Review, si riinizia.

Ecco i ruoli previsti:

• Product Owner
• Scrum Master
• Release Train Engineer
• Product Management
• System Architect/Engineer • Business Owners
• Solution Architect
• Solution Train Engineer
• Solution Management
• Lean Portfolio Management • Epic Owners
• System Team
• Lean UX
• Lean Agile Leaders

Insomma…. ci mancano solo i due leocorni.
Il problema principale, in tutto questo formalismo, è che si mantengono i ruoli precedenti e quindi anche i problemi precedenti. Il ruolo del cliente, come da immagine, è uno dei tanti, andando parecchio in controcorrente rispetto al cuore del manifesto agile. Inoltre l’eccesso di processi e strumenti non lascia ben trasparire il fatto che individui e interazioni debbano venire prima.
Ma allora perché piace? Beh qualunque grande organizzazione riesce a trasporre vecchi ruoli in nuovi ruoli, cambiandone semplicemente il nome. La scala gerarchica è pressoché garantita e così il malumore dei management si placa. Il problema è che non basta scrivere su un cartellone parole come qualità, devops e lean per avere garanzia che ci sia un cambio culturale. Inoltre la percezione di miglioramento sfugge di mano, tutti presi a seguire un processo così ingombrante.
SAFe negli intenti è un ottima idea per scalare in maniera organizzata, ma non si concentra sulla responsabilizzazione e crescita dei singoli. Il PI Planning è una buona idea, ma pensare che grandi organizzazioni Enterprise investano in così tanti costi di gestione (ad esempio le trasferte) è abbastanza lontano dalla realtà.

PRO

  • In organizzazioni molto mature che hanno compreso le basi vere dell’agile può dare una strutturazione che però diventa il mezzo e non il fine.
  • Eseguito “alla lettera” pone molte sfide soprattutto nella zona alta dell’azienda.
  • E’ un’idea per una intera organizzazione e non di un singolo progetto.
  • Tutta l’azienda si deve muovere in una direzione unica, dando spazio quindi a un’evoluzione architetturale consistente come a una progettazione della UX univoca.
  • Si pone la domanda di come gestire il budget, ma non lo risolve del tutto, dà solo una struttura.

CONTRO

  • Troppi ruoli: non va verso la leadership contestuale e tutti i vantaggi che essa comporta .
  • Mantiene eventuali problemi precedenti: non obbligando all’uscita dalla zona di comfort .
  • E’ il processo ad essere al centro e non il cliente né l’individuo.
  • Cerca di formalizzare concetti culturali, ad esempio gli Enabler, ma senza cultura saranno solo atti stilistici che non producono reali miglioramenti

Insomma SAFe rappresenta un tentativo di trasformare un’intera organizzazione, il problema è che è molto idealizzato e lontano dalla vita di tutti giorni. Noi non possiamo dire se sia vera la famosa critica “SAFe is not Agile”, ma di sicuro non è un framework coraggioso adatto ad organizzazioni innovative dove sono le competenze e la leadership di contesto ad essere il fulcro.

Ritornando alle metriche esposte prima, in SAFe abbiamo un numero eccessivo di ruoli e di relazioni obbligatorie che creano centri di potere che non aiutano la cross-funzionalità. Secondo questi parametri SAFe non invoglia a creare innovazione ma tende solo ad evitare che l’entropia prenda il sopravvento. Ma perché viene proposto sempre più di frequente nelle

aziende Enterprise? Sicuramente è un modello più appetibile all’interno di una proposta di consulenza richiesta ad aziende terze. Il problema è che Agile, con i suoi valori e principi, non si può vendere, rimangono solo i processi da mettere in piedi che possono essere fonte di guadagno in caso di consulenza prezzolata. Il grosso problema è che le trasformazioni agile sono qualcosa di intimo con cui le aziende, attraverso una profonda riflessione verso se stesse, provano a cambiare la cultura e non ad introdurre ulteriori processi che altro non fanno che generare lavoro da zero invece di cancellarlo. Insomma Lean fatto un po’ male.

SAFe è di fatto venduto e l’accesso alle informazioni avviene attraverso l’erogazione di corsi a pagamento con relativa certificazione.

In un’ottica di questo tipo è molto difficile che spontaneamente i dipendenti tendano ad approfondire questo Framework, arrivando ad odiarlo e ad identificarlo come un veleno senza antidoto per la transizione. SAFe prende spunto dalle principali metodologie storiche e moderne facendo un mix bello da vedere ma molto difficile da implementare. E’ troppo pesante anche se può mitigare aziende troppo entropiche in relazioni e processi.

In caso di transizione di organizzazioni Enterprise, l’adozione di SAFe può rappresentare uno step verso modelli organizzativi che richiedono maggior maturità.

Cosa ne pensiamo di SAFe? ….insomma

Scrum of Scrums

Questo framework è molto semplice e può essere efficace in caso di iniziative di piccole/medie dimensioni, che hanno necessità di scalare ma non necessitano di particolare coordinazione.

Questa tecnica può funzionare nel caso in cui le dipendenze tra teams siano poche, cercando più che altro di risolvere gli impedimenti.

In sostanza ogni giorno rappresentati dei team coinvolti (dev, scrum master o anche i PO) si incontrano successivamente ai rispettivi daily per verificare se esistano impedimenti o in generale far girare le informazioni al fine di evitare uno scollamento eccessivo.

Non possiamo dire che si tratti realmente di un framework di scaling, è soltanto un modo per tenersi allineati, il fatto di farlo tutti i giorni è sicuramente più efficace del classico SAL, il quale allinea per lo più verso l’alto, ma molto poco potente in caso di forti dipendenze o tanti team coinvolti.

Probabilmente un volta provati altri Framework non userete più Scrum of Scrums, troppo poco per le vostre mire da super trasformatori aziendali.

Molto semplice e non inserisce Poco efficace in caso di forti

PRO

  • Molto semplice e non inserisce nuovi ruoli
  • Focalizzato sugli impedimenti
  • Non richiede particolari conoscenze

CONTRO

  • Poco efficace in caso di forti dipendenze
  • Non tratta la pianificazione
  • Non definisce un PO unico di Riferimento e quindi la ownership viene frastagliata
  • Non affronta il cambiamento culturale aziendale

Cosa ne pensiamo? … da usare in contesti semplici

Scrum@Scale

Ideato da Jeff Sutherland, uno dei due autori della guida Scrum, è definito come scale free. Parte dalla creazione di un ruolo, quello dell’EAT. “La prima sfida è creare un piccolo gruppo di team che implementino bene Scrum. Questo può essere fatto efficacemente creando un Executive Action Team (EAT), responsabile della definizione ed implementazione della strategia di trasformazione. L’EAT deve essere composto da individui con la necessaria autorità, sia politica che finanziaria, per assicurarsi dell’esistenza del modello di riferimento. Questo insieme di persone permette di risolvere gli impedimenti organizzativi che bloccano l’agilità e creare il modello di riferimento di Scrum che funzioni in quel contesto e che possa essere utilizzato come riferimento per l’estensione di Scrum in tutta l’organizzazione.”. Purtroppo la presenza di un comitato o team non garantisce il successo delle trasformazioni. Il sottile gioco tra bottom up e top down richiede una spinta maggiore alla collaborazione piuttosto che l’istituzionalizzazione di un gruppo di persone responsabili che Agile o Scrum vengano applicate e comprese.

Scrum@Scale promette di scalare all’interno dell’organizzazione, mantenendo lo spirito di Scrum ed in maniera efficiente.

Esistono 2 cicli principali :

  • Il ciclo degli Scrum Master: orientato al come
  • Il ciclo dei PO: orientato al cosa

I vari team si coordinano tramite Scrum of Scrums, facilitati da uno Chief Scrum Master. Qui è necessario che siano presenti anche i PO dei vari team e si cerca di essere allineati e trovare rimedio agli impedimenti. Poiché Scale@Scrum cerca di scalare creando livelli successivi di team via via scalati verso l’alto, indipendentemente dalla dimensione dell’organizzazione, si arriva prima o poi ai livelli più alti nella scala manageriale di un’azienda. Per affrontare il tema della gestione dei team manageriali, oltre che degli stakeholder, Scrum@ Scale propone alcuni ruoli aggiuntivi oltre che eventi aggiuntivi. Il Chief Product Owner è una nuova figura che coordina le priorità di tutti i Product Owner che lavorano con i singoli team.


Lo Scrum of Scrums Master serve l’insieme dei team che collaborano al raggiungimento di obiettivi di release o comunque obiettivi condivisi fra più team Lo Scaled Daily Scrum è un evento che vede la partecipazione quotidiana di rappresentanti di team per ispezionare e adattare l’esecuzione dello sprint fra più team che collaborano insieme Infine l’Executive Meta Scrum Team è l’insieme di persone che partecipano all’evento Executive Meta Scrum dove product owner, stakeholders, management si incontrano periodicamente, una volta a Sprint, per allinearsi sulle priorità aziendali.

PRO

  • Molto semplice e non inserisce nuovi ruoli
  • Focalizzato sugli impedimenti
  • Non richiede particolari conoscenze

CONTRO

  • Poco efficace in caso di forti dipendenze
  • Non tratta la pianificazione
  • Non definisce un PO unico di riferimento e quindi la ownership viene frastagliata
  • Non affronta il cambiamento culturale aziendale

Cosa ne pensiamo? … ancora troppo presto per sapere se funziona.

Nexus

Nexus nasce dall’altro autore di Scrum, Ken Schwaber. Nexus nelle intenzioni vuole essere un approccio di scaling molto leggero (la guida è abbastanza sintetica, sulla falsariga della guida Scrum). Possiamo trovare molte similitudine con Less, ad esempio come Less richiede che i diversi team coinvolti partecipino insieme ai vari eventi Scrum: il Planning, la Review e la Retrospettiva.

Nexus “istituzionalizza” il momento del Refinement che sostanzialmente elegge come uno dei momenti più importanti nella vita del Nexus (ossia dell’insieme degli Scrum team). Con una cadenza periodica tutti i team fanno insieme il refinement per analizzare, rivedere, stimare le attività del backlog iniziando ad assegnarle ai team. Nexus prevede una board delle dipendenze (qualcosa di più elaborato la troviamo anche in SAFe), ossia un piano con visibilità di alcuni sprint dove si identifica se alcune attività dipendono da altre. Questa board viene aggiornata ai successivi Refinement da tutti i team insieme.

Con Nexus ci si è voluti focalizzare sul problema dell’integrazione del lavoro di diversi team, problema che si è pensato di risolvere tramite la definizione di un nuovo team, il Nexus Integration Team. Questo team, la cui composizione viene aggiornata sprint dopo sprint in base alle specifiche esigenze, ha l’obiettivo di fare in modo che il lavoro dei diversi team sia sempre integrato. In qualche modo è una forma per una gestione continua dell’integrazione, per rendere effettiva la possibilità di rilasciare software funzionante dopo ogni sprint, diversamente da SAFe che prevede un’integrazione a livello di release con un apposito sprint di integrazione.

PRO

  • A meno del Nexus Integration Team non inserisce nuovi ruoli. Fondamentalmente è un modello Scrum quindi più immediato da capire per team che già lo applicano
  • Pone l’attenzione sul refinement fra tutti i team
  • Gestisce le dipendenze e l’integrazione in maniera continua

CONTRO

  • Introduce delle sovrastrutture, il Nexus Integration Team, team che è complesso da rendere realmente efficace
  • Assume che le dipendenze esistano, non suggerisce come eliminarle ma solo come gestirle.

Cosa ne pensiamo? …. utile per progetti complessi.

Less

Less è il framework di scaling che in realtà cerca di togliere la necessità di scalare alla base. Greg Larman durante un meetup a Milano definì così la propria creatura. Il focus di Less si sposta dal processo alle persone, cercando di aggregare tutto il meglio “presente sul mercato” e cercando di azzerare le strutture sovrabbondanti che ci creano tanti problemi.

Esistono due modalità in Less:

  • Less-> fino ad 8 team
  • Less Huge -> più di 8 Team Less

La focalizzazione è sul prodotto, mantenendo vivo uno dei principi di Scrum. L’attenzione è sulle persone e non sul processo.
I ruoli presenti sono i medesimi di Scrum ed il fulcro è sulla collaborazione. In alcuni aspetti è molto simile a Nexus, come già detto nel relativo paragrafo. Il tutto parte con un Planning Parte 1 dove gli argomenti considerati Ready vengono presentati dal PO e prelevati dai rappresentanti dei team per essere portati al Planning Parte 2. Questa seconda parte del planning è la classica di Scrum. Tutto questo è molto simile a Nexus. Durante lo Sprint avremo un Overall Backlog Refinement in cui delegati dei Team raffinano gli elementi del backlog per arrivare al Planning Parte Uno con le idee più chiare. Ovviamente poi ogni Team Scrum farà il suo refinement come meglio crede. La review è accomunata dal prodotto e sostituisce quella dei singoli teams, come in Nexus. Ogni Team avrà la sua retrospective, ma alla fine i delegati dei team faranno una Overall Retrospective in cui ci si interroga su come migliorare l’intero processo Less. Parliamo di ruoli: non vengono aggiunti ruoli e la coordinazione è data dalla collaborazione spontanea e da Scrum of Scrums tra PO e SM. A tutto questo aggiungiamo tutte le best practice di Agile, come CoP, CI e tutto il resto. In Less Huge ragioniamo su scala più grande Qui abbiamo un Product Owner di Area che cerca di calare priorità/valore alle macro aree composte da Teams che sono raccolti in Less da al massimo 8 Teams. Qui avremo un Backlog di Area che verrà pian paino decomposto e convogliato ai vari backlog più specifici.

PRO

  • Non aggiunge ruoli
  • Semplice da capire
  • possibile calarlo in tutta l’azienda
  • piccolo overhead per la sincronizzazione

CONTRO

  • Non parla di budgeting
  • Richiede alta consapevolezza e maturità, quindi difficile da utilizzare in aziende agilmente giovani

Cosa ne pensiamo? … semplice, mantiene lo spirito di Scrum, basato su competenze e non su ruoli

SPOTIFY MODEL

Inutile negare che il modello Spotify è la Buzzword del momento. Gartner lo ha posizionato come modello da adottare, peccato che non è un modello ma qualcosa che Spotify ha fatto per se stessa.

Spotify nasce con 50 dipendenti ed in breve tempo diventa un colosso, capace di competere in un mercato nascente e con i big. In breve aprono diverse sedi nel mondo aumentando la complessità generale organizzativa.

Se volessimo estremamente semplificare, il modello Spotify è una semplice matrice basata sulla cultura (svedese però).
Il modello prevede….

SQUAD

Un team cross-funzionale classico al più di 9 dev member ed 1 PO. La Squad rilascia continuamente (Continuous Delivery) ed è focalizzato su una piccola e compartimentata parte dell’ecosistema Spotify.

TRIBE

Gruppi di Squad formano Tribe accomunate da obbiettivi specifici (OKR).

CHAPTER

Il chapter è un aggregato di persone cross- squad che nutre lo stesso interesse per un tema specifico. Un esempio potrebbe essere “gli sviluppatori frontend”, che creano una community of practice sul tema.

Ora andiamo sui ruoli

TRIBE LEAD

• Definisce Mission, Strategia e metriche della Tribe

• Budget Tribe
• Rapporti fuori dalla tribe
• Curare la qualità
• Mantenere alto livello pratiche tecniche

PRODUCT OWNER

• Strategia lungo termine prodotto • Fornisce i razionali del business
• Priorità
• Osserva il mercato

• Si allinea con gli altri PO
• Contratti con fornitori esterni

CHAPTER LEAD

Reponsabile dello sviluppo delle persone afferenti al chapter. SI occupa anche di salari. Rimane all’interno delle Squad.

AGILE COACH

• Profonda conoscenza delle pratiche • Gestisce gli impedimenti
• Formatore

SYSTEM OWNER

Il System owner è la persona da cui andare per tematiche relative al sistema. Solitamente è il membro di una squad. Dal momento che il software è “collettivo” è di fatto la persona che dà

l’ok sull’utilizzo o modifiche di parti di architettura considerate delicate.

COME NASCE UNA SQUAD?

La creazione di una squad avviene durante un workshop in cui i PO spiegano le esigenze ed attraverso un “mercato” basato sulle competenze avviene la scelta e la creazione della SQUAD. Per tale motivo le skill matrix sono trasparenti ed aggiornate.

La rotazione delle persone nei team non è frequente (Scrum ama i team stabili).

PRATICHE

Ovviamente Spotify utilizza tutte le pratiche conosciute in ambito agile, da quelle Lean a tutto il mondo Extreme Programming (CI, CD, pratiche di test automatici), il concetto di Review, il Daily.

CONCLUDENDO

Non è un modello di scaling, ma un sano processo Kaizen che Spotify ha messo in atto per crescere organicamente e cogliere le sfide del mercato. Purtroppo qui vale proprio la considerazione che il “copia e incolla” può generare diverse disfunzionalità e purtroppo difficili da prevedere.

PRO

  • Bello davvero, almeno a livello concettuale
  • Copre ogni aspetto di una organizzazione

CONTRO

  • Il copia/incolla dei modelli non funziona, se funziona per Spotify non è detto che funzioni da te.
  • Richiede elevata mastery in ogni ambito agile.

Cosa ne pensiamo? … può ispirarti ma non applicarlo copia/incolla.

Concludendo

Se prendiamo l’analogo report di VisionOne sull’adozione di un framework a livello di team notiamo come Scrum (o leggere variazioni di Scrum) sono adottate da più del 70% dei team.
Nell’immagine presentato all’inizio di questo articolo si vede che il leader è SAFe ma “solo” al 30%. Non ci sono ulteriori dettagli ma è molto plausibile che quel 30% di aziende che dichiara di adottare SAFe in realtà ne faccia un uso abbastanza parziale se non molto personalizzato.

Scrum si impone nettamente come framework di riferimento a livello di team, al contrario in termini di scaling non c’è questa netta preponderanza di SAFe o altri. Potremmo tornare a guardare il Cynefin e ragionare sul fatto che Scrum affronta la complessità ed in buona parte aiuta a risolverla, al contrario la complessità aziendale, troppo specifica di ogni azienda, non trova la sua “formula magica”.
Ogni azienda deve capire cosa è meglio per se stessa. La pratica principale deve essere il Kaizen, ovvero sperimentare per capire e migliorare. Partire piano per capire meglio.
Se Agile è mindset allora non dovrebbe richiedere troppi ruoli e troppe regole. Di sicuro dovreste arrivare ad un modello invece di farvelo vendere.
Ogni Framework presentato può essere applicato in toto o in parte. L’importante è aver compreso il Manifesto e mantenere vivo il suo spirito, al di là della scelta che faremo.