Escalar Agile sin SAFe: coordinación ligera para organizaciones de ingeniería en crecimiento
Hay un patrón que he visto repetirse al menos una docena de veces. Una startup pasa de un equipo a tres o cuatro. La coordinación empieza a complicarse. 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 consigue tener claras. 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 entre 20 y 50 ingenieros es la solución equivocada: un framework pensado para empresas con cientos de ingenieros, embutido en una organización de escala media.
El problema real que SAFe intenta resolver
Seamos justos con SAFe y empecemos por lo que aborda. Cuando pasas de un equipo a varios, aparecen problemas de coordinación que antes no existían:
- Dependencias entre equipos. El equipo A no puede lanzar su funcionalidad hasta que el equipo B termine la API que necesita. Y nadie se entera hasta el último día del sprint.
- Prioridades en conflicto. Producto le dice al squad 1 que la funcionalidad X es urgente mientras el squad 2 trabaja en la infraestructura de la que depende esa misma funcionalidad — y nadie ha atado los cabos.
- Código y servicios compartidos. Varios equipos desplegando sobre los mismos servicios, a veces pisándose los cambios o provocando regresiones inesperadas.
- Alineación estratégica. Cada equipo optimiza su propio backlog sin entender cómo encaja su trabajo en los objetivos trimestrales de la empresa.
Son problemas reales. Los he vivido todos. La pregunta no es si hay que abordarlos, sino cuánta sobrecarga de proceso se justifica para el tamaño de tu organización.
Por qué SAFe se pasa de frenada a escala media
SAFe introduce una estructura enorme: 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á se justifique. ¿Para una startup de 30 ingenieros con cuatro squads? Esto es lo que la hace absurda:
La sobrecarga de ceremonias es brutal. Solo el PI Planning ya es un evento de dos días cada 8-12 semanas. Suma la preparación, el seguimiento y las ceremonias recurrentes, y habrás añadido días enteros de reuniones por trimestre al calendario de cada ingeniero.
La proliferación de roles añade coste sin aportar valor. Release Train Engineer, Solution Architect, Epic Owners — en una organización de 30 personas, esos roles o no existen o recaen en gente que ya va al límite.
Prioriza la previsibilidad por encima de la velocidad. Encerrarte en compromisos de PI de 10 semanas daña activamente tu capacidad de reaccionar al feedback del mercado.
Desincentiva la comunicación informal. «Eso es tema del Scrum of Scrums» se convierte en la excusa para no escribir por Slack a la persona que puede desbloquearte ahora mismo.
La alternativa ligera: lo que funciona de verdad
He visto funcionar bien los siguientes enfoques en organizaciones de entre 20 y 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 asiste a una reunión semanal. La agenda es simple:
- ¿Qué vais a lanzar esta semana? (2 minutos por equipo)
- ¿Qué os está bloqueando de otro equipo? (sacar las dependencias a la superficie)
- ¿Qué va a cambiar que los demás deban saber? (servicios compartidos, cambios de API, actualizaciones de infraestructura)
Nada más. Sin informes de estado. Sin porcentajes de avance. Si algo necesita una conversación más profunda, se agenda aparte. La sincronización sirve para detectar, no para resolver.
Taller trimestral de mapa de dependencias (medio día)
Una vez al trimestre, los líderes de equipo y los product managers vuelcan el trabajo previsto para el siguiente trimestre en un tablero compartido. No es un plan detallado: es un mapa aproximado de dependencias. Buscas tres cosas: dos equipos tocando el mismo servicio, funcionalidades que dependen de trabajo sin priorizar e infraestructura compartida sin dueño.
Este es el núcleo útil del PI Planning, despojado de la ceremonia. Medio día en lugar de dos. Apuntas las dependencias en un tablero de Miro, asignas responsables y sigues adelante.
Sprint reviews conjuntas
En lugar de que cada equipo haga su sprint review por su cuenta, monta una sesión de demos compartida cada dos semanas (o mensual, según tu cadencia). Cada equipo enseña lo que ha lanzado. El público son los demás equipos.
Esto consigue tres cosas:
- Construye una visión compartida. Los ingenieros ven en qué trabajan los demás equipos y cómo encaja todo en el producto.
- Genera coordinación informal. «¿Estáis construyendo eso? Nosotros tenemos una necesidad parecida: hablamos después.»
- Sube la calidad. Cuando sabes que otros ingenieros van a ver tu trabajo, eres más deliberado con lo que lanzas.
Que sea ágil: 10 minutos por equipo, como máximo. Si las demos se alargan, dejan de ser útiles.
Backlogs compartidos para el trabajo de plataforma
Si varios equipos dependen de infraestructura compartida, crea un backlog de plataforma al que cualquier equipo pueda contribuir. Todavía no necesitas un equipo de plataforma dedicado. Pero sí necesitas una lista visible y priorizada del trabajo de plataforma, para que no se diluya en el backlog de funcionalidades de cada equipo. Asigna un responsable — normalmente un ingeniero senior o un tech lead — que priorice y se asegure de que el trabajo se recoge.
Rituales entre squads
Dos prácticas ligeras con un retorno desproporcionado:
Tech talks. Cada dos semanas, un ingeniero presenta algo durante 20-30 minutos: una herramienta nueva, una decisión de arquitectura, un incidente en producción. Difunde conocimiento y crea relaciones entre equipos.
Revisores rotatorios entre equipos. Asigna revisores de otros equipos para los PRs que tocan servicios compartidos. Detecta problemas de integración a tiempo y genera familiaridad entre equipos.
Cuándo SAFe sí tiene sentido
No estoy en contra de SAFe por sistema. Hay contextos donde la sobrecarga se justifica:
- Organizaciones muy grandes (más de 100 ingenieros), donde la coordinación informal sencillamente no puede escalar
- Sectores regulados, donde la trazabilidad, los registros de auditoría y la planificación documentada son requisitos de cumplimiento
- Empresas multiproducto, donde distintas unidades de negocio necesitan coordinar lanzamientos
- Organizaciones con poca madurez de ingeniería, donde los equipos necesitan más estructura, no menos (aunque diría que hay mejores sitios por donde empezar que SAFe)
Pero si eres una startup o scale-up con 20-50 ingenieros y de 3 a 6 equipos, casi seguro que no lo necesitas.
El principio detrás de todo esto
El principio de fondo es simple: la coordinación debe ser tan ligera como exija la complejidad, y ni un gramo más. Empieza con el proceso mínimo viable. Si se rompe, añade estructura. Si aguanta, no lo toques.
La pregunta correcta no es «¿qué proceso deberíamos adoptar?», sino «¿cuál es la mínima coordinación que nos permite lanzar sin rompernos el trabajo unos a otros?»
En Conectia, los equipos que montamos para startups europeas y estadounidenses suelen incorporarse justo en esta etapa de crecimiento: tres a cinco squads aprendiendo a coordinarse. Nuestros ingenieros senior de LATAM tienen experiencia en entornos distribuidos con varios equipos, y traen patrones prácticos de coordinación que funcionan sin necesidad de adoptar un framework empresarial.
¿Tu organización de ingeniería está creciendo y la coordinación entre equipos empieza a complicarse? Habla con un CTO.
