Llevo décadas en la profesión del software y la forma más común de organizar equipos que he visto es siempre la misma: por especialidad. De un lado, los developers de backend. Del otro, los de frontend. Más allá, los ingenieros de quality assurance. Cada grupo es dueño de su capa y le pasa el trabajo al siguiente.
Y muchas veces hay un nivel más de complejidad: dentro de cada capa, las personas se sobreespecializan en un solo componente. Ya no es “el equipo de backend”, es “la persona que conoce el módulo de pagos” o “el único que sabe tocar la integración con facturación”.
Esta forma de organizarse parece lógica. Cada uno hace lo que mejor sabe hacer. Pero cuando una empresa quiere escalar Scrum a varios equipos, es la decisión que más pesa. Y casi siempre pesa en contra.
Dos formas de organizar equipos
Un equipo por componente es responsable de una parte del sistema: una capa técnica (frontend, backend, base de datos) o un componente (pagos, facturación, notificaciones). Para entregar una funcionalidad que le sirva al cliente, hace falta que varios de estos equipos coordinen su trabajo.
Un equipo de funcionalidad (feature team, en inglés) es un equipo estable, multifuncional y multicomponente que entrega funcionalidades completas, de punta a punta, una tras otra. Tiene dentro de sí las habilidades para tocar todas las capas y todos los componentes que una funcionalidad necesita.
En LeSS, los equipos de funcionalidad no son una recomendación más: son la forma de organizar a los equipos. Y la razón es económica. Como lo resumen en less.works, los equipos de funcionalidad están optimizados para entregar el máximo valor al cliente, mientras que los equipos por componente están optimizados para producir la mayor cantidad de líneas de código.
Trabajar con especialistas es trabajar en cascada
Mi postura es categórica: trabajar con especialistas equivale, al 100%, a trabajar en cascada. Con todas las ineficiencias que ese modelo conlleva.
Piensa en el recorrido de una funcionalidad cualquiera. Primero alguien la analiza. Luego el equipo de backend construye su parte. Cuando termina, se la pasa al de frontend. Cuando el frontend termina, se la pasa a QA. Si QA encuentra un problema, vuelve al principio de la fila. No importa si a eso le llamas Sprint: es una cascada, solo que más corta.
Y una cascada trae siempre los mismos problemas:
- Tiempos muertos. Cada especialista espera a que el anterior termine. Mientras tanto, empieza otra cosa, y el trabajo a medio hacer se acumula.
- Cuellos de botella. La funcionalidad avanza a la velocidad del equipo más saturado. Si la única persona que conoce el módulo de pagos está ocupada, todo lo que toca pagos espera.
- Información tácita que se pierde. En cada traspaso se pierde contexto. Lo que el backend entendió de la necesidad del cliente no viaja completo en un ticket. Lo que QA descubre llega tarde a quien lo podría haber evitado.
- Más coordinación, más gente. Las dependencias entre equipos hay que planificarlas, y alguien tiene que hacerlo. Así nacen los coordinadores, los gerentes de integración y las reuniones de sincronización. La organización crece para administrar problemas que ella misma creó.
La sobreespecialización por componente lo empeora: cada componente se convierte en un pequeño feudo, con su dueño, su cola de pedidos y su propio ritmo. Y cuando esa persona se va de vacaciones, o de la empresa, el conocimiento se va con ella.
La estructura se copia en el producto
Hay una razón más profunda por la que esto importa. En 1968, Melvin Conway observó que las organizaciones diseñan sistemas que copian su propia estructura de comunicación. Es lo que hoy se conoce como la ley de Conway.
Si organizas a tu gente por capas y componentes, vas a obtener un producto partido en capas y componentes, con interfaces negociadas entre equipos que no necesariamente responden a lo que el cliente necesita. Los equipos por componente siguen la ley de Conway. Los equipos de funcionalidad la usan a su favor: la estructura se organiza alrededor del valor para el cliente, y el producto también.
Dos errores comunes
1. Hacer Scrum con especialistas y creer que eso alcanza
El error más común es adoptar Scrum, con sus eventos, sus roles y sus Sprints, y mantener intactos los equipos por especialidad. Se cree que el marco por sí solo va a resolver las ineficiencias de la cascada. No lo hace.
Lo que pasa en la práctica es que el Sprint se convierte en una mini cascada: los primeros días se analiza, los del medio se desarrolla y los últimos se prueba. O, a escala, cada equipo hace “su parte” de la funcionalidad en su propio Sprint, y la funcionalidad completa recién está lista varios Sprints después. Scrum funciona, pero así no despierta todo el potencial que tiene para ofrecer.
2. Repetir el mismo error con la IA
Peor todavía es lo que estoy viendo en estos tiempos: empresas que entrenan o configuran modelos de IA que, igual que sus developers, están especializados en capas y componentes. Un agente para el backend, otro para el frontend, otro para las pruebas.
Es la misma cascada, ahora automatizada. Los traspasos siguen existiendo, solo que entre máquinas. Y los problemas de fondo, las dependencias, la pérdida de contexto y la falta de una visión de punta a punta del cliente, siguen ahí. La IA no corrige una mala estructura: la acelera.
“Pero no todos pueden saber de todo”
Es la objeción que escucho siempre, y es razonable. Un equipo de funcionalidad no significa que cada persona domine todas las capas y todos los componentes. Significa que el equipo, en su conjunto, tiene las habilidades para entregar una funcionalidad completa.
Las personas mantienen una especialidad principal, pero aprenden y colaboran en otras áreas cuando el trabajo lo requiere. En LeSS se habla de equilibrar especialización y flexibilidad. Las prácticas técnicas como la integración continua y la propiedad compartida del código hacen que eso sea posible.
Con la IA, este modelo es más barato que nunca
Lo que antes era un esfuerzo grande de aprendizaje, hoy es mucho más accesible. Un developer que domina el backend puede apoyarse en la IA para trabajar con seguridad en el frontend, entender un componente que nunca tocó o escribir las pruebas automatizadas de su propia funcionalidad.
La IA reduce justamente la barrera que hacía costoso tener equipos multicapa y multicomponente. Por eso creo que, en la era de la IA, los equipos de funcionalidad son la forma más económica y eficiente de desarrollar software. La IA no hace que la especialización sea más necesaria: la hace menos necesaria.
Esto es lo que enseño en mis clases, y lo que he visto funcionar en la práctica. Y va a seguir funcionando, porque no depende de una moda ni de una herramienta: depende de reducir los traspasos, las esperas y las dependencias entre el problema del cliente y su solución.
La pregunta para tu organización
Si quieres saber de qué lado estás, hazte esta pregunta: para entregar una funcionalidad completa a un cliente, ¿cuántos equipos tienen que intervenir?
Si la respuesta es uno, vas por buen camino. Si la respuesta es tres, cuatro o cinco, no importa cuántos Sprints hagas: estás trabajando en cascada.
Aprende a escalar con equipos de funcionalidad
En mis cursos de LeSS trabajamos en detalle cómo pasar de equipos por componente a equipos de funcionalidad, y cómo hacerlo sin detener la operación. Y si tu organización ya está en ese camino y necesita acompañamiento, conversemos.
