Frameworks di Scaling. esiste un modello che si adatta alla mia organizzazione?

di Tiziano Interlandi e Andrea Feraco

Versione PDF “Pretty”

https://agileitalia.agileforitaly.com/index.html#1_2019

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 è 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

nsomma 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? ……. 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.

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 può funzionare

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à applicano Scrum

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 agilemente giovani

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.

Il copia incolla dei modelli non funziona, se funziona per Spotify non è detto che funzioni da te.

Richiede elevata mastery in ogni ambito agile.

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.