Agile

Agile non è una metodologia: è una mentalità per gestire il lavoro in condizioni di incertezza, formalizzata nel Manifesto Agile del febbraio 2001 da diciassette professionisti del software riuniti a Snowbird, Utah.

Sotto l'ombrello Agile vivono framework operativi diversi — Scrum, Kanban, XP, Lean — accomunati da una stessa filosofia di fondo: consegnare valore in modo iterativo e incrementale, adattandosi al cambiamento.

Manifesto Agile: i 4 valori

1. Individui e interazioni più che processi e strumenti
2. Software funzionante più che documentazione esaustiva
3. Collaborazione col cliente più che negoziazione contrattuale
4. Risposta al cambiamento più che seguire un piano

⚠ Il "più che" è cruciale: non significa che il secondo elemento sia inutile, ma che si dà priorità al primo. La documentazione resta importante — solo non a discapito del software funzionante.

I 12 principi

I valori si traducono in dodici principi operativi:

1. La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in modo continuo.
2. Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo.
3. Consegniamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo tempi brevi.
4. Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.
5. Affidate i progetti a persone motivate, fornite loro l'ambiente e il supporto di cui hanno bisogno, e fidatevi.
6. La comunicazione faccia a faccia è il modo più efficiente per trasmettere informazioni.
7. Il software funzionante è il principale metro di misura del progresso.
8. I processi agili promuovono uno sviluppo sostenibile: il ritmo deve poter essere mantenuto indefinitamente.
9. L'attenzione continua all'eccellenza tecnica e al buon design aumenta l'agilità.
10. La semplicità — l'arte di massimizzare il lavoro non fatto — è essenziale.
11. Le architetture, i requisiti e i progetti migliori emergono da team auto-organizzati.
12. A intervalli regolari, il team riflette su come diventare più efficace, e si adatta di conseguenza.

Le quattro famiglie più diffuse

Scrum e Kanban sono spesso combinati nel cosiddetto Scrumban: sprint ridotti o assenti, ma con WIP limit e flusso continuo.

Scaling framework

Per organizzazioni grandi, dove molti team devono coordinarsi su un unico prodotto:

• SAFe (Scaled Agile Framework) — il più strutturato e diffuso in enterprise
• LeSS (Large Scale Scrum) — Scrum scalato preservandone la leggerezza
• Spotify Model — squad / tribe / chapter / guild (più descrittivo che prescrittivo)
• Nexus — framework di Scrum.org per 3-9 team Scrum

⚠ Gli scaling framework sono forti farmaci: introducono complessità e dovrebbero essere adottati solo quando il problema di scala è reale, non per moda.

Quando Agile funziona

Agile è adatto se:

• Il prodotto è digitale o software
• I requisiti evolvono col feedback degli utenti
• Si lavora in alta incertezza (innovation, startup, R&D)
• Si può rilasciare incrementalmente valore
• Il team ha autonomia e cross-funzionalità
• Esempi: SaaS, app mobili, nuovi prodotti digitali, growth experiments

Quando Agile non funziona

Non tutti i contesti tollerano Agile. Evitalo o adatta pesantemente se:

• Il prodotto finale è fisico o difficilmente modificabile dopo il rilascio (ponti, farmaci, hardware)
• Esiste un vincolo contrattuale rigido (es. appalto pubblico a corpo)
• I requisiti sono bloccati dalla compliance (medical, aerospaziale)
• Il team non ha autonomia e dipende da approvazioni gerarchiche per ogni mossa
• L'organizzazione non è disposta a tollerare l'incertezza che Agile rende visibile

In questi casi → Waterfall o PRINCE2.

Anti-pattern

• ✕ Agile washing — chiamare "agile" un waterfall mascherato con post-it colorati e una daily standup
• ✕ Cargo cult — copiare le pratiche senza capirne il senso ("facciamo gli sprint perché lo fa Spotify")
• ✕ Confondere framework e cultura — Agile è prima una mentalità, poi un processo. Senza la cultura, il framework è teatro
• ✕ Imporre Agile a chi non lo vuole o non lo può — alcuni contesti non lo permettono e va bene così
• ✕ Pensare che Agile = niente documentazione — il manifesto dice "più che", non "invece di"
• ✕ Confondere velocità con valore — un team agile veloce che consegna la cosa sbagliata fallisce più velocemente
• ✕ Manager-driven Agile — se le decisioni passano comunque dal capo, l'auto-organizzazione è una finzione

Agile vs. agile

Una distinzione utile, dovuta a Martin Fowler:

• Agile (con la maiuscola) — il movimento storico, il Manifesto, i framework codificati
• agile (minuscolo) — la qualità di essere flessibili, reattivi, adattivi

Si può essere agili senza adottare Agile, e si può adottare Agile senza essere agili. La seconda è una delle disfunzioni più comuni.

Collegamenti

• Metodologie — confronto Waterfall / Agile / Hybrid e guida alla scelta
• Scrum — il framework Agile più diffuso
• Kanban — flusso continuo, alternativa o complemento a Scrum
• Retrospective — il cuore del miglioramento continuo
• User Stories — il formato di backlog item più usato in Agile
• MVP — consegnare valore minimo e imparare