Lean y Agile: Ancestros y Primos

El Manifiesto Ágil fue escrito en 2001. El sistema de producción de Toyota comenzó a evolucionar en la década de 1940. El pensamiento Lean precede a agile por más de medio siglo.

Esto importa porque las prácticas Agile a menudo solo tienen sentido a la luz de los principios Lean. ¿Por qué favorecemos "software funcionando sobre documentación exhaustiva"? Porque la documentación antes de codificar es inventario—una forma de desperdicio. ¿Por qué queremos "responder al cambio sobre seguir un plan"? Porque los planes a largo plazo son especulación, y la especulación produce desperdicio cuando la realidad difiere.

Muchas luchas ágiles provienen de equipos que adoptan prácticas sin entender los principios subyacentes. Hacen standups diarios porque Scrum lo dice, no porque entiendan cómo reduce el desperdicio de coordinación. Delimitan sprints porque ese es el marco, no porque entiendan cómo los lotes pequeños reducen el riesgo.

Cuando entiendes Lean, las prácticas Agile se vuelven obvias. Cuando no, parecen rituales arbitrarios.

Scrum adoptó varios conceptos Lean:

• Delimitación de tiempo como restricción de tamaño de lote
• Equipos multifuncionales para reducir transferencias
• Retrospectivas para mejora continua
• Autoorganización como respeto por las personas
• Software funcionando cada sprint (entrega JIT)

Extreme Programming (XP) es aún más explícitamente Lean:

• La programación en parejas reduce defectos (construir calidad)
• La integración continua previene inventario (lotes pequeños)
• El desarrollo guiado por pruebas detecta errores temprano (Jidoka)
• El diseño simple evita desperdicio (YAGNI)
• El ritmo sostenible respeta a las personas

Kanban es el método más directamente derivado de Lean. David Anderson adaptó explícitamente conceptos de TPS: sistemas pull, límites de WIP, visualización de flujo, mejora continua. Si Scrum tomó prestada la filosofía de Lean, Kanban tomó prestados sus mecanismos.

Ninguno de estos métodos requiere que entiendas Lean para usarlos. Pero entender Lean te ayuda a:

• Saber cuándo romper las reglas
• Adaptar prácticas a tu contexto
• Diagnosticar por qué las cosas no funcionan
• Combinar prácticas coherentemente

Mientras Lean proporciona la base, Agile agregó elementos importantes para el trabajo de conocimiento:

Abrazar la incertidumbre: El Lean de manufactura optimizó procesos conocidos. El desarrollo de software enfrenta incertidumbre fundamental—a menudo no sabemos qué construir o cómo construirlo hasta que lo intentamos. Agile construye explícitamente mecanismos para el descubrimiento: iteraciones, retroalimentación del usuario, pivotes.

Delimitaciones de tiempo: TPS no necesitaba sprints—la producción era continua. Agile introdujo delimitaciones de tiempo como una función forzada para equipos de software no acostumbrados al flujo continuo. La delimitación de tiempo crea ritmo, limita el aumento de alcance y fuerza la entrega regular.

Ceremonias: Retrospectivas, standups, revisiones—estos son mecanismos para los ciclos de retroalimentación que Lean requiere, adaptados a equipos de trabajo de conocimiento. No son únicos de Agile (Toyota tenía prácticas similares), pero Agile los codificó para software.

El elemento humano: Mientras el pilar de "Respeto por las Personas" de Lean es profundo, Agile lo hizo más explícito para el trabajo de conocimiento. El "individuos e interacciones sobre procesos y herramientas" del Manifiesto y el "ritmo sostenible" de XP enfatizan que el trabajo de conocimiento requiere motivación intrínseca, no solo eficiencia de procesos.

Ni Lean ni Agile están completos solos. Lean proporciona principios y teoría. Agile proporciona prácticas específicas para software. Los mejores equipos se nutren de ambos.