Cos’è l’Agile Software Manifesto e perché è ancora rilevante nel 2026?
L’Agile Software Manifesto è un documento di 68 parole, firmato l’11 febbraio 2001 da 17 sviluppatori, che definisce 4 valori e 12 principi per uno sviluppo software più leggero e centrato sul cliente (fonte: agilemanifesto.org). Meno di 500 parole in tutto. Eppure, a oltre vent’anni di distanza, è il testo di riferimento citato nel PMBOK, nella Scrum Guide e nel framework Disciplined Agile del PMI.
Personalmente, ogni volta che qualcuno mi chiede da dove cominciare per capire l’agile, la risposta è sempre la stessa: leggiti il Manifesto per intero, non i riassunti. Ci vuole meno di tre minuti. Ma quei tre minuti cambiano il modo in cui si legge qualsiasi metodologia successiva.
Le 68 parole che hanno cambiato l’industria
Il cuore del documento sono i 4 valori. Individui e interazioni sopra processi e strumenti. Software funzionante sopra documentazione esaustiva. Collaborazione col cliente sopra negoziazione contrattuale. Rispondere al cambiamento sopra seguire un piano. Ogni valore è formulato come contrasto, non come divieto: il Manifesto non dice di buttare i processi, dice di mettere le persone prima.
Ma sono i 12 principi a rendere operative quelle idee. Uno dei più citati in assoluto è questo: «Simplicity, the art of maximizing the amount of work not done, is essential» (fonte: pmi.org). In soldoni: fare meno, meglio. Non è pigrizia, è disciplina progettuale. E poi c’è il principio sulle consegne frequenti, quello sulla collaborazione quotidiana tra business e sviluppatori, quello sui ritmi sostenibili nel tempo. Tutti e dodici formano un sistema coerente, non una lista di buone intenzioni.
Un dato che sorprende ancora oggi: Robert C. Martin propose nel 2008 un quinto valore agile, «craftsmanship over execution», nato da una formulazione originale molto più tagliente («craftsmanship over crap»), per ricordare che la qualità del codice non è negoziabile (fonte: theserverside.com). Il Manifesto apre, altri continuano a costruirci sopra.
Da reazione al waterfall a standard globale
Prima del 2001 il modello dominante era il waterfall: requisiti completi in anticipo, fasi sequenziali, documentazione pesante a ogni passaggio. Funzionava bene per costruire ponti. Per lo sviluppo software, molto meno.
I 17 firmatari si riunirono a Snowbird, Utah, non per scrivere un framework, ma per trovare un linguaggio comune intorno a pratiche che ognuno di loro usava già da anni in modo indipendente. Eran pratici, non teorici. E questo si sente nel testo: niente termini tecnici astratti, niente modelli da certificare, niente diagrammi. Solo valori e principi espressi in inglese semplice.
Però il salto da documento di nicchia a standard globale non è stato automatico. Ci sono voluti anni, e soprattutto Scrum e XP come framework concreti che traducevano quei principi in rituali quotidiani. Oggi il Manifesto è richiamato esplicitamente nella Scrum Guide e nei materiali ufficiali del PMI per il Disciplined Agile. Chi studia per una certificazione agile, qualunque essa sia, prima o poi ci torna sopra.
Ma la rilevanza nel 2026 non è solo storica. Il principio che prescrive di accogliere i requisiti che cambiano anche tardi nello sviluppo, perché «agile processes harness change for the customer’s competitive advantage» (fonte: agilealliance.org), descrive esattamente la pressione che vivono oggi i team di prodotto. I mercati cambiano in settimane. I requisiti cambiano in giorni. A conti fatti, il problema che il Manifesto voleva risolvere nel 2001 è diventato più urgente, non meno.
Perché lo sviluppo software pre-2001 stava fallendo?
Il Manifesto Agile nasce come reazione esplicita al modello di sviluppo software document-driven, heavyweight che dominava l’industria, in cui l’eccesso di pianificazione faceva perdere di vista l’obiettivo reale: consegnare qualcosa di utile al cliente. Non è una riforma incrementale. È una rottura.
Il peso del modello document-driven
Negli anni ’90 un progetto software si apriva con mesi di analisi, requisiti scritti su centinaia di pagine, specifiche funzionali rivedute e corrette da comitati di revisione. Prima ancora di scrivere una riga di codice, il team produceva documentazione su documentazione. Il problema è che nel frattempo il mercato cambiava, il cliente cambiava idea, e quei documenti diventavano già obsoleti.
Il risultato? Software consegnato in ritardo. Software fuori budget. Software che il cliente non riconosceva più come proprio, perché i requisiti firmati due anni prima non corrispondevano più a ciò di cui aveva bisogno.
Nei miei anni di formazione in ambito project management ho visto ancora team difendersi con il documento dei requisiti come fosse uno scudo. “Il cliente ha firmato qui.” Vero. Ma il cliente non usava il software che aveva firmato, e questo dovrebbe dire tutto.
I metodi heavyweight non erano irrazionali in astratto. Venivano dall’ingegneria civile, dalla manifattura, da settori dove cambiare un pilone a metà costruzione costa una fortuna. Ma il software non è cemento. Cambiarlo a metà non solo è possibile: spesso è necessario. Ignorarlo significa ignorare la natura stessa del prodotto che si sta costruendo.
E poi c’era il problema della misurazione. In un modello document-driven il progresso si misura in documenti prodotti, milestone formali raggiunte, percentuali di completamento stimate. Non in software funzionante. Il Manifesto Agile avrebbe poi codificato questa critica in un principio netto: «Working software is the primary measure of progress» (fonte: agilealliance.org). Ma nel 1999, pochi lo dicevano ad alta voce.
Cosa cercavano i 17 al Snowbird Resort
La storia ufficiale del Manifesto Agile inizia nel febbraio 2001, in un resort sciistico a Snowbird, Utah (fonte: pmi.org). Diciassette persone, un weekend di sci, e un’agenda informale: capire se i metodi leggeri che ciascuno stava sviluppando per conto proprio avevano qualcosa in comune.
Non era un convegno. Non c’era un programma con keynote e tavole rotonde. Era un incontro tra professionisti che si conoscevano, che si rispettavano, e che avevano ciascuno la propria risposta al problema del software che non funzionava. I firmatari provenivano da mondi diversi: Scrum, Extreme Programming, Pragmatic Programming, Feature Driven Development (fonte: theserverside.com). Metodi nati indipendentemente, in contesti diversi, da persone che non avevano coordinato nulla.
Però avevano tutti lo stesso problema sul tavolo. Il modello dominante non funzionava. Produceva burocrazia invece di risultati. Metteva i processi davanti alle persone, i contratti davanti alla collaborazione, i piani davanti alla capacità di rispondere ai cambiamenti.
A conti fatti, Snowbird non era il punto di arrivo di un movimento organizzato. Era il momento in cui persone che avevano già trovato soluzioni simili si accorgevano di stare parlando la stessa lingua. E decidevano di scriverla.
Quello che uscì da quel weekend non era un manuale. Era quattro valori e dodici principi. Poche pagine. Ma abbastanza per cambiare come si pensa allo sviluppo software.
Quali sono i 4 valori dell’Agile Software Manifesto?
I 4 valori core dell’Agile Manifesto sono: individui e interazioni più che processi e strumenti; software funzionante più che documentazione esaustiva; collaborazione col cliente più che negoziazione del contratto; risposta al cambiamento più che seguire un piano (fonte: agilemanifesto.org). Quattro frasi. Semplici in apparenza. Ma il modo in cui vanno lette cambia tutto.
Il punto che quasi sempre si fraintende è questo: i valori non cancellano la colonna destra. Non dicono “i processi non servono” o “il piano è inutile”. Il testo originale è esplicito: «That is, while there is value in the items on the right, we value the items on the left more» (agilemanifesto.org). È una scelta di priorità, non una demolizione. E questa distinzione, a mio avviso, è la cosa più importante da capire prima ancora di leggere i singoli valori.
Individui e interazioni più che processi e strumenti
Un processo ben documentato non scrive codice. Non risolve un malinteso tra due sviluppatori. Non decide come gestire un requisito ambiguo alle 17 di un venerdì. Lo fanno le persone.
Questo valore mette al centro la qualità delle relazioni e delle conversazioni nel team. Processi e strumenti restano utili, ma sono impalcature: servono finché reggono il peso, poi si adattano. Il Manifesto punta a squadre capaci di auto-organizzarsi, come conferma il principio per cui «the best architectures, requirements, and designs emerge from self-organizing teams» (agilealliance.org). Un team che si fida e comunica produce architetture migliori di un team che segue pedissequamente un workflow.
Nei team che ho seguito nel tempo, il problema raramente era la mancanza di strumenti. Era la mancanza di conversazioni oneste.
Software funzionante più che documentazione esaustiva
La documentazione non si installa in produzione. Il software sì.
Il Manifesto è diretto su questo punto: «Working software is the primary measure of progress» (agilealliance.org). Non il numero di pagine di specifiche approvate, non la completezza dei diagrammi UML. La misura è una sola: il software gira, fa quello che deve fare, porta valore. Tra i 12 principi, il Manifesto prescrive di «deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale» (pmi.org). Frequenza alta, cicli brevi, feedback reale.
Ma attenzione. “Più che documentazione esaustiva” non vuol dire zero documentazione. Vuol dire che quando le due cose sono in conflitto, sai cosa scegliere. La documentazione che non serve a nessuno è carta, non valore.
Collaborazione col cliente più che negoziazione del contratto
Un contratto firmato non garantisce che il cliente ottenga quello di cui ha bisogno. Garantisce solo quello che è scritto, nel momento in cui è stato scritto. E i requisiti cambiano. Sempre.
Questo valore sposta il rapporto col cliente da adversariale a collaborativo. Il Manifesto prescrive che «business people and developers must work together daily throughout the project» (pmi.org). Non “all’inizio per definire i requisiti” e “alla fine per il collaudo”. Ogni giorno. Questa continuità è quello che permette di correggere la rotta prima che un malinteso diventi un bug da 40 ore.
E quindi il contratto? Resta. Ma è uno strumento di accordo, non un recinto.
Risposta al cambiamento più che seguire un piano
Il piano è una fotografia del futuro scattata nel passato. Utile, ma già parzialmente obsoleta nel momento in cui viene stampata.
Il Manifesto Agile affronta il cambiamento senza riserve: «Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage» (agilealliance.org). “Harness” è la parola chiave: il cambiamento non è un nemico da contenere, è una risorsa da usare. Chi riesce ad adattarsi più velocemente della concorrenza ha un vantaggio reale sul mercato.
Questo non significa pianificare male o non pianificare affatto. Significa pianificare sapendo che il piano cambierà, e costruire un sistema che regga l’urto. A conti fatti, un team agile non è un team caotico: è un team che ha trasformato la flessibilità in disciplina.
Tutti e quattro i valori funzionano insieme. Togliere uno dei quattro o leggerli in isolamento produce distorsioni. Il valore sulla collaborazione col cliente perde senso se il team non ha individui capaci di dialogare. La risposta al cambiamento è vuota se non si consegna software funzionante con cui testare le nuove direzioni. Il Manifesto Agile è un sistema coerente, non un menu à la carte.
Quali sono i 12 principi dietro il Manifesto Agile?
I 12 principi dell’Agile Manifesto traducono i 4 valori in regole operative: customer satisfaction, delivery frequente, accoglienza del cambiamento, collaborazione quotidiana tra business e developer, ritmo sostenibile, eccellenza tecnica, semplicità, team auto-organizzati e retrospettive periodiche (fonte: agilealliance.org). Non è un elenco di buone intenzioni. Sono vincoli progettuali veri, pensati per chi costruisce software in condizioni reali, con clienti che cambiano idea e mercati che non aspettano.
Principi 1-4: focus sul cliente e sul cambiamento
Il primo principio è anche il più citato, e a ragione. «Our highest priority is to satisfy the customer through early and continuous delivery of valuable software» (fonte: agilealliance.org). Non “soddisfare i requisiti”. Non “rispettare il contratto”. Il cliente. E in modo continuativo, non a fine progetto quando ormai il danno è fatto.
Il secondo principio è quello che spaventa di più chi viene dalla gestione tradizionale dei progetti. «Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage» (fonte: agilealliance.org). Nei miei anni a seguire team in transizione verso Agile, ho visto questa frase generare più resistenza di qualsiasi altra cosa nel Manifesto. Il motivo è semplice: accettare il cambiamento tardi costa. Ma rifiutarlo costa di più, perché consegni qualcosa che non serve più a nessuno.
Il terzo principio prescrive di «deliver working software frequently, from a couple of weeks to a couple of months» (fonte: pmi.org), con preferenza per i cicli più corti. Non documentazione. Non prototipi. Software che funziona.
E poi il quarto: business e developer devono lavorare insieme ogni giorno, non solo nella fase di raccolta requisiti e nella demo finale. Questo è il principio che, a conti fatti, rompe più frequentemente in pratica. Non per malafede, ma perché le strutture organizzative tradizionali non lo permettono fisicamente.
Principi 5-8: persone, collaborazione e ritmo sostenibile
I principi dal quinto all’ottavo riguardano le persone che il software lo costruiscono davvero.
Il quinto principio chiede di costruire i progetti attorno a individui motivati, di dargli l’ambiente e il supporto di cui hanno bisogno, e di fidarsi che facciano il loro lavoro (fonte: agilealliance.org). Sembra ovvio. Non lo è. Molte organizzazioni dichiarano di seguire Agile e poi controllano ogni commit, ogni ora, ogni micro-decisione. Quello non è Agile, è Agile con la camicia di forza.
Il sesto principio punta sulla conversazione faccia a faccia come metodo più efficiente per trasmettere informazioni dentro e fuori il team di sviluppo (fonte: pmi.org). Non la mail. Non il ticket. La conversazione. Poi arriva il settimo principio, quello più scomodo per chi ama i Gantt chart: «Working software is the primary measure of progress» (fonte: agilealliance.org). Non le milestone. Non le ore consumate. Il software che gira.
L’ottavo principio introduce il concetto di ritmo sostenibile. «Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely» (fonte: pmi.org). Questo è il principio che tutela le persone dall’overwork cronico. Un team esausto produce debito tecnico, non valore.
Principi 9-12: eccellenza tecnica, semplicità e retrospettive
Gli ultimi quattro principi sono quelli tecnicamente più densi. E spesso i più sottovalutati.
Il nono afferma che «continuous attention to technical excellence and good design enhances agility» (fonte: agilealliance.org). Non è un’aggiunta opzionale. La qualità tecnica non è in contraddizione con la velocità: è la condizione che la rende possibile nel tempo. Robert C. Martin ha spinto questa idea ancora più in là nel 2008, proponendo “craftsmanship over execution” come possibile quinto valore del Manifesto, proprio per rimarcare che il modo in cui si scrive il codice conta quanto quello che si consegna.
Il decimo principio è forse il più citato fuori contesto: «Simplicity — the art of maximizing the amount of work not done — is essential» (fonte: pmi.org). In soldoni: non costruire quello che non serve. La complessità non richiesta è costo puro.
L’undicesimo riconosce che «the best architectures, requirements, and designs emerge from self-organizing teams» (fonte: agilealliance.org). Non dai capi. Non dagli architetti di sistema che scrivono documenti da 80 pagine. Dal team, che conosce il problema dall’interno.
Il dodicesimo principio chiude il cerchio con la retrospettiva: «at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly» (fonte: pmi.org). È l’unico principio che parla del team come sistema che si auto-migliora. Ma attenzione: “a intervalli regolari” non significa una volta all’anno durante la revisione delle performance. Significa ogni sprint, ogni ciclo, ogni volta che si consegna qualcosa.
Tutti e dodici i principi formano una struttura coerente solo se li si legge insieme. Prenderne sei e ignorarne altri sei non è Agile: è un’interpretazione selettiva che di solito finisce per giustificare esattamente i comportamenti che il Manifesto voleva eliminare.
Chi sono i 17 firmatari del Manifesto Agile?
I 17 firmatari dell’Agile Manifesto sono gli sviluppatori riuniti a Snowbird nel febbraio 2001, provenienti da Scrum, Extreme Programming, Pragmatic Programming e Feature-Driven Development (fonte: pmi.org). Non era un convegno istituzionale. Era una settimana in montagna, nello Utah, tra professionisti che si conoscevano già e che condividevano una stessa insofferenza verso i processi pesanti dell’ingegneria del software degli anni Novanta.
I nomi completi, per chi vuole andare alla fonte: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. Diciassette persone. Ognuna con una storia metodologica diversa, alcune con metodologie già consolidate e già in concorrenza tra loro.
I padri di Scrum, XP e FDD
Tre nomi pesano più degli altri, almeno in termini di diffusione globale delle loro metodologie.
Kent Beck aveva già pubblicato Extreme Programming Explained nel 1999. La sua visione, costruita su pratiche come il test-driven development e il pair programming, era radicalmente diversa dai modelli a cascata che dominavano i contratti pubblici e le grandi aziende. A Snowbird portò quella visione, e la firmò senza riserve.
Ken Schwaber e Jeff Sutherland arrivarono con Scrum, un framework che i due avevano presentato per la prima volta alla conferenza OOPSLA nel 1995. Ma non erano in conflitto con Beck. Anzi: condividevano l’idea che i team piccoli, autonomi e focalizzati sul software funzionante battessero qualsiasi piano di progetto lungo centinaia di pagine. Questa convergenza è, a mio avviso, la cosa più interessante di Snowbird: persone che avevano costruito metodologie distinte si ritrovarono d’accordo sui principi di fondo.
Martin Fowler portò il refactoring come pratica sistematica. Il suo libro omonimo era uscito nel 1999 e aveva cambiato il modo in cui molti sviluppatori pensavano alla qualità del codice nel tempo. Robert C. Martin, che di lì a qualche anno avrebbe scritto Clean Code, portò una sensibilità analoga: il codice non è solo funzionante, è scritto da persone che ci mettono la firma professionale.
Eredità e ruolo attuale nella community
Tutti e diciassette hanno continuato a lavorare, scrivere e insegnare dopo il 2001. Ma l’agile software manifesto non è rimasto fermo alla firma originale, almeno nel dibattito interno alla community.
Nel 2008, Robert C. Martin propose un quinto valore da aggiungere ai quattro originali: «craftsmanship over execution», originariamente formulato nella versione più diretta «craftsmanship over crap» (fonte: theserverside.com). La proposta non venne mai ufficializzata nel documento originale, ma generò il movimento del Software Craftsmanship, che oggi ha una propria manifesto separato. In soldoni: Martin sosteneva che l’esecuzione veloce senza cura per la qualità tradiva lo spirito di Snowbird.
Fowler è rimasto probabilmente il più attivo nel ridefinire cosa significhi “agile” nel 2020 e oltre, spesso attraverso il suo sito personale e articoli critici verso le derive burocratiche di certi framework certificati. Schwaber e Sutherland continuano ad aggiornare la Scrum Guide, l’ultima versione risale al 2020. Beck lavora su temi di ingegneria e cultura aziendale.
Ma la domanda più utile non è dove sono oggi. È che cosa hanno prodotto insieme in quei giorni a Snowbird. Quattro valori e dodici principi, tra cui l’idea che «continuous attention to technical excellence and good design enhances agility» (fonte: agilealliance.org). Un principio che collega direttamente la qualità tecnica alla capacità di adattarsi, e che è ancora il punto su cui si divide chi applica l’agile come filosofia da chi lo applica come checklist.
Diciassette firme. Una pagina. E vent’anni di dibattito che non accenna a finire.
Come si traducono valori e principi in pratica di team?
Tradurre il Manifesto Agile in pratica significa adottare framework operativi come Scrum, Kanban e XP, che incarnano i 12 principi in ruoli, cerimonie e artefatti misurabili. Non si tratta di studiare una filosofia e poi sperare che il team la applichi da solo. Si tratta di strutture operative che rendono ogni principio quasi impossibile da ignorare, perché lo mettono dentro al flusso di lavoro quotidiano.
Dalla teoria a Scrum, Kanban e XP
Scrum prende il principio «Business people and developers must work together daily throughout the project» e lo trasforma in una cerimonia concreta: il daily standup. Quindici minuti ogni mattina, stesso orario, stessa stanza (o stessa call). Kanban invece rende visibile il limite del lavoro in corso: il WIP limit è la forma pratica del principio che chiede di massimizzare il lavoro non fatto, «Simplicity — the art of maximizing the amount of work not done — is essential». XP va ancora più fondo sulla qualità tecnica, e riflette direttamente l’affermazione del Manifesto per cui «Continuous attention to technical excellence and good design enhances agility».
Nei miei anni di formazione con team di sviluppo, ho visto che il punto di rottura più comune non è la comprensione dei valori. È il passaggio dal “lo sappiamo” al “lo facciamo ogni giorno”. Scrum, Kanban e XP servono esattamente a questo: rendere i principi non negoziabili.
Ma c’è un principio che tutti citano e pochi applicano davvero. Il Manifesto dichiara che «The most efficient and effective method of conveying information to and within a development team is face-to-face conversation» (fonte: pmi.org). In un contesto distribuito o ibrido, questo principio diventa una scelta attiva, non automatica. Bisogna costruire le condizioni perché avvenga.
Indicatori concreti: working software, retrospettive, ritmo sostenibile
Il Manifesto è esplicito: «Working software is the primary measure of progress» (fonte: agilealliance.org). Non lo stato del Gantt. Non le ore rendicontate. Non le slide della review. Il software funzionante è l’unico indicatore che conta davvero, e questo cambia in modo radicale come si misura l’avanzamento di un progetto.
In soldoni: se a fine sprint non si consegna nulla di funzionante, lo sprint non è andato bene. Punto.
Le retrospettive traducono il 12° principio in routine. Il testo del Manifesto prescrive che «at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly». In Scrum questo diventa una cerimonia fissa a fine sprint, in genere ogni due settimane. Non è una riunione di sfogo. È il meccanismo con cui il team si auto-corregge, sprint dopo sprint, senza aspettare una revisione annuale delle performance. I team che saltano le retrospettive si accorgono nel tempo di accumulare disfunzioni che invece si sarebbero potute aggiustare in venti minuti.
E poi c’è il ritmo sostenibile. Il Manifesto afferma che «Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely». Questo principio è spesso il primo sacrificato quando arriva la pressione di fine trimestre. Ma un team che brucia le persone in tre mesi non è agile: è solo veloce finché regge. La sostenibilità non è un lusso, è una condizione di esistenza del metodo.
Approccio autodidatta vs percorso strutturato con certificazione
Leggere il Manifesto Agile e i 12 principi richiede meno di mezz’ora. È il primo passo, ed è gratis. Il Manifesto è pubblico su agilealliance.org, e chiunque può leggerlo oggi pomeriggio.
Ma conoscere i principi non significa saperli applicare in un team reale, con backlog reali, con stakeholder che cambiano idea ogni settimana. Qui sta la differenza tra l’autodidatta e chi ha fatto un percorso strutturato.
Il Manifesto stesso chiarisce il punto quando afferma: «Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done» (fonte: agilealliance.org). L’ambiente e il supporto non emergono da soli. Vanno costruiti, e spesso serve qualcuno che sappia già come farlo.
Personalmente, a mio avviso la certificazione Professional Scrum Master (PSM I) è oggi uno degli strumenti più concreti per accelerare questa transizione. Non perché la certificazione in sé garantisca qualcosa, ma perché il percorso strutturato verso il PSM I obbliga a confrontarsi con scenari pratici, decisioni di facilitazione e situazioni di conflitto che un libro non può simulare. Un corso strutturato verso il PSM I o una certificazione equivalente riduce il tempo che un team impiega per smettere di “fare Agile” e iniziare a essere agile. E questa differenza, alla fine della fiera, si misura in sprint, non in anni.
Quali sono i limiti e le critiche al Manifesto Agile oggi?
Le critiche principali al Manifesto Agile riguardano la sua applicazione fuori dal software, l’adozione superficiale delle pratiche senza i valori sottostanti e il rischio di degradazione qualitativa quando manca focus sull’eccellenza tecnica. Non si tratta di difetti del documento in sé, che è rimasto immutato dal 2001. Si tratta di ciò che succede quando un testo scritto da diciassette sviluppatori per risolvere un problema concreto di sviluppo software diventa una filosofia aziendale universale.
Agile oltre il software: opportunità o forzatura?
Il documento si chiama esplicitamente «Manifesto for Agile Software Development», come chiunque può verificare leggendolo su agilemanifesto.org. La parola “software” non è un dettaglio accessorio. È nel titolo.
Eppure negli ultimi quindici anni l’agile software manifesto è diventato il punto di riferimento per trasformazioni che con il software hanno poco a che fare: team HR che fanno sprint per rivedere le policy di ferie, uffici marketing che gestiscono campagne con un Kanban board, funzioni finance che parlano di backlog e velocity. In alcuni contesti funziona, e non voglio negarlo. Ma l’estensione è sempre un’interpretazione successiva, mai una prescrizione del testo originale.
Prendiamo un principio come «Working software is the primary measure of progress» (agilealliance.org). In un team di sviluppo la frase è chirurgicamente precisa: conta il codice che gira, non le slide che lo descrivono. Ma cosa diventa questo principio in un dipartimento HR? «Working HR policies»? La traduzione è possibile, ma richiede un lavoro di adattamento che le organizzazioni spesso saltano.
A conti fatti, il problema non è applicare i valori agile al di fuori del software. Il problema è farlo senza chiedersi se il contesto lo regge.
Il rischio del cargo cult agile
C’è un fenomeno che nei miei anni di formazione tecnica ho visto ripetersi con una frequenza sconcertante. Un’organizzazione decide di “adottare l’agile”. Arriva un consulente, si installano le cerimonie: daily standup alle 9:30, sprint review ogni due settimane, retrospettiva il venerdì pomeriggio quando non ci sono altre riunioni. E i valori? Rimangono nel PDF del Manifesto che nessuno rilegge.
Questo è il cargo cult agile. Il nome viene dall’antropologia: le popolazioni del Pacifico che dopo la Seconda Guerra Mondiale costruivano piste di atterraggio finte sperando che tornassero gli aerei militari con i rifornimenti. La forma senza la sostanza. Le cerimonie senza i valori.
Il Manifesto prescrive che «at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly» (pmi.org). Una retrospettiva vera è un atto di autocritica collettiva. Ma nelle organizzazioni cargo cult diventa una riunione di trenta minuti dove si dice che “tutto sommato è andata bene” e si chiude in anticipo.
Il punto tecnico è forse quello più sottovalutato. Il Manifesto è esplicito: «Continuous attention to technical excellence and good design enhances agility» (agilealliance.org). Non è una frase decorativa. È un principio operativo che dice che la velocità sostenibile dipende dalla qualità del codice. Se trascuri il design e accumuli debito tecnico, prima o poi ogni sprint rallenta. Ma questa parte del Manifesto è quella che le organizzazioni ignorano più volentieri, perché richiede investimento e disciplina invece di sole cerimonie.
Proprio da questa lacuna nasce la proposta di Robert C. Martin che nel 2008 ha avanzato un quinto valore per l’agile software manifesto: «craftsmanship over execution», formulato originariamente nella versione più diretta «craftsmanship over crap» (theserverside.com). L’idea è semplice: rimettere al centro la qualità tecnica e la professionalità dello sviluppatore, non come optional ma come condizione necessaria per qualsiasi agilità reale. Non è un’aggiunta polemica. È la risposta documentata a un degrado che si stava già vedendo nel 2008, e che da allora non ha fatto che accelerare.
Ma, personalmente, il segnale più preoccupante non è chi ignora il craftsmanship. È chi non sa nemmeno che il dibattito esiste.
Domande frequenti su Agile Software Manifesto
Le domande più frequenti sull’Agile Software Manifesto riguardano data di firma, numero di valori e principi, ambito di applicazione e percorsi formativi collegati. Raccoglierle in un unico punto ha senso: sono domande secche, con risposte precise, e meritano altrettanta precisione.
Quando è stato firmato l’Agile Manifesto?
Il Manifesto Agile è stato firmato l’11 febbraio 2001 a Snowbird, nello Utah, da diciassette professionisti del software riuniti per trovare un terreno comune tra metodologie leggere già esistenti. La data e il luogo sono documentati direttamente su agilemanifesto.org. Non è un documento normativo: è una dichiarazione di valori condivisi, nata in un fine settimana di discussioni.
Quanti sono i valori e i principi del Manifesto Agile?
Il Manifesto Agile contiene 4 valori e 12 principi, come riportato anche dal PMI. I valori stabiliscono le priorità generali (persone sull’interazione, software funzionante, collaborazione col cliente, risposta al cambiamento). I 12 principi li declinano in comportamenti concreti: consegne frequenti, ritmo sostenibile, retrospettive periodiche, squadre auto-organizzate.
Quattro e dodici. Non di più.
Dove si può leggere il testo ufficiale del Manifesto?
Il testo integrale dell’Agile Software Manifesto è disponibile su agilemanifesto.org, il sito originale curato dagli autori stessi. Il documento si può leggere in oltre 60 lingue, incluso l’italiano. Niente versioni “aggiornate” o edizioni riviste: il testo è rimasto invariato dal 2001, e questa immutabilità è intenzionale.
Il Manifesto Agile vale solo per lo sviluppo software?
Formalmente no, anche se nasce dentro il mondo del software. I valori del Manifesto Agile, come la collaborazione continua tra chi finanzia il progetto e chi lo esegue o la consegna frequente di risultati concreti, si applicano bene a qualsiasi lavoro che richieda adattamento rapido: marketing, design, gestione di prodotto, formazione. Ma attenzione: chi li applica fuori dal software spesso ne perde la specificità tecnica, che è parte del messaggio originale. Principi come «continuous attention to technical excellence» non si traducono automaticamente in altri contesti.
Anzi, il rischio è usare il termine “agile” come etichetta vuota, senza i comportamenti concreti che il Manifesto prescrive.
Esiste una certificazione che si basa sul Manifesto Agile?
Sì. Tra le certificazioni più diffuse che poggiano esplicitamente sui valori e principi dell’Agile Software Manifesto c’è la PMI-ACP (Agile Certified Practitioner) del PMI, che include la comprensione del Manifesto tra i suoi requisiti di conoscenza. Ma anche certificazioni come PSM (Professional Scrum Master) e PRINCE2 Agile fanno riferimento diretto al documento del 2001. Nei miei anni a seguire candidati su questi percorsi ho visto che chi sottovaluta il Manifesto come “roba teorica” fatica poi nelle domande situazionali: i principi non sono ornamento, sono la logica che regge le risposte corrette.
A conti fatti, conoscere i 4 valori e i 12 principi non è un’opzione, è il punto di partenza.
