Introduzione
Nell’articolo precedente siamo partiti dai dati raccolti dal Politecnico di Milano in merito all’evoluzione di Agile negli ultimi venti anni. In questa seconda parte cerchiamo di collegare i dati liberi del primo articolo allo State of Agile in cui i dati sono indirizzati attraverso domande specifiche.
Lo State of Agile viene realizzato tramite un survey finalizzato a ottenere una fotografia attuale dello stato dell’adozione di Agile nelle aziende. Impiegheremo lo State of Agile come “specchio” dei risultati accademici, verificando i punti di convergenza che ho riassunto in tre punti chiave.
Robustezza dei benefici
Si evidenzia la robustezza dei benefici su velocità e visibilità. Questo è coerente con il pattern “agile-as-a-tool”, dove pratiche locali migliorano flusso e trasparenza anche senza cambi strutturali.
Fragilità nell’adozione
La fragilità dei benefici appare chiara invece quando l’adozione è solo nominale: i miglioramenti si esauriscono se non c’è passaggio a “agile-as-a-culture”, cioè coerenza di leadership, clima, governance e strategia.
Gli ostacoli
i principali ostacoli a un’adozione piena sono di natura culturale: leadership, silos e allineamento cross-funzionale. Questo è in linea con mancanza di un disegno di configurazione descritto nell’articolo precedente.
Il ciclo dello Hype di Agile
Riprendendo l’ormai famoso Hype Cycle di Gartner, sui cicli di adozione di una tecnologia, ho disegnato l’immagine di figura 1, basandomi sui dati degli State of Agile negli anni. In questo modo, è possibile illustrare l’evoluzione nel tempo di ciò che, a vario titolo, è ricaduto sotto l’ombrello di Agile.

Il cosiddetto “Agile strumentale” (agile-as-a-tool) si è chiaramente declinato su tutte le 5 fasi “obbligatorie” dell’Hype, mentre la “cultura” (agile-as-culture) ha avuto una crescita meno impetuosa e sicuramente più matura.
Guardando ai dati USA, il trend di agile-as-a-culture in questo periodo storico è in deciso rialzo, mentre l’agile-as-a-tool, dopo il peak of expectation, lo segue in modo più o meno parallelo, ma in maniera logica e guidata da quello che è deciso dalla cultura organizzativa.
La situazione italiana
In Italia, azzardando un’adozione ritardata dai 5 ai 10 anni rispetto agli USA, sembrerebbe che ad oggi ci troviamo nella fase di disillusione dell’agile-as-a-tool, quindi nel famoso “Agile non fa per me”. Ci tengo a specificare che sto parlando di cultura organizzativa e non necessariamente di capacità di applicare uno strumento, che è decisamente meno complessa.
Un’altra metafora: shuhari
Una riflessione che è nata dopo un confronto con Francesco Nardoni [1] è che la prima parte del ciclo non sia stata inutile: tutto quello che abbiamo sperimentato, applicato, scilupato, protetto come se fossero le tavole dei comandamenti, in realtà poteva essere immaginato come quello che nelle arti marziali giapponesi viene chiamato Shu.
Nel lessico delle arti marziali viene usato un termine — shuhari — che descrive l’evoluzione dell’apprendimento. La parola è composta da tre elementi: Shu, Ha e Ri.
“Shu” è la fase dell’obbedienza: si custodisce la forma, si imitano i kata del maestro senza deviazioni per costruire base tecnica e disciplina.
“Ha” è la rottura consapevole: dopo aver interiorizzato le forme, si comincia a metterle alla prova, a combinarle e adattarle al contesto, comprendendone i principi.
“Ri” è il superamento: le regole non vengono negate, ma trascese; il praticante agisce con naturalezza, guidato dai principi più che dalle tecniche, e le forme diventano trasparenti.
È un percorso nato nella tradizione giapponese — spesso richiamato in Aikidō — che parla di maturità: dalle regole imitate, ai principi compresi, fino all’espressione libera e coerente con l’intento.
Alistair Cockburn parla anche di kokoro come fase successiva, tradotto come “cuore”, nel senso di completa consapevolezza e interiorizzazione che porta quindi a eliminare tutto ciò che era complicato, per andare alle origini della sapienza.

Shu: “conservare”, “obbedire”
Nel grafico di figura 2, quindi, nello “Shu” la curva sale veloce: l’organizzazione applica metodi, copia i kata di Scrum, Kanban, DevOps, Safe… È il periodo in cui l’hype domina e l’adozione è soprattutto conformità a pratiche chiare e limpide, procedure, framework. È la fase in cui le organizzazioni si aspettano che applicare un framework risolva tutti i problemi. È la fase in cui potevamo etichettare e vendere un prodotto perché era concreto, palpabile, controllabile.
A dire il vero, è stato anche il periodo di di Agile “cosmetico”, in cui si chiedeva di “fare Agile” e non di risolvere un problema: la verità è che si voleva fare Agile senza sapere perché: semplicemente, dovevamo esserlo. Per restare nella metafora delle arti marziali giapponesi, abbiamo quindi allenato moltissime “forme”, anche troppe, senza sapere bene perché o senza capire come esse fossero realmente applicabili.
Ha: “distacco”, “divagazione”
Poi arriva lo “Ha”: la rottura necessaria. Qui la curva scende nella disillusione perché le forme non bastano più. Tutte quelle pratiche probabilmente, non ci servono e tutte quelle regole sembrano limitarci.
Si mettono in discussione gli standard, le tavole dei comandamenti, saltano fuori i limiti dello scaling cosmetico, e diventa evidente che il problema non è lo strumento, ma come lo utilizziamo. Le organizzazioni sentono la mancanza del perché, gli agilisti spingono su temi opposti agli strumenti.
È il pezzo più faticoso: le organizzazioni sono disilluse, dicono che “Agile non fa per noi”. Vengono fatte affermazioni del tipo “Con Agile non ci sono date, ma a me servono”, “Siete un po’ figli dei fiori”, “Non avete KPI”, e tante altre considerazioni scaturite principalmente dalla mancanza di cultura che, a sua volta, ha portato a un uso improprio anche dello strumento stesso che, di fatto, funziona.
Si inizia a definire bene il concetto ripreso dai dati, quindi che agile-as-a-culture è diverso da agile-as-a-tool così come che Agile non è Scrum e Scrum non è Agile.
Scrum (o Safe o quello che preferite) ha una ricetta che va seguita pedissequamente per raggiungere il beneficio desiderato: si “installa” nelle organizzazioni e, tendenzialmente, funziona.
Agile è fatto di soli 4 valori, che sono avvicinabili attraverso 12 principi che a loro volta sono abilitati da comportamenti, liberamente adottabili: è un fatto di cultura, che non si può “installare”.
Sono chiaramente due cose diverse. A dirla tutta, volendo cercare comunque di avvicinarli, nelle enunciazioni del Manifesto, Scrum lo vedo sulla destra pià ché su quanto scritto nella parte sinistra delle frasi… Mi rendo conto che sia un pensiero sovversivo ma, di fatto, resta solo una mia considerazione personale.
Ri: “lasciare”, “separare”
Infine il “Ri” coincide con la risalita: si interiorizzano i principi, si compone un design decisionale coerente, si pensa a partire dalla leadership e l’AI diventa acceleratore dei cicli di apprendimento, abilitatore, catalizzatore e in un futuro non troppo lontano, membro del team spostandosi dalla destra del primo valore Agile, alla sinistra.
Qui la maturità reale prende il largo rispetto allo hype: la linea verde cresce lenta e costante, indipendente dai tool, anzi, alimentata da una coerenza strutturale che rende le pratiche quasi trasparenti.
Conclusioni
Stiamo evolvendo verso uno stato in cui non si “fa Agile”, ma si tende a “lavorare bene”, grazie alla cultura che abbiamo costruito sia da un punto di vista strumentale, imparando quello che ci serve e abbandonando quello che non ha senso per il nostro contesto, sia, ancor di più, da un punto di vista culturale, puntando a leadership, sicurezza psicologica, intelligenza emotiva, product management, contratti agili e tutte quelle tematiche che sono molto care a noi agilisti.
Nel prossimo articolo cercheremo di passare la parola su questi temi alle persone, ascoltando il parere di numerosi operatori del nostro settore.
Riferimenti
[1] La pagina LinkedIn di Francesco Nardoni
https://www.linkedin.com/in/francesconardoni/
[2] Shuhari
https://it.wikipedia.org/wiki/Shuhari
