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.