Dual-track discovery & delivery,para no construir a ciegas

¿Qué es el Dual-track? ¿Dos carriles para un único destino?

Dual-track se basa en la premisa de que el desarrollo de software implica dos tipos de trabajo fundamentalmente distintos, pero que deben ocurrir simultáneamente y en paralelo:

1. Discovery (Descubrimiento): Es el carril de la incertidumbre. Aquí el objetivo es aprender rápido y barato. Preguntarnos: ¿Estamos construyendo el producto correcto? ¿El usuario lo quiere? ¿Es viable? Las herramientas aquí son entrevistas, prototipos de baja fidelidad y experimentos.
2. Delivery (Entrega): Es el carril de la calidad y la escala. Aquí el objetivo es construir un producto solvente. Nos preguntamos: ¿Estamos construyendo el producto correctamente? ¿Es seguro, escalable y mantenible?

La clave del dual-track es entender que discovery y delivery son actividades continuas, no fases secuenciales donde una termina para que empiece la otra.

"La forma más cara de validar una idea es desarrollarla. Dual-track trata de reservar intención y foco para descubrir qué merece la pena construir mientras el equipo sigue entregando valor."

Un solo equipo, dos velocidades

Esta es la teoría, y la clave fundamental es no emplear dos equipos separados —uno que "piensa" y otro que "desarrolla"—, sino una única unidad que entiende que su trabajo tiene dos velocidades simultáneas.

Mientras una parte de su atención está en el entregable que saldrá a producción este viernes (delivery), otra parte, igual de importante, está entrevistando a usuarios o analizando datos para lo que vendrá el mes que viene (discovery).

La trampa del "Mini-Waterfall"

El error más común al intentar adoptar esta mentalidad es caer en la trampa de los "mini-waterfalls" o mini-cascadas. Es muy tentador asignar a un par de personas (usualmente UX y product owner) para que trabajen dos sprints por delante y entreguen especificaciones "masticadas" a los desarrolladores.

Esto solo disfraza la cascada de agilidad. La magia ocurre cuando el conocimiento fluye en ambas direcciones. Cuando un desarrollador se une a una entrevista de discovery, no sólo aporta viabilidad técnica, sino que adquiere empatía y contexto que no se puede transmitir a través de documentaciones de requisitos. Dejan de ser ejecutores de tickets para convertirse en solucionadores de problemas.

Transformando las ceremonias de siempre

Para aterrizar dual-track, no hay que inventar nuevas reuniones, sino transformar el propósito de las que ya tenemos:

• El Refinement (Refinamiento): Deja de ser una sesión administrativa para estimar puntos y se convierte en el foro de discovery. Es el momento de preguntar: "¿Qué hemos aprendido de este experimento? ¿Vale la pena pasarlo al carril de delivery?".
• La Sprint Review: Evoluciona de ser una simple demo a un espacio de resultados. En lugar de solo mostrar el entregable funcionando, se discute el impacto: "Lanzamos esto, esperábamos que X usuarios lo usaran, y la realidad ha sido Y".

Conclusión: Un acto de honestidad profesional

Adoptar dual-track requiere disciplina. Los equipos experimentados suelen reservar un porcentaje de su capacidad —entre un 10% o 20%— para las actividades de exploración, visualizándolas en el tablero de equipo.

Al final, este enfoque es un acto de honestidad. Es admitir que desarrollar es caro y arriesgado, y que no tenemos todas las respuestas al inicio. dual-track nos permite descartar malas ideas rápido y barato, asegurando que cada línea de código tenga una razón de ser validada.

Referencias y Lecturas Recomendadas

Para profundizar en el origen y la aplicación rigurosa de este enfoque:

• El origen del concepto:

  Sy, Desirée (2007). "Adapting Usability Investigations for Agile User-Centered Design". Journal of Usability Studies. Leer paper original El paper fundacional donde Desirée Sy (Autodesk) documentó formalmente el sistema de pistas paralelas.

• La visión de producto moderna:

  Cagan, Marty (2018). INSPIRED: How to Create Tech Products Customers Love. Wiley. Ver libro Cagan popularizó la necesidad de "Continuous Discovery" y la separación conceptual entre descubrir valor y entregar software.

• La integración en el día a día:

  Patton, Jeff (2014). User Story Mapping. O'Reilly Media. Ver recursos del autor Patton ayudó a refinar el término enfatizando que se trata de aprendizaje y construcción simultáneos por parte de todo el equipo.