En demasiadas organizaciones, la conversación sobre agilidad se ha vuelto superficial. Se repiten ceremonias, se llenan tableros, se hacen retrospectivas, pero el software sigue saliendo con errores, con baja mantenibilidad, con deuda técnica crónica. La paradoja está servida: equipos “agilísimos” que producen productos que nadie quiere, o que no escalan, o que simplemente se caen.
O peor aún: también existe el otro extremo. Equipos que se sienten por sobre los marcos ágiles porque “saben mucho”. Esos que rechazan Scrum o Kanban porque les parecen “teatrales” o “de juguete”, y que construyen software técnicamente complejo, pero de forma caótica, sin validación continua, sin entrega temprana de valor, sin visión compartida.
Lo que tienen en común ambos extremos es que han olvidado el principio número 9 del Manifiesto Ágil:
“La atención continua a
la excelencia técnica y al buen diseño
mejora la agilidad.”
La agilidad real necesita bases técnicas sólidas. Y la excelencia técnica, para ser relevante, debe estar al servicio de la adaptabilidad, de la entrega temprana y frecuente de valor. Uno sin el otro es un espejismo.
El dilema de los extremos: dos caminos que llevan al mismo abismo
Hemos acompañado a demasiados equipos que se ubican en uno de estos dos polos.
Por un lado, los agile en apariencia, que han convertido las metodologías en una coreografía vacía: sprints, dailys, story points… pero sin una cultura de refactoring, sin test automáticos, sin integración continua. El resultado: velocidad aparente, deuda real.
Por otro lado, los técnicamente puros, que miran con desprecio los marcos ágiles y hacen despliegues a mano, desarrollan sin feedback del usuario, “dividen historias” porque “eso dice el manual” (y sin guía experta las dividen con criterios técnicos y no de negocio) o simplemente se rehúsan a colaborar más allá de su consola. Entregan código técnicamente sólido pero que nunca llega a producción. O que llega, pero tarde o sin ningún valor validado.
Ambos caminos producen rigidez, frustración, y alto costo de cambio. Ninguno es verdaderamente ágil.
Las metodologías ágiles siempre trajeron técnica
Scrum, Kanban, XP, Crystal Clear: no son solo formas de organizar el trabajo. Todas parten de la premisa de que hacer software es una disciplina técnica, y que para adaptarse rápidamente, la calidad interna del producto es fundamental.
Extreme Programming (XP) fue quizá el más explícito. Introdujo TDD, pair programming, refactoring continuo, integración frecuente. No por amor al código, sino porque entendía que la capacidad de responder al cambio está directamente ligada a la salud técnica del sistema.
Incluso Scrum, que parece centrarse en el proceso, presupone una definición clara de “Done”, la cual incluye calidad técnica. Pero muchas implementaciones de Scrum se quedan en la superficie y olvidan que sin excelencia técnica, todo marco se descompone.
6 prácticas técnicas puras que todo equipo que se dice ágil debería dominar
- Continuous Integration (CI/CD):
Integrar código frecuentemente en un repositorio compartido permite detectar errores rápido y reducir el riesgo. Es la base de cualquier flujo moderno. Automatizar el proceso completo desde commit hasta despliegue, para entregar valor real en cualquier momento. - Automated Testing:
Tests unitarios, de integración y de regresión. Automatizados desde el inicio. Sin esto, todo cambio es una apuesta a ciegas. - Refactoring continuo:
Mejorar el diseño del código sin cambiar su funcionalidad. Evita que el sistema se vuelva inmodificable. No se agenda: se hace todos los días. - TDD (Test-Driven Development):
Diseñar a partir del test. Obliga a pensar antes de escribir, reduce bugs, y mejora la claridad del diseño. - Pair Programming (o al menos Peer Review frecuente):
Programar en pares o revisar en conjunto mejora la calidad, la transferencia de conocimiento y la cultura de equipo. - Coding Standards / Clean Code:
Convenciones de codificación compartidas por el equipo para facilitar el mantenimiento, la colaboración y la revisión del código.
3 prácticas de gestión de producto con alto componente técnico
- Small Releases:
Entregas pequeñas y frecuentes que habilitan ciclos rápidos de feedback y reducen el riesgo. - Behavior-Driven Development (BDD):
Fomentar la colaboración entre negocio, QA y desarrollo usando lenguaje comprensible por todos para definir comportamientos esperados. - Domain-Driven Design (DDD):
Modelar el software en torno a los conceptos del negocio, promoviendo un lenguaje ubicuo entre expertos y desarrolladores, y favoreciendo un diseño alineado con el valor real.
Implementarlas no es fácil, pero hacerlo transforma. Requieren tiempo, formación y convencimiento. Y sobre todo, un liderazgo que entienda que calidad no es un extra, es el habilitador de todo lo demás.
Tu TDD ya no será lo que era: bienvenida la técnica aumentada
La inteligencia artificial está redefiniendo lo que significa “práctica técnica”. Muchas de las que mencionamos siguen vigentes, pero ahora se ven amplificadas o reconfiguradas:
- TDD con generación automática de tests.
- Pair programming con asistentes como GitHub Copilot.
- CI/CD gestionados por agentes inteligentes.
- Refactoring sugerido y ejecutado por IA.
- Code review automatizado.
Y aparecen nuevas prácticas emergentes:
- Generación de código por IA, con humanos supervisando.
- Debugging inteligente.
- Documentación automática.
Pero ojo: si la base es frágil, la IA solo acelera el desastre.
La excelencia técnica sigue siendo necesaria, ahora con nuevas competencias:
- Prompt engineering enfocado al código.
- Validación crítica de código generado.
- Supervisión de agentes…
Lo técnico ya no es solo técnico: es estratégico
En esta nueva era, la técnica no es solo dominio de los desarrolladores. La excelencia técnica es una condición para competir, adaptarse, escalar.
No se trata de elegir entre agilidad y calidad. Se trata de reconocer que sin calidad técnica, no hay verdadera agilidad. Y que sin agilidad, la calidad no basta.
No es teoría, es práctica acompañada
Hemos ayudado a equipos a reencontrarse con el sentido profundo de la excelencia técnica. A salir del ritual vacío y reconectar con la capacidad de entregar valor real, rápido y sostenible.
Si te ves en alguno de los extremos, o si simplemente sabes que puedes mejorar, conversemos.
Porque en esta era de codebots, de IA generativa y de velocidad infinita, hay algo que sigue siendo irremplazable: la disciplina técnica con sentido humano.


