Dual-track agile: discovery y delivery en paralelo
Dual-track agile corre dos carriles a la vez: discovery para decidir qué construir y delivery para construirlo. Cómo funciona y dónde suele fallar.
¿Qué es y de dónde viene?
Marty Cagan, en SVPG, dice que es un modelo que a veces se llama Dual-Track Agile, y lista otros nombres como Dual Track Scrum y Continuous Discovery/Continuous Delivery. Según su artículo de 2012, la discovery consiste en generar rápido elementos de backlog validados, y la delivery en generar software liberable (SVPG: Dual-Track Agile).
El origen del término es un poco confuso. Cagan cuenta que Jeff Patton le dio el nombre «Dual-Track Scrum», que él prefería. Antes había llamado al enfoque «Discovery Sprints», pero abandonó ese nombre porque sugería una discovery acotada en el tiempo y fases en serie. Más tarde, Cagan dejó de usar «Dual-Track Agile» y pasó a hablar de Continuous Discovery y Continuous Delivery porque, según él, la gente se concentraba demasiado en el proceso y no en los principios. Patton, por su parte, dibuja los dos carriles pero dice que no le gusta el término, porque sugiere equipos separados y no tipos de trabajo distintos (Zurb Radar).
¿Qué hace cada carril?
| Carril | Objetivo | Actividades típicas |
|---|---|---|
| Discovery | Decidir qué vale la pena construir | Entrevistas, prototipos, pruebas de concepto, análisis de datos |
| Delivery | Construir y liberar con calidad | Desarrollo, pruebas, despliegue, medición |
ProductPlan lista en discovery las entrevistas, los personajes y las historias de usuario, y mueve a delivery solo los elementos validados. En delivery ubica los prototipos, las pruebas iterativas y la aplicación de los comentarios de los usuarios (ProductPlan: Dual-track agile). La idea clave es que el backlog no se llena de hipótesis sin probar.
¿Por qué le importa a un diseñador?
Porque el diseño vive en discovery. Las pruebas de prototipo, las entrevistas y la síntesis de hallazgos son trabajo de diseño, y en dual-track ese trabajo corre una o dos iteraciones por delante del desarrollo. Cagan describe el modelo con el diseñador, el product manager y el ingeniero líder trabajando «lado a lado», en contraste con los mini-waterfalls, donde los artefactos pasan de un rol a otro.
Patton insiste en la misma idea: los dos carriles son dos tipos de pensamiento, no dos listas de personas, y todo el equipo entiende y contribuye a ambos tipos de trabajo. Y añade que discovery no termina al lanzar. Según el artículo, Jeff Gothelf trata el software en producción como tu último y mejor experimento (Zurb Radar).
¿Cómo fluye el trabajo?
En un flujo sano, discovery va «un paso adelante, no una fase antes». Zurb Radar describe equipos que mantienen discovery entre una y dos iteraciones por delante, y muestra que una idea puede ir y venir entre los carriles varias veces antes de salir (Zurb Radar).
Una forma práctica de empezar:
- Mantén un tablero con dos columnas de entrada: ideas por validar e ideas validadas.
- Cada semana, el equipo decide qué idea validar y con qué prueba.
- Solo entra al backlog de delivery lo que tiene evidencia suficiente para el alcance propuesto.
- Mide el aprendizaje, no solo la velocidad: cuántas hipótesis se probaron y cuántas se descartaron.
¿Cuándo NO conviene dual-track?
- Si el equipo es tan pequeño que una sola persona hace discovery y delivery en la misma semana, separar carriles en un tablero puede ser más burocracia que ayuda.
- Si la organización no permite que el equipo cambie prioridades cuando aprende algo, discovery producirá hallazgos que nadie usará.
- Si el producto es un cambio regulatorio con alcance fijo, el carril de discovery queda casi vacío. La parte de descubrimiento se reduce a entender el requisito, no a elegir entre opciones.
Recuerda que Cagan dejó de usar el término por el mismo motivo: el modelo es un principio, no un ritual. Si tu equipo cumple el ritual y no el principio, el problema sigue ahí.
Ejemplo
Ejemplo ilustrativo: un equipo de una app de finanzas personales tiene que decidir si agregar alertas de gasto. En discovery, la diseñadora hace cinco entrevistas y un prototipo de papel. Descubre que los usuarios no quieren alertas por cada compra, sino un resumen semanal. La idea de alertas se descarta antes de que alguien programe. En delivery, mientras tanto, el equipo termina la mejora de categorías que ya estaba validada. Dos semanas después, el resumen semanal pasa a discovery con una prueba de concepto. El backlog de delivery nunca se queda vacío, porque discovery va por delante.
Si quieres aprender a trabajar con el product manager en este flujo, mira trabajar con product managers. Para ordenar las pruebas de discovery, sirve un plan de investigación, y para convertir lo aprendido en decisiones, la síntesis de investigación.
Errores comunes
- Dividir el equipo en un grupo de discovery y otro de delivery, lo que recrea el traspaso.
- Tratar discovery como una fase previa que termina en una especificación cerrada.
- Dejar el trabajo de discovery fuera del tablero, de modo que nadie lo ve ni lo mide.
- Medir solo la velocidad de delivery y no el aprendizaje.
- Apurar discovery para alimentar a los que construyen, y que el backlog se llene de ideas sin validar.
Qué puedes hacer mañana
- Revisa tu tablero y marca qué tarjetas son hipótesis y cuáles tienen evidencia.
- Propón una prueba de discovery para la siguiente iteración y define antes qué resultado la descartaría.
- Pide al product manager que señale qué elemento del backlog no tiene todavía evidencia.