Con 20 equipos el problema no son las ceremonias: es la topología de dependencias
Cuando escalar duele, la respuesta habitual es agregar sincronización — más reuniones, más coordinadores, más tableros. Eso administra el síntoma. La causa es cuántos equipos necesitan a otros equipos para terminar su trabajo.
Una organización pasa de cinco equipos a veinte. La entrega se vuelve más lenta, no más rápida. Aparecen bloqueos que nadie anticipó, integraciones que fallan tarde, decisiones que esperan semanas. La reacción instintiva es agregar coordinación: una reunión de sincronización semanal entre líderes técnicos, un tablero de dependencias, un rol de coordinador de programa, un ritual de planificación conjunta cada dos meses.
Todo eso administra el síntoma. Con suerte lo hace visible. Pero no toca la causa, y por eso la sensación de que “coordinamos más y avanzamos menos” persiste y hasta se agrava.
Con veinte o cuarenta y cinco equipos, el problema dominante no son las ceremonias. Es la topología de dependencias: cuántos equipos necesitan a otros equipos para terminar una unidad de trabajo, y con qué frecuencia.
La aritmética que explica el dolor
La coordinación no crece de forma lineal con el número de equipos. Si cada equipo puede necesitar a cualquier otro, el número de relaciones posibles crece con el cuadrado. Diez equipos totalmente acoplados tienen cuarenta y cinco pares posibles; veinte equipos tienen ciento noventa.
Ninguna cantidad de ceremonias administra ciento noventa relaciones. Y aquí está el punto clave: agregar coordinación no reduce las dependencias. Las hace visibles y las ordena, lo cual es mejor que nada, pero el costo sigue ahí y sigue creciendo.
Las tres consecuencias que aparecen siempre son reconocibles. El tiempo de espera empieza a dominar el tiempo de trabajo: una unidad de trabajo pasa la mayor parte de su vida esperando algo de otro equipo. La responsabilidad se difumina: cuando una entrega depende de seis equipos, nadie es responsable del resultado. Y el riesgo se concentra al final: los problemas de integración aparecen tarde, cuando corregirlos es más caro.
Reducir dependencias, no administrarlas
La intervención efectiva es de arquitectura y de límites, no de proceso. Hay cuatro palancas.
Alinear los límites de los equipos con los límites del dominio. Si un equipo es dueño de un ámbito completo del negocio —con sus datos, su lógica y sus interfaces— puede entregar valor sin negociar con nadie. Si los equipos se cortaron por capa técnica —uno de interfaz, uno de servicios, uno de base de datos—, entonces cada funcionalidad requiere a los tres por definición. Esa segunda topología genera dependencias estructurales que ninguna ceremonia va a resolver.
Definir ownership explícito de servicios y datos. Cada componente y cada conjunto de datos tiene un equipo dueño, nombrado. Sin eso, los cambios en zonas grises requieren negociación cada vez.
Establecer interfaces estables entre equipos. Un equipo debe poder consumir lo que otro produce sin conversaciones. Eso requiere que la interfaz esté documentada, versionada y con compromisos de compatibilidad. Cuando la interfaz es estable, la dependencia deja de ser de coordinación y pasa a ser de consumo, que es mucho más barata.
Mover a la plataforma lo que todos necesitan. Si quince equipos dependen del equipo de infraestructura para desplegar, esa es una dependencia de quince a uno con cola garantizada. Convertir eso en autoservicio elimina quince dependencias de golpe.
Cómo medir la topología
No se puede mejorar lo que no se mide, y las dependencias se pueden medir con instrumentos simples.
Dependencias por unidad de trabajo. De las últimas veinte entregas, ¿cuántos equipos distintos tuvo que involucrar cada una? Si el promedio está por encima de dos, hay un problema estructural.
Tiempo bloqueado. Del tiempo total de ciclo, ¿qué proporción se pasó esperando a otro equipo? Este número suele sorprender: en organizaciones con dependencias fuertes, la espera puede superar ampliamente al trabajo efectivo.
Concentración. ¿Hay un equipo que aparece en la mayoría de las dependencias? Ese equipo es el cuello de botella del sistema, y probablemente está siendo evaluado por su carga en vez de por su efecto sobre el flujo global.
Handoffs. Cuántas veces cambia de manos una unidad de trabajo entre su inicio y su entrega. Cada handoff es un punto de espera y de pérdida de contexto.
Estas cuatro mediciones se pueden hacer con una revisión manual de veinte entregas recientes. No requieren instrumentación sofisticada, y producen un diagnóstico más útil que cualquier evaluación de madurez.
El error de elegir modelo de escalado primero
La conversación típica en este punto es qué marco de escalado adoptar. Es la pregunta equivocada en el momento equivocado.
Un marco de escalado provee una estructura de coordinación. Si el problema es que hay demasiadas dependencias, adoptar un marco va a hacer esa coordinación más ordenada y más costosa, sin reducir la carga subyacente. Muchas organizaciones que se sienten frustradas con un marco de escalado no tienen un problema con el marco: tienen un problema de arquitectura que el marco nunca prometió resolver.
La pregunta correcta antes de elegir cualquier modelo es: ¿cuántas de nuestras dependencias son estructurales —derivadas de cómo cortamos los equipos y los sistemas— y cuántas son coyunturales? Las estructurales se reducen rediseñando límites. Las coyunturales se administran con coordinación. Confundirlas lleva a administrar durante años algo que se podía haber eliminado.
Tres topologías y lo que producen
Vale la pena comparar las formas más comunes de cortar equipos, porque cada una genera un patrón de dependencias distinto y predecible.
Por capa técnica. Un equipo de interfaz, uno de servicios, uno de datos, uno de infraestructura. Es la topología heredada de las organizaciones de tecnología tradicionales y sigue siendo común.
Produce dependencias estructurales máximas: toda funcionalidad relevante requiere a los cuatro equipos por definición. Ninguna cantidad de coordinación arregla eso, porque el acoplamiento está en el corte. Su única ventaja real es la profundidad técnica dentro de cada especialidad, que se puede obtener de otras formas.
Por proyecto o iniciativa. Equipos que se arman según lo que se aprobó y se disuelven al terminar.
Produce pocas dependencias durante la vida del proyecto y un problema distinto: nadie es dueño de nada de forma permanente. Los sistemas quedan sin custodio, la deuda se acumula sin responsable, y cada equipo nuevo redescubre lo que otro ya sabía. Las dependencias no desaparecen: se convierten en dependencias con el pasado, que son peores porque no hay a quién preguntarle.
Por dominio de negocio. Equipos dueños de un ámbito completo, con su interfaz, su lógica, sus datos y su operación.
Produce la menor cantidad de dependencias estructurales, porque un equipo puede entregar valor de punta a punta dentro de su dominio. Requiere a cambio dos cosas que hay que construir: límites de dominio bien elegidos —lo cual es trabajo analítico real, no un ejercicio de organigrama— y una plataforma que absorba lo transversal, para que cada equipo no reinvente infraestructura.
La tercera es la que sostiene el escalado, y también la más difícil de adoptar, porque exige decidir dónde están los límites del negocio antes de repartir personas. Es tentador saltarse ese análisis y cortar por lo que ya existe: las áreas actuales, las especialidades, los sistemas heredados.
Ese atajo es exactamente el origen de la mayoría de las topologías dolorosas. Los equipos quedaron definidos por la estructura que había, no por el trabajo que hay que hacer, y a partir de ahí cada funcionalidad tiene que atravesar fronteras que no se pusieron ahí por ninguna razón vigente.
Un ejercicio de dos horas
Reúne a los líderes técnicos y dibuja el mapa: cada equipo un nodo, cada dependencia real de los últimos tres meses una flecha, con grosor según frecuencia.
El mapa produce hallazgos casi siempre iguales y casi siempre útiles. Hay uno o dos nodos con muchas más flechas entrantes que el resto. Hay un conjunto de equipos que forman un grupo densamente acoplado y que probablemente deberían ser menos equipos. Y hay flechas que nadie sabía que existían, que se descubren en la sala.
Ese mapa vale más que la elección de modelo de escalado, porque describe el sistema real que cualquier modelo va a tener que operar.