Escalar Agile Sin SAFe: Enfoques Ligeros para Organizaciones de Ingeniería en Crecimiento
Aquí hay un patrón que he visto repetirse al menos una docena de veces. Una startup crece de un equipo a tres o cuatro. La coordinación se complica. Alguien propone SAFe (Scaled Agile Framework) como solución. Seis meses después, la organización de ingeniería se ahoga en ceremonias de PI Planning, Agile Release Trains y definiciones de roles que nadie puede recordar. Los ingenieros pasan más tiempo en reuniones de alineación que escribiendo código.
SAFe resuelve un problema real. Pero para la mayoría de las organizaciones de ingeniería entre 20 y 50 ingenieros, es la solución equivocada — un framework diseñado para empresas con cientos de ingenieros, comprimido en una organización de escala media.
El Problema Real que SAFe Intenta Resolver
Seamos justos con SAFe nombrando lo que aborda. Cuando pasas de un equipo a múltiples equipos, te topas con problemas de coordinación que antes no existían:
- Dependencias entre equipos. El Equipo A no puede lanzar su función hasta que el Equipo B termine la API que necesita. Nadie se entera hasta el último día del sprint.
- Prioridades conflictivas. El equipo de producto le dice al Equipo 1 que la función X es urgente, mientras el Equipo 2 trabaja en la infraestructura de la que depende la función X — pero nadie conectó los puntos.
- Bases de código y servicios compartidos. Múltiples equipos desplegando en los mismos servicios, a veces sobreescribiendo los cambios de los otros.
- Alineación estratégica. Cada equipo optimiza para su propio backlog sin entender cómo su trabajo se conecta con los objetivos trimestrales de la empresa.
Estos son problemas reales. Los he vivido todos. La pregunta no es si necesitas abordarlos. Es cuánta sobrecarga de proceso está justificada para tu tamaño de organización.
Por Qué SAFe Se Excede a Escala Media
SAFe introduce una estructura masiva: Program Increments, Agile Release Trains, Release Train Engineers, System Demos, Solution Trains y toda una taxonomía de roles y ceremonias. Para una organización de 200 ingenieros en sanidad o finanzas, quizás justificado. ¿Para una startup de 30 ingenieros con cuatro squads? Aquí está por qué es absurdo:
La sobrecarga de ceremonias es brutal. El PI Planning solo es un evento de dos días cada 8-12 semanas. Sumando preparación, seguimiento y ceremonias continuas, has añadido días de reuniones por trimestre al calendario de cada ingeniero.
La proliferación de roles añade coste sin valor. Release Train Engineer, Solution Architect, Epic Owners — en una organización de 30 personas, estos roles o no existen o los ocupan personas ya sobrecargadas.
Optimiza la previsibilidad sobre la velocidad. Comprometerse en ciclos de 10 semanas daña activamente tu capacidad de responder al feedback del mercado.
Desalienta la comunicación informal. "Eso es un tema de Scrum of Scrums" se convierte en una excusa para no escribir al Slack de la persona que te puede desbloquear ahora mismo.
La Alternativa Ligera: Lo Que Realmente Funciona
He visto los siguientes enfoques funcionar bien para organizaciones en el rango de 20-50 ingenieros. Resuelven los mismos problemas de coordinación con una fracción de la sobrecarga.
Sincronización Semanal entre Equipos (30 minutos)
Un representante de cada equipo se une a una reunión semanal. La agenda es simple:
- ¿Qué lanzáis esta semana? (2 minutos por equipo)
- ¿Qué os bloquea de otro equipo? (identificar dependencias)
- ¿Qué cambia que los demás deberían saber? (servicios compartidos, cambios de API, actualizaciones de infra)
Eso es todo. Sin informes de estado. Sin porcentajes de progreso. Si algo necesita una discusión más profunda, programa un seguimiento. La sincronización es para identificar, no para resolver.
Taller Trimestral de Mapeo de Dependencias (medio día)
Una vez al trimestre, los líderes de equipo y los product managers mapean el trabajo planificado del próximo trimestre en un tablero compartido. No un plan detallado — un mapa aproximado de dependencias. Buscas: dos equipos cambiando el mismo servicio, funciones que dependen de trabajo no priorizado, infraestructura compartida que nadie posee.
Este es el núcleo útil del PI Planning, despojado de ceremonias. Medio día en lugar de dos días. Escribe las dependencias en un tablero de Miro, asigna propietarios, sigue adelante.
Sprint Reviews Conjuntas
En lugar de que cada equipo haga su sprint review de forma aislada, haz una sesión de demo compartida cada dos semanas (o mensualmente, dependiendo de tu cadencia). Cada equipo muestra lo que lanzó. La audiencia son los otros equipos.
Esto hace tres cosas:
- Construye comprensión compartida. Los ingenieros ven en qué están trabajando los otros equipos y cómo se conecta el producto.
- Crea coordinación informal. "¿Oh, estáis construyendo eso? Tenemos una necesidad similar — hablemos después."
- Eleva la calidad. Cuando sabes que otros ingenieros verán tu trabajo, eres más intencional sobre lo que lanzas.
Mantén el tiempo ajustado. 10 minutos por equipo, máximo.
Backlogs Compartidos para el Trabajo de Plataforma
Si múltiples equipos dependen de la infraestructura compartida, crea un backlog de plataforma al que cualquier equipo pueda contribuir. No necesitas todavía un equipo de plataforma dedicado. Pero necesitas una lista visible y priorizada del trabajo de plataforma para que no se pierda en el backlog de funcionalidades de cada equipo.
Rituales entre Squads
Dos prácticas ligeras que dan dividendos desproporcionados:
Tech talks. Cada dos semanas, un ingeniero presenta algo durante 20-30 minutos. Una nueva herramienta, una decisión arquitectónica, un incidente en producción. Difunde conocimiento y construye relaciones entre equipos.
Revisores rotativos entre equipos. Asigna revisores de otros equipos para PRs que tocan servicios compartidos. Esto detecta problemas de integración temprano y construye familiaridad entre equipos.
Cuándo SAFe Realmente Tiene Sentido
No soy contra SAFe de manera categórica. Hay contextos donde la sobrecarga está justificada:
- Organizaciones muy grandes (100+ ingenieros) donde la coordinación informal físicamente no puede escalar
- Industrias reguladas donde los rastros de auditoría y la planificación documentada son requisitos de cumplimiento
- Empresas multiproducto donde diferentes unidades de negocio necesitan coordinar lanzamientos
Pero si eres una startup o scale-up con 20-50 ingenieros y 3-6 equipos, casi con certeza no lo necesitas.
El Principio Detrás de Todo Esto
El principio subyacente es simple: la coordinación debe ser tan ligera como la complejidad requiere y no más pesada. Comienza con el proceso mínimo viable. Si se rompe, añade estructura. Si aguanta, déjalo en paz.
La pregunta correcta no es "¿qué proceso deberíamos adoptar?" Es "¿cuál es la cantidad mínima de coordinación que nos permite lanzar sin romper el trabajo de los demás?"
En Conectia, los equipos que construimos para startups europeas y estadounidenses a menudo se incorporan exactamente en esta etapa de crecimiento — tres a cinco squads averiguando cómo coordinarse. Nuestros ingenieros senior de LATAM tienen experiencia trabajando en configuraciones distribuidas de múltiples equipos y aportan patrones prácticos de coordinación que no requieren adoptar un framework empresarial para funcionar.
¿Haciendo crecer tu organización de ingeniería y necesitas ingenieros que sepan trabajar entre equipos? Habla con un CTO — nuestros ingenieros senior se integran en configuraciones de múltiples squads y aportan experiencia de coordinación desde el primer día.
