Lean, XP y Mentalidad de producto. Tres pilares para un desarrollo sostenible

Cuando hablamos de desarrollar software de forma sostenible, no estamos hablando solo de cuidar el código o de ir a una velocidad razonable. Nos referimos a la capacidad de construir productos útiles, con calidad técnica, en un flujo continuo, sin quemar al equipo y sin hacer que el sistema colapse con cada cambio.Es un equilibrio difícil. Sin embargo, en los últimos años he ido viendo cómo ciertos enfoques nos han ayudado una y otra vez a mantenerlo.

No son ideas nuevas ni especialmente exóticas. Pero cuando se combinan bien, pueden marcar la diferencia. Me refiero a tres pilares concretos: las prácticas de Extreme Programming (XP), el pensamiento Lean aplicado al desarrollo de software, y una mentalidad de producto que nos impulsa a construir con propósito y entender el “porqué” detrás de cada decisión.

Curiosamente, aunque a veces se presentan como enfoques distintos, XP y Lean Software Development tienen raíces y objetivos muy similares. De hecho, muchos de los principios de Lean —como eliminar desperdicio, optimizar el flujo o fomentar el aprendizaje continuo— están profundamente presentes en la forma de trabajar de XP. No es casualidad: Kent Beck, creador de XP, fue uno de los primeros en aplicar el pensamiento Lean al desarrollo de software, incluso antes de que este se popularizara con ese nombre. Como él mismo escribía:

"If you eliminate enough waste, soon you go faster than the people who are just trying to go fast." — Kent Beck, Extreme Programming Explained (2nd ed.), Chapter 19: Toyota Production System

Esta cita de Kent Beck resume la esencia de la eficiencia a través de la eliminación de lo superfluo.

No pretendo decir que esta sea la única forma válida de trabajar, ni que todo equipo tenga que funcionar así. Pero sí quiero compartir que, en mi experiencia, cuando estos tres pilares están presentes y equilibrados, es mucho más fácil mantener un ritmo sostenible, adaptarse al cambio, y crear algo que realmente aporta valor. Y cuando falta alguno, por lo general, se nota.

Este artículo no es una receta, sino una reflexión sobre lo que hemos ido aprendiendo como equipos al construir productos reales, con ciclos de vida largos, bajo presión de negocio y con la necesidad de mantener el control técnico, una forma concreta que nos ha funcionado para hacer “la cosa correcta, de la forma correcta… y sin desperdicio”.

Hacer la cosa correcta, de forma correcta… y sin desperdicio

Hay una frase que me gusta mucho y que resume bien el tipo de equilibrio que buscamos: hacer la cosa correcta, de la forma correcta. Esta frase se ha atribuido a Kent Beck y también la ha usado Martin Fowler en algunos contextos. En nuestra experiencia, esta frase se queda corta si no añadimos una tercera dimensión: hacerlo sin desperdicio, de forma eficiente y fluida. Porque puedes estar haciendo lo correcto, hacerlo bien, y aun así hacerlo con un coste o una lentitud que lo haga insostenible.

A lo largo de los años, hemos visto cómo trabajar de esta manera —haciendo lo correcto, de forma correcta y sin desperdicio— requiere tres pilares:

• Hacer lo correcto implica entender qué problema hay que resolver, para quién, y por qué. Y esto no se puede delegar fuera del equipo técnico. Requiere que quienes diseñan y desarrollan el software también piensen en producto, en impacto y en negocio. Es lo que en muchos contextos se ha llamado Mentalidad de Producto: vernos como un equipo de producto, donde cada persona actúa desde su disciplina, pero siempre con una mirada de producto.
• Hacerlo de forma correcta significa construir soluciones que sean mantenibles, testeables, que nos den confianza para evolucionar sin miedo y que lo hagan a un ritmo sostenible, respetando a las personas. Aquí entran de lleno las prácticas de Extreme Programming.
• Y hacerlo sin desperdicio nos lleva a optimizar el flujo de trabajo, a eliminar todo lo que no aporta valor, a posponer decisiones que no son urgentes y a reducir el coste basal del sistema. De nuevo, mucho del pensamiento Lean nos ayuda aquí.

Estas tres dimensiones no son independientes. Se refuerzan entre sí. Cuando falla una, normalmente se resienten las otras. Y cuando conseguimos que las tres estén presentes, aunque sea a un nivel básico, es cuando el equipo empieza a funcionar con fluidez y con impacto real.

Los tres pilares

A lo largo del tiempo, hemos ido viendo que cuando un equipo tiene estos tres pilares presentes —XP, Lean Thinking y Product Engineering— y los mantiene equilibrados, el resultado es un sistema de trabajo que no solo funciona, sino que aguanta. Aguanta el paso del tiempo, los cambios de estrategia, los picos de presión y las decisiones difíciles.

1. XP: evolucionar sin romper

Las prácticas de Extreme Programming son lo que nos permiten construir software que se puede cambiar. Tests automatizados, integración continua, TDD, diseño simple, refactorización frecuente… todo eso está al servicio de una idea muy simple: si queremos evolucionar, necesitamos ciclos de retroalimentación muy cortos que nos permitan ganar confianza rápidamente.

Con XP, la calidad no es un objetivo separado. Es la base sobre la que se apoya todo lo demás. Poder desplegar cada día, hacer experimentos, probar cosas nuevas, reducir el coste de equivocarse… todo eso depende de que el sistema no se nos caiga cada vez que tocamos algo.

"The whole organization is a quality organization." — Kent Beck, Extreme Programming Explained (2nd ed.), Chapter 19: Toyota Production System

Recuerdo, en Alea, cambiar el núcleo de un producto (sistema de provisión de routers de fibra) en menos de una semana, pasando de funcionar de forma síncrona a asíncrona. Nos apoyamos en los tests principales con la lógica de negocio y fuimos cambiando todos los puntos de entrada del componente poco a poco, test a test. O en The Motion, donde cambiamos en paralelo toda la arquitectura del componente que calculaba el estado y el resultado de los lotes de vídeos que generábamos, para que pudiera escalar a lo que el negocio necesitaba.

Hacer este tipo de cambios en un sistema que no hubiese usado buenas prácticas de ingeniería moderna (XP/CD) habría sido un drama, o incluso se habría descartado totalmente, optando por el parche sobre parche hasta tener que declarar la bancarrota técnica y rehacer el sistema desde cero.

Sin embargo, para nosotros, gracias a XP, era simplemente trabajo normal: conseguir mejoras de escalabilidad o adaptar un componente a cambios del fabricante. Nada excepcional.

Nada de esto sería posible sin equipos que puedan mantener un ritmo constante en el tiempo, porque XP no solo se busca construir sistemas flexibles y robustos, sino también de cuidar a las personas que los desarrollan.

XP no sólo impulsa la sostenibilidad técnica del producto, sino también un ritmo de trabajo sostenible, que incluye holgura productiva para ser creativos, aprender e innovar. Evita “marchas de la muerte” y esfuerzos heroicos que agotan y reducen la calidad. La regla de las 40 horas semanales de Kent Beck refleja una idea clave: la calidad no se sostiene con equipos exhaustos; el exceso de horas reduce la productividad y aumenta los errores.

2. Lean Thinking: foco en valor y eficiencia

El pensamiento Lean nos da herramientas para priorizar, simplificar y eliminar lo innecesario. Nos recuerda que hacer más no siempre es mejor, y que cada línea de código que escribimos tiene un coste de mantenimiento. A menudo, lo más valioso que podemos hacer es no construir nada.

Aplicamos principios como eliminar desperdicio, posponer decisiones hasta el último momento responsable (defer commitment), medir el flujo en lugar de la ocupación o aplicar sistemáticamente YAGNI. Esto nos ha permitido evitar complejidades prematuras y reducir el trabajo innecesario.

En todos los equipos con los que he trabajado hemos simplificado procesos: eliminando ceremonias, trabajando en pasos pequeños y sólidos, prescindiendo de estimaciones y orientándonos a un flujo continuo. Asimismo, hemos reutilizado tecnología “aburrida” antes de introducir nuevas herramientas, y buscado siempre minimizar el coste basal de cada solución, eliminando funcionalidades no usadas cuando es posible.

Recuerdo, en Alea, que durante los primeros meses del sistema de provisión de routers de fibra almacenábamos todo en un par de ficheros de texto, sin base de datos. Esto nos permitió lanzar rápido y migrar a algo más complejo solo cuando fue necesario. O en Clarity AI, donde nuestro bot de operaciones evitó mantener estado aprovechando el que ya guardan los sistemas que opera (como AWS) y prescindió de un sistema propio de autenticación y autorización, usando el que ya ofrece Slack, que es su interfaz principal.

Estos enfoques nos han ayudado a centrarnos en lo esencial, reducir costes y mantener la flexibilidad para adaptarnos cuando las necesidades realmente lo requieren.

3. Mentalidad de Producto: entender el problema, no solo construir la solución

Y, por último, el pilar que más a menudo se olvida o se subcontrata mentalmente: entender el problema.
Como equipo de producto, no podemos limitarnos a ejecutar tareas desde nuestras disciplinas; necesitamos implicarnos en el impacto de lo que construimos, en la experiencia del usuario y en el porqué de cada decisión.

Cuando el equipo asume esta mentalidad, la forma de trabajar cambia por completo. Desaparece la línea divisoria entre “negocio” y “tecnología”, y empezamos a pensar como un todo. No significa que todos hagan de todo, pero sí que compartimos la responsabilidad sobre el resultado final.

En la práctica, esto implica priorizar problemas antes que soluciones, descartar funcionalidades que no aportan valor aunque ya estén planificadas, y mantener abiertas las opciones técnicas hasta contar con datos y feedback reales. El trabajo se organiza en incrementos verticales pequeños y funcionales, entregando mejoras casi a diario para validar hipótesis con usuarios y evitar grandes entregas llenas de incertidumbre. Gracias a esto, este enfoque permite adaptar en pocas horas procesos críticos a cambios de requisitos o contexto, sin comprometer la estabilidad ni la experiencia del usuario.

No todos los pilares aparecen a la vez

Una de las cosas que he aprendido con el tiempo es que los equipos no arrancan desde el equilibrio. A veces heredas un equipo con un nivel técnico muy sólido, pero sin ninguna conexión con el producto. Otras veces llegas a un equipo que tiene buen criterio sobre qué construir, pero que vive en una trinchera de código imposible de mantener. O el equipo está tan ahogado por los procesos y las dependencias que ni siquiera puede salir a producción con fluidez.

Lo primero, en esos casos, no es meter una metodología o una práctica concreta. Es entender. Ver cuál de los pilares está más débil y trabajar en mejorarlo hasta que, al menos, te permita avanzar. Si el equipo no puede desplegar sin sufrir, importa poco que entienda perfectamente el producto. Si el equipo construye rápido pero lo que hace no lo usa nadie, el problema está en otra parte.

Nuestro enfoque ha sido siempre buscar un cierto equilibrio de base, aunque sea en un nivel muy inicial, y a partir de ahí mejorar en los tres pilares a la vez. En pasos pequeños. Sin grandes revoluciones.

El objetivo no es alcanzar la perfección en ninguno de los tres, sino evitar que alguno falle tanto que el equipo quede bloqueado o se frustre. Cuando conseguimos que los tres estén razonablemente presentes, la mejora se retroalimenta. Aumentar la calidad permite probar más cosas. Entender mejor el producto permite reducir código innecesario. Mejorar el flujo hace que podamos aprender más rápido.

Cuando falta algún pilar…

Con el tiempo, también hemos visto lo contrario: qué pasa cuando alguno de los pilares no está. A veces parece que el equipo funciona, pero hay algo que no termina de encajar, y al final siempre acaba apareciendo la factura.

• Equipos sin autonomía se convierten en meros ejecutores, sin impacto ni motivación.
• Equipos sin prácticas técnicas acaban atrapados en su propia complejidad, incapaces de evolucionar sin romper cosas.
• Equipos sin foco en valor son capaces de construir rápido… basura rápida.

Y muchas veces, el problema no es técnico sino estructural. Como bien apunta Kent Beck:

"The problem for software development is that Taylorism implies a social structure of work... and it is bizarrely unsuited to software development." — Kent Beck, Extreme Programming Explained (2nd ed.), Chapter 18: Taylorism and Software

En algunos contextos se puede trabajar para recuperar el equilibrio. Pero también hay veces en las que el propio entorno no lo permite. Cuando no hay espacio para que el equipo tome decisiones, ni siquiera para mejorar sus propias dinámicas o herramientas, la situación se vuelve muy difícil de sostener. En mi caso, cuando no ha sido posible cambiar eso desde dentro, he preferido cambiar de contexto directamente.

Solo una forma entre muchas

Todo lo que cuento aquí viene de mi experiencia en empresas de producto. Equipos que construyen sistemas que tienen que evolucionar, que tienen vidas largas, que están bajo presión de negocio y que no pueden permitirse tirar todo a la basura cada seis meses.
No es el único contexto posible. En entornos más orientados a servicios o consultoría, las dinámicas pueden ser distintas. Se trabaja con otros ritmos, con otras responsabilidades y con otras prioridades. No tengo experiencia directa en esos contextos, por lo que no opinaré sobre lo que funcionaría mejor allí.

Solo quiero dejar claro que esto que propongo es una forma, no la forma. Pero también he visto muchas otras que, sin unos pilares mínimos de disciplina técnica, enfoque en el valor real y una búsqueda constante de la eficiencia, simplemente no funcionan a medio o largo plazo en entornos de producto que necesitan evolucionar. Mi experiencia me dice que, si bien no tienes que seguir esto al pie de la letra, tampoco puedes esperar grandes resultados si te dedicas a 'guarrear' el código, a construir sin entender el problema o a generar desperdicio por doquier.

Esta combinación, en cambio, es la que más veces ha resistido el paso del tiempo, los cambios de dirección, la presión y la incertidumbre. Y es la que ha hecho que muchos equipos no solo funcionen bien, sino que disfruten de lo que hacen.

Reflexión final

Construir software sostenible no es solo una cuestión técnica. Es un equilibrio entre hacer lo correcto, hacerlo bien y hacerlo sin desperdicio. Y para eso, necesitamos algo más que prácticas o procesos. Necesitamos una forma de trabajar que nos permita pensar, decidir y construir con sentido.

En nuestro caso, eso ha pasado por apoyarnos en tres patas: XP, Lean y Product Engineering. No siempre hemos tenido las tres a la vez. A veces hemos tenido que fortalecer una para poder avanzar con las otras. Pero cuando están presentes, cuando se refuerzan entre sí, el resultado es un equipo que puede entregar valor de forma continua, adaptarse, y crecer sin agotarse.

Ojalá este artículo te sirva para reflexionar sobre cómo trabajas, qué patas tienes más fuertes, y cuáles podrías empezar a equilibrar.

Optimizar el Todo: del principio Lean a la práctica real

Introducción

"Optimizar el todo" es uno de los principios fundamentales de Lean y Lean Software Development. Implica dejar de lado las mejoras locales para mirar el sistema completo, desde la idea hasta el usuario —personas, procesos y tecnología— y alinear todo hacia un objetivo común: entregar valor al usuario de forma rápida y sostenible.

En mi experiencia, muchos equipos creen que están siendo eficientes porque nadie para de trabajar, pero al final el usuario espera semanas (o meses) para ver valor real. He aprendido que la verdadera mejora nace de una visión sistémica, cooperando para que el flujo de valor fluya sin fricciones de extremo a extremo.

Fragmentación: Herencia del Taylorismo

El paradigma del desarrollo de software ha heredado, a menudo inconscientemente, principios arraigados en el tayloismo y el fordismo, concibiendo la creación de productos digitales como una "cadena de montaje" fragmentada. Bajo esta visión, cada fase (análisis, diseño, desarrollo, QA, operaciones) se convierte en un silo funcional, donde los equipos se especializan en tareas específicas y se enfocan en optimizar su eficiencia local.

Sin embargo, lo que en la fabricación de bienes físicos pudo generar economías de escala para la producción en masa, con el tiempo también ha demostrado sus límites al sacrificar la flexibilidad y la capacidad de adaptación rápida a cambios en la demanda o las necesidades del usuario.

En el software, esto se traduce en cuellos de botella crónicos, handoffs costosos y una desconexión fundamental entre quienes definen las necesidades y quienes las implementan. Esta fragmentación rompe el flujo de valor, fomenta la acumulación de "inventario" de trabajo a medio hacer y dificulta la adaptación rápida, resultando en funcionalidades que no resuelven problemas reales o que tardan meses en llegar al usuario, desvirtuando la promesa de agilidad y valor continuo.

Comparison of Taylorism, Fordism, and Lean Thinking—highlighting their core principles and how each has influenced software development practices.

¿Qué ocurre cuando no optimizamos el todo?

A lo largo de los años trabajando con diferentes equipos, he observado que cuando no optimizamos el todo, caemos en la trampa de optimizar localmente, casi siempre con buena intención pero con consecuencias no deseadas. Los equipos pueden volverse muy "eficientes" en sus propias métricas internas, pero si no están alineados con el valor al usuario, el flujo global se ralentiza. Surgen cuellos de botella, se multiplican los handoffs y el trabajo queda atascado esperando en algún sitio.

He visto esto especialmente cuando ingeniería o desarrollo se ve como una fábrica de funcionalidades que "ejecuta" o "implementa" lo que otros deciden. El equipo se limita a implementar, sin entender el problema, la prioridad ni el impacto real en el usuario. Sin aportar su conocimiento técnico a las decisiones. El resultado: soluciones desconectadas de las necesidades reales, feedback lento y funcionalidades que no resuelven el problema.

En mi experiencia, la causa de fondo suele ser una estructura organizativa funcional y fragmentada, heredada del pensamiento "cadena de montaje". Pero he aprendido que el software no se comporta como una fábrica lineal. El software necesita equipos de producto con responsabilidad extremo a extremo, sin silos (backend, frontend, QA, ops, diseño, etc), y con autonomía real para tomar decisiones y operar lo que construyen.

He comprobado que esto no es solo una cuestión de motivación: es la única manera de optimizar el flujo total y entregar valor real al usuario de forma rápida y sostenible.

Cuellos de botella y la Teoría de Restricciones

La Teoría de las Limitaciones (TOC por sus siglas en inglés) nos recuerda que en cualquier sistema siempre existe al menos una restricción que determina la capacidad máxima de entrega. Identificar y gestionar ese cuello de botella es esencial para mejorar el flujo global.

Por ejemplo, en ClarityAI, al principio se sacaban funcionalidades a producción que podían quedarse semanas detrás de un feature toggle, esperando que producto decidiera cuándo abrirlas al usuario. Aunque técnicamente ya estaban listas, el valor no fluía.

Otro ejemplo: cuando existían flujos de trabajo separados por funciones (frontend, backend, data engineering), cualquier cambio podía tardar semanas porque cada grupo optimizaba su propio flujo o cola de trabajo, en lugar de pensar en el flujo global desde el punto de vista del usuario.

(Por suerte, estos problemas específicos en Clarity AI hace tiempo que los solucionamos, pero sirven como ejemplo de lo que puede ocurrir cuando no optimizamos el todo.)

En mi experiencia trabajando con diferentes equipos, he aprendido que acelerar todo indiscriminadamente solo empeora la acumulación y genera frustración. 

Una condición necesaria para poder identificar restricciones reales es que todo el trabajo esté visible. No solo las tareas de desarrollo, sino también testing, operaciones, soporte, automatización, documentación, análisis, coordinación, etc. Si una parte importante del esfuerzo del equipo queda oculta (porque no se registra, no se visualiza o no se considera "trabajo técnico"), es muy fácil que las restricciones reales pasen desapercibidas. Como plantea Dominica DeGrandis en Making Work Visible, lo que no se ve no se puede gestionar ni mejorar. Hacer visible todo el trabajo es un paso clave para tomar decisiones informadas, reducir el trabajo en curso y enfocar mejor los esfuerzos de mejora continua.

La clave está en:

• Identificar la restricción. Hacerla visible y priorizarla.
• Explotar la restricción. Darle foco, evitar distracciones y asegurar que siempre trabaje en lo que más valor aporta.
• Subordinar el resto del sistema. Ajustar ritmos y prioridades para no saturar la restricción.
• Elevar la restricción. Mejorar su capacidad mediante automatización, formación o rediseño de procesos.
• Revisar y repetir. Siempre habrá una nueva restricción tras cada mejora.

A lo largo de los años, he observado que cuantas más etapas separadas con colas existan entre la idea y el valor entregado al usuario, más posibilidades hay de que se formen cuellos de botella. Además, si cada etapa pertenece a un grupo distinto (organizativamente hablando), que incluso puede tener agendas propias, es probable que ni siquiera exista interés en optimizar el valor para el usuario. En estos casos, cada grupo puede centrarse únicamente en mejorar su parte del proceso o en no ser percibido como el cuello de botella.

Equipos end-to-end y optimización real

En todos los equipos que he creado, he insistido en que fueran equipos de producto con responsabilidad de extremo a extremo, sin silos para QA, operaciones, seguridad o diseño. La razón es simple: si el equipo no controla ni comprende todo el flujo, no puede optimizar el conjunto y, además, corre el riesgo de no asumir la responsabilidad sobre el producto completo.

Cuando el mismo equipo se encarga de idear, construir, desplegar y operar, se elimina el desperdicio que surge en cada traspaso y se acelera el aprendizaje. Cada miembro entiende el impacto de su trabajo en el usuario final y el valor que realmente se entrega. La responsabilidad end-to-end no solo mejora la calidad técnica, sino que refuerza el enfoque en el valor para el usuario, evitando inversiones innecesarias en optimizaciones locales que no aportan al objetivo global.

En este entorno de trabajo, los perfiles más generalistas, a menudo denominados "T" (por su profundidad en un área y amplitud en otras) o "M" (con varias especializaciones profundas y amplia versatilidad), son especialmente valorados. Estos profesionales, al poder contribuir en múltiples fases del desarrollo y tener una visión más holística, resultan clave donde la eficiencia de flujo es prioritaria.

Si bien los especialistas puros, también conocidos como "perfiles I", siguen siendo necesarios en dominios muy específicos, su rol se transforma: se convierten en habilitadores y educadores, ayudando a escalar su conocimiento y a capacitar al resto del equipo en diversas facetas del producto.

Además, mantener opciones abiertas, trabajar en ciclos cortos y hacer entregas pequeñas permite adaptarse mejor a lo que el negocio y los datos van mostrando. La simplicidad y el corte vertical reducen el riesgo y facilitan el aprendizaje rápido, liberando al equipo de la carga mental de grandes planes cerrados y fomentando la autonomía.

Esta forma de trabajo es inviable cuando el producto debe pasar por diferentes silos antes de llegar al usuario final.

Equipos end-to-end en la práctica: experiencias reales

Cuando formé el equipo en Alea Soluciones, desde el principio empujé para que asumiéramos todas las tareas y funciones posibles. Recuerdo que tanto el CEO como el CTO me ofrecieron la opción de asumir menos responsabilidades, "para tener menos presión y menos trabajo". Pero rechacé esa propuesta: sabía que si nos quedábamos solo con una parte, perderíamos la visión global y la capacidad de optimizar el sistema completo.

Al asumir todas las áreas —desarrollo, soporte, ideas de producto, operación— logramos mantener siempre una visión holística del producto. Esto nos permitió identificar en cada momento dónde estaba el cuello de botella real y actuar donde más impacto podíamos tener, sin depender de otros equipos ni de silos funcionales. Así podíamos decidir si, en un momento concreto, tenía más sentido centrarnos en soporte, en acelerar desarrollos clave o en pensar nuevas funcionalidades, siempre optimizando el flujo total de valor para el usuario.

En Nextail y en Clarity AI, junto con más personas, trabajé para que los equipos evolucionaran hacia un modelo end-to-end, evitando silos de QA, operaciones o producto. En estos casos, aplicamos ideas de Team Topologies para transformar la estructura: pasamos de una organización basada en funciones (infraestructura/operaciones, frontend, backend, data engineering, producto) a una organización matricial de equipos de producto autónomos.

El objetivo siempre fue el mismo: acortar el lead time de cualquier cambio, desde la idea hasta que el usuario lo puede usar. Con equipos autónomos y responsables de extremo a extremo, podíamos entregar valor más rápido, aprender continuamente y mejorar el producto en ciclos muy cortos.

En todos estos contextos, he comprobado que el enfoque end-to-end no solo ha sido una mejora técnica u organizativa: ha sido la clave para mantener una mentalidad centrada en el usuario, reducir desperdicio y optimizar el conjunto, cada día.

Cómo optimizar el todo ayuda a eliminar desperdicio

Uno de los principios fundamentales de Lean es eliminar el desperdicio. Cuando nos enfocamos solo en optimizar partes locales, es muy fácil acumular trabajo que no aporta valor, crear funcionalidades innecesarias o generar retrasos invisibles. En cambio, al optimizar el todo y mirar el sistema completo, reducimos de manera natural múltiples tipos de desperdicio.

En mi trabajo con diferentes equipos, he observado que cuando no pensamos en el flujo global y nos centramos en optimizar "mi parte", aparecen incentivos para generar más funcionalidades, aunque no aporten valor real al usuario. Se prioriza "estar ocupados" y terminar tareas, en lugar de cuestionar si son necesarias.

He visto cómo al no tener feedback temprano y trabajar en ciclos largos, se avanza sin validar y se terminan construyendo funcionalidades que nadie pidió o que no resuelven ningún problema importante.

Además, cuando las decisiones están fragmentadas (producto define grandes paquetes, ingeniería ejecuta sin cuestionar, y QA valida después), se pierde la visión de impacto y se tiende a hinchar el backlog con funcionalidades que quedan bloqueadas tras un feature toggle o, directamente, nunca se lanzan.

Al optimizar el todo y alinear cada paso con el flujo completo de valor hacia el usuario, cada funcionalidad se revisa con preguntas clave:

• ¿Resuelve un problema real y prioritario?
• ¿Podemos lanzarla en pequeño para aprender rápido?
• ¿Cómo sabremos si realmente aporta valor?

Así, se construye solo lo necesario, se aprende pronto y se evita transformar esfuerzo en desperdicio.

• Evitar funcionalidades innecesarias (sobreproducción): Al priorizar valor real para el usuario y trabajar en entregas pequeñas, se validan hipótesis rápido. Así, evitamos desarrollar grandes funcionalidades que después nadie usa o que el negocio decide no lanzar.
• Reducir esperas y bloqueos (tiempos de espera): Al eliminar silos y trabajar de extremo a extremo, el trabajo no se queda atascado esperando a que otro equipo o función lo retome. Esto acelera el flujo y elimina tiempos muertos.
• Menos retrabajo y correcciones tardías: Entregar en ciclos cortos y validar pronto permite detectar problemas rápidamente y corregirlos con bajo coste. De lo contrario, pequeñas decisiones locales pueden acabar en grandes refactorizaciones posteriores.
• Evitar optimizaciones locales inútiles (movimiento innecesario): Optimizar tu propio "departamento" o tu cola de trabajo puede dar una falsa sensación de eficiencia, pero no genera valor si no avanza el flujo completo. Mirar el sistema global evita este tipo de desperdicio.
• Reducir inventario oculto: Limitar el trabajo en curso y priorizar flujo constante minimiza el inventario de funcionalidades medio hechas o pendientes de lanzamiento, que consumen energía y generan confusión.
• Menor desperdicio de oportunidad: Al tener una visión clara del todo y estar alineados con el negocio, se evita invertir en direcciones equivocadas y se responde rápido a nuevas oportunidades. Esto reduce el riesgo de perder el momento correcto para impactar al usuario.

En mi experiencia, cuando optimizamos el sistema completo, cada decisión se toma pensando en el flujo de valor hacia el usuario final. Así, cada línea de código, cada validación y cada despliegue contribuye a reducir el desperdicio y maximizar el impacto.

Cómo optimizar el todo: aprendizajes en la práctica

• Visión extremo a extremo: Desde el problema de negocio hasta el software funcionando y operado por el propio equipo. Sin fragmentar ni ceder responsabilidad a "otros".
• Flujo sobre ocupación: Dejamos de medir cuánto trabaja cada persona y pasamos a medir cuánto valor fluye hasta el usuario.
• Prácticas habilitadoras: Pair programming, TDD, CI/CD, limitar el WIP y visualizar el flujo… Son herramientas clave para mantener el sistema sano, adaptable y preparado para aprender rápido.
• Entregas pequeñas y feedback inmediato: Cada entrega es una oportunidad de aprendizaje. Trabajar en cortes verticales ayuda a priorizar lo que realmente importa, fomenta la simplicidad y reduce el miedo a equivocarse.
• Colaboración y seguridad psicológica: Transparencia, confianza y responsabilidad compartida. Se fomenta cuestionar, proponer mejoras y experimentar sin miedo.
• Empoderamiento consciente: Los equipos asumen más decisiones a medida que demuestran capacidad, siempre alineados con el negocio y con foco en el impacto real.

Por qué "Optimizar el todo" importa

Optimizar el todo es crucial porque aborda una contradicción fundamental en muchas organizaciones: la búsqueda de la eficiencia de recursos frente a la eficiencia de flujo. Tradicionalmente, se ha incentivado que cada persona, equipo o etapa de un proceso esté lo más "ocupado" posible, buscando maximizar el uso individual de los recursos. Sin embargo, esta obsesión por la eficiencia local de recursos (que nadie esté parado) suele ser catastrófica para la eficiencia de flujo, es decir, la velocidad y suavidad con la que el valor llega desde la idea inicial hasta las manos del usuario final.

Cuando cada componente del sistema se centra en su propia optimización, se generan cuellos de botella, colas de espera y handoffs que rompen la continuidad del flujo. Paradójicamente, cuando "todo el mundo está muy ocupado" suele ser una clara indicación de que existe un problema importante con el flujo de valor al usuario. El trabajo se amontona, las entregas se retrasan, y la organización está invirtiendo un gran esfuerzo en actividades que no se traducen rápidamente en valor real.

Al optimizar el todo, logramos:

• Evitar cuellos de botella invisibles que bloquean el valor al usuario, al tener una visión global del sistema.
• Reducir drásticamente el desperdicio: funcionalidades no usadas, esperas interminables, retrabajo innecesario y la falsa sensación de productividad.
• Permitir un aprendizaje más rápido y la capacidad de construir solo lo que realmente importa, ya que el ciclo de feedback se acelera.

El verdadero objetivo no es que todos parezcan ocupados, sino que el flujo de valor hacia el usuario sea constante, predecible y sostenible.

Máxima ocupación, mínimo avance. Optimizar el todo es evitar esto.

Conclusión: el impacto transformador

Después de años experimentando con equipos que realmente optimizan el todo, puedo afirmar que ya no quieres volver atrás. Los equipos se vuelven más resilientes, crecen más rápido y encuentran sentido en el trabajo.

He aprendido que optimizar el todo no es solo un principio: es una forma de trabajar que transforma equipos y personas y, sobre todo, maximiza el impacto real para el usuario.

¿Te atreves a empezar a optimizar el todo en tu equipo? El primer paso es atreverse a mirar el sistema completo y dejar de obsesionarse con métricas locales.

Artículos relacionados y otras referencias

• Conceptos Lean interesantes para desarrollo de software
• Eliminar desperdicios en el desarrollo de software
• Empoderar al equipo
• Construyendo con calidad
• Libro Making Work Visible 

Lean Software Development: Superando resistencias y creando condiciones para la calidad

Quinto artículo sobre calidad en Lean Software Development. En los posts anteriores hablamos de cómo construir con calidad desde los errores, el diseño técnico, la colaboración y la visibilidad. Ahora abordamos un tema clave: por qué muchas organizaciones aún no trabajan así, y qué podemos hacer para cambiarlo.

En el mundo del desarrollo de software, existe un mito persistente: que la calidad y la velocidad son fuerzas opuestas, que hay que sacrificar una para obtener la otra. Sin embargo, la realidad, como demuestran los informes DORA y la experiencia de equipos de alto rendimiento, es que la calidad es el camino más directo y sostenible hacia la mayor velocidad posible.

Existe una paradoja fundamental: cuanto más nos obsesionamos con la velocidad inmediata sacrificando calidad, más lentos nos volvemos. Los equipos que acumulan deuda técnica, bugs no resueltos, o código difícil de mantener hacen que cada nueva funcionalidad sea exponencialmente más costosa. Lo que parecía una decisión "pragmática" se convierte en un lastre que ralentiza todo el sistema.

El verdadero pragmatismo está alineado con los principios Lean: posponer decisiones hasta tener información suficiente, aplicar YAGNI (You Aren't Gonna Need It), mantener un diseño simple, e iterar constantemente para tener la versión más sencilla del sistema que cumpla con las necesidades actuales. Esto es ser realmente pragmático.

Es importante entender que en la época que vivimos, de continuo cambio y adaptación del software, cuando hablamos de "medio plazo" en realidad nos referimos a unas pocas semanas. No estamos hablando de meses o años para ver los beneficios de la calidad. Los efectos de trabajar con calidad se notan en muy poco tiempo, y ese supuesto trade-off a corto plazo solo tiene sentido para software de usar y tirar.

En el pensamiento Lean, la forma de tener más impacto es minimizar el desperdicio, siendo la falta de calidad uno de los principales desperdicios en software. Así que la combinación ganadora en desarrollo de software es maximizar el impacto, minimizando la cantidad de software generada, y haciéndolo con calidad en el proceso. El enfoque no es hacer peor o más rápido, sino ser inteligente y disciplinado para conseguir tener más impacto con menos, y con calidad. Esta es la verdadera forma de ir rápido, lograr el máximo impacto y ser un equipo de alto rendimiento sostenible.

Motivos comunes para no trabajar así (resistencias frecuentes)

Presión por velocidad a corto plazo

"No tenemos tiempo para escribir tests", "hay que entregar ya". Esta es la más clásica. Sin embargo, como ya hemos visto, los tests bien integrados en el flujo de desarrollo permiten avanzar más rápido y con menor coste a medio plazo.

En entornos donde se valora el output inmediato, invertir en calidad al inicio puede parecer más lento, pero evita una ralentización mayor incluso a corto plazo. No estamos hablando de beneficios que tardan meses en llegar —en cuestión de semanas ya se nota la diferencia cuando la deuda técnica no se acumula y el desperdicio se mantiene bajo control. Las prácticas Lean suelen malinterpretarse como un freno inicial, pero su verdadero valor se revela claramente cuando el sistema empieza a fallar y se evidencia el coste real de no haber invertido en calidad.

Desalineación entre negocio y tecnología

Si el negocio solo mide entregas visibles (features) y no entiende el valor del refactor, los tests o el diseño simple, se generan incentivos perversos que empujan a evitar todo lo que no "se vea".

Aquí es necesario alinear los incentivos, demostrando con datos que la inversión en calidad genera un mayor retorno. Además, el desperdicio de construir funcionalidades innecesarias o mal entendidas se dispara cuando falta esta alineación. Y no nos engañemos, el desperdicio fundamental en el desarrollo de producto software es implementar lo que no se necesita, y además mantenerlo durante toda la vida del producto. Ya sabemos que el coste basal no se aplica solo a las funcionalidades que se usan.

Falta de formación o experiencia

Para muchas personas, esta forma de trabajar es nueva. No han visto entornos con trunk-based development, TDD o automatización real. Si no han vivido sus beneficios, es normal que desconfíen o los subestimen. Algunas de estas prácticas requieren un cambio de mentalidad significativo y competencias técnicas específicas que necesitan tiempo para desarrollarse. La inversión en formación y mentorización es clave para superar esta barrera inicial y construir la confianza necesaria en estos métodos.

Miedo al cambio

El temor a lo desconocido es una respuesta natural humana. Muchos equipos se sienten cómodos con sus procesos actuales, incluso si son ineficientes. Cambiar rutinas establecidas genera incertidumbre y resistencia. Este miedo puede manifestarse como escepticismo ("esto no funcionará aquí") o incluso como sabotaje pasivo. La transición requiere liderazgo efectivo, comunicación clara de los beneficios esperados y creación de un entorno seguro donde experimentar con nuevos métodos sea valorado y respaldado.

Falta de calidad estructural

Algunos equipos quieren trabajar con calidad, pero ya tienen un sistema lleno de deuda, sin tests, sin confianza. Cambiar requiere una inversión que muchas veces la organización no está dispuesta a hacer. Aquí la mejora debe ser incremental, con wins visibles: reducir el tiempo de despliegue en un 10%, arreglar los 3 bugs más críticos, etc. Establecer "zonas limpias" en el código y expandirlas gradualmente puede ser una estrategia efectiva para recuperar terreno sin necesidad de una reescritura completa.

Inercia organizativa y estructuras rígidas

Si los equipos no tienen autonomía, si las decisiones se toman desde arriba sin feedback técnico, o si los procesos de release, QA o seguridad están fuera del equipo, es difícil aplicar jidoka o reaccionar rápido a problemas.

El sistema inhibe la calidad y el desperdicio de tiempo y recursos aumenta exponencialmente mientras los problemas persisten.

Cultura del castigo y la culpa

Si la organización no tolera errores, si se busca culpables en lugar de causas, o si los incidentes generan miedo en vez de aprendizaje, se oculta el error en lugar de visibilizarlo. Y sin visibilidad, no hay mejora ni se puede reducir el desperdicio.

El miedo paraliza la innovación, retrasa la identificación de problemas y oculta el desperdicio en todos los niveles.

Aunque parezca exagerado, muchas organizaciones se enfrentan a esta disyuntiva cuando ven que su forma de trabajar ya no es sostenible. Mejorar requiere esfuerzo, pero no mejorar tiene consecuencias inevitables.

Crear las condiciones para construir con calidad

Trabajar con calidad, como hemos visto a lo largo de esta serie, no depende solo de herramientas ni de talento individual. Es una consecuencia directa del entorno (sistema) que construimos. La calidad no surge de forma espontánea: necesita espacio, alineación y una cultura que la valore.

Desde Lean Software Development, partimos de una premisa: las personas quieren hacer un buen trabajo. Pero si los incentivos, los hábitos y la cultura no acompañan, incluso los equipos con las mejores intenciones caerán en prácticas que sacrifican la calidad en favor de la urgencia, el volumen o la apariencia de productividad. Y esto inevitablemente lleva a generar mucho desperdicio.

“A bad system will beat a good person every time.”
—W. Edwards Deming

Como líderes en desarrollo de productos, tenemos una responsabilidad clara: crear las condiciones adecuadas para que la calidad no solo sea posible, sino inevitable. Esto implica intervenir en tres dimensiones clave: los incentivos, los sistemas de trabajo y la cultura.

La calidad no mejora actuando solo sobre lo visible. Como bien resume Donella Meadows, existen muchos niveles desde los que intervenir en un sistema. Cuanto más profundo es el punto de intervención (mentalidad, cultura, estructura), mayor es su impacto. Este marco nos recuerda que si queremos calidad sostenible, no basta con ajustar métricas: hay que transformar cómo pensamos y cómo trabajamos.

Lugares para intervenir en un sistema según Donella Meadows

Redefinir el éxito

En lugar de celebrar solo la cantidad de funcionalidades entregadas o la velocidad aparente, enfoquémonos en el impacto real, en la sostenibilidad del sistema y en la capacidad del equipo para adaptarse con confianza.

Calidad no es entregar más, sino poder entregar mejor: con menos riesgo, manteniendo un ritmo sostenible, aprendiendo continuamente y anticipando mejor los cambios.

Dar espacio al aprendizaje y la mejora continua

Uno de los errores más comunes es pensar que el tiempo para el Kaizen es prescindible. Pero reservar tiempo para refactorizar, automatizar, revisar procesos o simplificar no es un lujo: es parte del trabajo del equipo y una inversión en salud del sistema.

Para hacerlo posible, necesitamos introducir slack intencional: espacio planificado para observar, aprender y mejorar. Sin ese margen, todo el tiempo se dedica a entregar, y no queda energía ni foco para el Kaizen.

La mejora continua requiere tiempo, atención y un ritmo sostenible. Es lo que permite reducir el desperdicio de forma constante.

Cuidar la cultura del equipo

La seguridad psicológica es clave. Si hay miedo a equivocarse o a señalar problemas, no habrá jidoka, kaizen ni visibilidad. Solo en un entorno donde se pueda dudar, explorar y aprender sin castigo podremos detectar errores a tiempo y mejorar juntos, reduciendo el desperdicio que generan.

También debemos evitar incentivar el trabajo heroico: cuando el buen resultado depende solo del esfuerzo extraordinario de una persona, es señal de que el sistema está fallando.

En lugar de héroes, necesitamos equipos que trabajen de forma sostenible, con procesos que aseguren calidad de manera continua y predecible. El trabajo heroico suele ser un generador crónico de desperdicio.

Además, hay que dar autonomía real: decidir tecnologías, diseñar los procesos de testing, tener voz en la planificación, etc. Un equipo sin control sobre su entorno técnico, su flujo de trabajo o su forma de validar lo que construye, difícilmente podrá garantizar calidad.

La autonomía, combinada con responsabilidad compartida, es uno de los pilares más fuertes de la calidad en Lean.

Por último, hay que alinear los incentivos con la calidad. Reconocer y visibilizar el trabajo que permite que todo fluya: no solo las nuevas funcionalidades, sino también cuando se reduce deuda técnica, se mejora el proceso de testing, se evita una caída en producción o se simplifica una parte crítica del sistema.

Todo eso también es valor entregado. Y suele ser el que más perdura.

Cómo hacer que la calidad sea inevitable: liderazgo en la práctica

Hacer posible la calidad no consiste en pedir más esfuerzo a los equipos. Consiste en cambiar el sistema para que trabajar con calidad sea lo más natural, lo más sencillo y lo más rápido. A lo largo de los años, he intentado sistematizar este enfoque con decisiones muy concretas. Aquí algunas de ellas:

• Reservar espacio para el aprendizaje. Decidir activamente qué parte del tiempo se invierte en aprender. A veces es formación, otras veces simplemente es preguntar: “¿Qué habéis aprendido? ¿Qué podéis compartir?”.
• Convertir los errores en aprendizaje colectivo. Introducir blameless postmortems. Liderar los primeros, definir el proceso, normalizar que los errores no son culpa, sino oportunidades de mejora.
• Liderar con el ejemplo. Aplicar TDD, diseño evolutivo, pairing. Ser el primero en documentar y actuar sobre incidencias. No exigir lo que no se practica.
• Introducir Technical Coaching. Aprender junto a quienes ya dominan prácticas como TDD o Pair Programming. Si es posible, traer personas expertas con experiencia real.
• Cambiar los procesos de contratación. Evaluar cómo trabajan, no solo qué saben. Introducir TDD, pairing, diseño colaborativo como parte del proceso.
• Recompensar y visibilizar mejoras estructurales. Valorar explícitamente lo que mejora la calidad: reducción de deuda, mejor estrategia de tests, simplificaciones, etc.

Este tipo de liderazgo que busca cambiar el sistema para hacer la calidad inevitable no es una intuición aislada. Estudios como los del informe DORA demuestran que el liderazgo transformacional, junto con prácticas Lean, tiene un impacto claro en la performance del equipo, el bienestar y los resultados de negocio.

Modelo de impacto del liderazgo transformacional según DORA / Accelerate

Liderar para hacer la calidad inevitable

Construir con calidad no es solo una cuestión de prácticas técnicas: es, sobre todo, una cuestión de liderazgo. Nuestro papel como líderes no es exigir calidad como si fuera un extra opcional, sino entender que es la base para una velocidad sostenible, para reducir el desperdicio y para maximizar el impacto real.

La calidad no es una meta ni una opción: es el sistema operativo sobre el que se apoya todo lo demás. Si ese sistema falla, cualquier intento de avanzar rápido nos lleva directo al colapso.

Nuestro trabajo como líderes es crear las condiciones donde la calidad no dependa de la voluntad individual, sino que sea lo más fácil, lo más rápido y lo más natural. Donde construir con calidad no sea un acto heroico, sino lo inevitable.

Lean Software Development: Calidad desde la colaboración y la visibilidad

 Cuarta parte de la serie sobre calidad en Lean Software Development. En la entrega anterior hablamos de cómo la calidad técnica e interna es clave para sostener la calidad externa y acelerar el desarrollo.

Calidad desde la colaboración y el diseño compartido

Una parte esencial de la calidad, que a menudo se subestima, no está en el código ni en las herramientas, sino en cómo trabajamos juntos. En Lean Software Development, los errores no se entienden solo como fallos técnicos, sino también como fallos de entendimiento. Muchos de los defectos que llegan a producción no se deben a que el código esté mal escrito, sino a que no resuelve el problema correcto, o no lo hace de la forma adecuada.

Por eso, uno de los mecanismos clave para construir con calidad es la colaboración cercana y continua entre todas las personas involucradas: quienes diseñan, desarrollan, prueban o hablan con los usuarios. Cuanto antes se comparta el entendimiento del problema y se alineen expectativas, menos errores se introducirán en el sistema. De nuevo, calidad desde el origen.

Prácticas como el pair programming, el trabajo en ensemble, el uso de ejemplos concretos en conversaciones con negocio o el diseño compartido de soluciones son mecanismos que permiten detectar errores —técnicos y conceptuales— tan pronto como aparecen. De esta forma, favorecen una intervención temprana coherente con el espíritu de jidoka. Y lo hacemos de forma natural, porque hay muchas miradas sobre el problema, muchas oportunidades de hacer visibles los malentendidos.

Este enfoque colaborativo también refuerza el kaizen, porque facilita la mejora continua. Las ideas se contrastan, se explican, se afinan. El sistema evoluciona de forma más coherente porque no depende de decisiones individuales aisladas, sino de un conocimiento compartido y distribuido.

Además, colaborar reduce el desperdicio: se construye lo que realmente se necesita, se evitan suposiciones erróneas y se minimizan los retrabajos. Las soluciones tienden a ser más simples porque han sido discutidas y refinadas desde distintos ángulos.

En definitiva, si entendemos que construir con calidad es evitar defectos, reducir desperdicio y mantener un sistema sano que podamos evolucionar con confianza, entonces colaborar no es opcional. Es una de las formas más potentes de prevenir errores antes de que se conviertan en código.

El valor de visibilizar la calidad (o su falta)

Uno de los principios fundamentales de Lean es hacer los problemas visibles. Si no podemos ver un problema, no podemos mejorarlo. Y si la calidad no es visible para el equipo, para quienes toman decisiones o para quienes dan soporte al producto, entonces difícilmente será una prioridad.

Por eso, en Lean Software Development es esencial visibilizar el estado real de la calidad en todo momento. No solo mediante métricas técnicas, sino también con mecanismos que hagan evidente cuándo algo está fallando, cuándo acumulamos desperdicio o cuándo estamos arriesgando la estabilidad del sistema.

Esto se conecta directamente con jidoka: cualquier señal de problema, por pequeña que sea, debería detener el flujo o hacernos prestar atención. Ya sea un test que falla, una alerta de monitorización, una caída en la cobertura o un aumento del tiempo medio de resolución de bugs, todo debería encender una luz. El objetivo es que nada pase desapercibido y podamos actuar a tiempo.

También es un refuerzo constante de kaizen: lo que no se ve, no se mejora. Visibilizar la calidad —interna y externa— nos permite tomar decisiones informadas sobre dónde enfocar nuestro esfuerzo de mejora. Si vemos que los defectos en producción provienen siempre de cierta parte del sistema, probablemente necesitemos reforzar nuestras pruebas allí. Si la velocidad de cambio se reduce, quizás la complejidad esté creciendo sin control.

Los mecanismos para visibilizar la calidad pueden ser muchos: desde dashboards de integración continua hasta alarmas en producción, desde paneles físicos con bugs abiertos hasta reuniones periódicas de revisión de incidentes. Lo importante no es la herramienta, sino el hábito de mirar con honestidad el estado del sistema y del proceso.

Hacer visible la calidad (o su ausencia) también tiene un efecto cultural: refuerza la responsabilidad compartida. Si todos vemos que hay un problema de calidad, es más fácil que todos participemos en su solución. Se elimina la invisibilidad del deterioro, se evita la resignación y se fomenta un entorno donde los problemas se atacan en cuanto aparecen.

Porque, al final, construir con calidad es también construir con transparencia.

Calidad como hábito organizativo

Construir con calidad no es una fase del proceso, ni una tarea asignada a una persona concreta, ni algo que se pueda “añadir al final”. Es una forma de trabajar, un hábito que se cultiva a diario y que atraviesa todo lo que hacemos: cómo diseñamos, cómo escribimos código, cómo colaboramos, cómo resolvemos problemas y cómo aprendemos.

En Lean Software Development, la calidad no es negociable, porque es la base de todo lo demás. Sin calidad, el flujo se rompe, el aprendizaje se ralentiza, el coste del cambio crece y la confianza desaparece. Por eso, la calidad no se persigue por un ideal técnico, sino porque es el camino más eficaz para entregar valor de forma continua y sostenible.

Los principios de jidoka, poka-yoke y kaizen están presentes en cada práctica que hemos mencionado: en los tests automatizados que detienen el flujo ante un fallo, en los procesos que previenen errores humanos, en la mejora constante de nuestras herramientas y procesos, en la forma en que tratamos los incidentes como oportunidades de aprendizaje.

Pero nada de esto funciona si no se convierte en parte de la cultura del equipo. La calidad no emerge por azar ni por buenas intenciones: surge cuando hay prácticas concretas que la sustentan, cuando existen acuerdos compartidos sobre cómo trabajar, y cuando el entorno refuerza esos comportamientos una y otra vez. Es decir, cuando hay hábitos.

Y como todo hábito, se entrena. Se empieza con pequeños gestos: escribir un test antes de arreglar un bug, parar el desarrollo para investigar un error, revisar el diseño con otra persona antes de implementar. Con el tiempo, estos gestos se vuelven la forma natural de trabajar. El equipo gana confianza, el sistema se mantiene sano y los problemas se abordan con rapidez y serenidad.

En la última entrega, exploraremos por qué muchas organizaciones aún no trabajan con calidad, incluso sabiendo sus beneficios. Veremos las resistencias más comunes y cómo podemos crear un entorno donde la calidad no dependa del esfuerzo heroico, sino que sea una consecuencia natural del sistema.

Lean Software Development: Calidad como base del desarrollo sostenible

Tercera parte de la serie sobre calidad en Lean Software Development. Después de ver cómo detectar errores a tiempo y aprender de ellos, en esta entrega exploramos cómo la calidad técnica e interna es clave para sostener la calidad externa, por qué menos es más y cómo crear una cultura donde trabajar con calidad no sea la excepción, sino la norma. En esta entrega, exploraremos cómo esta calidad fundamental no es un lujo, sino la higiene esencial de un producto de software bien hecho.

Calidad como acelerador del desarrollo

Una de las creencias más extendidas, especialmente en organizaciones que aún no han adoptado enfoques Lean, es que trabajar con calidad ralentiza el desarrollo. Se asume que escribir tests, automatizar validaciones o refactorizar consume tiempo que podríamos dedicar a “entregar más rápido”. Sin embargo, desde la perspectiva de Lean Software Development, esta visión no sólo es errónea, sino que perpetúa el desperdicio.

En realidad, la calidad bien entendida es un acelerador. Cuando el sistema está sano —con tests automatizados fiables, diseño simple y procesos robustos—, cada paso que damos tiene menos fricción. La confianza del equipo en su capacidad para cambiar el sistema crece, el feedback es más rápido y el coste del cambio se reduce drásticamente. Es decir, vamos más rápido no a pesar de la calidad, sino gracias a ella.

Esto está completamente alineado con los principios Lean que hemos ido explicando en esta serie (poka-yoke, jidoka, kaizen).

Además, cuando el equipo confía en su sistema —porque sabe que los errores se detectan a tiempo, que el diseño permite evolucionar fácilmente y que se puede experimentar sin romper nada—, se atreve a innovar, probar ideas nuevas y adaptarse rápido a lo que aprende del usuario. Es decir, se potencia la entrega continua de valor.

En mi experiencia, los equipos que invierten en calidad desde el principio y la incorporan como parte de su forma de trabajar avanzan de forma mucho más sostenida, rápida y con menor coste emocional. No tienen que parar constantemente para “arreglar el sistema”, porque nunca lo han dejado deteriorarse. Y eso es posible porque entienden que la calidad no se inspecciona al final, sino que se construye en cada paso.

Calidad interna como cimiento de la externa

En Lean Software Development, la calidad externa —la que perciben directamente los usuarios o clientes— es prioritaria. Sin embargo, para que esa calidad se mantenga en el tiempo, es imprescindible contar con una calidad interna sólida: un sistema bien diseñado, comprensible, que se pueda mantener y evolucionar sin miedo.

Muchas veces, los defectos visibles para los usuarios tienen su origen en problemas invisibles dentro del sistema: código acoplado, tests poco fiables, decisiones técnicas tomadas sin contexto o procesos frágiles. Estos problemas no solo generan errores, sino que ralentizan al equipo, dificultan la adaptación al cambio y elevan el coste de entregar valor. Son una forma silenciosa, pero muy real, de desperdicio.

Lean nos invita a ver estos problemas estructurales como oportunidades de mejora (kaizen) y a abordarlos de forma sistemática. No se trata de “embellecer el código” ni de seguir reglas arbitrarias, sino de construir una base técnica sólida que reduzca la fricción del día a día y permita avanzar con rapidez y confianza.

Aplicamos jidoka también en este contexto: cuando un test flaky, una dependencia opaca o un sistema difícil de desplegar nos impide avanzar, lo señalamos como un problema del sistema, no como una debilidad individual. Paramos, analizamos y mejoramos la infraestructura técnica para evitar que vuelva a ocurrir. Cada pequeño cambio suma. Por ejemplo, si un despliegue falla repetidamente, no solo lo intentamos de nuevo, sino que investigamos la causa raíz y automatizamos una solución para evitar que vuelva a ocurrir, como un script que verifica la disponibilidad de la base de datos antes del despliegue.

Además, los principios de poka-yoke también son aplicables a la calidad interna. Usar tipado fuerte, patrones de diseño sencillos, encapsulación adecuada y herramientas que faciliten el trabajo sin requerir esfuerzo constante son formas de prevenir errores técnicos y facilitar la evolución del sistema. Cuanto más fácil sea hacer lo correcto, menos probable será introducir deuda o errores involuntarios. Por ejemplo, usar un linter de código para detectar errores de sintaxis automáticamente antes de que lleguen a producción o configurar un sistema de control de versiones que impida el envío de código sin una revisión adecuada.

En resumen, la calidad interna no es un fin en sí mismo, sino un medio para garantizar la calidad externa de forma sostenible. Cuando el sistema es fácil de entender, probar y modificar, el equipo puede centrarse en entregar valor, aprender más rápido y adaptarse mejor a lo que necesita el cliente. Esa simplicidad estructural es la que permite construir con calidad… y moverse rápido sin romper cosas.

Calidad no es complejidad ni sofisticación

Una confusión habitual en ingeniería de software es asociar la calidad con la sofisticación técnica. Se valora el código “bonito”, las soluciones elegantes o los diseños complejos que anticipan futuras necesidades. Sin embargo, desde la perspectiva de Lean Software Development, este enfoque es profundamente equivocado. En realidad, la calidad no es un lujo, sino una necesidad básica, la higiene fundamental de un producto de software bien hecho.

Lean no premia la complejidad innecesaria ni el sobrediseño. Todo lo contrario: promueve la simplicidad deliberada como vía para reducir el desperdicio, facilitar la evolución del sistema y garantizar su fiabilidad. La calidad, en este contexto, no se mide por cuántos patrones aplicamos o lo "intelectualmente interesante" del diseño, sino por lo bien que resuelve el problema actual, con el menor esfuerzo y el menor riesgo posible. Es como la limpieza en una casa: no es un adorno, es lo mínimo indispensable para vivir saludablemente.

Cualquier línea de código que no necesitamos ahora mismo es una fuente potencial de errores. No solo añade coste de mantenimiento, sino que complica la comprensión del sistema, frena su evolución y puede inducir a decisiones equivocadas. 

"el mejor código es el que no existe" Ward Cunningham

Desde Lean, adelantarse a funcionalidades que aún no existen o diseñar sistemas más allá de las necesidades actuales es una forma de desperdicio. También es un fallo de kaizen, porque impide iterar y aprender paso a paso. Y rompe con poka-yoke, al introducir caminos opcionales no validados ni protegidos con tests. En lugar de evitar errores, los estamos sembrando.

La calidad en Lean se construye con código claro, probado, comprensible y limitado a lo estrictamente necesario. Cuidamos el diseño no para hacerlo más complejo, sino más simple, seguro y fácil de evolucionar. Nos apoyamos en tests, feedback continuo, diseño evolutivo y refactorización constante para mantener el sistema sano sin caer en la trampa de planificar el futuro desde el presente.

Así que no: la belleza técnica o el sobrediseño no son calidad. A menudo, son su enemigo. Construir con calidad en Lean es, ante todo, tener la humildad de resolver lo justo, hacerlo bien y prepararnos para mejorar según lo que aprendamos mañana.

Conclusiones: Calidad como higiene básica

En resumen, la calidad en Lean Software Development no es una característica opcional ni un adorno sofisticado. Es la base, el cimiento, la higiene fundamental de un producto de software sostenible y valioso. No se trata de buscar la complejidad o la elegancia por sí mismas, sino de construir un sistema claro, simple, probado y fácil de mantener.

La calidad es como el aire que respiramos: no siempre la notamos, pero su ausencia nos ahoga rápidamente. Un software sin calidad es un software destinado al fracaso, lleno de errores, difícil de cambiar y costoso de mantener. Por eso, invertir en calidad desde el principio, y entenderla como una práctica esencial y no como un lujo, es la mejor manera de asegurar el éxito a largo plazo.

La calidad no es un extra, es lo mínimo indispensable. Y la simplicidad, la mejor aliada para conseguirla.

En la cuarta parte, veremos cómo la colaboración y la visibilidad son también fundamentales para mantener esta higiene y construir un software de calidad sostenible.

Lean Software Development: Detectar errores antes de que duelan

Segunda parte de la serie sobre cómo construir con calidad desde Lean Software Development. Si aún no has leído la primera parte de esta serie, donde explicamos los fundamentos de Lean Software Development, puedes encontrarla aquí: https://www.eferro.net/2025/04/lean-software-development-construyendo.html. Tras entender por qué la calidad no es solo el resultado final, en esta entrega nos enfocamos en cómo detectamos errores lo antes posible, detenemos el flujo cuando aparecen y aprendemos de ellos para mejorar el sistema.

Para evitar confusiones, utilizaremos "error" para referirnos a cualquier desviación del resultado esperado, y "defecto" para errores que impactan al cliente en producción.

Detectar los errores lo antes posible

En enfoques más tradicionales, suele priorizarse la clasificación de los defectos según su criticidad, lo que en algunos casos determina si se corrigen o no, y en qué plazo. Sin embargo, en Lean Software Development, que considera la calidad como una parte fundamental del producto y se enfoca en la mejora continua de procesos y sistemas, es más común clasificar los errores (potenciales defectos) según dónde y cuándo se han identificado dentro del proceso.

Disponer de esta información nos permite identificar las etapas del proceso donde los errores son más comunes y así enfocar nuestros esfuerzos de mejora para detectarlos lo antes posible (shift left), reduciendo la probabilidad de que se conviertan en defectos.

En mi experiencia, resulta muy útil clasificar la detección de errores dependiendo de la etapa en la que se identifican. Yo suelo usar la siguiente clasificación:

1. Máquina local (trabajo en pareja o ensemble).
1. Ciclo de desarrollo (incluyendo el ciclo TDD, verificación continua de estilo (linting), tipos, errores, etc).
2. Pre-commit.
3. Pre-push.
2. CI Pipeline:
1. Checks.
2. Tests (clasificados de más rápidos a más lentos).
3. Despliegue (incluyendo smoke tests y validaciones durante el rollout).
3. Entorno de producción.
1. Pre-release (desplegado, pero no activado para el cliente).
2. Activación para el cliente.

Cuando una funcionalidad ya está activada para el cliente, es útil también clasificar los errores o defectos según quién o qué los detectó:

1. Sistema automático, antes de que afecte al cliente (Monitoring).
2. Usuario interno, como un miembro del equipo realizando pruebas o alguien de otro departamento.
3. Usuario final, reportado el defecto a soporte.

Independientemente de la etapa o del responsable de la detección, el objetivo principal siempre es el mismo: detectar (y resolver) el error lo antes posible, idealmente antes de que sea identificado por un usuario final en el entorno de producción (cuando ya se considera un defecto).

Lean Software Development acepta que cometemos errores continuamente, y entiende que el coste (desperdicio generado) es mayor cuanto más tarde se detecte y arregle.

Para ilustrar cómo se estructura y visualiza esta detección progresiva de errores, a continuación muestro dos ejemplos reales de pipelines que usamos. En ambos casos, se organizan los distintos pasos (checks, tests, publicación, despliegue, validaciones en producción, rollback...) de forma que sea fácil detectar cualquier error lo antes posible, detener el proceso y corregirlo. Esta visualización ayuda no solo a estructurar mejor el flujo de trabajo, sino también a que todo el equipo entienda claramente en qué etapa puede aparecer cada tipo de error.

En este primer pipeline, cada componente (webapp, API, event processor…) tiene sus propios checks, tests unitarios, de integración y de aceptación, así como procesos de publicación y despliegue diferenciados por entorno (dev y mgmt). Además, se automatizan las pruebas end-to-end en producción antes de activar los cambios, y se incluye una lógica de rollback si algo falla. Esta estructura refuerza el principio de detener el flujo automáticamente ante errores y facilita la trazabilidad en cada etapa.

En este segundo ejemplo, más centrado en validaciones estructurales y pruebas especificas de ciertas tecnologías (argo workflows en este caso), se destacan fases adicionales como los static checks, tareas de cleanup antes de publicar la imagen en ECR y pruebas de integración con diferentes configuraciones. Este tipo de pipeline muestra cómo incluso tareas auxiliares como la validación de configuración o la limpieza del entorno son parte integral de un enfoque que busca detectar errores antes de que duelan.

Política parar y arreglar

Jidoka, también conocido como "autonomación" o "automatización con un toque humano", es un principio clave de Lean Software Development. No se trata solo de automatizar procesos, sino de automatizarlos de manera que se detengan automáticamente cuando se detecta un problema, permitiendo que los equipos investiguen y resuelvan la causa raíz antes de continuar. Aplicando el concepto Jidoka, los equipos que trabajan con Lean Software Development diseñan procesos de desarrollo en los que es muy fácil detectar errores. Bien porque son detectados de forma automática en la mayoría de los casos, o bien de forma manual gracias a un proceso de desarrollo que facilita la identificación de esos errores.

Para que la mejora continua de la calidad funcione, no solo necesitamos detectar esos errores, sino que es clave parar inmediatamente (Ver https://en.wikipedia.org/wiki/Andon_(manufacturing)) y contar con una política que nos obligue a priorizar su resolución de inmediato. Esta forma de trabajar puede parecer demasiado radical al principio y dar la impresión de que puede reducir la velocidad del equipo. Sin embargo, mi experiencia es justo la contraria. Si desde el principio adoptas un enfoque de trabajo en el que, al detectar un error, lo analizas, aprendes de él y lo solucionas de raíz  —por ejemplo, añadiendo un test que evite que vuelva a ocurrir—, en muy poco tiempo consigues un proceso que resuelve los errores lo antes posible. Esto elimina un montón de retrabajo y de potenciales problemas para el cliente final, a la vez que genera una gran confianza en el equipo para moverse rápido, tomar riesgos y experimentar.

De hecho, considero que es la mejor forma de ir rápido de forma sostenida, y los estudios de los DORA Reports y el libro Accelerate confirman que la mejor manera de ser rápido es hacerlo con calidad. Al menos, si hablamos de desarrollo de producto.

En mi caso, esta aplicación del enfoque Jidoka se refleja en:

• Tests automáticos que, al detectar un fallo, interrumpen temporalmente el flujo de desarrollo para evitar que el error se propague.
• Git hooks (pre-commit, pre-push, etc.) que interrumpen el flujo si se intenta subir código con errores.
• Trabajo en trunk based development, una estrategia donde todos los desarrolladores integran sus cambios en una única rama principal. En esta configuración, ejecutamos todas las validaciones en la rama principal. Cuando un test falla en integración continua, paramos para arreglarlo inmediatamente. Esto es crucial en "trunk based development" porque cualquier fallo bloquea la capacidad de integrar nuevos cambios, asegurando que la rama principal siempre esté en un estado estable y listo para ser desplegado. Esta disciplina es fundamental para mantener la calidad y evitar la acumulación de errores, permitiéndonos movernos rápido con confianza.
• Priorización automática en el flujo de trabajo para la resolución de bugs detectados en producción, siguiendo un proceso de gestión de incidentes con postmortem para los incidentes de producción. Esta priorización automática se basa en la severidad del error y su impacto en el cliente, determinando qué bugs se abordan primero. (https://www.eferro.net/2024/12/using-blameless-incident-management-to.html).
• Pair programming o ensemble programming, donde varias personas trabajan juntas en una misma tarea, lo que permite detectar malentendidos o errores potenciales desde el inicio. Esta colaboración intensa actúa como una revisión continua que previene muchos errores, tanto en el entendimiento del problema como en la implementación de la solución.

Tratar con defectos y aprender de ellos

Asumir que vamos a cometer errores —y que algunos se convertirán en defectos— es parte fundamental del enfoque Lean. En lugar de negarlo o esconderlo, lo aceptamos como algo natural. Trabajamos en entornos complejos, con múltiples dependencias, incertidumbre constante y, además, somos humanos. Somos falibles por definición.

Eso no quiere decir que no intentemos evitar los errores o defectos. Al contrario, ponemos mucho esfuerzo en prevenirlos con técnicas como poka-yoke, tests automáticos, pair programming, diseño evolutivo y muchas otras prácticas que forman parte de nuestro día a día. Aun así, sabemos que ocurrirán. Y cómo lo sabemos, nos preparamos para que su impacto sea mínimo y el tiempo de recuperación, el menor posible.

Este cambio de mentalidad es clave: pasamos de una obsesión por evitar el error a toda costa a una estrategia más robusta y sostenible, basada en la rapidez de recuperación (resilience) y en la capacidad de aprendizaje. Porque cuando un defecto llega a producción, el primer objetivo es recuperar el servicio lo más rápido posible. Y justo después, aprender.

Durante los últimos años, en varios de los equipos en los que he trabajado, hemos ido refinando y aplicando un enfoque basado en blameless incident management. La idea es sencilla: cuando ocurre un incidente, no buscamos culpables. Nos centramos en entender qué ha pasado, cómo el sistema ha contribuido al error y qué podemos hacer para evitar que se repita o para reducir su impacto la próxima vez.

Este tipo de enfoque, por simple que parezca, ha tenido un impacto enorme en la cultura de los equipos. Aporta seguridad psicológica, genera confianza, fomenta la transparencia y ayuda a que la gente se atreva a hacer visibles los problemas sin miedo. En TheMotion, Nextail y ClarityAI lo usamos no solo como forma de gestionar incidentes, sino como una de las principales palancas para evolucionar la cultura hacia una más colaborativa, orientada al aprendizaje y centrada en la mejora continua.

Por ejemplo, en un incidente reciente donde un servicio falló, aplicamos los 5 Whys y descubrimos que el problema inicial (un error en una configuración) había desencadenado una serie de eventos en cascada debido a la falta de manejo de errores en otro servicio. Esto nos llevó a añadir tests de integración más robustos y a mejorar la resiliencia del segundo servicio.

Nuestro proceso de gestión de incidentes blameless se apoya en varios principios:

• Mantener la calma. No entrar en pánico. Incluso en los procesos de entrevista valoramos esta capacidad como una señal de madurez profesional.
• Asignar un Incident Commander que coordine la respuesta y asegure que nadie se quede solo apagando fuegos.
• Recuperar el servicio cuanto antes. A veces implica desactivar una funcionalidad, comunicar al cliente o hacer una mitigación temporal. Lo importante es estabilizar el sistema.
• Analizar en profundidad lo ocurrido, sin buscar una “causa raíz” única. Entendemos que los incidentes suelen deberse a una combinación de causas y circunstancias. Usamos técnicas como los 5 Whys, repitiendo la pregunta “¿por qué?” a partir del primer síntoma visible. Al hacerlo en grupo, desentrañamos los distintos factores que contribuyeron al incidente. Muchas veces descubrimos fallos en el proceso, en los supuestos, en la comunicación o incluso en la interpretación de los datos.
• Definir acciones correctivas y preventivas que no solo eviten el problema, sino que reduzcan el tiempo de recuperación futuro y aumenten la resiliencia del sistema.
• Integrar estas acciones en el flujo normal de trabajo, para que no se queden en papel mojado.
• Usar un informe de incidente blameless, público dentro de la empresa y colaborativo, que sirva como base para el aprendizaje colectivo. Este proceso de análisis y aprendizaje continuo es un ejemplo de Kaizen, la mejora continua aplicada a la gestión de incidentes, donde buscamos constantemente formas de mejorar nuestros procesos y evitar errores futuros.

Estos informes incluyen resumen, línea temporal, causas, acciones y aprendizajes. Compartirlos abiertamente refuerza el mensaje: los errores no se esconden, se aprenden. Y cuando todo el equipo lo interioriza, la organización mejora más rápido.

Al final, se trata de reforzar un mensaje claro: los incidentes son inevitables, pero cómo respondemos a ellos es lo que realmente define nuestra cultura. Podemos esconderlos, culpar y pasar página... o podemos usarlos como catalizadores de mejora y aprendizaje continuo. En Lean Software Development, elegimos lo segundo.

En la siguiente entrega…

Una vez que hemos establecido cómo detectar y responder rápidamente a los errores, es crucial construir una base sólida. En la tercera parte, profundizaremos en la calidad interna como base del desarrollo sostenible. Veremos por qué menos es más, cómo la simplicidad y el diseño bien cuidado aceleran el desarrollo y cómo una buena base técnica permite moverse rápido sin romper cosas.

Lean Software Development: Construyendo con Calidad

Primera parte de una serie sobre cómo construir con calidad desde los principios de Lean Software Development. En esta entrega exploramos qué significa realmente "calidad", cómo se diferencia del enfoque tradicional y qué principios nos ayudan a evitar que los errores se conviertan en defectos.

Lean Software Development: Construyendo con Calidad

Una de las grandes diferencias entre Lean Software Development y los enfoques tradicionales radica en el tratamiento de la calidad, tanto del software o producto resultante como del entorno de trabajo (colaboración, herramientas, comunicación).

Lean Software Development considera la calidad como una parte integral del valor del producto, imprescindible para aportar valor al cliente de la manera más eficiente posible. Desde esta perspectiva, todos los problemas de calidad se consideran uno de los principales desperdicios que debemos eliminar.

En contraste, los enfoques tradicionales suelen centrarse principalmente en la calidad del producto final. Lean, por su parte, pone el foco en la mejora continua de los procesos y del sistema que genera ese producto final.

El control de calidad, que tradicionalmente se enfoca en la inspección del producto al final del proceso, se convierte en Lean en una parte fundamental de cada etapa. Dicho de otro modo, en lugar de inspeccionar y validar la calidad al final, esta se construye desde el principio y se mantiene durante todo el proceso. Esto implica pasar de una aproximación reactiva a los problemas a una más proactiva, visibilizando cualquier inconveniente con el objetivo de solucionarlo de inmediato y atacando las causas raíz (sistema o procesos).

Podemos resumir estas diferencias de la siguiente forma:

Foco

• Tradicional: Principalmente en la calidad del producto final.
• Lean Software Development: Mejora continua de los procesos y sistemas.

Control de calidad

• Tradicional: Inspección al final o en puntos concretos de la producción.
• Lean Software Development: Calidad incorporada en cada paso (jidoka).

Resolución de problemas

• Tradicional: Reactiva, abordando los problemas después de que ocurren.
• Lean Software Development: Proactiva, destacando y resolviendo los problemas inmediatamente.

Al final, Lean Software Development considera que todo el retrabajo (incidentes, resolución de bugs, procesos repetidos, etc.) generado por problemas y defectos es uno de los grandes desperdicios a eliminar. Por ello, se enfoca en introducir calidad en cada paso del proceso, minimizando el desperdicio y fomentando un hábito de trabajar con calidad y mejorar continuamente.

La calidad es un concepto amplio que puede abarcar varios aspectos: la calidad externa (cómo es percibida por el cliente o usuario final), la calidad interna (relacionada con la facilidad de evolución y mantenibilidad del código o sistema) e incluso la calidad de nuestros procesos y entorno de trabajo.

En esta serie de artículos, pondremos especial énfasis en la calidad externa, tal y como la perciben los clientes o usuarios. No obstante, también abordaremos aspectos de calidad interna y de proceso, ya que son fundamentales para sostener una calidad externa alta a largo plazo. Además, dado que Lean Software Development pone un fuerte énfasis en la mejora continua tanto de los procesos como del sistema para garantizar dicha calidad, también abordaremos aspectos relacionados con la calidad de los procesos y el entorno de trabajo.

Conceptos base

Comencemos con algunos conceptos y definiciones que nos serán útiles en el resto de los artículos:

• Error: Consideramos un error como cualquier desviación del resultado esperado. Por ejemplo, en la ejecución de nuestras aplicaciones, un error puede ser un test fallido, código que funcionalmente no cumple con lo esperado, entre otros.
• Problema: En el contexto de Lean Software Development, un problema es cualquier obstáculo que nos impide entregar valor al cliente de la manera más eficiente y efectiva posible. Esto incluye la diferencia entre el estado actual y el estado deseado, pero también abarca situaciones como:
• Requisitos ambiguos que llevan a una implementación incorrecta.
• Problemas de comunicación entre el equipo que resultan en malentendidos y retrasos.
• Limitaciones técnicas que impiden alcanzar el rendimiento deseado.
• Ineficiencias en el proceso de despliegue que causan demoras
• Defecto: Es un error que impide que el producto cumpla su función o propósito afectando de forma directa a los clientes. Los defectos son una de las principales fuentes de desperdicio identificadas en Lean Software Development (ver Eliminar desperdicios en el desarrollo). Por ello, es prioritario evitarlos siempre que sea posible y eliminarlos de inmediato cuando se detecten. El artículo enlazado explora cómo Lean Software Development adapta los siete tipos de desperdicio del Lean Manufacturing al software, enfocándose en eliminar actividades que no añaden valor al cliente y promoviendo prácticas como reducir el "Trabajo Parcialmente Hecho" y evitar "Funcionalidades y Código Extra". Ver artículo para ampliar. 

Es importante recordar que los defectos son un subconjunto de errores, y los problemas pueden incluir múltiples errores y defectos.

Aunque esta clasificación puede parecer confusa al principio, distinguir entre problema (una situación genérica que incluye errores y defectos), error (cualquier desviación de lo esperado, como un test fallido, un nombre incorrecto para una variable o una funcionalidad mal implementada) y defecto (un error que afecta al cliente o al propósito del sistema y fuente fundamental de desperdicio) nos ayuda a comprender mejor la situación y a definir procesos adecuados para abordar cada caso.

Enfoque Lean para la reducción de errores y defectos:

• Jidoka: También conocido como "autonomación", este principio busca detectar y corregir defectos automáticamente, deteniendo la producción en cuanto se identifica un error. Un ejemplo clásico de esto en Lean Manufacturing son las "Andon Cards", sistemas de señalización visual que permiten a cualquier trabajador detener la línea de producción al detectar un problema. En nuestro contexto de desarrollo de software, esto se traduce en testing automatizado en distintas etapas, alarmas y monitorización, el uso de un pipeline de CI que detiene el despliegue si las pruebas fallan, entre otros mecanismos.
• Poka-Yoke: Traducido como "a prueba de errores", este enfoque se basa en sistemas y diseños que previenen errores humanos. En el contexto del desarrollo de software, Poka-Yoke se aplica tanto a nuestros procesos internos como a la interacción del usuario con el producto.
• En el proceso de desarrollo, implementamos Poka-Yoke a través de prácticas como el uso de tipado fuerte en lenguajes de programación, herramientas con valores predeterminados óptimos, tests automatizados, el uso de ValueObjects y precondiciones. Estas técnicas ayudan a prevenir errores de codificación y diseño.
• En la usabilidad del software, aplicamos Poka-Yoke mediante sistemas anti-error, mensajes de ayuda contextual efectivos y diseños intuitivos. Aquí es donde la Experiencia de Usuario (UX) juega un papel crucial. Aunque la UX no es un mecanismo Poka-Yoke directo en el sentido técnico (como un sensor físico que detiene una máquina), comparte el objetivo fundamental de prevenir errores del usuario. Un buen diseño de UX anticipa posibles errores, guía al usuario de manera clara y ofrece retroalimentación inmediata, reduciendo significativamente la probabilidad de que cometa errores. En este sentido, la UX complementa y refuerza los principios de Poka-Yoke, asegurando que el software sea lo más intuitivo y libre de errores posible para el usuario final.
• Kaizen: Es el principio de mejora continua aplicado a nuestros procesos y sistemas. Como uno de los pilares de Lean, fomenta la búsqueda constante de formas de reducir errores y mejorar la calidad, tanto en el producto como en los procesos y herramientas que utilizamos.

De Majo statt Senf - Trabajo propio, CC BY-SA 4.0
https://commons.wikimedia.org/w/index.php?curid=38767688

Evitar que los errores se conviertan en defectos

En todos los equipos con los que he trabajado, cometemos errores de forma continua. Algunos son simplemente errores en el proceso de desarrollo, mientras que otros son errores de entendimiento. Estos últimos surgen porque vamos aprendiendo sobre el problema de manera continua. Esta es la realidad: cometemos errores constantemente, y todas las personas que conozco en esta profesión los cometen. Unos se equivocan más, otros menos, pero nadie está libre de errores. 

Si reconocemos y asumimos esta realidad, lo importante es entender que el objetivo no es evitar completamente los errores (algo imposible), sino asegurarnos de que esos errores no se conviertan en defectos que impacten la experiencia del usuario final. El artículo "Be humble, no rockstars allowed" aboga por la humildad y el trabajo en equipo en el desarrollo de software, enfatizando que el aprendizaje continuo y la gestión efectiva de errores son cruciales, en lugar de depender de "rockstars" individuales. Ver artículo para ampliar.

Esa es la aproximación de Lean Software Development: reconocer y aceptar que cometemos errores, y enfocarnos en tener un proceso que nos permita detectarlos, protegernos de ellos de forma continua, solventarlos y evitar que se conviertan en defectos.

¿Cómo lo conseguimos?

1. Incorporando calidad en cada fase del desarrollo, de forma automatizada siempre que sea posible (Jidoka + Poka-Yoke).
2. Mejorando continuamente los mecanismos y técnicas que garantizan la calidad en cada etapa (Kaizen).

En la siguiente entrega, exploraremos cómo detectar errores lo antes posible, detener el flujo cuando aparecen y aprender de ellos sin buscar culpables. Esto podría significar detener el pipeline de CI/CD si una prueba de integración falla, bloquear la subida de código si no pasa los tests unitarios, detener una sesión de pairing si se descubre un error crítico, o incluso detener temporalmente el desarrollo de nuevas funcionalidades para abordar un problema de rendimiento grave. Porque trabajar con calidad implica también tener una estrategia para que los errores no lleguen a convertirse en defectos.