En mi último libro defendí Scrum. Escribí un capítulo entero para argumentar que, leída con cuidado, la Guía de Scrum ya contiene la respuesta a lo que los agentes de código le están haciendo a los equipos de software: los timeboxes son topes, el refinamiento es escribir prompts, la Definición de Terminado es la restricción que deja fuera de producción el código verosímil y equivocado. Creo cada frase de ese capítulo. También es la versión educada.
Esta es la otra.
Imagina un equipo. Casi cualquier equipo que trabaje con agentes este año lo va a reconocer. Cinco desarrolladores, un Product Owner, un Scrum Master, Sprints de dos semanas. El lunes, la Planificación del Sprint se compromete con ocho elementos del backlog. El martes por la tarde, los agentes ya han escrito los ocho. No a la perfección: dos necesitan retoques, uno entendió mal los criterios de aceptación y otro se inventó un método del framework que no existe. Pero el código existe, y los tests también, y las pull requests están abiertas.
Y entonces el equipo espera. Espera la revisión, porque cinco personas no pueden revisar con cuidado lo que ocho agentes produjeron en día y medio. Espera el Scrum Diario, donde todos cuentan que «están trabajando» en cosas que se escribieron el martes. Espera la Revisión del Sprint, nueve días después, para enseñar a los interesados un trabajo que estaba terminado antes de que ellos terminaran el café. El calendario dice que el equipo está a mitad de Sprint. El trabajo dice que está en una sala de espera.
Nadie en esa sala está haciendo Scrum mal. Eso es lo incómodo. Están haciendo exactamente lo que describe la Guía, y la Guía ya no encaja con el trabajo.
Para qué se construyó Scrum
Scrum merece una audiencia justa antes de recibir una dura, porque lo que acertó, lo acertó de lleno.
Nació en los años noventa como reacción a una enfermedad concreta: proyectos grandes planificados enteros antes de escribir una línea de código, construidos durante un año, entregados tarde y equivocados. La cura fue el empirismo. Haz un poco de trabajo, míralo, decide qué hacer después. La Guía de 2020 lo sigue diciendo con claridad: Scrum se basa en el empirismo y en el pensamiento lean, y sus tres pilares son la transparencia, la inspección y la adaptación.
Todo lo demás en Scrum es maquinaria para que esos tres pilares ocurran en un mundo con una restricción decisiva. Construir software era lento, caro e incierto. Una parte utilizable costaba días o semanas de trabajo humano cualificado, y ese trabajo era el recurso más escaso de la organización.
Relee la Guía con esa restricción en mente y cada estructura encaja. El Sprint es un contenedor fijo, de un mes o menos, porque construir un incremento utilizable llevaba más o menos eso y hacía falta un momento regular para inspeccionarlo. El Product Owner ordena el backlog porque la capacidad de los desarrolladores era escasa y alguien tenía que decidir en qué se gastaba. El equipo es pequeño y multifuncional porque quienes construían eran el cuello de botella, así que se eliminaban todos los traspasos entre ellos. El Scrum Diario existe porque esas personas necesitaban coordinar sus horas escasas. La estimación existe porque había que saber cuánto de lo escaso iba a consumir cada trabajo.
Fue un diseño brillante. Para esa restricción.
La premisa que se rompió
La restricción ya no está.
No del todo, y no para todo tipo de trabajo. Pero para una parte grande y creciente de lo que hacen los equipos de software, producir un cambio que funciona ya no es la parte lenta. Un agente escribe la migración, el controlador, los tests y la documentación en minutos. Lo hace con competencia la mayoría de las veces, y con verosimilitud todas.
Lo que no se abarató es todo lo que rodea al código. Decidir qué cambio merece hacerse. Saber si el cambio que se hizo es correcto de verdad, que, cuando el autor es un modelo capaz de producir llamadas a una API seguras, idiomáticas y completamente inventadas, es un trabajo real y lento. Integrar cuarenta cambios correctos uno a uno en un sistema que siga teniendo sentido. Responder a las tres de la mañana por lo que se fusionó.
El recurso escaso se movió. Antes era construir. Ahora es el criterio: decidir y verificar.
Y este es el problema de Scrum, dicho con toda la precisión de la que soy capaz. Cada estructura de la Guía está pensada para la escasez antigua, y casi nada en ella está pensado para la nueva. No es un problema de práctica. Es un problema de diseño.
El Sprint es un lote
Empecemos por el corazón. La Guía llama a los Sprints «el corazón de Scrum», eventos de duración fija de un mes o menos, y tiene razón en que lo eran. También eran un lote: una cantidad de trabajo que se empieza junta, se inspecciona junta y se entrega junta, con un tamaño a la medida de lo que tardaba construir.
El pensamiento lean, que la Guía nombra como uno de sus dos fundamentos, tiene una opinión firme sobre los lotes. Los lotes grandes esconden defectos, retrasan la retroalimentación y generan inventario. Se reducen hasta que el coste de gestionar cada uno es lo que limita. Cuando construir llevaba dos semanas, dos semanas era un lote razonable. Cuando construir lleva una tarde, un lote de dos semanas significa que tu ciclo de retroalimentación es diez veces más lento que tu producción. No estás iterando. Estás haciendo cola.
Los defensores de Scrum tienen una respuesta, y es buena, así que le doy todo su peso. La Guía dice que se pueden crear varios Incrementos dentro de un Sprint, que el trabajo se puede entregar en cualquier momento y que la Revisión del Sprint nunca debe considerarse una barrera para liberar valor. Nada en Scrum te impide entregar el martes.
Es cierto. Pero mira lo que sigue funcionando al reloj del Sprint. El Objetivo del Sprint, un compromiso que se toma al principio sobre lo que logrará el Sprint entero, antes de que el equipo descubra que el trabajo que estaba planificando quedaría hecho en un día. La Planificación del Sprint, que pronostica un lote. La Revisión del Sprint, el gran momento de inspección con los interesados. La Retrospectiva, el gran momento de adaptación. Los pilares del empirismo, la inspección y la adaptación, van agendados sobre el lote. Puedes entregar de forma continua y seguir aprendiendo solo cada dos semanas, y aprender era todo el sentido.
Un marco construido sobre el empirismo que fija la frecuencia de su propia inspección, sin importar lo rápido que se mueva ahora el trabajo que hay debajo, ha dejado de ser empírico consigo mismo.
La estimación mide una variable muerta
La Guía es prudente en esto. No impone puntos de historia, ni velocidad, ni ninguna técnica de estimación; solo dice que los Developers dimensionan el trabajo durante el refinamiento y que el pronóstico del Sprint debe caber en su capacidad. Los puntos de historia son una costumbre de la comunidad, no una escritura sagrada.
Pero la costumbre nació del diseño, porque el diseño la necesitaba. Si el Sprint es un contenedor y lo que contiene es la capacidad de los desarrolladores, hace falta una unidad para medir cuánta capacidad consume cada elemento. Fuera cual fuera la unidad, siempre midió el esfuerzo de construir.
El esfuerzo de construir es ahora casi cero para mucho trabajo, y casi impredecible para el resto, porque que un agente acierte un cambio en cuatro minutos o produzca cuatro horas de disparates seguros de sí mismos depende de cosas que ninguna sesión de refinamiento puede ver. La estimación mide una variable que ya no restringe nada.
La velocidad es peor, porque ha dejado de ser simplemente inútil para volverse peligrosa. Los agentes la inflan. Un equipo que dimensionaba el trabajo por el esfuerzo de escribirlo ve que todo encoge, mete más en el Sprint, termina más elementos y ve subir el gráfico. El valor no sube con él. Las colas de revisión se alargan, los defectos que se escapan son cada vez más verosímiles, y el tablero del equipo anuncia el mejor trimestre de su historia. Los equipos que optimizan la velocidad en 2026 no miden productividad. Miden inventario y lo llaman progreso.
Las responsabilidades racionan lo que no es
La Guía de 2020 sustituyó los «roles» por las «responsabilidades», y la palabra es exacta, así que tomémosla en serio y preguntemos de qué responde cada una.
El Product Owner responde de maximizar el valor del producto resultante del trabajo del Scrum Team, sobre todo ordenando el Product Backlog. Ordenar es racionar. Responde a la pregunta: como no podemos construirlo todo, ¿qué construimos primero? Cuando construir era escaso, era la decisión más importante de la sala. Cuando construir abunda, la pregunta del orden no desaparece, pero cambia de forma. La pregunta difícil ya no es «¿qué construimos primero?». Es «¿qué merece construirse, ahora que podríamos construirlo todo, y cuánto nos va a costar mantenerlo?». Eso se parece más a la estrategia de producto que a la gestión del backlog, y la Guía no le da al Product Owner más herramienta que el backlog.
Los Developers se definen como las personas comprometidas a crear cualquier aspecto de un Incremento utilizable en cada Sprint. Crear. En un equipo que trabaja con agentes, lo que más hacen los Developers no es crear. Es especificar, verificar e integrar: escribir el elemento con la precisión suficiente para que un agente pueda actuar, comprobar que lo que volvió es correcto y asegurarse de que cuarenta cambios correctos sigan formando un sistema coherente. La Guía habla de inculcar calidad adhiriéndose a una Definición de Terminado, que se acerca. Pero describe al Developer como un constructor que además comprueba. El trabajo se ha convertido en un comprobador que además construye.
El Scrum Master responde de la efectividad del Scrum Team, estableciendo Scrum tal como lo define la Guía. Y ahí está exactamente la trampa. Un Scrum Master que hace bien su trabajo establece un proceso cuyo cuello de botella se ha movido, defiende eventos cuyo ritmo ya no coincide con el trabajo y enseña a estimar una variable que ya no restringe nada. Cuanto mejor es en el Scrum tal como está escrito, con más fidelidad mantiene al equipo en la sala de espera.
Ahora hazte la pregunta que importa. ¿Quién, en la Guía, responde de la verificación? ¿De lo escaso? La respuesta honesta es: todos y nadie. Va doblada dentro del compromiso de los Developers con la Definición de Terminado, junto a crear, junto a todo lo demás. En un mundo donde la verificación es el cuello de botella, el marco no tiene a nadie cuyo trabajo sea ese.
Los eventos hacen las preguntas de ayer
El Scrum Diario es un evento de quince minutos para que los Developers inspeccionen el progreso hacia el Objetivo del Sprint. En la práctica, y la propia Guía lo invita, es una conversación entre productores sobre lo que están produciendo. Cuando la producción la hacen agentes en minutos, los productores tienen muy poco que contar. La pregunta que importa, ¿qué está esperando a ser verificado, y desde cuándo?, no es la que el evento se construyó para hacer.
La Revisión del Sprint inspecciona el Incremento con los interesados. Con agentes, el Incremento es grande, y la tentación es exhibirlo: cuarenta pull requests, seis funcionalidades, una diapositiva con la velocidad. A los interesados les impresiona el volumen porque el volumen es lo que pueden ver. Si algo de eso funciona, si es correcto, si sobrevivirá a usuarios reales, es invisible en una demo, y el evento no tiene ninguna estructura que lo haga visible.
La Retrospectiva del Sprint es el único evento que sobrevive intacto al cambio. Su propósito es planificar formas de aumentar la calidad y la efectividad, y la Guía incluye expresamente las herramientas y la Definición de Terminado en lo que inspecciona. Una buena Retrospectiva, con la pregunta correcta (¿qué cosa verosímil y equivocada se escapó en este Sprint, y qué la habría atrapado?), es la hora más útil que puede pasar un equipo que trabaja con agentes.
También es el evento que los equipos se saltan primero.
Liturgia sin teología
Aquí va lo más duro que voy a decir, y lo digo como alguien que tiene el certificado.
El valor real de Scrum nunca estuvo en sus eventos, sus artefactos o sus responsabilidades. Estuvo en la teología que hay debajo: el empirismo, la convicción de que lo que funciona se descubre haciendo un poco y mirando con honestidad el resultado. Los eventos eran la liturgia, las prácticas que hacían que esa teología ocurriera en un calendario.
En la mayoría de las organizaciones que he visto, la liturgia ha sobrevivido a la teología. Los equipos celebran todos los eventos, rellenan todos los artefactos y cubren todas las responsabilidades, e inspeccionan casi nada y adaptan todavía menos. Eso ya era verdad antes de que llegaran los agentes. Lo que han hecho los agentes es volver imposible ignorar la distancia, porque la liturgia está ahora visiblemente desacompasada del trabajo. El equipo planifica ceremoniosamente dos semanas de algo que llevó dos días. Todos en la sala lo notan.
También hay una industria alrededor de la liturgia, y vale la pena nombrarla porque explica por qué sobrevive. Certificaciones, formadores, marcos escalados apilados sobre el marco, consultores que venden los eventos. Nada de eso es malintencionado. Todo tiene interés en que Scrum siga siendo reconociblemente el mismo. Un marco cuya supervivencia es en parte comercial es un marco que tardará en admitir que su premisa ha cambiado.
Lo que debe sustituirlo, o en lo que Scrum debe convertirse
No propongo un marco nuevo. La industria no necesita otra marca registrada. Propongo lo que tendría que decir la próxima versión de la Guía si se escribiera hoy, desde el mismo empirismo, para la nueva restricción.
Verificación continua en lugar de un Sprint fijo. Mantén una cadencia para lo que de verdad la necesita: hablar con los interesados, tomar distancia, decidir el rumbo. Pero deja de agrupar el trabajo mismo en esa cadencia. Cada cambio debe inspeccionarse cuando está listo, no cuando lo dice el calendario. La unidad de ritmo pasa a ser el cambio verificado, no el Sprint.
La Definición de Terminado como artefacto principal. No una lista en una wiki: un contrato que hacen cumplir las máquinas donde pueden y revisores con nombre donde no. Pruebas, no afirmaciones: el cambio en disco, la compilación que corrió, los tests que pasaron con su salida, el comportamiento observado. El autor de un cambio, sea persona o agente, nunca es su único juez. Cuando producir es barato, la definición de terminado es el producto.
Límites al trabajo sin verificar en lugar de velocidad. Deja de medir cuánto se produjo. Mide cuánto espera a ser verificado, cuánto lleva esperando y qué parte de lo que se declaró terminado resultó no estarlo. Pon tope a la cola de cambios sin revisar, igual que lean pone tope al trabajo en curso. Cuando se alcanza el tope, nadie empieza trabajo nuevo; se verifica.
Una responsabilidad de verificación. Nómbrala. Alguien en el equipo responde de la pregunta «¿lo que entregamos es correcto de verdad?», igual que el Product Owner responde de «¿lo que construimos merece la pena?». Puede rotar. No puede ser todo el mundo, porque todo el mundo es nadie.
Planificar por capacidad de revisión. El límite real del rendimiento de un equipo es cuánto puede verificar con cuidado. Planifica contra ese número. Dimensiona el trabajo por lo que costará comprobarlo (cuán reversible es, hasta dónde puede extenderse el daño, cuánto pueden ver de verdad los tests) y no por lo que costará escribirlo.
Un Product Owner para el criterio, no para el racionamiento. Cuando el equipo puede construir casi cualquier cosa, el trabajo del Product Owner es decidir qué merece la pena poseer: cada funcionalidad construida es una funcionalidad que hay que mantener, verificar, proteger y explicar. El backlog deja de ser una cola y se convierte en un conjunto de apuestas.
Nada de esto abandona los fundamentos de Scrum. Los aplica al mundo tal como es. Esa es la prueba de si un marco es empírico: cuando cambia la evidencia, ¿cambia el marco?
Tres palabras
El sucesor de Scrum, se llame como se llame, conservará tres palabras: transparencia, inspección, adaptación. Tirará casi todo lo que se construyó encima de ellas para un mundo en el que construir era lento.
Si Scrum está dispuesto a ser ese sucesor, sobrevive, y lo merece. Quienes escribieron la Guía ya la han revisado antes, y la revisión de 2020 fue más valiente de lo que muchos le reconocen: la hizo más corta y menos prescriptiva, y sustituyó los roles por responsabilidades. Otra revisión con ese valor bastaría.
Si no está dispuesto, se convierte en aquello que se inventó para sustituir: un proceso que se sigue porque es el proceso, por equipos que notan que el calendario y el trabajo han dejado de estar de acuerdo, y a los que se les dice que el problema es su disciplina.
El problema nunca fue su disciplina. El cuello de botella se movió. Scrum no.