Lean e Agile: Antenati e Cugini

Il Manifesto Agile fu scritto nel 2001. Il sistema di produzione Toyota iniziò a evolversi negli anni '40. Il pensiero Lean precede agile di oltre mezzo secolo.

Questo è importante perché le pratiche Agile spesso hanno senso solo alla luce dei principi Lean. Perché favoriamo "software funzionante rispetto a documentazione esaustiva"? Perché la documentazione prima della codifica è inventario—una forma di spreco. Perché vogliamo "rispondere al cambiamento rispetto al seguire un piano"? Perché i piani a lungo termine sono speculazione, e la speculazione produce spreco quando la realtà differisce.

Molte difficoltà agile derivano da team che adottano pratiche senza comprendere i principi sottostanti. Fanno standup giornalieri perché Scrum lo dice, non perché comprendono come riduca lo spreco di coordinamento. Delimitano gli sprint in timebox perché è il framework, non perché comprendono come i piccoli batch riducano il rischio.

Quando comprendi Lean, le pratiche Agile diventano ovvie. Quando non lo fai, sembrano rituali arbitrari.

Scrum ha adottato diversi concetti Lean:

• Il timeboxing come vincolo di dimensione del batch
• Team cross-funzionali per ridurre i passaggi di consegne
• Retrospettive per il miglioramento continuo
• Auto-organizzazione come rispetto per le persone
• Software funzionante ogni sprint (consegna JIT)

Extreme Programming (XP) è ancora più esplicitamente Lean:

• Il pair programming riduce i difetti (costruire qualità)
• L'integrazione continua previene l'inventario (piccoli batch)
• Il test-driven development cattura i bug presto (Jidoka)
• Il design semplice evita lo spreco (YAGNI)
• Il ritmo sostenibile rispetta le persone

Kanban è il metodo più direttamente derivato da Lean. David Anderson ha adattato esplicitamente i concetti TPS: sistemi pull, limiti WIP, visualizzazione del flusso, miglioramento continuo. Se Scrum ha preso in prestito la filosofia di Lean, Kanban ha preso in prestito i suoi meccanismi.

Nessuno di questi metodi richiede di comprendere Lean per usarli. Ma comprendere Lean ti aiuta a:

• Sapere quando infrangere le regole
• Adattare le pratiche al tuo contesto
• Diagnosticare perché le cose non funzionano
• Combinare le pratiche in modo coerente

Mentre Lean fornisce le fondamenta, Agile ha aggiunto elementi importanti per il lavoro di conoscenza:

Abbracciare l'incertezza: il Lean manifatturiero ottimizzava processi noti. Lo sviluppo software affronta un'incertezza fondamentale—spesso non sappiamo cosa costruire o come costruirlo finché non proviamo. Agile costruisce esplicitamente meccanismi per la scoperta: iterazioni, feedback degli utenti, pivot.

Timebox: il TPS non aveva bisogno di sprint—la produzione era continua. Agile ha introdotto i timebox come funzione forzante per i team software non abituati al flusso continuo. Il timebox crea ritmo, limita lo scope creep e forza la consegna regolare.

Cerimonie: retrospettive, standup, review—questi sono meccanismi per i cicli di feedback che Lean richiede, adattati ai team di lavoro di conoscenza. Non sono unici di Agile (Toyota aveva pratiche simili), ma Agile li ha codificati per il software.

L'elemento umano: mentre il pilastro "Rispetto per le Persone" di Lean è profondo, Agile lo ha reso più esplicito per il lavoro di conoscenza. "Individui e interazioni rispetto a processi e strumenti" del Manifesto e il "ritmo sostenibile" di XP enfatizzano che il lavoro di conoscenza richiede motivazione intrinseca, non solo efficienza di processo.

Né Lean né Agile sono completi da soli. Lean fornisce principi e teoria. Agile fornisce pratiche specifiche per il software. I migliori team attingono da entrambi.