Dual-Track Scrum
Cuando me encuentro por primera vez con equipos de producto ágiles, los miembros del equipo suelen estar en una situación en la que sufren reuniones de Sprint Planning largas y frustrantes, ya que los Backlog Items están mal definidos y no se comprenden correctamente. La Velocity es lenta y el diseño deficiente, porque los detalles aún se están elaborando durante el Sprint. Además, hay mucho desperdicio y muchas correcciones que realizar, porque los Backlog Items no habían sido validados.
Recuerda que nuestro objetivo principal es validar nuestras ideas de la manera más rápida y económica posible. Implementar realmente una idea de producto y lanzarla al mercado es básicamente la forma más lenta y costosa de hacerlo.
¿Qué es Dual-Track Scrum?
Por eso soy un gran fan de algo que se conoce, entre otros nombres, como Dual-Track Scrum. Antes usaba el término "Discovery Sprints" para ello, pero eso daba la impresión de un Discovery con tiempo limitado y la serialización de fases.
Jeff Patton fue el primero que me habló del "Dual-Track Scrum". Prefiero este término porque destaca mejor el paralelismo entre Discovery y Delivery.
El Product Discovery Track consiste en generar Product Backlog Items validados lo más rápido posible. El Product Delivery Track consiste en generar software entregable.
Otra razón por la que me gusta la metáfora de las dos "vías" en Dual-Track Scrum es el hecho de que a menudo veo personas que básicamente incorporan mini-cascadas en su framework Scrum. El Product Manager realiza algún "trabajo de requisitos" que luego pasa a un diseñador. Este crea un diseño y genera sus artefactos (normalmente wireframes anotados) y después todo se pasa al equipo de Delivery para desarrollar y probar.
En contraste, el flujo de trabajo en Dual-Track Scrum no se caracteriza por el traspaso de artefactos de un rol al siguiente. En cambio, Dual-Track Scrum es colaborativo: Product Manager, diseñador y el desarrollador principal trabajan codo a codo para crear y validar Backlog Items.
Los lectores de mis artículos saben lo importante que es el diseño de User Experience en mi opinión. Sin embargo, el ritmo y la velocidad de Scrum pueden representar un problema para muchos equipos de UX tradicionales. Por eso soy tan fan de Lean UX. Lean UX y Dual-Track Scrum están hechos el uno para el otro. En lugar de centrarnos en artefactos, nos centramos en prototipos y la validación de estos prototipos durante el Discovery. Otra ventaja es que estos prototipos funcionan como especificaciones para el Delivery.
El punto más importante, sin embargo, es que la validación no ocurre después del release como en un proceso cascada, sino que en Dual-Track Scrum ya realizamos la validación durante el Discovery. En cuanto al principio de validar algo lo más rápido y económicamente posible, podemos realmente a menudo realizar la validación antes de que se escriba código alguno, siguiendo el lema "fake it before we make it" (simulárlo antes de construirlo).
Conclusión sobre Dual-Track Scrum
Si tu equipo está frustrado porque hay demasiado desperdicio y los resultados de negocio concretos se logran lentamente, deberías considerar Dual-Track Scrum. Quizás pueda conducir a una mejor colaboración, una iteración y validación más rápidas y, por tanto, a un mejor trabajo.
Este texto proviene del blog de Marty Cagan y fue traducido al español.
Estrategia empresarial vs. estrategia de producto
Aprende más sobre potenciales conflictos de estrategia en nuestro artículo sobre la diferencia entre estrategia empresarial y estrategia de producto.
