Cualquier organización que diseñe un sistema producirá una estructura de diseño que es una copia de la estructura de comunicación de la organización. Melvin Conway, 1967

En el mundo del desarrollo de software, la Ley de Conway no es solo una observación técnica, es un espejo que refleja las dinámicas internas de tu organización. Y en tiempos de metodologías ágiles, este principio cobra más fuerza que nunca.

¿Qué nos dice la Ley de Conway?

Imagina que tienes cuatro equipos que apenas se comunican entre sí. El resultado, según Conway, será probablemente un sistema compuesto por cuatro módulos distintos que reflejan esas barreras de comunicación. No es casualidad: el diseño del software imita la forma en la que las personas colaboran (o no lo hacen).

La Ley de Conway nos recuerda que el código no vive en un vacío. Es el reflejo de nuestras conversaciones, nuestras barreras, nuestras decisiones. Así que si quieres cambiar tu software, quizás debas empezar por cambiar tu forma de colaborar.

¿Dónde encaja lo ágil?

Las metodologías ágiles (Scrum, Kanban, SAFe, etc.) promueven equipos multidisciplinares, ciclos de feedback cortos y una comunicación fluida. En teoría, esto debería “romper” los silos y permitir la creación de sistemas más cohesionados, mantenibles y centrados en el usuario. Pero…

¿Y si aplicas lo ágil sin cambiar la estructura?

Muchas empresas adoptan prácticas ágiles, pero mantienen jerarquías rígidas, equipos aislados o canales de comunicación burocráticos. ¿El resultado? Software que sigue reflejando una estructura disfuncional. El ágil se vuelve cosmético. No es una cuestión de usar Jira o hacer dailys. Es una cuestión de rediseñar cómo colaboramos.

Invertir la Ley de Conway: el Inverse Conway Maneuver

Otras organizaciones, sin embargo, lo han entendido: si quieres un sistema modular, crea equipos modulares. Si buscas una arquitectura orientada a dominios, alinea tus equipos con esos dominios. Esta idea se conoce como el Inverse Conway Maneuver y es clave para el éxito en enfoques como Domain-Driven Design o Team Topologies.

Queda claro que no se puede diseñar buen software sin mirar cómo están organizadas las personas. Adoptar ágil sin transformar la estructura organizativa es como poner pintura nueva en una casa con humedades, si no resuelves el problema de la humedad, la pintura se caerá y volveran a notar las manchas. Si el software se complica, quizás no es un problema técnico, sino estructural y cultural.