Cuando empiezo a trabajar con un equipo de productos Ágiles, una de las situaciones más comunes que encuentro es que los equipos tienen reuniones largas y frustrantes de planificación de Sprints porque los elementos atrasados no están bien definidos y no se entienden bien; tienen una velocidad lenta y un diseño deficiente porque los detalles aún se están resolviendo durante el Sprint; y la cantidad de desperdicio y reelaboración es muy alta porque los elementos atrasados no se han validado.

Recuerde que nuestro objetivo de orden superior es validar nuestras ideas de la manera más rápida y económica posible. En realidad, crear y lanzar una idea de producto es generalmente la forma más lenta y costosa de validar la idea.

Es por eso que soy un gran defensor de lo que a veces se conoce como Ágil de Doble Pista (también conocido como Scrum de Doble Pista, Fúndalo Antes De Hacerlo, Cree Cosas Que No Escalan/Construya Cosas Que Sí Escalan, Muévase Rápido/No Rompa Cosas, Descubrimiento Continuo/Entrega Continua, etc.).

Solía referirme a esto como simplemente Sprints de Descubrimiento, pero eso tiene una implicación de Descubrimiento en caja de tiempo, y también de serialización de fases. Jeff Patton compartió por primera vez conmigo el término “Scrum de Doble pista” y prefiero este término porque capta mejor la naturaleza paralela de Descubrimiento y Entrega.

La pista de descubrimiento tiene que ver con la generación rápida de artículos de productos pendientes validados, y la pista de entrega tiene que ver con la generación de software liberable.

Otra razón por la que me gusta la metáfora Ágil de Doble Vía es que encuentro a muchas personas haciendo pequeñas mini cascadas dentro de su marco de Scrum. El gerente de producto hace algún tipo de trabajo de” requisitos”, que se pasa a un diseñador que hace sus diseños y genera sus artefactos (generalmente marcos de alambre anotados), y luego se entrega al equipo de entrega para que los construya y pruebe.

En cambio, en la metodología Ágil de doble vía, el flujo de trabajo no se caracteriza por que cada función entregue artefactos al siguiente paso; más bien es colaborativo: el gerente de producto, el diseñador y el ingeniero principal trabajan juntos, uno al lado del otro, para crear y validar los elementos atrasados.

Los lectores de estos artículos saben lo importante que considero el diseño de la experiencia de usuario, pero una de las dificultades para muchos equipos ágiles es que el ritmo y el ritmo de la metodología Ágil pueden ser muy difíciles en los equipos tradicionales de experiencia de usuario. Por eso soy fan de Lean UX. Lean UX y Dual Track Agile están hechos el uno para el otro. En lugar de centrarnos en artefactos, nos centramos en prototipos y validamos esos prototipos en el Descubrimiento, con el beneficio adicional de que el prototipo sirve como especificación para la Entrega.

Lo más importante, a diferencia de un proceso en cascada donde la validación ocurre después del lanzamiento, en la metodología Ágil de Doble vía, estamos validando durante el Descubrimiento. En el principio de validar lo más rápido y barato que podamos, la mayor parte del tiempo podemos hacer nuestra validación antes de escribir cualquier código de producción, con el espíritu de “fake it before we make it.”

Por lo tanto, si su equipo de productos se siente frustrado por la cantidad de desperdicio y la lentitud para lograr resultados comerciales reales, considere probar la metodología Ágil de doble vía. Vea si esto puede inspirar un nivel de colaboración, iteración rápida y validación que resulte en un trabajo mucho mejor.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.