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.

Optimize the Whole: From Lean principle to real-world practice

Introduction

"Optimize the Whole" is one of the fundamental principles of Lean and Lean Software Development. It means setting aside local improvements to look at the entire system, from the idea to the user—people, processes, and technology—and aligning everything toward a common goal: delivering value to the user quickly and sustainably.

In my experience, many teams believe they are being efficient because no one ever stops working, but in the end, the user waits weeks (or months) to see real value. I’ve learned that true improvement comes from a systemic vision, working together so that the flow of value moves without friction from end to end.

Fragmentation: The Legacy of Taylorism

The paradigm of software development has often—consciously or unconsciously—inherited principles rooted in Taylorism and Fordism, conceiving the creation of digital products as a fragmented "assembly line." Under this view, each phase (analysis, design, development, QA, operations) becomes a functional silo, where teams specialize in specific tasks and focus on optimizing their local efficiency.

However, what in physical goods manufacturing could generate economies of scale for mass production has over time also shown its limits by sacrificing flexibility and the ability to quickly adapt to changes in demand or user needs.

In software, this translates into chronic bottlenecks, costly handoffs, and a fundamental disconnect between those who define needs and those who implement them. This fragmentation breaks the flow of value, fosters the accumulation of "inventory" in the form of work in progress, and hinders rapid adaptation—resulting in features that don’t solve real problems or that take months to reach the user, undermining the promise of agility and continuous value.

Comparison of Taylorism, Fordism, and Lean Thinking

What Happens When We Don’t Optimize the Whole?

Over the years working with different teams, I’ve observed that when we don’t optimize the whole, we fall into the trap of optimizing locally—almost always with good intentions but with unintended consequences. Teams may become very “efficient” in their own internal metrics, but if they are not aligned with user value, the overall flow slows down. Bottlenecks appear, handoffs multiply, and work gets stuck somewhere waiting.

I’ve seen this especially when engineering or development is seen as a feature factory that “executes” or “implements” what others decide. The team just implements, without understanding the problem, the priority, or the real impact on the user—and without contributing their technical knowledge to decisions. The result: solutions disconnected from real needs, slow feedback, and features that don’t solve the problem.

In my experience, the root cause is usually a functional and fragmented organizational structure inherited from “assembly line” thinking. But I’ve learned that software doesn’t behave like a linear factory. Software needs product teams with end-to-end responsibility, without silos (backend, frontend, QA, ops, design, etc.), and with real autonomy to make decisions and operate what they build.

I’ve found that this is not just a matter of motivation: it’s the only way to optimize the total flow and deliver real value to the user quickly and sustainably.

Bottlenecks and the Theory of Constraints

The Theory of Constraints (TOC) reminds us that in any system there is always at least one constraint that determines the maximum delivery capacity. Identifying and managing that bottleneck is essential to improving the overall flow.

For example, at ClarityAI, in the beginning, features were released to production but could remain behind a feature toggle for weeks, waiting for product to decide when to expose them to users. Even though they were technically ready, value wasn’t flowing.

Another example: when workflows were separated by functions (frontend, backend, data engineering), any change could take weeks because each group optimized its own flow or backlog instead of thinking about the overall flow from the user’s perspective.

(Fortunately, these specific problems at Clarity AI were solved long ago, but they serve as an example of what can happen when we don’t optimize the whole.)

In my experience working with different teams, I’ve learned that speeding everything up indiscriminately only makes the backlog pile up and creates frustration. 

A necessary condition to identify real constraints is that all work is visible—not only development tasks, but also testing, operations, support, automation, documentation, analysis, coordination, etc. If a significant part of the team’s effort is hidden (because it’s not recorded, visualized, or considered “technical work”), it’s very easy for the real constraints to go unnoticed. As Dominica DeGrandis points out in Making Work Visible, what you can’t see, you can’t manage or improve. Making all work visible is a key step for informed decision-making, reducing work in progress, and better focusing continuous improvement efforts.

The key steps are:

• Identify the constraint. Make it visible and prioritize it.
• Exploit the constraint. Keep it focused, avoid distractions, and ensure it’s always working on the highest-value items.
• Subordinate the rest of the system. Adjust rhythms and priorities so as not to overload the constraint.
• Elevate the constraint. Improve its capacity through automation, training, or process redesign.
• Review and repeat. There will always be a new constraint after each improvement.

Over the years, I’ve noticed that the more separate stages with queues there are between the idea and the value delivered to the user, the greater the chances of bottlenecks forming. Furthermore, if each stage belongs to a different group (organizationally speaking) that may even have its own agenda, there is likely little interest in optimizing value for the user. In these cases, each group may focus solely on improving its part of the process—or on avoiding being perceived as the bottleneck.

End-to-End Teams and Real Optimization

In every team I’ve built, I’ve insisted that they be product teams with end-to-end responsibility, without silos for QA, operations, security, or design. The reason is simple: if the team doesn’t control or understand the entire flow, it can’t optimize the whole, and it also risks not taking full responsibility for the complete product.

When the same team is in charge of conceiving, building, deploying, and operating, it eliminates the waste that arises in each handoff and accelerates learning. Every member understands the impact of their work on the end user and the value actually being delivered. End-to-end responsibility not only improves technical quality but also strengthens the focus on user value, avoiding unnecessary investments in local optimizations that don’t contribute to the overall goal.

In this work environment, more generalist profiles—often referred to as "T" (deep in one area and broad in others) or "M" (with several deep specializations and wide versatility)—are especially valued. These professionals, being able to contribute in multiple phases of development and having a more holistic view, are key in contexts where flow efficiency is a priority.

While pure specialists, also known as "I" profiles, are still needed in very specific domains, their role changes: they become enablers and educators, helping to scale their knowledge and train the rest of the team in various facets of the product.

In addition, keeping options open, working in short cycles, and making small deliveries allows for better adaptation to what the business and data reveal. Simplicity and vertical slicing reduce risk and facilitate rapid learning, freeing the team from the mental load of large, fixed plans and fostering autonomy.

This way of working is unfeasible when the product must pass through different silos before reaching the end user.

Rediscovering my joy of coding:

How AI Is Shaping My Journey as a Tech Leader

I’ve been near a keyboard since the mid-80s, but I only started programming professionally around 1997. Fast forward nearly 30 years, and much of my career has been spent leading teams and working closely with product—so I’ve been coding less directly.

But AI has changed that. Now I can jump back in as a team contributor (I prefer this term because software development is really a collaborative effort) while staying in my leadership role. I can explore new technologies, make quick tweaks, and run experiments without becoming a bottleneck for the team. The usual hurdles—like boilerplate code or ramping up on a new stack—have shrunk.

This has supercharged my learning and experimentation. I can run more tests, dive into new tech, and rediscover the joy of focusing on what truly adds value—without the tedious overhead that used to slow things down.

We’re at a unique moment: with AI as our companion, we can build more software, handle complexity, and reinvent how we work together.

To fellow tech leads: are you feeling this shift too? I’d love to hear if this transformation excites you as much as it does me. We’re in the midst of a profound change, and it’s up to us to shape this new chapter.

IA y Lean Software Development: Reflexiones desde la experimentación

Explorando cómo la inteligencia artificial podría estar cambiando las reglas del juego en el desarrollo de software - ideas preliminares desde la trinchera

Una exploración en territorio inexplorado

Quiero ser transparente desde el inicio: lo que voy a compartir no son conclusiones definitivas ni principios probados. Son reflexiones abiertas que surgen de unos meses de experimentación personal intensa con IA aplicada al desarrollo de software, explorando sus posibilidades y tratando de entender cómo afecta esto a las prácticas Lean que habitualmente utilizamos.

Estos pensamientos no son conclusiones definitivas basadas en experiencia prolongada, sino reflexiones abiertas que me gustaría seguir experimentando y discutiendo con otros interesados en este fascinante tema. No hablo como alguien que ya tiene las respuestas, sino como alguien que está explorando preguntas fascinantes y que sospecha que estamos ante un cambio de paradigma que apenas empezamos a entender.

La paradoja fundamental: velocidad versus validación

Una idea central que estoy observando es que, aunque la inteligencia artificial nos permite trabajar más rápido, eso no implica que debamos ampliar automáticamente el alcance inicial de nuestras funcionalidades. Mi intuición me dice que debemos seguir entregando valor en pequeños incrementos, validar rápidamente y decidir en función del feedback real y no simplemente de la velocidad con que ahora podemos ejecutar tareas.

Pero aquí hay un matiz interesante que he empezado a considerar: en contextos de baja incertidumbre, donde tanto el valor como la implementación son claros y el equipo está muy seguro, podría tener sentido avanzar algo más antes de validar. Sin embargo, mis sensaciones me llevan a pensar que mantener la disciplina para evitar caer en diseño especulativo es fundamental, ya que aunque la IA lo facilite, puede poner en peligro la simplicidad y flexibilidad futura del sistema.

La crisis cognitiva que no vemos venir

Gráfico: Mientras la velocidad de desarrollo con IA crece exponencialmente, nuestra capacidad cognitiva humana permanece constante, creando una "zona de peligro" donde podemos crear complejidad más rápido de lo que podemos gestionarla.

Aquí sí que tengo una convicción que cada día se vuelve más clara: ahora deberíamos ser mucho más radicales a la hora de borrar y eliminar código y funcionalidades que no están generando el impacto esperado.

Lo que me muestra esta visualización es algo que siento visceralmente: tenemos que ser implacables para evitar que la complejidad nos devore, porque por mucha IA que tengamos, la capacidad cognitiva de los humanos no ha cambiado - tanto para gestionar la complejidad técnica como para que los usuarios gestionen el número creciente de aplicaciones y funcionalidades.

Estamos en ese punto crítico donde la línea azul (velocidad de IA) se cruza con la roja (nuestra capacidad), y mi intuición me dice que o desarrollamos disciplinas radicales ahora, o nos adentramos en esa zona roja donde creamos más complejidad de la que podemos manejar.

La paradoja del Lean amplificado

Pero aquí está el quid de la cuestión, y creo que esta tabla lo visualiza perfectamente:

Tabla: La IA elimina las restricciones naturales que nos mantenían disciplinados (al menos a algunos), creando la paradoja de que necesitamos recrear artificialmente esas restricciones a través de disciplina radical.

Esta visualización me parece que captura algo fundamental que estoy observando: la IA elimina las restricciones naturales que nos mantenían aplicando principios Lean. Antes, el alto coste de implementación naturalmente nos forzaba a hacer batches pequeños. Ahora tenemos que recrear esa disciplina artificialmente.

Por ejemplo, fíjate en el línea de "Small Batches": tradicionalmente la velocidad de desarrollo era la restricción natural que nos forzaba a validar temprano. Ahora, con IA, ese freno desaparece y corremos el riesgo de crecimiento inconsciente del scope. La contramedida no es técnica, es cultural: redefinir explícitamente qué significa "pequeño" en términos de carga cognitiva, no de tiempo.

Lo mismo pasa con YAGNI: antes el alto coste de implementación era una barrera natural contra el diseño especulativo. Ahora la IA "sugiere mejoras" y hace que el overengineering sea tentador y fácil. La respuesta es hacer YAGNI aún más explícito.

Esta es la paradoja que más me fascina: tenemos que volvernos más disciplinados justo cuando la tecnología nos lo pone más fácil.

A partir de esta intuición general, he identificado varios patrones específicos que me preocupan y algunas oportunidades que me emocionan. Son observaciones que surgen de mi experimentación diaria, algunas más claras que otras, pero todas me parecen lo suficientemente relevantes como para compartirlas y seguir explorándolas.

Sobre el scope y la complejidad

Cambio en el "tamaño por defecto" del trabajo

La IA facilita el desarrollo inmediato de funcionalidades o refactors, lo que puede llevarnos inconscientemente a aumentar su tamaño. El riesgo que percibo es perder la disciplina de small batch size clave para validación temprana.

Exploración en curso: Mi intuición sugiere redefinir explícitamente lo que significa "pequeño" en un contexto con IA, enfocado en tamaño cognitivo y no solo en tiempo de implementación. Una forma de conseguirlo es apoyándonos en prácticas como BDD/ATDD/TDD para limitar cada ciclo a un test o comportamiento externo validable.

Diseño especulativo amplificado

En varias ocasiones he tenido que deshacer trabajo hecho por la IA porque intenta hacer más de lo necesario. He observado que la IA carece de sensibilidad al diseño orientado a objetos y no tiene ningún tipo de consciencia sobre la complejidad que genera, creándola muy rápido hasta llegar a un punto del que no sabe salir y entra en bucle, arreglando una cosa y rompiendo otras.

Reflexión: Esto me sugiere reforzar prácticas deliberadas como TDD, walking skeletons o feature toggles estrictos.

Nuevo tipo de "overengineering"

Mi experiencia inicial sugiere que la facilidad que ofrece la IA puede llevar a añadir funcionalidades innecesarias. No es el overengineering clásico del arquitecto que diseña una catedral cuando necesitas una cabaña. Es más sutil: es añadir "solo una funcionalidad más" porque es fácil, es crear "solo una abstracción adicional" porque la IA puede generarla rápidamente.

Sensación clave: Reforzar el principio YAGNI de forma aún más explícita parece necesario.

Sobre el flujo de trabajo y las validaciones

Diferenciar trabajo visible vs. trabajo liberado

Mi experiencia me indica que el rápido desarrollo no debe confundir "listo para desplegar" con "listo para liberar". Mi sensación es que mantener clara la separación entre deployment y release sigue siendo fundamental.

También he desarrollado varias veces pequeñas funcionalidades que luego no se han usado. Aunque, siendo honesto, como tengo muy interiorizado eliminar desperdicio y coste basal, simplemente he borrado el código posteriormente.

Oportunidad que veo: La IA puede acelerar desarrollo mientras validamos con pruebas controladas como A/B testing.

Más trabajo en curso, pero con límites

Aunque la IA puede permitir más trabajo paralelo, mi intuición me dice que esto puede fragmentar la atención del equipo y complicar la integración. Es tentador tener tres o cuatro funcionalidades "en desarrollo" simultáneo porque la IA hace que avancen rápido.

Mi preferencia actual: Usar IA para reducir tiempo de ciclo por historia, priorizando feedback rápido, en lugar de paralelizar más trabajo.

Cambio en el tipo de errores que cometemos

Mis observaciones sugieren que con IA, los errores pueden propagarse rápidamente, generando complejidad innecesaria o decisiones superficiales. Una decisión superficial o un malentendido del problema puede materializarse en código funcional antes de que haya tenido tiempo de reflexionar sobre si es la dirección correcta.

Exploración: Mi intuición apunta hacia reforzar guardrails culturales y técnicos (tests, revisión de decisiones, principio de mínima solución viable).

Sobre la cultura y el aprendizaje

Impacto en la cultura y el aprendizaje

Siento que existe el riesgo de confiar excesivamente en IA, lo que podría reducir la reflexión colectiva. La capacidad cognitiva humana no ha cambiado, y seguimos siendo mejores enfocándonos en pocas cosas a la vez.

Intuición de trabajo: Pair programming asistido por IA, rotaciones de ownership y revisiones explícitas de decisiones de producto podrían contrarrestar este efecto.

Ideas que estoy explorando para gestionar estos riesgos

Después de identificar estos patrones, la pregunta natural es: ¿qué podemos hacer al respecto? Las siguientes son ideas que estoy explorando, algunas ya las he probado con resultados mixtos, otras son hipótesis de trabajo que me gustaría contrastar. Siendo honestos, estamos en una fase muy embrionaria de entender todo esto.

Disciplina en la Eliminación Radical Mi intuición sugiere introducir "Deletion Reviews" periódicas para eliminar activamente código sin impacto real. Sesiones específicas donde el objetivo principal sea identificar y borrar lo que no está generando valor.

"Sunset by Default" para experimentos La sensación es que podríamos necesitar una política explícita de caducidad automática para experimentos no validados. Si no demuestran valor en X tiempo, se eliminan automáticamente, sin excepciones.

Tracking de Impacto más riguroso Mi experiencia me lleva a pensar en definir criterios explícitos de impacto antes de escribir código y eliminar despiadadamente lo que no cumpla expectativas en el tiempo establecido.

Fomentar la Mentalidad de "Disposable Software" Mi sensación es que etiquetar explícitamente funcionalidades como "disposable" desde el inicio podría facilitar psicológicamente la eliminación si no cumplen expectativas.

Reducción continua de "Legacy generado por IA" Siento que podrían ser valiosas las sesiones regulares para revisar código generado automáticamente y eliminar complejidades innecesarias que la IA haya introducido sin que nos diéramos cuenta.

Reforzar radicalmente el Principio de "YAGNI" Mi intuición me dice que deberíamos integrar explícitamente preguntas críticas en revisiones para evitar diseño especulativo: "¿Realmente necesitamos esto ahora? ¿Qué evidencia tenemos de que será útil?"

Mayor rigor en Pair Programming Asistido por IA Mi experiencia inicial sugiere promover "Pair Programming híbrido" para asegurar reflexión suficiente y calidad estructural. Nunca dejar que la IA tome decisiones arquitectónicas sola.

Una oportunidad fascinante: Cross Cutting Concerns y el YAGNI reforzado

Más allá de gestionar los riesgos, he empezado a notar algo prometedor: la IA también parece abrir nuevas posibilidades para decisiones arquitectónicas y funcionales que tradicionalmente debían anticiparse desde el principio.

Me refiero específicamente a elementos como:

• Internacionalización (i18n): ¿Realmente necesitamos diseñar para múltiples idiomas desde el día uno?
• Observabilidad y monitorización: ¿Podemos empezar simple y añadir instrumentación después?
• Cumplimiento normativo (compliance): ¿Es posible construir primero y adaptar regulaciones más tarde?
• Escalabilidad horizontal y adaptación a arquitecturas distribuidas: ¿Podemos diferir estas decisiones hasta tener evidencia real de necesidad?

Mi sensación es que estas decisiones pueden posponerse deliberadamente y ser introducidas más tarde gracias a las capacidades de refactorización automática que parece brindar la IA. Esto podría fortalecer aún más nuestra capacidad de aplicar YAGNI y defer commitment.

Los guardrails que creo necesarios

Para que esto funcione, siento que necesitamos mantener ciertos guardrails técnicos:

• Separación clara de responsabilidades: Para que los cambios posteriores no rompan todo
• Pruebas automatizadas sólidas: Para refactorizar con confianza
• Documentación explícita de decisiones pospuestas: Para no olvidar lo que diferimos
• Uso de IA especializada para spikes arquitecturales: Para explorar opciones cuando llegue el momento

Pero insisto: esto son solo intuiciones que me gustaría validar colectivamente.

Hipótesis de trabajo que me encantaría contrastar

Después de estos meses de experimentación, estas son las hipótesis que han emergido y que me encantaría discutir y probar colectivamente:

1. Velocidad ≠ Amplitud

Hipótesis: Deberíamos usar la velocidad de la IA para validar más rápido, no para construir más grande.

2. YAGNI radical

Hipótesis: Si antes YAGNI era importante, ahora podría ser crítico. La facilidad de implementación no debería justificar la complejidad adicional.

3. Eliminación como disciplina central

Hipótesis: Tratar la eliminación de código como una práctica de desarrollo de primera clase, no como una actividad de mantenimiento.

4. Pair Programming híbrido

Hipótesis: Combinar la velocidad de la IA con la reflexión humana podría ser clave. Nunca dejar que la IA tome decisiones arquitectónicas sola.

5. Separación deployment/release reforzada

Hipótesis: Mantener esta separación más clara que nunca. La facilidad de implementación podría crear espejismos de "producto terminado".

6. Cross-cutting concerns diferidos

Hipótesis: Podemos posponer más decisiones arquitectónicas que antes, aprovechando las capacidades de refactorización de la IA.

Una invitación honesta al aprendizaje conjunto

En definitiva, estas son ideas y reflexiones iniciales, abiertas a discusión, experimentación y aprendizaje. Mi intuición me dice que la inteligencia artificial está cambiando radicalmente la forma en que desarrollamos producto y software, potenciando nuestras capacidades, pero sugiriéndome la necesidad de una disciplina aún mayor en validación, eliminación y simplificación radical del código.

Mi hipótesis más fuerte es esta: la IA amplifica tanto nuestras buenas como nuestras malas prácticas. Si tenemos disciplina para mantener pequeños batches, validar rápido y eliminar desperdicio, la IA podría hacernos extraordinariamente efectivos. Si no la tenemos, podría ayudarnos a crear desastres más rápido que nunca.

Pero esto es solo una corazonada que necesita validación.

¿Qué experiencias habéis tenido vosotros? ¿Habéis notado estos mismos patrones, o completamente diferentes? ¿Qué prácticas estáis probando? ¿Habéis notado estos mismos efectos en vuestros equipos? ¿Qué sensaciones os genera la integración de IA en vuestros procesos Lean?

Estamos en los primeros compases de entender todo esto. Necesitamos las perspectivas de toda la comunidad para navegar este cambio que intuyo puede ser de paradigma, pero que aún no comprendo del todo.

Continuemos la conversación. La única forma de avanzar es explorando juntos.

¿Te resuenan estas reflexiones? ¿Has notado patrones similares o completamente diferentes? Me encantaría conocer tu experiencia y seguir aprendiendo juntos en este territorio fascinante y aún inexplorado.

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 

Good talks/podcasts (Jul) / AI & AI - Augmented Coding Edition!

These are the best podcasts/talks I've seen/listened to recently — AI & AI-Augmented Coding Edition! All of them explore how AI and Large Language Models (LLMs) are reshaping software development, product design, and engineering culture.

• How To Get The Most Out Of Vibe Coding | Startup School 🔗 talk notes (Tom Blomfield) [AI, Software Design, testing] [Duration: 00:16] A talk exploring best practices and practical tips for leveraging AI tools and Large Language Models (LLMs) to achieve great results in software development through the "vibe coding" approach.
• Stop Writing Code – That’s what LLMs are for 🔗 talk notes (Steve Yegge) [AI, Engineering Career, testing] [Duration: 00:29] (⭐⭐⭐⭐⭐) This talk by Steve Yegge exploring the inevitable transformation of software engineering due to AI and LLMs, detailing changing developer roles and the increasing importance of testing and validation
• Andrew Ng: Building Faster with AI 🔗 talk notes (Andrew Ng) [AI, Product, startup] [Duration: 00:43] (⭐⭐⭐⭐⭐) Andrew Ng's talk provides best practices for startups to achieve unprecedented execution speed by leveraging new AI technology for rapid engineering, product iteration, and strategic decision-making
• Vibe Coding For Grownups with Gene Kim 🔗 talk notes (Gene Kim) [AI, Architecture, Devops] [Duration: 00:37] Gene Kim discusses the transformative power and inherent dangers of AI-assisted "Vibe Coding", emphasizing the critical role of architecture and sound practices in achieving high performance and avoiding "vibe coding disasters"
• How custom GPTs can make you a better manager | Hilary Gridley (Head of Core Product at Whoop) 🔗 talk notes (Hilary Gridley) [AI, Management, leadership] [Duration: 00:36] This talk demonstrates how custom GPTs significantly leverage managers' time by scaling their expertise and providing consistent, automated feedback to their teams.
• AI prompt engineering in 2025: What works and what doesn’t 🔗 talk notes (Sander Schulhoff, Lenny Rachitsky) [AI, Generative AI, Product, Security] [Duration: 01:37] Sander Schulhoff, discusses tangible prompt engineering techniques (including few-shot prompting, decomposition, self-criticism, and additional information), distinguishes between conversational and product-focused prompt engineering, and delves into the critical and unsolvable problem of AI prompt injection and red teaming.
• How AI is changing software engineering at Shopify with Farhan Thawar 🔗 talk notes (Farhan Thawar, Gergely Orosz) [AI, Developer Productivity, Engineering Culture, Technology Strategy] [Duration: 00:47] (⭐⭐⭐⭐⭐) A deep dive into Shopify's AI-first transformation, emphasizing pervasive AI tool adoption, internal AI infrastructure, and cultural shifts empowering all employees to leverage AI.
• Gene Kim on developer experience and AI engineering 🔗 talk notes (Gene Kim) [AI, Developer Productivity, Devex, Generative AI] [Duration: 00:44] (⭐⭐⭐⭐⭐) Gene Kim explores how Developer Experience, Generative AI, and Platform Engineering serve as the next chapter in organizational transformation, fundamentally improving developer productivity and value creation.
• TDD, AI agents and coding with Kent Beck 🔗 talk notes (Kent Beck, Gergely Orosz) [AI, XP, tdd] [Duration: 01:15] Industry legend Kent Beck, creator of XP and TDD, shares insights on the evolution of Agile, Extreme Programming, and Test-Driven Development, alongside his current experience of "most fun ever" coding with AI agents.
• The Agent Native Company — Rick Blalock, Agentuity 🔗 talk notes (Rick Blalock) [AI, Company Culture, Management, Teams] [Duration: 00:20] This talk introduces the concept of agent native companies, where AI is fundamental to their operations, fundamentally reshaping culture, workflows, and team structures
• AI at Honeycomb: What’s Actually Working 🔗 talk notes (Charity Majors) [AI, Engineering Culture, Product] [Duration: 00:11] A talk with Honeycomb's CTO exploring AI's impact on engineering velocity and culture, the emergence of disposable software, and the future of product interfaces focused on production.

Reminder: All of these talks are interesting, even just listening to them.

You can now explore all recommended talks and podcasts interactively on our new site:

• 🌐 Interactive Site: https://eferro.github.io/eferro-picks-site/

The new site allows you to:

• 🏷️ Browse talks by topic
• 👤 Filter by speaker
• 🎤 Search by conference
• 📅 Navigate by year

Feedback Welcome!
Your feedback and suggestions are highly appreciated to help improve the site and content. Feel free to contribute or share your thoughts!
Related:

• Recommended Talk/Podcast Database
• Recommended resources tag