Hace unos meses acompañé a una organización que estaba convencida de tener un problema con Scrum. "No funciona", me dijeron en la primera reunión. Cuando me senté con uno de sus equipos, descubrí lo contrario: ese equipo trabajaba de maravilla, entregaba cada dos semanas y la moral era alta. El problema no era el equipo. Era todo lo que pasaba alrededor de él: ocho equipos más que dependían entre sí, una planificación anual rígida y una dirección que seguía pidiendo fechas exactas a doce meses. Lo que estaba roto no era Scrum, sino la idea de que podía copiarse tal cual desde un equipo hacia toda la empresa. En estos años he visto el patrón repetirse tantas veces que vale la pena detenerse a entenderlo.
En corto: Scrum está diseñado para un equipo pequeño y autónomo, y a esa escala funciona muy bien. Al subir al nivel de varios equipos y de la organización completa aparecen dependencias, coordinación y gobierno que un solo marco no resuelve. Escalar agilidad no es multiplicar ceremonias, sino rediseñar cómo se coordina, se decide y se financia el trabajo.
Scrum resuelve con elegancia un problema acotado: cómo hacer que un grupo de cinco a nueve personas entregue valor de forma incremental, inspeccione lo que hizo y se adapte. Casi toda su fuerza viene de tres condiciones que se dan de manera natural a esa escala.
Cuando estas tres condiciones se cumplen, Scrum se siente casi mágico. El error es pensar que esa magia es transferible por simple repetición. Si quiere repasar los fundamentos del marco a nivel de equipo, escribí antes sobre cómo aplicar Scrum bien desde el primer sprint; aquí me interesa lo que ocurre cuando hay muchos equipos a la vez.
El problema no es que Scrum "deje de servir". Es que las tres condiciones anteriores desaparecen una por una en cuanto pasamos de un equipo a diez. Lo que era trivial se vuelve costoso.
Ninguno de estos problemas es de actitud ni de disciplina. Son problemas estructurales que aparecen por el solo hecho de crecer. Por eso las respuestas también tienen que ser estructurales.
Escalar agilidad obliga a tomar decisiones que en un solo equipo ni siquiera existían. En mi experiencia, hay cuatro frentes que toda organización tiene que resolver de forma explícita, sin importar qué marco adopte.
Marcos como SAFe, LeSS o Nexus están justamente tratando de dar respuesta a estos cuatro frentes. Vale la pena conocerlos, pero con una advertencia: son puntos de partida, no recetas. Adoptar un marco de escalamiento al pie de la letra suele reproducir el mismo error original a mayor tamaño.
Estos son los tropiezos que veo con más frecuencia cuando una organización intenta llevar Scrum más allá del equipo. Reconocerlos a tiempo ahorra meses de frustración.
Cuando hablo de gobierno ágil no me refiero a más control, sino a cambiar la naturaleza del control. El gobierno tradicional pregunta "¿cumpliste el plan?". El gobierno ágil pregunta "¿estamos entregando valor y aprendiendo rápido?". Es un cambio profundo en lo que la dirección mira y exige.
Sin gobierno ágil, la dirección sigue pidiendo certezas que el método ya no entrega, y los equipos terminan fabricando planes ficticios para tranquilizar a sus jefes. Es la receta perfecta para que "lo ágil" pierda credibilidad arriba.
Aquí soy deliberadamente poco dogmático. La agilidad no reemplaza a la gestión de proyectos en todos los contextos; convive con ella. Hay trabajo que se beneficia de Scrum y trabajo que sigue necesitando un enfoque más predictivo, sobre todo cuando hay regulación, contratos a precio fijo, integraciones físicas o dependencias externas con fechas inamovibles.
En la práctica, las organizaciones grandes operan en modo híbrido: equipos ágiles entregando incrementos, dentro de un marco de portafolio que sí necesita coordinación, presupuesto y rendición de cuentas. Las prácticas formales de gestión de proyectos, como las que sistematiza el cuerpo de conocimiento del PMI, siguen siendo muy útiles para gobernar el portafolio, gestionar riesgos transversales y comunicar con stakeholders que piensan en términos de proyecto. El arte está en saber qué capa va a qué velocidad, sin obligar a toda la empresa a moverse al mismo ritmo.
¿Necesito un marco como SAFe para escalar Scrum?
No necesariamente. Un marco le da un lenguaje común y un punto de partida, pero el problema de fondo (dependencias, alineación, gobierno) hay que resolverlo en su contexto. Muchas organizaciones avanzan bien combinando prácticas de varios marcos y descartando lo que no les sirve.
¿Cuántos equipos puedo coordinar antes de necesitar estructura adicional?
Como regla práctica, mientras los equipos quepan en una misma sala de planificación y compartan un producto claro, la coordinación es ligera. Más allá de unos cuantos equipos interdependientes, conviene introducir sincronización y gobierno explícitos.
¿Escalar agilidad es un tema de método o de cultura?
De ambos, pero la cultura pesa más. Las prácticas se aprenden en semanas; la disposición a delegar decisiones y a tolerar incertidumbre toma mucho más. Si la dirección no cambia su forma de gobernar, ningún marco lo salvará.
¿Puedo mantener Scrum en los equipos y gestión de proyectos en el portafolio?
Sí, y suele ser lo más sensato en organizaciones grandes. La clave es definir con claridad la frontera entre ambas capas para que no se contradigan ni se dupliquen.
Si su organización siente que Scrum "no escala", lo más probable es que el método esté bien y lo que falte sea diseño organizacional alrededor de él. Antes de adoptar un marco completo, vale la pena hacer un diagnóstico honesto: dónde están las dependencias reales, qué decisiones siguen subiendo cuando no deberían y cómo se financia hoy el trabajo. En SUMāTO acompañamos ese diagnóstico con criterio de consultor, mirando la organización completa y no solo las ceremonias. Si quiere conversarlo con su caso concreto sobre la mesa, escríbanos y agendemos una conversación. El primer paso casi nunca es escalar más rápido; es entender bien qué necesita escalar.