Che cosa succede a Scrum?

Ogni tanto si leggono affermazioni forti tipo “L’Agile è morto” o “Scrum è finito”. Sono esagerazioni che però mostrano un aspetto interessante: sicuramente, almeno a livello di riflessione teorica e di dibattito tra gli “esperti”, è passata l’epoca d’oro dello scorso decennio in cui era tutto un fiorire di metodologie, libri, tecniche, approfondimenti, variazioni sul tema e così via.

Poi, di fatto, probabilmente mai come oggi certi principi e certe pratiche Agile sono stati così diffusi nel mondo produttivo e Scrum è diventato una delle infrastrutture metodologiche più adottate. Però è vero che, a differenza di anche “solo” dieci anni fa, la spinta evolutiva del mondo Agile in generale e di Scrum in particolare si è affievolita. Del resto, prima o poi, tecnologie, metodi, approcci e prodotti devono raggiungere un loro livello di maturità…

Di Scrum si parla su queste pagine ormai da tre lustri. E, se si andassero a riguardare gli articoli che in questi anni ne hanno parlato, si coglierebbe sicuramente un senso di sviluppo e di cambiamento che, nel tempo, ha portato all’attuale concezione del framework metodologico.

Per rimanere solo agli ultimi anni, il passaggio dalle direttive contenute nella Scrum Guide del 2017 a quelle del 2020 aveva segnato un passaggio piuttosto significativo [1], nonostante alcuni osservatori non avessero invece riscontrato grosse modifiche. È certo però che, se guardiamo alle prime implementazioni di Scrum e poi arriviamo alla versione attuale, le differenze sono tante ed evidenti.

Certo, se andiamo a guardare cosa accade sul campo, si vede ancora, in certi casi, introdurre Scrum nei gruppi di lavoro con la terminologia e l’approccio precedenti al 2020, quando non succede ancora di peggio: qualcuno si ricorda la storia di “uova e prosciutto?”. E, come veniva scritto su un articolo in queste pagine [2], da un lato l’ultima versione della guida [3] aveva il merito di precisare anche terminologicamente tutta una serie di modifiche intervenute nei trent’anni che separano gli inizi di Scrum da oggi, dall’altro essa era diventata un documento estremamente minimalista (14 pagine in tutto nella versione originale inglese in PDF) che si limitava a fornire i concetti e le meccaniche di base. Ma poi, come è evidente, in pochi si limitano ad applicare Scrum solo come descritto nella Guida, dove ad esempio non si parla assolutamente di come fare uno Sprint Planning nel concreto, con le varie tecniche di stima per “pesare” le storie, né tantomeno si suggerisce l’adozione di una lavagna in stile Kanban per gestire il flusso di lavoro durante lo Sprint.

La necessità di un’espansione

Chi  applica Scrum in azienda, anche seguendo strettamente la Guida ufficiale versione 2020, sa che deve necessariamente andare oltre e apportare quelle “personalizzazioni” — non tagli o stravolgimenti — che proprio l’ufficialità delle “regole del gioco” consente e favorisce.

E di questo sono consapevoli gli autori, al punto che è stato rilasciato recentemente (giugno 2025) un documento intitolato Scrum Guide Expansion Pack [4] i cui autori sono Ralph Jocham, John Colemane Jeff Sutherland e che è dichiaratamente basato sulla Guida a Scru scritta da Ken Schwaber e dallo stesso Sutherland.

Già nella lunghezza si capisce che siamo di fronte a qualcosa di “espanso”: è infatti lunga 50 pagine nella versione originale in inglese nel formato PDF. Al momento, non è ancora presente la traduzione in italiano, ma ce ne è una in lingua Klingon, se qualcuno fosse interessato…

A ben guardare, non si tratta certo di un volume corposo come molti manuali o trattati su argomenti simili e affini. Di sicuro è molto più breve della Guida Galattica per Agilisti che fu pubblicata qualche anno fa da MokaByte e che, in un futuro non immediato ma neanche tanto lontano, vedrà la sua nuova edizione riveduta e aggiornata.

Ma torniamo allo Expansion Pack della Guida a Scrum.

Gli argomenti

Da una rapida occhiata all’indice, si capisce subito il tipo di operazione compiuta: non si tratta tanto di tornare ad espandere gli argomenti presenti nella Guida a Scrum, che comunque vengono riproposti, quanto di ampliare la portata della discussione con l’aggiunta di una serie di temi e riflessioni che nella Guida “semplice” non ci sono.

Sono infatti affrontati alcuni argomenti “collaterali”, ma importantissimi, quali il System Thinking e le teorie della complessità, i cicli OODA (Osservare, Orientare, Decidere, Agire) e il ruolo della leadershipo, il Beyond Budgeting e una maggiore focalizzazione sul prodotto, che nella Guida “minimalista” non ci sono.

Qualcosa di nuovo, quindi? Ma in realtà no… viene semplicemente “istituzionalizzato” quanto chi utilizza Scrum e, ancor più, chi lo insegna e lo diffonde all’interno delle organizzazioni, ha sempre fatto. Per tornare alla già citata Guida Galattica per Agilisti, l’idea è proprio quella di non parlare solo delle meccaniche di Scrum, ma anche di tutti quegli aspetti “culturali” sottesi alle metodologie agili e di quelle tecniche “collaterali” che consentono di applicare in maniera più fluida e consapevole le meccaniche del framework metodologico. Per dirlo in modo sbrigativo: se faccio Scrum, è bene anche che sappia creare e usare una Kanban Board e o un Burn Down Chart perché mi aiutano a lavorare meglio. Se imparo come è composto un Team Scrum, magari è bene anche che conosca alcune tipiche dinamiche dei gruppi, o che sia in possesso di determinate soft skills che ci aiutano, per esempio, nello svolgimento della retrospettiva.

Tutte cose che, nella Guida a Scrum ufficiale non ci sono ma, si potrebbe dire, restano sottintese.

Un aiuto per chi applica Scrum…

Esplicitare una serie di argomenti come viene fatto nello Scrum Guide Expansion Pack rappresenta un sicuro vantaggio per chi Scrum deve metterlo in pratica nella propria organizzazione: vediamone brevemente alcuni.

Pensiero sistemico e teorie della complessità

Sono aspetti non presenti nella Guida a Scrum “minimalista”, ma che da sempre rientrano nelle spiegazioni di molti tra coloro che in azienda fanno formazione e coaching agile. Si tratta di argomenti importanti: Scrum non è solo una meccanica da applicare pedissequamente, ma presuppone la consapevolezza sul tipo di contesto complesso del mondo produttivo contemporaneo.

Outcome Done vs. Output Done

Sarà interessante capire come questo concetto verrà tradotto in italiano ma, per il momento, fermiamoci appunto al concetto.

Viene fornita una definizione chiara della differenza tra fonire un risultato in termini di funzionalità prodotte e in termini di necessità realmente risolte all’utente finale. È il solito discorso sulla reale consegna di valore, ma è importante che venga sottolineato e che su questo tema ci sia una riflessione.

Focus sugli stakeholder

Sì, gli stakeholder esistono anche nella versione minimale della Guida a Scrum, ma riconoscere formalmente gli stakeholder come parte dell’equazione affronta un’evidente omissione nelle implementazioni tradizionali di Scrum. Spesso i fallimenti nei progetti gestiti con Scrum sono legati più a una cattiva interazione con gli stakeholder o a problemi organizzativi sistemici, che non a reali disfunzioni del team.

Standard professionali

L’enfasi sulla professionalità e sulla responsabilità fornisce munizioni contro la falsa narrazione che descrive Scrum — e i metodi Agili in generale — come sistemi improvvisati in cui “ognuno fa un po’ quello che gli pare e alla fine ne vien fuori solo confusione”… Questo è un aspetto da non sottovalutare ai fini di una sempre maggiore accetazione e adozione di Scrum.

…ma anche un po’ di criticità

Accanto a una indubbia serie di elementi positivi, lo Scrum Guide Expansion Pack presenta dei punti crticabili o che necessitano comunque di un’attenta riflessione.

Definizioni e gergo

Procede il riordinamento della terminologia già portato molto avanti con la Guida a Scrum versione 2020. Se lì si era passati da Dev Team a Developers, qui la trasformazione continua arrivando a definire Product Developer il vecchio “sviluppatore”.

Un altro ambito a cui fare attenzione, e che anch’esso prosegue il riordinamento del 2020, è quello delle Definition of done che già si erano moltiplicate nella Guida “minimalista”. Tutto questo, se di certo non spaventa chi già adotta Scrum da anni, potrebbe creare un po’ di confusione ai novizi, per cui non è facile assimilare tutte queste diverse sfumature.

Tono prescrittivo

In alcuni casi, ci sono toni prescrittivi abbastanza discutibili. In un passaggio, si arriva a dire (traduzione nostra) che “[…] lo Scrum Master che non è né disposto, né pronto, né in grado di essere un agente di cambiamento dovrebbe dimettersi da Scrum Master”. Come iperbole non è neanche sbagliata, ma il fatto è che, in un’organizzazione disfunzionale, questo tipo di affermazione può essere utilizzata in chiave “politica” per destabilizzare team e persone con la scusa del miglioramento.

Apparente difficoltà di adozione

A ben guardare, la difficoltà è solo apparente, ma è indubbio che, rispetto alla Guida semplice, le cose da imparare contenute in questo Expansion Pack sono di più.

Per organizzazioni che già faticano con i concetti di base di Scrum potrebbe diventare pesante affrontare aspetti ancor più complessi. Questo fatto potrebbe alimentare la narrazione per cui “Agile è troppo complicato e bisogna sapere troppe cose” che spinge i team a tornare ad altri approcci.

Perfezionismo teorico

In maniera speculare, ma con analoghi risultati negativi, i team potrebbero rimanere intrappolati nella ricerca della perfetta padronanza di ogni concetto: tutte le sottigliezze del pensiero sistemico e della teoria della complessità, o le innumerevoli dinamiche relazionali dei gruppi, potrebbero diventare il focus del team, magari sostenuto da qualche consulente che perda di visto lo scopo finale della trasformazione agile, facendo dimenticare il miglioramento empirico. Lo sviluppo del prodotto si blocca mentre i team discutono se hanno compreso correttamente certi principi teorici.

Qualche conclusione sull’Expansion Pack alla Scrum Guide

Questa nuova “versione” della Guida non fa altro che accogliere ufficialmente quanto in molti casi già avveniva nella realtà dei fatti: Scrum “nudo e crudo” è applicato solo in poche, peculiari, realtà; spesso c’è la necessità di una serie di elementi aggiuntivi che gli Agile Coach sanno adeguatamente servire al momento giusto nel percorso di apprendimento. Se non in modo “ufficiale”, l’espansione esisteva già da tempo.

Come sempre accade, accanto a elementi di sicuro valore si dispongono indicazioni che potrebbero trasformarsi addirittura in criticità. L’aumento dell’enfasi sugli aspetti teorici, ad esempio, potrebbe rendere Scrum più vulnerabile alla sostituzione da parte di alternative più semplici come Shape Up o approcci basati su Kanban.

Ma uno Scrum più consapevole e approfondito come quello descritto nello Scrum Guide Expansion Pack non può rappresentare un problema per le organizzazioni che non perdano di vista l’obiettivo principale del loro operare: risolvere i problemi dei clienti in modo sostenibile e profittevole, venendo incontro alle loro necessità.

Nel momento in cui lo strumento diventa più importante del risultato, qualcosa è andato storto e non è tanto questione di documento — o libro o scuola — che si segue, quanto del fatto che si sono perse di vista le basi fin dal principio.

Riferimenti

[1] Francesco Saliola, La nuova Guida Scrum. Niente di nuovo o cambiamento sostanziale?. MokaByte 267, dicembre 2020
https://www.mokabyte.it/2020/12/16/scrumguide2020/

[2] Luigi Mandarino, Fare “il tagliando” a Scrum. A due anni dalla pubblicazione della nuova guida. MokaByte 288, novembre 2022
https://www.mokabyte.it/2022/11/11/tagliandoscrum22/

[3] Scrum Guide
https://scrumguides.org/scrum-guide.html

[4] Scrum Guide Expansion Pack. Evolving Scrum for Modern Product Development
https://scrumexpansion.org