Compraste licencias de IA para tu equipo y la velocidad sigue siendo prácticamente la misma. Es la queja número uno que escuchamos de CTOs y VP de Ingeniería en 2026, y casi siempre tiene la misma raíz: el problema no es la herramienta, es el método. La IA que le diste a tu equipo acelera un tramo del proceso —teclear código— pero deja intactos los dos tramos donde de verdad se pierde el tiempo: decidir qué merece la pena construir y verificar que lo construido es correcto. Este artículo explica cómo montar un Scrum dual-track acelerado con IA que ataca los tres tramos a la vez, con el método operativo que onext usa en producción.
Por qué el Scrum "normal" con IA acelera el tramo equivocado
El Scrum clásico mete descubrimiento y entrega en el mismo carril: un backlog, un sprint, y la esperanza de que las historias lleguen "suficientemente definidas" al empezar. Funcionaba —con fricción— cuando escribir el código era el trabajo caro. La IA rompe ese equilibrio: cuando teclear una función pasa de horas a minutos, el trabajo caro se desplaza aguas arriba (¿qué construyo y con qué reglas?) y aguas abajo (¿esto es correcto, seguro y mantenible?).
El resultado, en equipos que "adoptaron IA" sin cambiar el método, es predecible:
- Se genera código más rápido de lo que se puede decidir y revisar. El generador va a 10x; el que decide el alcance y el que revisa el PR siguen a 1x. El cuello se mueve, no desaparece.
- La "velocidad percibida" sube y la entrega no. Es la paradoja que documentó METR: los equipos sienten que van más rápido mientras el lead time real hasta producción no mejora, porque el retrabajo se come la ganancia.
- La deuda se difiere, no se elimina. Código sin especificación previa ni verificación sistemática produce bugs y reprocesos que aparecen uno o dos trimestres después, cuando ya nadie los atribuye a "la semana que fuimos rápido".
La conclusión operativa: para que la IA acelere la entrega (no solo la escritura), hay que separar el carril que decide del carril que construye, y meter verificación en ambos. Eso es el dual-track.
Qué es un dual-track y por qué la IA lo hace por fin viable
El dual-track agile no es nuevo: separa discovery (qué construir y por qué) de delivery (cómo se construye), corriendo en paralelo y no en cascada. La idea siempre fue buena; el problema es que hacer bien el discovery —especificar sin ambigüedad, mapear reglas de negocio, casos límite— era tan caro que casi nadie lo mantenía, y el track se degradaba a "un backlog un poco mejor".
La IA cambia la economía: especificar, diseñar y verificar dejan de ser el trabajo caro y lento. Y ahí está la inversión clave que la mayoría no ve —usar la IA sobre todo para pensar mejor antes de codificar, no solo para codificar más rápido. Cuando el coste de una buena especificación cae, el dual-track deja de ser un lujo de proceso y se convierte en el multiplicador: cada hora invertida en el track de discovery ahorra varias en el de delivery, porque el código se genera contra una diana clara en vez de contra una intuición.
En onext lo operamos con una espina dorsal de método —Spec-Driven Development (SDD)— sobre tres niveles de estabilidad:
| Nivel | Qué fija | Cadencia de cambio |
|---|---|---|
| Módulo (estable) | qué hace cada pieza del sistema y cómo está construida de verdad | lento — se refresca al cerrar cada historia |
| Discovery / Feature (medio plazo) | qué problema resolvemos y para quién | por feature |
| Delivery / Historia (corto plazo) | qué construimos ahora y cómo | por historia, una vez |
El track de discovery: decidir bien, con IA, antes de tocar código
El track de discovery responde a qué construir y por qué, y su salida es una feature "shaped": definida sin asunciones y priorizada. El flujo:
- Idea. Entra cruda en un inbox, sin filtro. Puede venir de negocio, de soporte, de un análisis de mercado o de un spike técnico que valida viabilidad.
- Cualificación. La idea se acepta (se promueve a feature) o se descarta con motivo. Aquí ya se decide qué NO se hace, que es la mitad del valor.
- Shaping sin asunciones. La feature se especifica elicitando actores, casos de uso, reglas de negocio, invariantes y casos límite — preguntando todo lo que haga falta en vez de asumir. Este es el paso que la IA hace por fin barato: un asistente disciplinado interroga la idea hasta que no quedan huecos.
- Priorización. La feature entra en un backlog priorizado que alimenta el roadmap (el cuándo).
El gate humano es explícito: una feature no pasa a delivery sin aprobación de una persona. La IA acelera el shaping; no firma el alcance. Ese es el primer punto donde el human-on-the-loop mantiene el control.
El track de delivery: construir con verificación en cada paso (SDD)
Cuando una feature priorizada "pasa a desarrollo", se descompone en Historias de Usuario atómicas —cada una una entrega coherente que se puede demostrar funcionando— y cada historia recorre el ciclo SDD completo. Aquí es donde la IA acelera de verdad, porque cada etapa tiene un artefacto de salida y un gate antes de avanzar:
- Historia — "Como… quiero… para…" + criterios de aceptación.
- PRD (especificación) — requisitos curados, con requisitos no funcionales cuantificados y ≥3 casos límite por requisito crítico. Estado "listo" = cero preguntas abiertas.
- Diseño técnico — modelo de amenazas, rendimiento objetivo por endpoint, decisiones impactadas, rutas de error por caso límite. Si la historia usa LLM, incorpora una revisión específica de ingeniería de IA.
- Tareas — descomposición en vertical slices de ≤4 h, con al menos una tarea adversarial por requisito crítico (una tarea cuyo trabajo es intentar romper lo construido).
- Implementación + tests — con límites de calidad forzados por hooks automáticos (tamaño de archivo y función, cobertura mínima, tests obligatorios).
- Review — no una persona mirando el PR, sino varios auditores especializados en paralelo (seguridad, aislamiento de datos, coherencia doc-código…), cada uno con su checklist. Veredicto cuantificado antes de cerrar.
- Sincronización del módulo — la documentación "cómo está construido de verdad" se actualiza automáticamente, para que el siguiente que llegue no herede una mentira.
Y un gate a escala de sprint: cuando todas las historias están hechas, una auditoría del diff consolidado del sprint caza las regresiones e interacciones que la revisión historia-a-historia no ve, antes de dar el sprint por cerrado.
Dónde acelera la IA (y dónde decide el humano)
El malentendido caro es pensar que "IA acelerada" significa "IA autónoma". En el dual-track de onext la IA hace el trabajo pesado de cada etapa —redactar la especificación, proponer el diseño, generar las tareas, escribir el código y los tests, ejecutar las auditorías— y el humano conserva la decisión en los gates: qué feature entra, qué especificación está lista, qué diseño se aprueba, qué veredicto de review cierra la historia.
Esto es human-on-the-loop, no human-in-the-loop: el humano no teclea cada línea, pero firma en cada frontera de riesgo. Es exactamente lo que permite ir ×7 sin que la calidad se pague en producción — y lo que hace defendible ante un comité la frase "vamos más rápido": no es sensación, hay un artefacto y un gate detrás de cada paso.
Además, varios de esos pasos corren en paralelo real: los auditores de review se lanzan a la vez, no en fila. La aceleración no viene solo de que cada tarea sea más rápida, sino de que el proceso deja de ser una secuencia de esperas.
Cómo implementarlo en tu equipo: un camino de 8 semanas
No se instala un dual-track por decreto ni comprando otra licencia. Es un cambio de método que, en la práctica de onext, se construye con el equipo en unas 8 semanas, sin parar la entrega:
- Semanas 1-2 · Línea base y espina dorsal. Medir el lead time real hasta producción (no la sensación) y montar el nivel "módulo": escribir, para las piezas que tocaréis, qué hacen y cómo están de verdad. Sin esta base, todo lo demás flota.
- Semanas 3-4 · Track de discovery. Instaurar el flujo idea → shaping sin asunciones → priorización, con la IA haciendo el trabajo de especificación y una persona firmando el gate. Objetivo: que ninguna historia entre a delivery sin alcance cerrado.
- Semanas 5-6 · Track de delivery (SDD). Llevar 2-3 historias reales por el ciclo completo (PRD → diseño → tareas → review) con gates y auditoría. Se aprende haciendo, sobre trabajo que igualmente había que entregar.
- Semanas 7-8 · Gates de sprint y transferencia. Activar la auditoría de sprint y, sobre todo, transferir el método al equipo: el objetivo no es que dependas de nosotros, sino que el método se quede dentro. Al terminar, la capacidad es tuya.
El principio que ordena todo el calendario: 0 sprints perdidos durante la transformación. No se para para transformar; se transforma entregando.
Cómo sabrás que funciona: qué medir
Cambiar de método sin medir es cambiar de fe. El dual-track acelerado se defiende con números que un comité entiende:
- Lead time hasta producción (de idea aceptada a feature en producción gobernada). Es la métrica; baja ~50% sobre una base de mercado de ~16 semanas.
- Velocidad de entrega (throughput de historias con valor verificado, no líneas de código). El headline firmado en 2026 es ×7.
- Sprints perdidos durante la transición. Objetivo: 0.
- Retrabajo / bugs en producción por historia. Debe bajar, no subir — es la prueba de que la velocidad no se paga en deuda.
- Coste por tarea útil verificada, no por licencia instalada. La unidad que de verdad mide el retorno.
Preguntas frecuentes
¿Qué es un Scrum dual-track acelerado con IA?
Es un método ágil que separa dos carriles que corren en paralelo: discovery (decidir qué construir y con qué reglas, sin asunciones) y delivery (construirlo con verificación en cada paso, vía Spec-Driven Development). La IA acelera el trabajo pesado de ambos carriles —especificar, diseñar, generar, testear, auditar— mientras una persona conserva la decisión en los gates. Ataca los tres cuellos del desarrollo (decidir, construir, verificar), no solo el de escribir código.
¿Por qué mi equipo tiene licencias de IA y no va más rápido?
Porque la IA acelera escribir código, que rara vez es el cuello de botella real. Sin un método que ordene qué se construye y cómo se verifica, generas más código más rápido y trasladas el atasco a la decisión de alcance y a la revisión — además de acumular deuda que aparece meses después. El problema no es la herramienta, es el método.
¿Cuánto se tarda en implementar un dual-track con IA?
En la práctica de onext, unas 8 semanas, construyéndolo con el equipo y sin parar la entrega (objetivo: 0 sprints perdidos). Primero se fija la línea base y la documentación de módulos; luego se instauran los dos tracks sobre historias reales; al final se transfiere el método para que la capacidad se quede en tu equipo.
¿Esto no ralentiza al equipo con "más proceso"?
Al revés, si el proceso tiene los gates correctos. El dual-track no añade burocracia: sustituye el retrabajo (la parte cara e invisible) por especificación y verificación baratas —porque la IA las hace en minutos—. El resultado medible en los equipos transformados es ×7 en velocidad de entrega con la deuda bajando, no subiendo.
Conclusión
La IA no acelera a tu equipo por estar instalada. Acelera cuando el método aprovecha que especificar y verificar ya no son caros: un carril que decide bien qué construir y otro que lo construye con verificación en cada paso, con la persona firmando en los gates que importan. Ese es el Scrum dual-track acelerado con IA — y es la diferencia entre generar más código y entregar más valor con menos deuda. En los equipos que onext ha transformado, ese cambio de método vale ×7 en velocidad, 0 sprints perdidos y −50% de time-to-production, con la capacidad quedándose dentro del equipo.