Le organizzazioni oggi stanno adottando nuove metodologie che spaziano in tutta la gamma nella speranza di trovare il miglior vantaggio competitivo per il loro business. Alcuni guardano alle metodologie Agile tradizionali, mentre altri guardano a organizzazioni come Spotify per l'ispirazione. Con così tanti framework, modelli, terminologie e opinioni nello spazio agile, è una sfida per i business leader e i professionisti agili decidere quale approccio sarà più adatto alla loro organizzazione, o anche dove iniziare. In questo articolo, faremo luce sulla relazione tra due di questi approcci: Scrum@Scale®, e il cosiddetto "Modello Spotify".
Alcuni attualmente classificano il Modello Spotify e Scrum@Scale come due framework separati per lo scaling Agile. Eppure, nel 2019, il Registered Scrum@Scale Trainer™ ed ex Agile Coach di Spotify, Henrik Kniberg, ha pubblicato un case study di Scrum@Scale intitolato, "Spotify - a Scrum@Scale Case Study" in cui spiega che il "Modello Spotify" è in realtà solo una prima implementazione di Scrum@Scale.
La domanda rimane: Scrum@Scale e il Modello Spotify sono due approcci diversi allo scaling agile, o il Modello Spotify è solo una prima implementazione di Scrum@Scale? Prima di iniziare, è importante chiarire la distinzione tra un "framework" e un "modello". Secondo il New Oxford American Dictionary, un Framework è "una struttura di supporto essenziale; una struttura di base sottostante un sistema, un concetto o un testo", e un Modello è "un sistema o una cosa usata come esempio da seguire o imitare; un particolare design o una versione di un prodotto."
Il Modello Spotify è stato introdotto per la prima volta nel 2012 quando Henrik Kniberg e Anders Ivarsson hanno pubblicato il white paper, "Scaling Agile @ Spotify." Nel documento, Kniberg e Ivarsson dettagliano l'approccio di Spotify per consentire l'agilità. Dopo la pubblicazione di quel documento, Henrik Kniberg ha commentato in numerose occasioni che il modello Spotify non è un framework - ma piuttosto, rappresenta la visione di Spotify sulla scalabilità da una prospettiva tecnica e culturale.
Come dice Henrik, "Ho passato alcuni anni a lavorare con Spotify e ho pubblicato alcune cose.... Questo è diventato noto come il "Modello Spotify" nel mondo agile, anche se in realtà non era affatto inteso come un quadro generico o "modello". È solo un esempio di come un'azienda lavora."
Il framework Scrum@Scale, invece, è un vero e proprio framework. Scrum@Scale estende naturalmente il nucleo del framework Scrum per fornire risultati migliori in qualsiasi organizzazione. Fornisce l'impalcatura per far crescere organicamente i sistemi e i processi, permettendo alle organizzazioni di raggiungere l'agilità del business e fornire un maggiore impatto. Piuttosto che cercare di applicare una soluzione "one size fits all", Scrum@Scale fornisce un framework leggero e adattabile che ha la capacità di adattarsi al vostro contesto, rendendolo personalizzabile in tutti i settori. Il Dr. Jeff Sutherland, co-creatore di Scrum, ha passato anni a codificare le pratiche principali per lo scaling, con i primi esperimenti per quel framework nel 1983. All'inizio del 2018, Sutherland ha introdotto formalmente la Guida Scrum@Scale alla comunità agile come "il framework per le organizzazioni per sviluppare iterativamente il modo migliore per far funzionare Scrum nel loro contesto."
Il Modello Spotify e Scrum@Scale sono allineati; tuttavia le differenze tra il modello e il framework sono importanti. Per fornire più contesto e storia, abbiamo chiesto al Dr. Jeff Sutherland, co-creatore di Scrum e inventore di Scrum@Scale, e ad Avi Schneier, consulente principale di Scrum Inc. e collaboratore della guida Scrum@Scale, di rispondere ad alcune delle domande più popolari sulla relazione tra Scrum@Scale e il Modello Spotify.
Sutherland: "Il primo prototipo dei miei pensieri sullo scaling che hanno portato alla sintesi finale di Scrum@Scale è stato implementato al Mid-Continent Computer Services nel 1983. Diverse versioni migliorate sono state implementate in diverse aziende fino alla formazione del primo team Scrum nel 1993. Nel 1995, Ken Schwaber ed io abbiamo scritto il primo documento formale su Scrum. Nel 1996, avevamo implementato la prima serie di team basati su questo documento formale su Scrum che aveva tutti i pezzi chiave di quello che oggi conosciamo come Scrum@Scale, compresa un'architettura basata sui componenti. Questa architettura basata sui componenti permetteva alle aziende di costruire la loro organizzazione come costruiscono i loro prodotti. I prototipi di Scrum@Scale erano sul mercato, si evolvevano e si adattavano in centinaia di aziende fino a quando Intel Agile Leadership mi chiese di creare una guida formale di Scrum@Scale. Le prime iterazioni della Guida Scrum@Scale sono state realizzate nel 2014 e codificate a partire dal feedback del mercato reale, e la versione 1.0 è stata formalmente rilasciata nel 2018".
Sutherland: "Oggi i prodotti devono avere un modello di componenti scalabile in modo che ogni pezzo di un sistema possa essere aggiornato quotidianamente senza rompere altri pezzi del sistema. Questa strategia è quella che Saab Technologies usa per costruire aerei da combattimento, Tesla per costruire automobili e Apple per costruire iPad. Per un'organizzazione per costruire con successo tali prodotti e scalare, il loro modello organizzativo deve essere parallelo alla loro implementazione tecnica o non saranno in grado di fare miglioramenti quotidiani in nuove caratteristiche che sono distribuite sul mercato più di una volta al secondo, come ad Amazon. Questa velocità sconvolge intere industrie in settimane. Per esempio, qualche anno fa Amazon ha rapidamente conquistato gran parte del mercato dei prestiti al consumo in Germania".
Schneier: "Questa è in realtà la più grande sfida che vedo quando le organizzazioni adottano Scrum@Scale. L'errore comune è quello di prendere la loro gerarchia esistente e cercare di mappare Scrum@Scale e il modo in cui i team devono organizzarsi su di essa. Questo è problematico. Il modo corretto è, prima, mappare il vostro flusso di valore (s) e poi mappare le persone su di esso. Noi diciamo che per essere Agile su scala, devi essere disposto a rifattorizzare l'organizzazione per ottimizzare la produzione. La resistenza a questo crea solo sprechi".
Sutherland: "Quando Henrik è subentrato come Head Agile/Lean Coach a Spotify, stavano facendo Scrum, tuttavia, gli Scrum Master e i team non stavano performando, così Henrik ha fatto alcuni cambiamenti. Ha cambiato il nome del team in "Squad", ha chiamato i gruppi di team "Tribes" e ha affiancato i team con Agile Coaches per migliorare le prestazioni. I manager erano responsabili dei "Capitoli", che includevano l'assunzione e la formazione di sviluppatori con specifici set di abilità nei team. Henrik ed io insegnavamo insieme Scrum@Scale a Stoccolma, quindi c'era un'alimentazione incrociata reciproca in quel periodo. Quando ero a Stoccolma visitavo Spotify, dove Henrik ed io ci incontravamo con gli Agile Coaches per affrontare questioni critiche. Per esempio, il CEO di Spotify disse a Henrik che i team dovevano consegnare due volte più velocemente per competere con Google e Amazon. Nella nostra riunione di Agile Coaches a Spotify, abbiamo notato che tutti i team stavano già consegnando ogni sprint, ma il modo migliore per raddoppiare la produzione era quello di allenare gli sviluppatori a consegnare ogni singolo giorno, proprio come Google e Amazon. In circa sei mesi avevamo circa ⅓ dei team che consegnavano ogni giorno".
Schneier: "Quello che oggi è conosciuto come il "modello Spotify" in realtà ha poco a che fare con Spotify o con il modo in cui stavano lavorando. Nella maggior parte dei casi, le aziende e i consulenti hanno adottato la terminologia mentre rinunciavano alle strutture chiave, alle pratiche e alla mentalità che hanno permesso a Spotify di funzionare in primo luogo".
Sutherland: "Scrum@Scale è un sistema operativo per tutte le organizzazioni che offre il doppio del valore a metà del costo e permette loro di fornire una vera agilità di business. Si basa sul lavoro con alcune delle più grandi e preziose aziende del mondo. Il doppio del valore in metà tempo è dimostrato in un nuovo documento nella IEEE Digital Library, "Rocket Mortgage Delivers Twice the Value in Half the Time at Scale." Questo documento illustra, passo dopo passo, come anche in una grande implementazione SAFe di successo si può ridurre il tempo di ciclo del 400% implementando Scrum@Scale."
Sutherland: "Scrum@Scale chiarisce l'implementazione di un Executive Action Team e di un MetaScrum Forum che sono fondamentali per un'azienda che vuole fornire un maggiore valore. Questo si rifletterà tipicamente nel prezzo delle azioni o nella valutazione dell'azienda se l'organizzazione è di proprietà privata. Ha anche un'implementazione più rigorosa di Scrum e ci si aspetta che gli Scrum Master siano "Leader che servono". Ciò che Henrik Kniberg ha implementato a Spotify è stato prezioso per l'azienda in quel momento. L'implementazione ha portato Spotify ad un'offerta pubblica ed è stata un'ispirazione per molti sviluppatori agili. Sono stato spesso invitato da Henrik a visitare Spotify per lavorare con gli Agile Coaches per risolvere i loro problemi più difficili.
Come Henrik sottolinea nel suo case study Scrum@Scale, è un'istanza unica di Scrum@Scale adatta al suo tempo e al suo luogo. La direzione di Spotify dice che non lo usa più e nessuno dei creatori del modello è attualmente associato a Spotify. Come dice Marcin Floryan, direttore dell'ingegneria di Spotify, "Non abbiamo inventato questo modello. Spotify è (come ogni buona azienda agile) in rapida evoluzione. Questo articolo è solo un'istantanea del nostro attuale modo di lavorare - un viaggio in corso, non un viaggio completo. Nel momento in cui leggerete questo, le cose saranno già cambiate".
Schneier: "Ci viene spesso chiesto, quando iniziamo a lavorare con un nuovo gruppo di leader aziendali, di implementare le "migliori pratiche". Questo è spesso un'impresa avventata. Prima di tutto, non c'è alcuna garanzia che l'adozione del modo di lavorare di un'altra organizzazione, compresi i modi di lavorare Agile, funzionerà nel vostro contesto. Mentre la maggior parte dei problemi che le aziende affrontano sono comuni, ogni azienda è una combinazione unica di prodotti, ecosistema e cultura. Questo è il motivo per cui l'approccio "one-size-fits-all" è inutile. I migliori risultati si ottengono quando iniziamo ad esaminare il "perché" sottostante una data pratica o framework ha successo e poi sperimentiamo e iteriamo su come funziona nel vostro contesto e cultura. Questo è il motivo per cui Scrum@Scale ha dato prova di sé in una moltitudine di organizzazioni e domini.
In secondo luogo, il concetto di "best practices" implica che non c'è un modo migliore per farlo, e ferma la ricerca organica da parte dell'organizzazione che adotta per trovare effettivamente ciò che funziona meglio per loro. Preferisco i termini "pratiche principali" o "pratiche migliori" per incoraggiare l'adozione e continuare la ricerca. Il rischio principale che un'organizzazione assume adottando il modello Spotify è che non sono Spotify, quindi non solo fallirà, ma impedisce loro di trovare effettivamente un modo migliore per operare".
Sutherland: "I pattern che hanno creato Scrum@Scale sono documentati nel libro dei pattern (Scrum: The Spirit of the Game) e i pattern sono sviluppati da aziende che esistevano decenni prima di Spotify. La cosa principale che prenderei da Spotify è che gli Agile Coaches non sono sufficienti, ma abbiamo bisogno che gli Scrum Master siano Agile Coaches che è quello che stiamo facendo a Scrum Inc. Henrik ha stabilito uno standard formale che gli Agile Coaches hanno un focus totale sul miglioramento dei team. La seconda cosa di valore a Spotify, secondo me, sono i manager come Leader dei Capitoli. I manager assumono, licenziano, formano e motivano le persone in specifiche aree di abilità in tutta l'organizzazione, inoltre, fissano gli standard per gli strumenti, la qualità e le prestazioni in tutta l'organizzazione. Non fanno alcuna gestione diretta giorno per giorno dei loro dipendenti".
Schneier: "Questo modello, anche se non fa formalmente parte di S@S, è una pratica benefica che abbiamo diffuso attraverso le nozioni di Comunità di Pratica e Cerchi della Qualità".
Sutherland: "Il primo prototipo alla Mid-Continent Computer Services nel 1983 aveva Sprint, Backlog, Product Owner, team auto-organizzati, Burndown Charts, ecc. e ha reso la Business Unit ATM la business unit più redditizia entro sei mesi. Questo è ciò che speriamo di vedere in tutte le implementazioni di Scrum@Scale.
La prima implementazione di Scrum@Scale con il modello formale di Scrum pubblicato da Ken e da me è stata fatta in una società internet che è diventata pubblica nel 1996 (Individual Inc.). All'epoca lavoravamo anche con grandi gruppi di team in aziende come Fidelity. Le basi formali di Scrum@Scale sono state ulteriormente sviluppate alla IDX (ora GE Healthcare) durante il 1996-2000. IDX è citata ripetutamente nei modelli di scala descritti in Scrum: The Spirit of the Game. Scrum è esploso con la pubblicazione del Manifesto Agile nel 2001.
Nel 2005, Ken mi ha chiesto di formare tutte le maggiori aziende della Silicon Valley, Yahoo, Google, Adobe e molte altre aziende hanno iniziato lo Scrumming con grandi gruppi di team in quel periodo. Dal 2000-2008, sono stato il CTO di PatientKeeper che aveva uno dei gruppi di lavoro Scrum@Scale più performanti mai documentati. Il MetaScrum è stato perfezionato ulteriormente a PatientKeeper. Entro il 2009, stavo implementando S@S in aziende come Pegasystems che raggiunse risultati incredibili come si era visto nell'implementazione del 1983 al Mid-Continent Computer Services.La documentazione formale di Scrum@Scale è stata fondamentale per la leadership Agile alla Intel e alla SAP e il lavoro fatto dal 2005 con migliaia di team alla Microsoft e Amazon è stato influente. La leadership agile alla SAP, con oltre 2000 team Scrum, ha contribuito a informare la prima versione della Guida Scrum@Scale ed è stata irremovibile sulla necessità di un MetaScrum efficace".
Sutherland: "Come mostrato in dettaglio nel paper menzionato prima, "Rocket Mortgage Delivers Twice the Value at Half the Cost", Scrum@Scale analizza sistematicamente sia le operazioni di business che quelle tecnologiche e implementa i miglioramenti che hanno il massimo impatto costi/benefici. Il primo passo per Rocket Mortgage è stato quello di implementare uno Scrum coerente. Hanno eliminato i 15 ruoli SAFe e li hanno ridotti ai tre ruoli della Guida Scrum. Tutti gli altri ruoli sono stati riqualificati come membri del team o spostati in un'altra area dell'azienda.
Il secondo passo è stato quello di implementare un focus sulla consegna in tutti i ruoli e in tutte le riunioni. I Product Owner dovevano migliorare la consegna del valore per punto. Gli Scrum Master dovevano migliorare le prestazioni del team e quelli che non potevano farlo efficacemente sono stati spostati in altri ruoli nell'azienda. Le riunioni sono state cambiate per concentrarsi totalmente sulla consegna. La loro tempistica, l'ordine del giorno e i partecipanti sono stati cambiati per consegnare un prodotto completamente funzionale in un lasso di tempo sempre più breve fino a raggiungere aggiornamenti quotidiani del prodotto dal vivo.
Ci sono molti altri dettagli nel documento che mostrano alle aziende come possono usare passo dopo passo Scrum@Scale per aumentare le prestazioni, con qualsiasi implementazione agile o framework per scalare preesistente".
Schneier: "Quando date un'occhiata ai primi video e documenti su Spotify di Kniberg, vedrete molta enfasi sul rilascio in modo DevOps. Questo è il modo in cui sono collegati. Proprio come Scrum è agnostico al metodo di consegna, così è Scrum@Scale. Detto questo, se un team Scrum - e quindi un gruppo di team Scrum, o uno Scrum of Scrum come lo chiamiamo noi, è un percorso indipendente verso la produzione, allora potete capire perché sosterremmo un metodo di consegna di tipo DevOps o DevSecOps. È semplicemente il modo più veloce per portare un prodotto funzionante ai vostri clienti".
Se voi, come molti business leader, state cercando risposte su come strutturare i vostri team o scalare Scrum per ottenere migliori risultati di business e agilità, non accontentatevi di adottare ciò che altri hanno provato e aspettarvi gli stessi risultati. Non esiste una soluzione magica chiavi in mano. Ogni organizzazione dovrebbe esaminare regolarmente le sue pratiche, e continuamente evolvere e adattarle man mano che il loro contesto, il mercato e la cultura inevitabilmente cambiano.
Come dice eloquentemente Jeremiah Lee, ex Product Manager di Spotify, "Potresti aver scoperto il modello Spotify perché stavi cercando di capire come strutturare i tuoi team. Non fermatevi qui. Continuate a cercare... potresti scoprire che Spotify nel 2012 non aveva capito come mantenere la velocità e l'agilità di un piccolo team in una grande organizzazione. L'azienda si è evoluta oltre il suo modello e ha guardato fuori di sé per trovare risposte migliori. Dovreste farlo anche voi" (more).
Questo è ciò che Scrum@Scale insegna e che Spotify ha implementato. Come framework, Scrum@Scale fornisce una struttura attraverso una burocrazia minimamente praticabile (MVB) che non vincola la crescita in un modo particolare. Invece, Scrum@Scale permette ad un insieme di team di crescere organicamente, in base ai bisogni unici del sistema, e ad un ritmo sostenibile di cambiamento che può essere meglio accettato dagli individui coinvolti e dall'organizzazione in generale.
Tradotto e adattato da Agileeducation.org. : https://agileeducation.org/spotify-model-scrum-at-scale/
Con Dr. Jeff Sutherland e Avi Schneier | 15 marzo 2022
Vuoi conoscere Scrum? Scegli uno dei componenti del Framework dalla lista e scopri come funziona il framework Agile più diffuso al mondo.