Hay una palabra que se cuela en cada presentación corporativa desde 2005, y es Lean. Lean Six Sigma, Lean Banking, Lean Hospital, Lean Government, Lean Coffee. Llegó tanto y a tantos lados que ya no significa nada, lo cual es exactamente la suerte que le tocó a Agile.
Pero el original es muy distinto al cliché de PowerPoint. Salió de una fábrica de autos en Japón post-guerra donde no había dinero, no había materia prima, no había mercado interno fuerte y los americanos hacían 8 veces más coches que ellos. Tenían que inventar otra forma de fabricar — una donde cada movimiento desperdiciado equivalía a quebrar antes que la competencia. Y la inventaron.
Este post va de cómo lo hicieron, qué sigue siendo cierto, y qué de eso aplica de verdad a escribir software. Sin acrónimos vacíos, sin la versión cursi.
El problema que se les puso enfrente
Toyota arrancó la posguerra (1945) en una situación que hoy llamaríamos startup en modo supervivencia. Las cifras del informe interno de Toyota, citadas por el propio Taiichi Ohno en su libro de 1978, son brutales: la productividad por trabajador en Estados Unidos era 9 veces mayor que en Japón. No “un poco mejor”. Nueve veces. En un mercado donde el comprador japonés no podía permitirse pagar más, y donde los volúmenes eran tan bajos que ninguna línea de producción americana tenía sentido.
La respuesta natural —contratar más gente, comprar más máquinas, hacer más ruido— no era una opción. Toyota necesitaba producir más con lo mismo. Y para eso la familia Toyoda y un ingeniero llamado Taiichi Ohno (1912–1990) se inventaron, durante 25 años de prueba y error, lo que después se llamaría Toyota Production System — TPS para los amigos.
Ohno escribió su libro Toyota Production System: Beyond Large-Scale Production en japonés en 1978; la traducción al inglés salió diez años después, en 1988, con Productivity Press. Ese libro es el documento fundacional. Si llevas años escuchando “lean” y nunca lo abriste, te aviso que es bastante terco y bastante divertido, en partes iguales. Ohno no fue un teórico amable; fue un ingeniero de fábrica con muy poca paciencia.
La anécdota del supermercado americano
Una de las historias mejor documentadas y más útiles para entender Lean es esta: en 1956, Ohno viajó a Estados Unidos a estudiar el Ford Production System (Henry Ford era su héroe declarado, vale aclarar). Pero lo que más lo impactó no fue una fábrica. Fue un supermercado.
El sistema americano de supermercados —el más conocido es Piggly Wiggly, que inventó el autoservicio en 1916— funciona así: el cliente toma del estante lo que necesita y, sólo cuando el estante baja de cierto nivel, alguien va a la trastienda a reponerlo. Nadie repone hasta que algo se consume. El estante “tira” la mercancía hacia adelante; la trastienda no la “empuja”.
Ohno se llevó esa idea a Toyota y la convirtió en kanban — que significa literalmente “tarjeta visual” en japonés, y nada más. La tarjeta original era física: un trabajador en la línea de ensamblaje terminaba una pieza, ponía una tarjeta en una caja, y la tarjeta era la señal para que la estación anterior produjera la siguiente. Sin tarjeta, no se produce nada. Si nadie está consumiendo, nadie está fabricando, y por lo tanto no se acumula inventario que después haya que descontar.
Esa es la inversión filosófica más importante de Lean, y la que más cuesta entender en cualquier industria:
El problema no es producir poco. El problema es producir antes de que se necesite.
En manufactura tradicional —Ford incluido— se produce en lotes grandes para “amortizar el setup” y se acumula inventario. En Lean, el inventario es deuda: ocupa espacio, esconde defectos, congela capital. La meta es producir lo justo, justo a tiempo, en respuesta a una demanda real. A eso se le llamó just-in-time.
Si la frase “just-in-time” te hace pensar en logística rota durante la pandemia, válido — pero para Lean significa otra cosa muy específica que vale la pena retener.
El libro que le puso nombre a “Lean”
Ohno trabajaba en Toyota desde dentro. La industria automotriz mundial, mientras tanto, no tenía ni idea de qué estaba pasando ahí. El término “Lean Production” lo inventó John Krafcik —un investigador del MIT, después CEO de Hyundai Motor America y luego de Waymo— en un artículo de otoño de 1988 en MIT Sloan Management Review, llamado “Triumph of the Lean Production System”. Krafcik notó que las fábricas Toyota usaban menos de todo —menos inventario, menos espacio, menos defectos, menos gente— y por eso lo llamó lean (delgado).
Dos años después, en 1990, James Womack, Daniel Jones y Daniel Roos —los tres del MIT International Motor Vehicle Program (IMVP), que era el estudio comparativo más grande de la industria automotriz hasta ese momento— publicaron el libro The Machine That Changed the World (Rawson Associates, 1990). Ese libro fue el que llevó “Lean” al mundo entero. Vendió cientos de miles de copias y en menos de cinco años cualquier consultor de gestión sabía la palabra.
Seis años después, en 1996, Womack y Jones publicaron el libro que de verdad sintetiza la filosofía: Lean Thinking: Banish Waste and Create Wealth in Your Corporation. Ahí formularon los 5 principios de Lean que se citan en cada introducción al tema:
- Definir el valor desde el punto de vista del cliente. No de quien construye, no de quien vende — del que paga.
- Mapear la cadena de valor (value stream): identificar todos los pasos que hacen falta para entregar ese valor, y separar los que sí agregan valor de los que no.
- Crear flujo: que el trabajo se mueva sin pausas innecesarias entre etapas.
- Establecer pull: que cada etapa produzca sólo cuando la siguiente lo pida.
- Buscar la perfección (kaizen): mejora continua, en pasos pequeños, todos los días, todos los del equipo.
Léelo en orden. Es una secuencia. Si no defines bien el valor, no puedes mapear la cadena. Si no la mapeas, no sabes dónde están las pausas. Si no las eliminas, el flujo no existe. Si no hay flujo, el pull se rompe. Y si nada de eso pasa, el kaizen sólo está pintando paredes.
Las 7 mudas — los siete tipos de desperdicio
Si Lean tiene un core idea, este es:
Todo lo que el cliente no está dispuesto a pagar es desperdicio.
Y Ohno catalogó 7 tipos de desperdicio (en japonés, muda) que aparecen una y otra vez en cualquier proceso. Se memorizan con el acrónimo TIMWOOD:
| Letra | Muda | En la fábrica | En tu trabajo de software |
|---|---|---|---|
| T | Transportation | Mover materiales sin necesidad | Pasar contexto entre dos servicios que podrían fusionarse |
| I | Inventory | Stock que duerme en bodega | PRs abiertos sin revisar; ramas vivas hace 3 meses; backlog de 800 tickets |
| M | Motion | Trabajadores caminando entre máquinas | Cambio constante entre 6 herramientas para hacer una sola tarea |
| W | Waiting | Línea parada esperando insumo | Esperar 2 días un code review; esperar al deploy del viernes |
| O | Overproduction | Producir más de lo que se va a vender | Construir features que nadie pidió ni va a usar |
| O | Over-processing | Más acabado del necesario | Sobre-ingeniería: 3 capas de abstracción cuando bastaba una función |
| D | Defects | Producto defectuoso que hay que rehacer | Bugs en producción; rollback; refactors mal pensados |
A esos 7 originales, Womack y Jones le añadieron en Lean Thinking un octavo que muchos consideran el más importante en trabajo de conocimiento: talento desaprovechado (unused human ingenuity). El acrónimo extendido es DOWNTIME.
Si haces el ejercicio honesto de mapear estas mudas en una semana típica de tu equipo, vas a encontrar varias horas tiradas. La mayoría de los equipos se obsesionan con la primera columna —la T y la M— porque es la más visible. La que más duele en software es la W (Waiting) y la O de Overproduction: el ticket que se queda 6 días en code review y la feature que se construye porque “el área comercial dijo que la necesitaban”, pero que tres meses después nadie usa.
Las 3 M — muda no va sola
Aquí hay una sutileza que casi siempre se omite cuando alguien presenta Lean en cuatro slides. Ohno no hablaba sólo de muda (desperdicio). Hablaba de 3 problemas conjuntos, las llamadas 3M:
| Concepto | Significado | Ejemplo en software |
|---|---|---|
| Muda | Desperdicio (todo lo que no agrega valor) | Reuniones sin agenda; código muerto; reportes que nadie lee |
| Mura | Variabilidad / desigualdad en el flujo | Sprint 1: 5 tickets. Sprint 2: 35 tickets. Caos cíclico |
| Muri | Sobrecarga (de personas o de máquinas) | Pedir el feature en 3 días “porque el cliente lo necesita ya” |
Lo importante: las 3 se alimentan entre sí. Muri (la sobrecarga, la presión irrazonable) genera muda (errores, retrabajos, atajos sucios) y deja mura (algunos sprints heroicos, otros catastróficos). Los equipos que sólo atacan muda sin tocar las otras dos terminan limpiando el mismo desorden cada trimestre.
Para programadores, traducción directa: un equipo bajo presión crónica produce código de mala calidad, que produce bugs, que producen presión adicional. El ciclo no se rompe optimizando code reviews. Se rompe quitando muri — bajando la carga, peleando los deadlines absurdos, eliminando dependencias que sobrecargan a una sola persona.
Cómo Lean llegó a software
En 2003, Mary y Tom Poppendieck —Mary venía de procesos manufactura y Tom de ingeniería de software, lo cual es una de esas combinaciones poco comunes que dan los mejores libros— publicaron Lean Software Development: An Agile Toolkit con Addison-Wesley.
Ese libro es la traducción canónica del TPS al mundo del software. Y lo hicieron limpiamente: tomaron las ideas de Ohno y las re-formularon en 7 principios específicos para construir software:
- Eliminate waste — Eliminar desperdicio.
- Amplify learning — Amplificar el aprendizaje (cada decisión es una hipótesis).
- Decide as late as possible — Decidir lo más tarde posible (mantener opciones abiertas hasta tener información).
- Deliver as fast as possible — Entregar lo más rápido posible (ciclos cortos).
- Empower the team — Empoderar al equipo (la decisión la toma quien tiene la información).
- Build integrity in — Construir con integridad (calidad como propiedad emergente, no como fase de QA al final).
- See the whole — Ver el todo (optimizar el sistema completo, no las partes).
Te invito a comparar esos 7 con tu última experiencia laboral. La mayoría de los equipos hace lo opuesto en al menos cuatro de los siete. Particularmente:
- Decidir tarde se confunde con “no decidir” — y son cosas distintas. Decidir tarde significa diseñar para mantener opciones abiertas, no postergar el problema.
- Build integrity in es el principio que justifica los tests, los code reviews, el type-checking estricto, la observabilidad. No son “actividades de calidad”. Son la única forma de que el sistema no se desmorone solo.
- See the whole es lo que evita la enfermedad clásica del frontend optimizando su build mientras el backend tiene una p99 de 8 segundos.
El diagrama mental: push vs pull
Esta diferencia merece un diagrama, porque es lo más concreto que tiene Lean.
En push, alguien arriba decide todo y empuja trabajo hacia abajo. El equipo recibe lo que se decidió hace meses, lo construye, y descubre al final que el mundo cambió. En pull, el equipo decide qué construir basado en lo que acaba de aprender del último deploy. La única forma de hacer pull es tener ciclos de entrega cortos — porque sin ciclo corto, no hay aprendizaje que jalar.
Esto es exactamente lo mismo que Womack y Jones decían con sus 5 principios. Sólo que ahora aplica a un ticket en lugar de a un coche.
Lean Startup — el descendiente que conviene matizar
En 2011, Eric Ries publicó The Lean Startup (Crown Business). El libro vendió millones, popularizó tres palabras —MVP, validated learning, pivot— y se convirtió en lectura obligatoria de cualquier startup deck de los 2010s. Ries era discípulo de Steve Blank, y Blank a su vez tomó parte del lenguaje de los Poppendieck, así que la cadena de transmisión está documentada.
Lo que Ries hizo bien: trasladar la idea de pull (ciclo corto + aprendizaje) al desarrollo de producto en empresas chicas con incertidumbre extrema. La fórmula central es honesta y útil: Build → Measure → Learn. Construye una versión mínima, mídela en uso real, aprende, repite.
Lo que la industria hizo mal con Lean Startup:
- Convirtió MVP (“la versión más chica que valida una hipótesis”) en “la versión más cutre con la que sales a vender”. No es lo mismo.
- Convirtió pivot (“cambio fundamental de hipótesis basado en datos”) en “cambio de plan porque hoy lo decidió el founder”. Un pivot sin aprendizaje previo es sólo improvisación.
- Y olvidó la parte de measure, que es la más cara. Sin instrumentación seria, “lean startup” es manualidades en PowerPoint.
Frase de Ries que sí vale guardar: “The only way to win is to learn faster than anyone else.”
(La única forma de ganar es aprender más rápido que cualquier otro.)
Esa frase, leída con cuidado, es la versión moderna de lo que Ohno predicaba. Lo difícil es que aprender rápido cuesta disciplina: instrumentación, tests, deploy continuo, feedback de usuarios reales. Las startups que dicen ser lean y no tienen analytics serias, no son lean.
Para programadores: el playbook pragmático
Llevándolo a tierra. Si tienes un equipo de software y quieres aplicar Lean sin perderte en el camino, aquí va una receta corta:
1. Atacar Waiting antes que Motion
La muda más cara en software es esperar. Casi cada bug en producción que costó dinero estuvo precedido por un PR esperando review 4 días. El plan:
- Code review máximo 1 día. Si un PR se atora más, algo está mal en el proceso, no en el revisor.
- Deploy diario o por demanda. Si tu equipo despliega los viernes, el cuello de botella es el viernes.
- Pair / mob programming en piezas críticas. No es ineficiente: elimina el ciclo autor → review → cambios → re-review.
2. Atacar Overproduction con disciplina brutal
Cada feature construida que nadie usa es dinero quemado y deuda futura. Antes de construir, una sola pregunta: “¿qué decisión cambia esto si lo construimos?”. Si la respuesta es “ninguna” o “no sé”, no se construye.
Concretamente:
- Hipótesis explícita por feature, escrita antes de codificar (1 párrafo, no un PRD).
- Métrica de éxito definida antes del deploy.
- Auditoría trimestral de features sin uso. Lo que no se usa, se borra, no se “deja por si acaso”.
3. Reducir el tamaño del lote (rebanar fino)
Lo mismo que en Agile, pero por la razón Lean: lotes grandes esconden defectos. Un PR de 1500 líneas es indetectable; uno de 80 se revisa en 10 minutos. Una entrega trimestral oculta el problema; una semanal lo expone temprano cuando es barato arreglarlo.
Esta es probablemente la práctica más demostrablemente buena del oficio. Y es la más difícil de adoptar porque exige planeación distinta y disciplina diaria.
4. Genchi Genbutsu — ve y mira
Concepto japonés del TPS: genchi genbutsu (現地現物), literalmente “lugar real, cosa real”. Toyota lo usa así: si hay un problema, vas al piso de fábrica y lo ves con tus propios ojos. No lo decides en una junta con un reporte.
En software esto traduce a:
- Hablar con usuarios reales antes de diseñar features. Sin intermediarios.
- Mirar logs de producción cuando hay un bug, no leer el resumen de soporte.
- Asistir a una llamada de soporte una vez al mes si construyes producto B2B. Vas a aprender cosas que ningún dashboard te enseña.
Una decisión técnica tomada desde un brief es probablemente mala. Una decisión técnica tomada después de mirar 30 minutos de uso real, casi siempre acierta.
5. Visualizar el trabajo
Tablero. Físico o digital, no importa. Pero visible — que cualquiera del equipo pueda ver dónde está cada cosa de un vistazo. Con WIP limits. Con una columna de “esperando” y una de “bloqueado”, separadas. Si tu Jira no muestra dónde está atorado el flujo, no estás haciendo Kanban, estás llenando tickets.
Lo que no se transfiere
Para honestidad: hay piezas del TPS original que no se traducen bien a software. No vale la pena forzarlas.
- 5S (Seiri, Seiton, Seiso, Seiketsu, Shitsuke — clasificar, ordenar, limpiar, estandarizar, sostener). En una fábrica tiene sentido. En un repo de software es a lo más una buena metáfora; intentar implementarlo literalmente produce documentos absurdos.
- Heijunka (nivelación de la producción): pretende repartir variedad de productos uniformemente en el tiempo. En software tiene un eco lejano (no acumular release-megalíticos), pero la mecánica es muy distinta.
- Just-in-time inventory: en software no hay inventario en sentido estricto, así que la idea sólo se aplica metafóricamente.
Si alguien te quiere vender Lean Six Sigma para software o Lean Coding en taller de fin de semana, está vendiendo decoración. La parte aprovechable de Lean para software cabe en el playbook de arriba.
La frase que sí vale guardar
De Taiichi Ohno, en el capítulo introductorio de su libro de 1978:
“All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing that time line by removing the non-value-added wastes.”
(Todo lo que estamos haciendo es mirar la línea del tiempo, desde que el cliente nos da una orden hasta el momento en que cobramos el dinero. Y estamos reduciendo esa línea quitando los desperdicios que no agregan valor.)
Esa frase, traducida a software, es: mira el tiempo desde que un usuario tiene una necesidad hasta que tiene una solución funcionando frente a él. Reduce ese tiempo eliminando todo lo que no agrega valor en medio.
Eso es Lean. Lo demás es decoración con palabras niponas.
Lecturas que sí valen la pena
- Taiichi Ohno (1978, ed. inglés 1988), Toyota Production System: Beyond Large-Scale Production (Productivity Press) — la fuente primaria, sin filtros. Léelo después de cualquier introducción para verificar.
- John Krafcik (1988), “Triumph of the Lean Production System” — el artículo de MIT Sloan Management Review donde se acuña el término lean.
- James Womack, Daniel Jones, Daniel Roos (1990), The Machine That Changed the World (Rawson Associates) — el estudio MIT que llevó Lean al mundo.
- James Womack & Daniel Jones (1996, rev. 2003), Lean Thinking: Banish Waste and Create Wealth in Your Corporation (Free Press) — los 5 principios.
- Jeffrey Liker (2004), The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer (McGraw-Hill) — el panorama completo, incluyendo cultura y management.
- Mary & Tom Poppendieck (2003), Lean Software Development: An Agile Toolkit (Addison-Wesley) — la traducción canónica al software.
- Donald Reinertsen (2009), The Principles of Product Development Flow — el tratado riguroso, con teoría de colas, sobre por qué los lotes pequeños y los WIP limits funcionan matemáticamente.
- Eric Ries (2011), The Lean Startup (Crown Business) — útil para producto y startups, con la advertencia de matizar la versión popularizada.
- Lean Enterprise Institute (lean.org) — fundado por Womack en 1997, mantiene la fuente más actualizada y menos viciada.
Y si te llevas una sola idea de todo el post: Lean no es ahorrar costos. Lean es acortar el tiempo entre el momento en que alguien necesita algo y el momento en que lo recibe funcionando. Si lo que estás haciendo en tu equipo no acorta ese tiempo, no es Lean — aunque tenga el nombre en la diapositiva.