Agile e Scrum: storia, creatori e idee principali
Agile e Scrum descrivono cose diverse
Agile è un insieme di valori e principi per sviluppare software imparando dall’esperienza e adattandosi ai cambiamenti. Scrum è un quadro di riferimento che offre al team una struttura specifica per affrontare lavoro complesso. Il legame è stretto, ma le parole non sono intercambiabili. Un team può seguire principi agili senza Scrum, e programmare riunioni Scrum non garantisce né adattabilità né risultati utili.
Una domanda concreta chiarisce la distinzione: che cosa dovrebbe accadere quando il team scopre che il piano originale non corrisponde più al problema? Un approccio agile considera le nuove informazioni un motivo per rivedere il piano. Scrum crea occasioni regolari per verificare il lavoro e apportare aggiustamenti. Nessuno dei due elimina la necessità di un obiettivo, giudizio professionale o attenzione alla qualità.
Perché serviva un approccio diverso
I progetti software iniziano spesso con conoscenze incomplete. Gli utenti possono faticare a descrivere un bisogno prima di vedere una possibile soluzione; gli sviluppatori possono scoprire vincoli tecnici solo tentando una realizzazione. Se tutti i requisiti vengono trattati come definitivamente fissati all’inizio, un team può eseguire fedelmente un piano che non porta più al prodotto più utile. Scoprire tardi questa divergenza rende la correzione più costosa e destabilizzante.
La risposta non fu abbandonare la pianificazione, ma ridurre la distanza tra una decisione e la scoperta della sua efficacia. Invece di attendere una grande consegna finale, i team potevano creare risultati utilizzabili più piccoli, cercare riscontri e aggiornare le priorità. Questo ragionamento si sviluppò in diversi approcci prima che Agile diventasse la loro denominazione comune. Non apparve in un giorno come invenzione completa di una sola persona.
Le radici di Scrum precedono il Manifesto Agile
Un passaggio importante è l’articolo del 1986 di Hirotaka Takeuchi e Ikujiro Nonaka, The New New Product Development Game. La metafora del rugby aiutò a interpretare lo sviluppo di prodotti come movimento coordinato del gruppo invece di una semplice sequenza di passaggi di consegne. L’articolo riguardava lo sviluppo di prodotti in senso ampio; non va confuso con il successivo framework software nella sua forma interamente definita.
Ken Schwaber e Jeff Sutherland svilupparono Scrum nei primi anni Novanta e lo presentarono insieme alla conferenza OOPSLA nel 1995. Sono riconosciuti come cocreatori, mentre altri professionisti contribuirono al suo sviluppo. La prima Scrum Guide apparve nel 2010. L’ordine conta: Scrum esisteva prima del Manifesto Agile e divenne poi uno dei framework più noti associati allo sviluppo agile.
L’incontro del 2001 diede ad Agile un’identità comune
Dall’11 al 13 febbraio 2001, diciassette professionisti del software si riunirono a Snowbird, nello Utah. Rappresentavano approcci diversi, tra cui Extreme Programming, Scrum e Crystal. Secondo il resoconto ufficiale dell’incontro, cercavano anche un terreno comune oltre i processi pesanti e centrati sulla documentazione. Ne nacque il Manifesto per lo sviluppo agile di software, comunemente chiamato Manifesto Agile.
I diciassette firmatari erano 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 e Dave Thomas. Agile ha dunque una paternità collettiva. I due cocreatori di Scrum erano tra i firmatari, ma il movimento più ampio non può essere attribuito soltanto a loro.
Quattro valori, con una precisazione importante
Il Manifesto attribuisce maggior peso alla collaborazione umana che alla dipendenza rigida dalle procedure, al software funzionante che alle descrizioni esaustive, a una relazione continua con il cliente che alla contrattazione e all’adattamento alle circostanze che alla conservazione meccanica di un vecchio piano. Queste priorità aiutano a risolvere tensioni reali dei progetti. Non vietano strumenti, contratti, documentazione o piani.
La precisazione è essenziale. Un prodotto regolamentato può richiedere documentazione ampia; un team distribuito può dipendere molto dagli strumenti. La domanda è se sostengano il lavoro e le persone che ne necessitano i risultati. I dodici principi complementari aggiungono consegne frequenti, lavoro sostenibile, cura tecnica e riflessione regolare. Agile chiede di esaminare il modo di lavorare, non soltanto adottare un vocabolario alla moda.
Che cosa aggiunge Scrum a queste idee
Scrum organizza il lavoro intorno a un piccolo team, una direzione di prodotto condivisa e periodi ripetuti chiamati Sprint. Uno Sprint dura al massimo un mese. Durante questo periodo il team persegue uno Sprint Goal e crea un’aggiunta utilizzabile al prodotto. Il ciclo breve limita il tempo durante il quale le ipotesi restano inesaminate, purché si verifichino davvero i risultati invece di riferire soltanto attività.
La Scrum Guide identifica tre responsabilità. Il Product Owner risponde della massimizzazione del valore e della gestione del Product Backlog ordinato. I Developers creano il risultato utilizzabile e organizzano il lavoro. Lo Scrum Master aiuta a stabilire Scrum e migliorare l’efficacia del team. Non è definito come un capo che assegna compiti quotidiani; il Product Owner è una persona, non un comitato decisionale.
Un ciclo di lavoro, non solo un calendario di riunioni
Lo Sprint Planning stabilisce perché lo Sprint successivo è importante, che cosa il team può assumere e come intende procedere. Durante lo Sprint, il Daily Scrum offre ai Developers quindici minuti per verificare i progressi verso l’obiettivo e adattare il piano. La Sprint Review esamina il risultato con le parti interessate e orienta il lavoro futuro. La Sprint Retrospective si concentra sul miglioramento della collaborazione.
Gli eventi hanno scopi differenti. La Review non è semplicemente una barriera di approvazione e la retrospettiva non serve a incolpare qualcuno per una settimana difficile. Nemmeno una riunione quotidiana diventa efficace soltanto perché le persone restano in piedi. Il collegamento tra osservazione e azione conta più delle apparenze: quando emerge un ostacolo o un’ipotesi sbagliata, il team deve avere una possibilità concreta di reagire.
Come appare l’approccio in un prodotto comune
Immaginiamo un team che costruisce un sito didattico. Invece di realizzare un’intera piattaforma di corsi prima di mostrare qualcosa, potrebbe consegnare una piccola esperienza di lezione utilizzabile. Gli studenti aprono una lezione, leggono il contenuto e la segnano come completata. I riscontri possono rivelare che comprendere i progressi conta più del sofisticato cruscotto previsto inizialmente. Questa scoperta può cambiare l’ordine del lavoro successivo.
È un esempio illustrativo, non un progetto storico. Mostra due idee complementari: lo sviluppo incrementale aggiunge capacità utilizzabili, mentre quello iterativo riesamina e migliora quanto appreso o costruito. Un prototipo destinato a esplorare un’idea può essere prezioso, ma non è automaticamente un’aggiunta completa al prodotto. In Scrum il lavoro deve soddisfare la Definition of Done del team prima di appartenere a un Increment completato.
Il posto di altre pratiche e persone
Agile va oltre Scrum. Extreme Programming enfatizza le pratiche di ingegneria del software; Kanban si concentra sul flusso e sulla limitazione del lavoro in corso. I team possono usare anche storie utente, tecniche di stima o lavagne visive. Sono possibili supporti, ma Scrum non impone storie utente, story point o planning poker. Confondere una raccomandazione comune con una regola ufficiale rende il framework apparentemente più complicato.
Successivamente formatori e autori contribuirono alla diffusione delle idee. Mike Cohn, per esempio, propose spiegazioni influenti su storie utente e pianificazione agile, pur non avendo firmato il Manifesto. CI/CD appartiene al versante tecnico: integrazione frequente, controlli automatici e processi di rilascio affidabili possono sostenere cicli brevi di riscontro. Non è un altro nome per Agile né una componente obbligatoria di Scrum.
Che cosa dovrebbe significare davvero il successo
Agile e Scrum non promettono che ogni progetto sarà facile o ogni scadenza corretta. Rendono l’incertezza gestibile tramite lavoro visibile, riscontri e adattamento. Servono condizioni oltre la sala riunioni: accesso agli utenti, priorità chiare, facoltà di decidere e attenzione sostenibile alla qualità. Cambiare i titoli professionali senza trasformare queste condizioni può lasciare intatti i problemi iniziali.
La verifica utile è concreta: il team scopre prima i malintesi, risponde alle evidenze e produce qualcosa di utilizzabile? Un calendario pieno e una lavagna affollata non rispondono. Capire la storia aiuta a conservare lo scopo: Agile espresse priorità condivise, mentre Scrum offrì un quadro per dare all’apprendimento e alla consegna coordinata un ritmo ripetibile.
