1. Introducción

1.1. El contexto del cambio

La Inteligencia Artificial Generativa lleva tres años en el centro del debate tecnológico. Ha traído cambios reales: asistentes de código que acortan ciclos, modelos que permiten a perfiles no técnicos generar prototipos funcionales, agentes que automatizan tareas que antes requerían horas. Y ha traído también promesas que no se han cumplido a la velocidad anunciada. En diciembre de 2025 MIT Technology Review describía el año como el gran correctivo del hype de la IA, señalando que la comunidad técnica estaba en plena revisión de expectativas. Este documento parte de ahí: de la realidad, no del entusiasmo.

Lo que sí ha cambiado de forma verificable es dónde se concentra el esfuerzo en los equipos de desarrollo. Cuando la IA puede generar código, tests y documentación en minutos, el cuello de botella deja de estar en la ingeniería y pasa a estar en otro lugar: decidir qué construir, para quién, y por qué. Eso no es un problema técnico. Es exactamente el problema que los marcos ágiles llevan décadas intentando resolver.

Scrum emergió en los años 80 como respuesta espontánea de comunidades de práctica al modelo en cascada, y desde entonces no ha dejado de transformarse con las aportaciones de esas mismas comunidades. Sus principios no nacieron pensando en la IA, pero tampoco nacieron pensando en el cloud, en el móvil ni en el software como servicio. Sobrevivieron a todos esos cambios. La pregunta que este documento se hace no es si Scrum sobrevivirá a la IA. Es qué deben cambiar los equipos que lo practican para que esa supervivencia genere valor real, y no se convierta en otro caso de adopción sin impacto.

1.2. Qué es este documento

Este documento es informativo, no normativo. No pretende definir un «nuevo Scrum» ni establecer reglas que sustituyan a ninguna fuente existente. Su propósito es ofrecer al lector un mapa actualizado del terreno para que cada equipo tome sus propias decisiones informadas.

El documento parte de una premisa que hace explícita: los principios ágiles mantienen su vigencia, pero muchas de las prácticas concretas que se han construido sobre ellos necesitan evolucionar. Esa evolución no tiene una forma única. Depende del contexto de cada equipo, de su madurez, de su sector y del papel real que la IA juega en su trabajo. Lo que encontrarás aquí no es una receta sino un conjunto de tensiones reales, evidencias contrastadas y preguntas abiertas que pueden ayudarte a trazar tu propio camino.

Nota para el lector: a lo largo de este documento encontrarás secciones de contexto, datos de la industria y modelos emergentes. Ninguno de ellos se presenta como «la respuesta correcta». La agilidad, por definición, rechaza las recetas universales. Usa esta guía como punto de partida para la reflexión y la experimentación de tu equipo.

2. El estado de la cuestión: Scrum frente a la IA

2.1. Scrum como conocimiento abierto y emergente

Para entender cómo debe evolucionar Scrum ante la IA, conviene primero entender qué es realmente Scrum y cómo ha llegado hasta aquí. Existe una confusión frecuente que merece ser aclarada desde el inicio de esta guía.

Scrum no es una metodología diseñada y difundida verticalmente desde una autoría académica, un comité de estandarización o un grupo de investigadores. A diferencia de modelos como CMMI (creado por la Universidad Carnegie Mellon) o SAFe (creado por Dean Leffingwell), Scrum no tiene un propietario que lo defina con exclusividad. Scrum emergió desde abajo, impulsado y construido horizontalmente por la comunidad profesional. Es un ejemplo de conocimiento abierto, de dominio público.

En los años 80, los ingenieros de empresas como 3M, Fuji, Honda o HP, descontentos con los modelos de producción basados en ciclos de cascada, desarrollaban un patrón iterativo con solapamiento de fases. En 1986 Hirotaka Takeuchi e Ikujiro Nonaka identificaron estos principios en su artículo "The New New Product Development Game" en Harvard Business Review, y les dieron el nombre de «scrum», tomado del rugby. Es importante entender que Nonaka y Takeuchi identificaron, dieron nombre y visibilidad al concepto, pero no lo crearon.

Posteriormente, diversas aportaciones enriquecieron el marco: Peter DeGrace y Leslie Hulet Stahl presentaron Scrum como propuesta de desarrollo iterativo en 1990; Jeff Sutherland y Ken Schwaber ofrecieron su propia interpretación en 1995; y desde entonces, la comunidad ágil ha continuado madurando y transformando las prácticas de Scrum de forma continua. La reducción de las iteraciones desde duraciones de uno o dos meses a una o dos semanas, la incorporación de las retrospectivas, el refinamiento del backlog, las prácticas de estimación (o de no estimación), los tableros kanban de gestión visual… todos son ejemplos de cómo la comunidad ha ido dando forma al Scrum que conocemos hoy.

Pensar en un autor único y en una «guía oficial» exclusiva es considerar cerrado y propietario a un conocimiento que es colaborativo y abierto. Al hacerlo, se encorseta y se le cortan las alas a un marco cuya fortaleza reside precisamente en su capacidad de evolución comunitaria.

Si Scrum fuera un modelo cerrado y propietario, adaptarlo a la IA requeriría esperar a que «sus autores» lo actualizaran. Pero si entendemos Scrum como conocimiento abierto, la adaptación a la IA es exactamente lo que la comunidad profesional debe hacer: observar cómo ha cambiado el contexto y evolucionar las prácticas manteniendo los principios. Eso es lo que esta guía propone.

2.2. El debate en la comunidad: aportaciones y voces relevantes

Ante el impacto de la IA, la comunidad ágil no ha guardado silencio. En poco tiempo ha producido un conjunto notable de aportaciones: algunas proponen adaptar las prácticas existentes, otras cuestionan si los marcos actuales siguen siendo válidos, y otras plantean paradigmas completamente nuevos. Lo que sigue es un mapa de las voces más relevantes, no un veredicto sobre cuál tiene razón.

El Scrum Guide Expansion Pack (SGEP, 2025)

Publicado en junio de 2025 por Jeff Sutherland, John Coleman y Ralph Jocham, el SGEP es un suplemento comunitario que se presenta como compañero opcional de la Scrum Guide de 2020. Sus aportaciones más relevantes para el debate sobre IA:

• Mutabilidad de Scrum: el SGEP declara explícitamente que Scrum es mutable, a diferencia de la Scrum Guide de 2020, que lo consideraba inmutable. Es un reconocimiento significativo: uno de los coautores originales del marco admite formalmente que necesita cambiar.

• IA como actor: reconoce a la IA como actor en ciertos contextos del equipo, incluyendo la posibilidad de que los «Product Developers puedan ser humanos o automatizados», con la condición de que al menos uno sea humano.

• Nuevas figuras y artefactos: renombra Developers como Product Developers, añade las figuras de Stakeholders y Supporters, e introduce la Definition of Outcome Done como medida de valor más allá de la calidad técnica del incremento.

El SGEP ha generado reacciones encontradas. No cuenta con el respaldo de Scrum.org ni con la participación de Ken Schwaber. Sus 50 páginas frente a las 13 de la Scrum Guide plantean además una pregunta de fondo: si la fortaleza de Scrum ha residido siempre en su concisión y en dejar espacio a cada equipo para completarlo, ¿un suplemento que multiplica por cuatro esa extensión está evolucionando el marco o contradiciendo su principio de simplicidad? Como toda aportación al conocimiento abierto, merece leerse con criterio propio.

El AI Teammate Framework (Scrum.org, 2025)

Scrum.org ha publicado un framework de cuatro pasos para integrar la IA en equipos Scrum: Model Management, Context Management, Prompt Engineering y Governance Management. Es un enfoque pragmático centrado en tratar la IA como un compañero de equipo al que se hace onboarding con contexto, se le guían las interacciones y se establece gobernanza sobre sus outputs.

La analogía del teammate es pedagógicamente útil, pero tiene un límite importante: a diferencia de un humano, la IA no tiene motivación propia, no desarrolla relaciones de confianza y no aprende del equipo en el sentido en que lo hace una persona. Eso no invalida el framework, pero sí invita a usarlo con conciencia de lo que la analogía no captura. La IA es una herramienta extraordinariamente potente; tratarla como un compañero de equipo puede simplificar su integración o puede generar expectativas equivocadas sobre lo que esa integración produce.

El Agile AI Manifesto (Scrum.org, 2025)

Un análisis que argumenta que los principios del Manifiesto Ágil de 2001 se alinean de forma notable con cómo funciona la IA generativa, y que la IA amplifica el valor de los profesionales que aportan juicio y experiencia mientras expone a quienes realizaban trabajo mecánico. Está sustentado en el estudio The Cybernetic Teammate (Dell'Acqua et al., 2025), un experimento de campo con 776 profesionales de Procter & Gamble.

La tesis es sólida en lo empírico. Merece, sin embargo, una lectura cuidadosa en un punto: que los principios del Manifiesto sean compatibles con la IA no implica automáticamente que las prácticas habituales construidas sobre ellos lo sean también. Y la afirmación de que la IA expone a quienes solo hacían trabajo mecánico, aunque respaldada por los datos, no es una conclusión neutral: es una narrativa que conviene examinar también desde dentro, preguntando en qué medida los propios marcos ágiles han generado trabajo mecánico disfrazado de iteración.

Voces críticas y aportaciones alternativas

No toda la comunidad parte del supuesto de compatibilidad entre IA y agilismo. Steve Jones, de Capgemini, publicó en febrero de 2026 en InfoQ un argumento directo: los entornos de desarrollo agentizados son demasiado rápidos para el agilismo tal como se practica hoy, y el Manifiesto Ágil necesita ser reemplazado, no adaptado. Desde la comunidad de desarrollo hay voces que señalan que la IA acumula deuda técnica a velocidades sin precedente, lo que hace que la especificación y la documentación recuperen relevancia crítica, invirtiendo paradójicamente una de las apuestas históricas del agilismo.

Plataformas como GitHub con su Spec Kit y consultoras como Thoughtworks están explorando paradigmas como el Spec-Driven Development y modelos de cadencia dual que no parten de adaptar Scrum sino de repensar desde cero cómo se organiza el trabajo cuando una parte sustancial de la ejecución la realiza un agente. Estas prácticas se desarrollan en la sección 4.

Este documento adopta una posición de «evolución»: los principios ágiles mantienen su vigencia, pero las prácticas concretas necesitan una transformación profunda. Y lo hace desde la convicción de que Scrum, como conocimiento abierto y emergente, tiene la capacidad de evolucionar. No necesita permiso de nadie para adaptarse: es lo que ha hecho siempre.

2.3. La paradoja de la productividad

Uno de los fenómenos más documentados del momento es lo que McKinsey ha denominado la «paradoja de la IA generativa»: adopción generalizada, impacto en resultados escaso.

McKinsey, en su State of AI 2025 (encuesta a 1.993 ejecutivos en 105 países), encontró que el 88% de las organizaciones ya usa IA en al menos una función de negocio, pero solo el 39% reporta algún impacto en EBIT, y en la mayoría de esos casos ese impacto es inferior al 5%. BCG llega a conclusiones similares desde una metodología distinta: el 60% de las organizaciones no genera valor material pese a sus inversiones en IA, y solo el 5% crea valor sustancial a escala. El factor que McKinsey identifica como más determinante para estar en ese 5% no es la herramienta adoptada sino haber rediseñado los flujos de trabajo en profundidad, no solo haber añadido IA encima de los procesos existentes.

La imagen es igualmente ambivalente entre los propios desarrolladores. La encuesta anual de Stack Overflow 2025, con más de 49.000 desarrolladores en 177 países, registra que el 84% usa o planea usar herramientas de IA, pero también que el 46% declara no confiar en la precisión de sus outputs, frente al 31% del año anterior. La valoración favorable hacia las herramientas de IA ha bajado del 70% al 60% en un solo año. La adopción crece; la confianza, no necesariamente.

La explicación más extendida para esta brecha no apunta a la tecnología en sí, sino a lo que rodea su uso: los equipos producen funcionalidades a mayor velocidad, pero sin la guía de producto, la validación con usuarios ni la visión estratégica necesarias para que esa velocidad genere valor real. La gestión de producto ha desplazado a la ingeniería como el factor limitante en la entrega de valor. Es un desplazamiento que plantea preguntas incómodas sobre cómo están organizados los equipos, qué roles tienen sentido y qué prácticas siguen siendo útiles.

3. Los principios ágiles como brújula invariable

Hay algo que el debate sobre IA y Scrum tiende a pasar por alto: los principios ágiles no nacieron pensando en ninguna tecnología concreta. Nacieron como respuesta a un problema organizativo que la IA no resuelve sino que intensifica. Los principios no "sobreviven" a la IA, como si fueran una especie en peligro de extinción: son más necesarios que nunca.

3.1. Los valores del Manifiesto

Empirismo sobre predicción

Scrum se fundamenta en tres pilares: transparencia, inspección y adaptación. La IA no debilita estos pilares; en todo caso los pone a prueba. Con dashboards más inteligentes y ciclos de retroalimentación más rápidos, los equipos tienen hoy más capacidad técnica de inspeccionar y adaptar que nunca. El riesgo es el opuesto: que la velocidad de generación de la IA supere la capacidad del equipo para reflexionar sobre lo que está construyendo, convirtiendo el empirismo en una declaración de intenciones vacía. Inspeccionar y adaptar requiere tiempo para pensar. La IA no lo genera automáticamente; hay que protegerlo.

Individuos e interacciones sobre procesos y herramientas

Este es el principio que más directamente interpela a la IA, porque la IA es exactamente lo que el Manifiesto situaba en la columna de menor valor: una herramienta. Por sofisticada que sea, por mucho que genere código, escriba tests o proponga soluciones, la IA no reemplaza la conversación humana como mecanismo para construir entendimiento compartido, gestionar conflictos o tomar decisiones en condiciones de incertidumbre. Lo que sí puede hacer es liberar tiempo y atención cognitiva para que esas conversaciones sean mejores. Eso solo ocurre si el equipo decide activamente a qué dedica el tiempo que la IA le devuelve.

Software funcionando sobre documentación extensiva

Con la IA es posible generar prototipos funcionales en horas. Eso refuerza el principio de validar con software que funciona en lugar de con documentos. Pero introduce una tensión real: como se verá en la sección 4, el Spec-Driven Development requiere especificaciones detalladas para guiar a los agentes de IA. La distinción que este documento propone es que esas especificaciones no son documentación en el sentido que el Manifiesto rechazaba —burocracia que sustituye al pensamiento— sino el lenguaje de instrucción que hace posible la colaboración entre humanos e IA. La forma cambia; el principio de priorizar la validación real sobre el papel, no.

Responder al cambio sobre seguir un plan

La IA hace operativamente viable lo que antes era costoso. Monitorizar patrones de comportamiento, analizar conversaciones de soporte o detectar señales de cambio en tiempo real ya no requiere ciclos de investigación de semanas. Lo que era un ideal se convierte en una posibilidad técnica real. El reto es organizativo: tener los mecanismos de decisión suficientemente ágiles para actuar sobre esa información cuando llega, no cuando el próximo trimestre lo permita.

3.2. La IA como tecnología, no como equipo

Hay una confusión que conviene despejar antes de entrar en el mapa de tensiones concretas. Algunas aportaciones recientes proponen tratar a la IA como un miembro más del equipo. La analogía tiene valor pedagógico para pensar en onboarding, contexto y gobernanza. Pero oscurece algo fundamental: la IA es tecnología.

Esto importa porque el primer valor del Manifiesto Ágil es precisamente ese: individuos e interacciones sobre procesos y herramientas. La IA, por muy generativa que sea, cae en la columna de herramientas. Eso no la hace menos valiosa; la sitúa correctamente. Un equipo que trata a la IA como tecnología poderosa que amplifica su capacidad toma mejores decisiones sobre cuándo usarla, cuándo no, y quién rinde cuentas de sus outputs. Un equipo que la trata como un compañero de equipo puede acabar delegando en ella decisiones que requieren juicio humano.

3.3. El riesgo de confundir velocidad con agilidad

La IA permite ir más rápido. Eso es un hecho. El error frecuente es asumir que ir más rápido equivale a ser más ágil. No es así. La agilidad no es velocidad: es la capacidad de responder eficazmente al cambio mientras se entrega valor. Son cosas distintas, y la diferencia se vuelve crítica cuando la IA acelera la producción más rápido de lo que la organización puede validar si lo que produce merece ser producido.

Cuando eso ocurre, la pregunta central deja de ser "¿puede la IA construirlo?" y pasa a ser "¿deberíamos construirlo, y por qué?". Esa segunda pregunta no tiene respuesta técnica. La responden personas con criterio de producto, con conocimiento del usuario y con capacidad de decir que no. La IA no sustituye ese juicio; lo hace más urgente.

4. Tensiones y decisiones: los ejes de evolución

Esta sección presenta los cinco grandes ejes donde los equipos están tomando decisiones reales ahora mismo, sin prescribir una respuesta única. Para cada eje se ofrecen opciones, evidencias y riesgos. Las respuestas correctas dependen del contexto de cada equipo.

4.1. Cadencia y ritmo de trabajo

El sprint de dos semanas se ha convertido en el estándar de facto, aunque no siempre fue así: las primeras iteraciones de Scrum en los años 90 utilizaban ciclos de uno o dos meses, y fue la propia comunidad la que fue acortando la cadencia a medida que el contexto lo requería. Con la IA esta cadencia entra de nuevo en tensión: los equipos pueden generar incrementos de producto, MVPs o funcionalidades en cuestión de horas o días. Lo que tardaba un sprint puede tardar una mañana.

Opciones que los equipos están explorando

• Sprints con micro-iteraciones internas: conservar el sprint como contenedor de planificación y revisión, pero dentro de él ejecutar múltiples ciclos cortos de ideación-generación-validación asistidos por IA. Preserva los puntos de sincronización sin frenar la velocidad.
• Sprints más cortos: reducir a una semana o menos, acercando la cadencia a la velocidad real de entrega. Algunos equipos experimentan con sprints de tres días para trabajo asistido por IA.
• Flujo continuo: abandonar el sprint como contenedor temporal y adoptar un flujo continuo con límites de trabajo en curso (WIP). Requiere mecanismos alternativos para los momentos de inspección y adaptación que el sprint proporcionaba.
• Cadencia dual: un ritmo rápido para prototipado y experimentación (días) y un ritmo más pausado para ingeniería de producción y validación estratégica (semanas). Se desarrolla en detalle en la sección 5.

Riesgos a considerar

Eliminar los sprints por completo conlleva un riesgo real: perder los momentos de reflexión estructurada. La retrospectiva es precisamente el mecanismo que permite al equipo inspeccionar y adaptar su forma de trabajar con IA. Paradójicamente, es ahora cuando más se necesita reflexionar sobre el proceso, justo cuando la velocidad invita a omitir estos momentos.

Pregunta para tu equipo: ¿Nuestro sprint actual es un contenedor útil que nos da ritmo y momentos de reflexión, o es un cuello de botella que frena nuestra capacidad de entrega real?

4.2. Tamaño y composición del equipo

Las prácticas estándar de Scrum se han optimizado para equipos de en torno a siete personas. La productividad que permite la IA hace que los equipos modernos puedan ser significativamente más pequeños. Un único perfil de negocio puede hoy generar prototipos funcionales sin intervención directa de diseño o ingeniería.

Esto no significa que los equipos pequeños sean siempre mejores. Significa que el tamaño del equipo debe responder al trabajo real, no a una convención heredada. Y plantea preguntas que las prácticas habituales de Scrum no abordaban:

• ¿Quién rinde cuentas cuando un agente de IA comete un error?
• ¿Cómo se gestiona el contexto de la IA para que sus outputs sean relevantes para el equipo?
• ¿Cómo se mide la contribución de la IA frente a la humana?
• ¿Qué eventos siguen teniendo sentido y en qué formato?

Scrum.org propone tratar la IA como un compañero de equipo al que se hace onboarding con contexto y se le establece gobernanza. Como se argumenta en la sección 3, esta analogía tiene un límite fundamental: la IA es tecnología, no equipo. Eso no invalida las preguntas prácticas que el framework plantea, pero sí invita a responderlas desde una premisa distinta: no estamos incorporando a un nuevo compañero, estamos gestionando una herramienta que requiere los mismos criterios de rigor que cualquier otra decisión de arquitectura o infraestructura.

Eventos en equipos reducidos

En equipos de dos o tres personas, las ceremonias extensas pierden parte de su propósito original de coordinación compleja. Eso no significa eliminarlas:

• La daily puede transformarse en un breve check-in asíncrono o una sincronización semanal.
• La planning puede simplificarse a una sesión de priorización y definición de especificaciones para la IA.
• La retrospectiva sigue siendo esencial —quizás más que nunca— como espacio para evaluar cómo funciona la colaboración con la IA y qué ajustar.

Pregunta para tu equipo: si redujéramos nuestro equipo a la mitad con asistencia de IA, ¿qué eventos seguirían aportando valor y cuáles se convertirían en burocracia sin sentido?

4.3. De historias de usuario a especificaciones: el lenguaje del trabajo

Las historias de usuario nacieron como herramienta de comunicación entre humanos: "Como [usuario], quiero [acción] para [beneficio]". Este formato es eficaz para transmitir intención entre personas, pero no es la forma más precisa de instruir a una IA generativa. Surge una tensión fundamental: el lenguaje que facilita la conversación humana no es el mismo que guía eficazmente a un agente.

El Spec-Driven Development (SDD)

Es uno de los paradigmas más significativos que han emergido en 2025. Utiliza especificaciones de requisitos bien elaboradas como instrucciones para que los agentes de codificación generen código ejecutable. La especificación se convierte en la fuente de verdad tanto para el humano como para la IA. A diferencia de las especificaciones tradicionales, las specs del SDD son artefactos ejecutables: se ejecutan durante la validación, y la implementación no puede desviarse sin provocar fallos en la build.

Herramientas como GitHub Spec Kit han formalizado este flujo en cuatro fases: Specify (descripción de alto nivel de qué se quiere construir y por qué), Plan (el agente propone un plan de implementación), Tasks (descomposición en tareas pequeñas y revisables), e Implement (el agente ejecuta y el desarrollador revisa cambios focalizados, no bloques masivos de código).

Los equipos adoptan el SDD en diferentes niveles de madurez:

• Spec-first: nivel de entrada. Se escriben especificaciones antes de codificar para guiar la implementación asistida por IA.
• Spec-driven con validación automatizada: las specs incluyen escenarios BDD, tests de contrato API o simulaciones que se ejecutan automáticamente.
• Spec-as-source-of-truth: la especificación reemplaza al código como artefacto principal. Mantener el software significa evolucionar las especificaciones.

El riesgo de regresión a Waterfall

Si las especificaciones se vuelven demasiado rígidas, se corre el peligro de regresar al modelo en cascada. Especificaciones excesivamente formalizadas pueden ralentizar los ciclos de cambio y retroalimentación, exactamente como ocurrió en las etapas tempranas del desarrollo en cascada. La solución no es elegir entre historias de usuario y specs, sino encontrar la convivencia adecuada:

• Specs como documentos vivos: las especificaciones deben iterar con el mismo espíritu que un backlog ágil: se refinan, se adaptan y evolucionan con cada ciclo de aprendizaje.
• No todo necesita el mismo nivel de especificación: un prototipo de validación puede partir de una historia de usuario; una funcionalidad crítica para producción requiere una spec detallada.
• La spec complementa, no sustituye, la conversación: el formato Conversation-Card-Confirmation sigue siendo válido; la spec traduce esa conversación a un lenguaje procesable por la IA.

Pregunta para tu equipo: ¿En qué proporción de nuestro trabajo actual las historias de usuario son suficientes para guiar a la IA, y en qué proporción necesitamos especificaciones más detalladas?

4.4. Roles en transformación

Los roles habituales en equipos Scrum no desaparecen, pero experimentan una transformación profunda en su foco, sus competencias y su relevancia relativa.

El Product Owner como cuello de botella estratégico

Con la IA capaz de construir features más rápido de lo que la organización puede validar su deseabilidad, el Product Owner se convierte en el factor limitante real. Su rol evoluciona hacia algo llamado Product Architect: no solo prioriza un backlog, sino que gestiona activamente qué merece ser construido, diseña experimentos de validación continua y decide dónde la IA aporta valor real frente a dónde genera ruido.

Las ofertas de empleo para estos roles se multiplicaron 75 veces en dos años entre 2022 y 2024, según datos de mercado laboral que Forrester también ha identificado como una de las tendencias de mayor crecimiento en gestión de producto. El mercado ha reconocido esta transformación antes de que la mayoría de los equipos la haya procesado.

El Scrum Master: transformación o extinción

Este es el rol con mayor riesgo de redefinición. Si su valor se define como facilitador de eventos, la IA lo hace prescindible: puede sugerir técnicas de facilitación, generar agendas, tomar notas y analizar métricas de flujo. Sin embargo, las competencias que la IA no puede replicar —inteligencia emocional, pensamiento sistémico, liderazgo de equipo, toma de decisiones éticas en contextos complejos— son precisamente las que definen el valor de un facilitador ágil evolucionado. Las proyecciones para 2030 sitúan a este rol como un líder centrado en estrategia, transformación cultural y coaching organizacional, alejado de la operativa diaria del equipo.

Los Developers como Product Builders

El equipo de desarrollo se transforma en Product Builders: perfiles que combinan el uso de herramientas no-code, la generación de código asistida por IA y una comprensión profunda del producto. Su valor se desplaza desde la implementación hacia la orquestación: diseñar arquitecturas, escribir especificaciones, revisar y validar lo que la IA genera, y asegurar que el código cumple estándares de calidad y seguridad.

Pregunta para tu equipo: para cada miembro del equipo, ¿qué proporción de su trabajo actual podría ser asistido o reemplazado por IA? ¿Hacia dónde debería desplazarse su aportación de valor?

4.5. Calidad y confianza: el nuevo QA

La calidad del software es posiblemente el área donde la IA genera más tensión entre sus promesas y su realidad.

La degradación silenciosa del código

Análisis de grandes bases de código muestran patrones preocupantes a medida que la asistencia de IA se generaliza:

• La duplicación de código en proyectos asistidos por IA aumentó significativamente (del ~8% al ~12% de las líneas cambiadas).
• La actividad de refactoring cayó drásticamente: los equipos producen código nuevo en lugar de mejorar el existente.
• En 2024, por primera vez, el código copiado o generado por IA superó al código refactorizado.
• Desarrolladores senior experimentaron una disminución del 19% en su rendimiento en tareas complejas al usar IA, debido al tiempo dedicado a revisar y probar el output generado.

Estos datos sugieren que, sin controles deliberados, la IA acelera la acumulación de deuda técnica. El equipo va más rápido, pero el código se vuelve frágil, duplicado y costoso de mantener.

La paradoja de la confianza

La confianza de los desarrolladores en la precisión del código generado por IA cayó del 69% en 2024 al 54% en 2025, a medida que el uso se generalizó y los equipos experimentaron más los límites de la tecnología. La frustración más común es obtener soluciones que son "casi correctas pero no del todo": el output parece plausible pero contiene errores sutiles que generan trabajo adicional.

Modelos emergentes de QA

• IA supervisando IA: utilizar una IA como revisor automático de lo que otra IA genera, estableciendo «semáforos» y revisiones automatizadas.
• Specification by Example (SbE): crear harnesses de test manuales con especificaciones concretas y verificables. No se puede confiar en que la IA «corrija sus propios deberes»; la SbE proporciona expectativas concretas y testeables.
• Definition of Done reforzada: adaptar la DoD específicamente para código generado por IA, incluyendo revisiones de seguridad, análisis estático y verificación de no-duplicación.
• Auditoría continua de deuda técnica: monitorizar activamente métricas de salud del código (duplicación, complejidad ciclomática, cobertura de tests) como contrapeso a la velocidad de generación.

Pregunta para tu equipo: ¿Hemos adaptado nuestra Definition of Done para contemplar específicamente el código generado por IA? ¿Tenemos métricas de calidad que contrarresten la tentación de priorizar velocidad sobre robustez?

5. Modelos de trabajo emergentes

Las tensiones descritas en la sección 4 no se resuelven de forma aislada. Los equipos que están navegando este momento con más criterio no están aplicando una opción por eje, sino combinando opciones en configuraciones completas que responden a su contexto. Esta sección describe los dos modelos más relevantes que han emergido. Ninguno ha alcanzado la madurez de las prácticas consolidadas de Scrum; los dos son prácticas en evolución. Se presentan para que cada equipo evalúe cuáles son relevantes para su situación, del mismo modo en que las retrospectivas o los tableros kanban fueron en su momento innovaciones comunitarias que enriquecieron el marco.

5.1. Doble Carril (Double-Track)

El concepto de dual-track agile —discovery + delivery— existe desde hace años. La IA lo hace más explícito y más necesario, porque la diferencia de velocidad entre explorar y construir para producción se ha vuelto tan grande que gestionarlos con el mismo ritmo genera fricción constante.

Vibe coding: el carril rápido

Un flujo orientado a crear prototipos no liberables a producción. Su propósito es validar ideas con usuarios rápidamente, usando herramientas de IA y no-code para generar artefactos funcionales en horas. En este carril, la calidad del código es secundaria; lo que importa es la velocidad de aprendizaje. Es el espacio natural del vibe coding: interacción libre con la IA para explorar posibilidades sin el rigor de producción.

Vibe engineering: el carril robusto

Un flujo que asegura mínimos de ingeniería, seguridad y calidad para que el producto sea robusto y mantenible. Aquí se aplican las prácticas de Spec-Driven Development descritas en la sección 4.3, se refuerza la Definition of Done y se ejecutan los mecanismos de QA de la sección 4.5. Es el espacio donde el código generado por IA se somete al rigor de producción.

La velocidad del Vibe coding puede ser 10x-100x mayor que la del Vibe engineering, lo que exige una gestión consciente de cuándo y cómo transicionar una idea del carril rápido al carril de producción. La decisión de cuándo hacer esa transición es una decisión de producto, no técnica.

5.2. Modelos híbridos: combinar según contexto

En la práctica, la mayoría de los equipos no adoptarán un único modelo de forma pura. Combinarán cadencia dual con SDD en el carril robusto, o flujo continuo con retrospectivas semanales, o sprints cortos con Byte Coding para el discovery. La configuración concreta depende del tipo de producto, el tamaño del equipo, la madurez técnica y el grado de incertidumbre del negocio.

La clave no es elegir el modelo correcto de antemano, sino experimentar con disciplina: probar un enfoque, medir resultados, inspeccionar y adaptar. Eso es exactamente lo que la comunidad ágil lleva haciendo desde los años 80: evolucionar sus prácticas en respuesta al contexto, enriqueciendo un conocimiento que es de todos. La integración de la IA es el siguiente capítulo de esa evolución, no su final.

6. Hoja de ruta para la reflexión del equipo

En lugar de un plan de implementación prescriptivo, esta sección ofrece un canvas de autoevaluación. No dice qué debe hacer cada equipo; ofrece las preguntas que permiten que cada equipo llegue a sus propias respuestas.

Se recomienda usarlo en una sesión facilitada —una retrospectiva específica, un workshop de equipo— donde todos los miembros puedan contribuir. El proceso sugerido es:

1. Evaluar: cada miembro responde individualmente a las preguntas de ¿Dónde estamos?
2. Compartir: se ponen en común las respuestas y se identifican patrones y divergencias.
3. Priorizar: se seleccionan una o dos dimensiones donde la fricción es más evidente.
4. Experimentar: se diseña un experimento concreto para el próximo ciclo.
5. Inspeccionar y adaptar: se revisan los resultados y se decide si continuar, ampliar o pivotar.

El canvas no es un diagnóstico definitivo ni una hoja de ruta universal. Es un punto de partida para la conversación que cada equipo necesita tener consigo mismo. Las respuestas correctas son las que surgen de ese proceso, no las que viene este documento a prescribir.

7. Conclusión: evolucionar sin perder el rumbo

La IA generativa no ha matado a Scrum. Ha hecho algo más sutil y profundo: ha puesto a prueba si los equipos realmente practican la agilidad o simplemente ejecutan un conjunto de rituales. Ha separado a quienes aportan juicio estratégico de quienes realizan tareas que la tecnología puede automatizar. Ha acelerado la capacidad de construir hasta el punto de que decidir qué construir se ha convertido en el desafío principal.

De ese diagnóstico se derivan algunas ideas que este documento ha intentado sostener con evidencia. Los principios ágiles —empirismo, entrega de valor, adaptación continua, colaboración humana— no sólo sobreviven a la era de la IA: se vuelven más necesarios precisamente porque la velocidad de construcción ha dejado de ser la restricción. La brújula no cambia; el terreno sí.

Las prácticas concretas, en cambio, necesitan revisión. Cadencias, composición de equipos, artefactos, roles y modelos de calidad requieren ser repensados, no ajustados cosméticamente. Y esa revisión no tiene una respuesta única: el Dual-Track, el Spec-Driven Development o los modelos híbridos son opciones, no prescripciones. La experimentación disciplinada —probar, medir, inspeccionar, adaptar— sigue siendo el camino.

Hay algo que este documento no puede resolver por ningún equipo: saber dónde está hoy y qué fricción está sintiendo. Eso requiere la conversación que solo puede tener el propio equipo. Lo que sí puede hacer es invitar a esa conversación, y dejarla abierta.

Este es un documento de trabajo. Es una aportación a un debate que la comunidad ágil lleva décadas construyendo y que, con la llegada de la IA, ha vuelto a hacerse urgente. Las críticas, las correcciones y las experiencias que surjan de leerlo son exactamente lo que necesita para mejorar.

Bibliografía

• BCG (2025). AI at Scale: Closing the Value Gap. Boston Consulting Group.
• DeGrace, P. & Hulet Stahl, L. (1990). Wicked Problems, Righteous Solutions: A Catalogue of Modern Engineering Paradigms. Prentice Hall.
• Dell'Acqua, F. et al. (2025). "The Cybernetic Teammate: A Field Experiment on Generative AI Reshaping Teamwork and Expertise". Harvard Business School Working Paper No. 25-043.
• Fernandes, D. [Darrell] (2025). The AI Teammate Framework: A Four-Step Framework for Product Teams. Scrum.org.
• GitHub Blog (2025). "Spec-driven development with AI: Get started with a new open source toolkit". Github.blog.
• Jocham, R., Coleman, J. & Sutherland, J. (2025). Scrum Guide Expansion Pack.
• Jocham, R. & Sutherland, J. (2026). AI and Scrum: An Evidence-Informed Integration Guide.
• Liu Shangqi / Thoughtworks (2025). "Spec-Driven Development: Unpacking 2025's Key New AI-Assisted Engineering Practices". Thoughtworks.com.
• McKinsey & Company (2025). The State of AI: How Organizations Are Rewiring to Capture Value. McKinsey QuantumBlack.
• Schwaber, K. (1997). "SCRUM Development Process". Presentado en OOPSLA'95, Austin, Texas. Publicado en: Sutherland, J. et al. (eds.), Business Object Design and Implementation. Springer, London.
• Schwaber, K. & Sutherland, J. (2020). The Scrum Guide.
• Stack Overflow (2025). Developer Survey.
• Takeuchi, H. & Nonaka, I. (1986). "The New New Product Development Game". Harvard Business Review, vol. 64, pp. 137-146.
• Wolpers, S. (2025). "The Agile AI Manifesto". Scrum.org Blog.
• Xebia Academy (2025). "Scrum Teams In 2030: The Future Of Agile With AI". Academy.xebia.com.

Puedes descargarlo en PDF (también puedes acceder a él en los recursos de nuestra web).