Parte I. Lo que cambia y lo que no
El cuello de botella siempre se mueve
De la cascada a los agentes: qué se abarató en cada época y qué siguió caro
Una historia que ya has vivido
Comencé a desarrollar en grandes proyectos web para bancos en el año 2000 dentro de IBM Lotus. Un analista nos entregaba documento funcional exhaustivo y el jefe de proyecto repartía los módulos entre diferentes compañeros del equipo. No habían planes de pruebas formales, así que lo que revisaba el jefe de proyecto iba directo a producción.
Y así nos devolvían muchas incidencias y algún que otro grito. Era un modelo de proyecto "de cowboys" que tiraba adelante porque poníamos muchas horas cada día. Y después de 4 años decidí dejar el desarrollo y moverme a otro departamento (IBM Rational) desde donde ayudar a otros equipos a desarrollar mejor.
El cuello de botella pasó de la comunicación informal entre compañeros a diseñar más documentación. Pero ahí Descubrí algo que lo cambió todo: la integración continua. El cuello de botella ya no era pasarse grandes bloques de trabajo, sino controlar cuando el flujo de tareas pasaban las pruebas técnicas y funcionales.
Pero continuaban habiendo grandes despliegues a producción, junto con su incertidumbre. Y luego llegó de DevOps y los entornos en la nube. La construcción y entrega de software cada vez ha sido más rápida y barata. En esta época ya no estaba en el desarrollo activo, pero sí acompañando a los equipos para adoptar esas prácticas y este cambio de mentalidad.
Ramón, el director de tecnología de GymTonic, lo contó a su manera en el comité. "Cuando entré, una versión de la app tardaba tres meses en llegar a las tiendas. Con la nube pasamos a publicar cada semana. Ahora el equipo escribe en una tarde lo que antes era un Sprint. Y aun así, el entrenador virtual lleva cuatro meses sin salir." Nadie le pidió que explicara por qué.
Cada época abarató un paso
Una idea, para llegar a un socio, recorre un camino: alguien decide qué merece la pena, alguien lo construye, se integra con lo que ya existe, se prueba, se despliega y alguien lo usa. Ese camino es el flujo de valor. Cada época del desarrollo de software abarató un paso de ese flujo, y cada vez el atasco se fue al paso siguiente.
En los noventa, equivocarse era carísimo. Integrar y desplegar llevaba semanas o meses, así que se intentaba acertar a la primera con fases y documentos: requisitos, diseño, construcción, pruebas. El cuello de botella era todo lo que venía después de escribir el código.
Con el cambio de siglo, la integración continua y las pruebas automáticas abarataron integrar. Ahí crecieron XP y Scrum: si integrar es barato, puedes entregar algo pequeño cada pocas semanas y aprender de ello. El atasco pasó a desplegar.
En la década de 2010, DevOps y la nube abarataron desplegar. Pasar de una vez al trimestre a varias veces al día dejó de ser una hazaña. El atasco pasó a escribir: había más ideas que capacidad para construirlas, y los equipos se organizaron para proteger esa capacidad.
En la década de 2020, la IA abarata escribir código. Y el atasco vuelve a moverse: a decidir qué construir, a validar que sirve, a revisar lo que se ha escrito y a responder de ello.
Lo que Scrum protegía de verdad
Scrum sobrevivió a cada salto porque nunca protegía la capacidad de los programadores. Protegía el aprendizaje: ciclos cortos para no equivocarse durante meses, una persona que decide el valor y una revisión con quien lo usa.
Muchas empresas, eso sí, lo usaron para lo otro. Sprints para repartir tickets, estimaciones para negociar capacidad, una Daily para controlar. Ese Scrum de fábrica de tickets es el que sobra con IA, porque la fábrica ya no es el problema.
El argumento contrario, de frente
Hay quien dice que Scrum ya no hace falta. Jeff Gothelf, en Product Management and AI (Sense & Respond Press, 2026, capítulo 1), escribe que cuando producir una funcionalidad lleva minutos y no meses, la entrega deja de ser un acontecimiento, y que procesos como Agile y Scrum ya no son necesarios de la misma manera.
Marty Cagan habla de la paradoja de productividad de la IA: los equipos van más rápido y las empresas no saben decir qué han ganado.
Tienen razón en lo que critican. Si tu Scrum consistía en proteger la capacidad de construir, con IA te sobra. Pero lo que proponen a cambio (hipótesis, experimentos, medir cómo cambia el comportamiento de la gente y decidir con esa evidencia) es el empirismo de Scrum bien hecho. No sustituyen a Scrum: le quitan lo que nunca debió tener.
El dato incómodo
Hay un dato que conviene tener a mano cuando alguien dice que la IA lo acelera todo. El informe DORA de 2024, que mide cada año cómo entregan software miles de equipos, encontró que un aumento del 25 % en el uso de IA iba asociado a una caída de alrededor del 7 % en la estabilidad de las entregas y del 1,5 % en el ritmo de entrega.
Un estudio de 2026 apunta en la misma dirección, con datos de uso real. Tres economistas del MIT y de Wharton (Mert Demirer, Leon Musolff y Liyuan Yang), en un trabajo publicado por la NBER (la oficina nacional de investigación económica de Estados Unidos), siguieron a más de 500.000 desarrolladores de GitHub y compararon su trabajo antes y después de usar herramientas de IA.
Con agentes autónomos, los cambios de código que subían (los commits) aumentaron un 240 %. Pero el efecto se diluía al acercarse al usuario: los proyectos crecieron un 80 % y las versiones publicadas, solo un 30 %. En las tiendas de aplicaciones que analizaron aparecieron muchas más aplicaciones nuevas, pero el uso total no creció.
Los autores lo atribuyen a los cuellos de botella humanos de la cadena: la IA multiplica lo que se escribe, no lo que llega a usarse.
Más velocidad en un paso no es más valor en el flujo. Si escribir es más rápido y revisar no, el código se amontona delante de la revisión y llega peor a producción. Volveremos sobre esto en los capítulos 11 y 13.
En resumen
Cada época abarató un paso del flujo de valor y el atasco se movió al siguiente. Con IA está en decidir, validar, revisar y responder. Eso es justo lo que Scrum hace bien cuando se usa para aprender y no para repartir tareas.
Pruébalo esta semana
Repasa los eventos de tu último Sprint y apunta, para cada uno, una decisión que se tomó en él. Si ninguno decidió nada, los críticos tienen razón contigo, y el capítulo 10 es para ti.
Si quieres la versión corta de este argumento para compartirla con tu equipo, está en el artículo La IA no ha matado Scrum.