En la era de la programación agéntica con IA, sigue siendo Scrum, Waterfall o cowboy

Ahora cualquiera puede tener su propio equipo de desarrollo dedicado por 100 dólares al mes y hacer realidad prácticamente cualquier cosa que imagine. Todo el mundo puede ser Product Owner.

Solo hay un pequeño inconveniente: esto es como crear un millón de Product Owners con una visión de producto sólida, pero sin ningún tipo de formación en Scrum, y darles un equipo de desarrollo con grandes habilidades técnicas, pero también sin formación alguna en Scrum. Desde el punto de vista de la productividad, la calidad y la capacidad de escalar, esto es una receta para el caos total.

Sabes qué quieres construir (a alto nivel), sabes cómo construirlo (a nivel de unidad o componente), pero no tienes ni idea de cómo orquestar todo el conjunto. Precisamente para eso existe Scrum, y normalmente necesitas las habilidades de un Scrum Master para hacerlo.

Pero la mayoría de la gente no las tiene. Así que, del mismo modo que ya tenemos un término para referirnos a la basura generada por IA en redes sociales (AI slop), ahora tenemos toneladas de «código basura generado por IA» (AI slop code).

Podríamos llamarlo el efecto Spider-Man: un gran poder conlleva una gran responsabilidad, y muy pocas personas conocen realmente Scrum, por lo que están plagadas de conceptos erróneos, malentendidos y frustraciones.

Pero Scrum sigue siendo Scrum: la forma indiscutible número uno de construir productos de software en el mundo. Simplemente no existe una alternativa.

¿Qué crees que ocurre cuando das a un Product Owner acceso ilimitado a un equipo deseoso de programar?

Cowboy. O quizá Waterfall, si la especificación es lo suficientemente detallada.

Anthropic y muchas otras personas reconocieron este problema y se propusieron abordarlo: los agentes y los equipos agénticos necesitan una metodología de desarrollo, igual que los humanos.

Empezaron a aparecer habilidades y técnicas para gestionar el trabajo. Una de las primeras fue el «Wiggum loop» de Geoffrey Huntley, una idea sencilla: iterar sobre algo hasta que alcance un estado de finalización. Es una especie de versión primitiva de Scrum, en la que las iteraciones son definidas por la máquina y el punto de finalización está definido de forma bastante difusa.

Anthropic lo malinterpretó inmediatamente y lanzó un plugin que no reiniciaba el contexto en cada iteración, lo que le valió bastante burla (aunque sospecho que sus ingenieros apostaban por una compactación automática del contexto).

También vimos surgir proyectos ambiciosos como Gas Town, de Steve Yegge, y combinaciones de skills como BMAD. Muchos de estos enfoques se parecen mucho a las prácticas Agile y a las ideas de Scrum, envueltas en algunas reflexiones adicionales de sus autores.

Finalmente, Superpowers, de Jesse Vincent, llegó al marketplace oficial de plugins de Anthropic: un conjunto de skills ajustadas para Claude Code que incorporaba de forma clara y explícita varias prácticas Agile, principalmente técnicas, en un conjunto ordenado de directrices para equipos agénticos.

Pero ninguno de estos enfoques aborda los problemas que Scrum está diseñado para resolver: construir un producto de alta calidad de forma iterativa e incremental.

De hecho, varios de ellos te llevan en la dirección opuesta, de vuelta a Waterfall.

«Construye primero la especificación perfecta y después entrégasela a un ejército de agentes» es el nuevo mantra.

Pero ¿es realmente el enfoque correcto? Basura entra, basura sale, ¿no? No puedes utilizar la IA para esquivar el problema de la complejidad: hasta que construyes y pruebas un producto con usuarios finales reales, no sabes realmente qué necesitabas construir. Por eso hacemos Scrum.

Entonces, ¿qué significaría que un equipo agéntico hiciera Scrum?

• El humano es el Product Owner.
• El agente es el Development Team.
• Las skills y el archivo AGENTS.md son el Scrum Master.

El tercer punto es la clave. En Scrum, gran parte del trabajo del Scrum Master consiste en «arrear gatos»: intentar conseguir que las personas definan y respeten acuerdos de trabajo. El día a día de un Scrum Master consiste en apoyar al PO en el mantenimiento del Product Backlog y en dividir los PBIs en piezas más pequeñas, ayudar a los desarrolladores a refinar y estimar el trabajo, y promover la excelencia técnica.

Ahora, gran parte, si no todo, de esto puede delegarse en agentes de IA. Así que el trabajo del Scrum Master pasa a estar, al menos parcialmente, automatizado. No completamente, pero sí en gran medida. La clave está en que necesitas un Sprint Zero sólido, en el que definas y configures todos los acuerdos de trabajo, herramientas, entornos, etc.

Lo cual parece devolvernos al punto de partida, ya que las únicas personas que quedan son perfiles de producto, no Agile Coaches. No pueden escribir acuerdos de trabajo que nunca han experimentado. Pero la buena noticia es que no tienen que hacerlo. Otra persona puede escribirlos una sola vez por ellos, y se convierte en un coste único, no en un coste por proyecto. Partes de un conjunto de prácticas que ya sabes que funcionan y solo cambias aquello que realmente exige tu contexto.

Por ejemplo, en un producto nuevo que estamos desarrollando, utilizamos una metodología Agile agéntica estricta que sigue de cerca lo que haríamos con un equipo humano:

• Creamos y dividimos los PBIs en un Product Backlog, con una Definition of Ready y una Definition of Done.
• Hacemos refinement y «PBI Planning» (el equivalente a Sprint Planning, pero a nivel de cada PBI; algo ligeramente Scrumban).
• Implementamos las prácticas técnicas que mantienen la calidad alta: TDD, code reviews, integración continua y un pipeline DevOps de entrega (tests de aceptación automatizados, despliegues automatizados y migraciones de base de datos).
• Actualizamos la documentación como parte de la Definition of Done.
  

Los agentes son muy buenos siguiendo instrucciones cuando su contexto está bien estructurado y no está sobrecargado. Los nuestros siguen siempre la metodología, lo que significa que tenemos pocas regresiones y somos capaces de mantener una velocidad constante. Según mi experiencia, una User Story típica tarda unos 20 minutos en recorrer todo su ciclo de vida, desde no estar lista hasta llegar a producción, en una base de código de unas 800.000 líneas.

Así que, en definitiva: o Scrum o cowboy. La buena noticia es que ahora gran parte de un buen Scrum puede hacerse automáticamente por ti si consigues definir las skills adecuadas y el CLAUDE.md correcto. La mala noticia es que ser Product Owner sigue sin poder automatizarse. Esa parte todavía tienes que aprenderla.

Y también tienes que aprender cómo crear, coordinar y controlar un ejército de agentes de desarrollo basados en IA. Podemos ayudarte con todo esto.