Cuando pensamos en hacer un nuevo producto nos ilusiona tener la mejor idea, ponemos mucho cariño en la conceptualización inicial, debatimos intensamente sobre cuál debería ser el MVP con el que enamorar a nuestros usuarios y corremos mucho durante los Sprints para salir a producción lo antes posible.

Hemos aprendido que en el mundo digital tenemos que trabajar de forma más rápida, romper las fases separadas de diseño, desarrollo y testing para trabajar con un equipo multidisciplinar capaz de paralelizar tareas e ir entregando de forma continua. Y, para esto, una de las cosas que necesitamos es acortar las fases iniciales donde esbozamos la visión y adelantamos todo lo necesario para comenzar a trabajar. A esto, nosotros lo llamamos Sprint 0.

Pero este post no va sobre el Sprint 0, va sobre los Sprints de después y cómo trabajamos en ellos. A cómo lo hacemos nosotros, en la industria tiene un nombre: Dual Track, y si buscas en Google hay literatura al respecto y artículos en blogs a favor y en contra. Así que aquí va otro más para posicionarnos a favor del método: en los productos en los que he estado trabajando es lo que mejor nos ha funcionado para poder mantener nuestros principios ágiles y respetar los tiempos que necesitan tanto el equipo de desarrollo como las organizaciones de nuestros clientes.

¿Qué es el Dual Track? ¿En qué consiste?

El Dual Track es establecer dos tracks de trabajo en paralelo:

No son dos equipos de trabajo separados. Es uno sólo realizando tareas de distinta índole. Y de esta forma conseguimos hacer más eficiente el trabajo del equipo y que haya una perfecta integración entre diseño y desarrollo.

El cocktail perfecto: Dual Track + Lean Analytics + Hypothesis-driven Development.

Efectivamente esto no lo hemos inventado nosotros, pero lo que sí hemos hecho es completar la misión y tareas de ambos tracks para no caer en el mayor riesgo que tiene todo proyecto: producir de forma ágil funcionalidades que el usuario no quiere y que no aportan valor a la compañía.

Por eso, al Dual Track le hemos sumado técnicas como Lean Analytics y Desarrollo basado en hipótesis para poder tener un método centrado en maximizar el éxito del producto.

Reforzamos el Discovery Track para que, además de la realización de diseños y el refinamiento de las historias de usuario, introduzca:

En el track de implementación se transforma ese software funcional en negocio y se participa, al igual que en el Discovery Track, en el análisis e interpretación de los datos analíticos.

Trabajar con un Dual Track básico (diseño y desarrollo escalonados un Sprint) puede funcionar hasta la primera release, sobre todo si es corta. Sin embargo, es crítico hacerlo a partir de tener el primer lote de funcionalidad en producción. Cuando esto pasa, muchos marcan un check y a otra cosa, otros siguen aquel plan de releases que hicimos hace meses durante la conceptualización inicial. Siento decir, que ambas opciones son un error. Es el momento en el que más importante es ver cómo está funcionando y cuestionar el plan de acción. No una vez, constantemente.

¿Por qué nos parece una buena opción?

Nosotros hemos completado aquello que no dicen los métodos ágiles para obtener el mayor rendimiento de un producto digital, poniendo los resultados de negocio al mando de los esfuerzos de desarrollo. La clave es que la medida de progreso del proyecto ya no es únicamente la entrega de software funcional, sino que ese software sea para conseguir resultados, es decir, la entrega constante de resultados de negocio.

Y vosotros, ¿habéis probado a trabajar así? ¿Qué tal os ha resultado?

Cuéntanos qué te parece.

Enviar.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.

Suscríbete

Estamos comprometidos.

Tecnología, personas e impacto positivo.