Episodio 6. Cómo alinear discovery y delivery en tu equipo Agile.
Dual Track Agile o cuándo realizar tareas UX/UI y búsqueda de requisitos
¡Hola de nuevo! ¿Cómo te va la semana? Parece que las restricciones nos liberan un poco más últimamente y al menos podemos retomar algo de la vida social que teníamos antes. Ahora bien, quizás es más complicado volver a la vida social manteniendo las precauciones anti-covid que alinear un equipo de producto completo. Así que vamos a por la segunda.
Como siempre, el podcast de este episodio #6 ya lo puedes encontrar en Spotify o en tu plataforma favorita. ¡Empezamos!
⚔️ Problemas a la vista
Lo primero de todo, a modo de disclaimer, si eres evangelista de Scrum puro quizás no estés muy conforme. Nos vamos a saltar algunas reglas y no quiero que te enfades conmigo. ¿Decidido? ¡Vamos allá!
Quizás habrás visto en muchos equipo de producto como el principio de cada proyecto de Scrum y el momento de definición de tareas es un desastre. Es como si escaparan del foco agile y acechara el caos. Sprints iniciales de definición interminables, tareas de definición sin estimar ni priorizar u olvidadas en el backlog, poca transparencia al resto del equipo... Incluso definiciones de tareas pobres sin contar con el equipo técnico, que después se deben de rehacer por limitaciones de tiempo o inviabilidad técnica. Seguro que ya has recordado alguna de estas circunstancias en tus proyectos.
Ante esto, hace unos años Jeff Patton propuso una solución acuñando el término Dual-Track. Jeff cuestionaba el hecho de que un MVP es la mejor forma de validar una idea, porque según él, para crearlo hace falta demasiado tiempo y dinero con un riesgo alto de fracaso, pudiéndose validar esa idea mediante otros métodos en una etapa más temprana.
🤔 ¿Que es Dual Track Agile?
Dual Track Agile es un concepto que crea dos líneas de trabajo en un mismo sprint. Estas dos líneas de trabajo son Discovery y Delivery. Las dos funcionan de manera simultánea, con componentes de un mismo equipo y con los timings propios del sprint en cuestión compartidos.
Con Discovery se pretende mirar un poco más atrás a la creación de requisitos y abarcar la creación, verificación, aceptación o eliminación de ideas a partir de las necesidades del cliente/usuarios. Por ello crea una línea (normalmente entre uno o dos sprints por detrás de delivery) de tratamiento de las ideas, validación, prototipos y creación de requerimientos. En esta línea suelen intervenir perfiles como UX designer, UI designers, product designer y product manager.
La principal ventaja es el ahorro en pérdidas de tiempo y errores en fases posteriores, así como aumentar la seguridad de un buen resultado en métricas y valor añadido en cada sprint. Además al validar y trabajar los requisitos anteriormente, en la etapa de desarrollo se obtendrá unos requerimientos más acotados y, por ende, mayor fiabilidad y tiempos menores.
Posteriormente se encuentra la línea de Delivery. Son los que se encargan del desarrollo de la idea definida anteriormente en Discovery y de su despliegue. En esta línea suelen encontrarse perfiles cómo developers, tech led, QA y product manager.
Una parte esencial es la gestión y organización de estos dos tracks y sus sprints. A modo de puente, se encuentra el llamado product trios, un equipo formado por el product manager, product design y tech led. Su función es gestionar la evolución de los sprints y, entre otras cosas, validar las ideas que se generen en discovery. Por lo tanto si una idea no se alinea o no es viable con diseño o desarrollo, se puede prescindir de ella de una forma más temprana.
Por lo tanto se quedaría un ciclo como este:
🤷 ¿Por qué no es Scrum?
No se puede decir que cumpla al 100% con la guía de Scrum por dos razones. La primera es porque al final de cada sprint no hay un producto entregable, al menos en Discovery. La segunda es porque quiebra de cierta forma el objetivo de crear un equipo multifuncional.
Este método es propenso a desviar el foco en crear un solo equipo y tiende a crear dos equipos diferenciados entre ellos, y más si partimos de metodologías waterfall anteriormente. Pero también es objetivo del product manager (y de todo el equipo) que esto no ocurra. Las líneas de trabajo no tienen una asignación de sus integrantes indefinida, sino que es flexible. En cada sprint pueden ser diferentes y con distintos roles. Por poner un ejemplo, si en discovery hace falta crear una pequeña web en forma de MVP para testear con los usuarios, un desarrollador puede pasar a formar parte de discovery sin ningún problema.
Además la conexión entre los dos equipos debería seguir siendo fuerte. Ya que participan en las mismas ceremonias de Scrum y comparten toda la información al respecto. También tienen la misma visión y goals que alcanzar, al igual que OKRs a conseguir (si los hay).
🫂 El método se adapta al equipo y no al revés
No hay ninguna metodología ni framework perfecto. Se debe de adaptar a la forma de trabajar de cada equipo y ajustarse a cómo se sienta más cómodo y realice un mejor resultado. Solo en Dual Track existen varias opciones diferentes de implementación.
La primera es crear dos backlogs diferentes. Quizás estimar y dividir algunas tareas en discovery, más concretamente de research y diseño, se hace una odisea. Por ello es posible trabajar de una manera no sincronizada. Puede que a priori los backlogs se vean más sencillos y fáciles de comprender, además de no tener que utilizar una nomenclatura común con diferentes perfiles. Pero a la larga esta opción es propensa a crear la desconexión entre los dos equipos que te comentaba antes.
Si el caso anterior es el que más se ajusta al equipo, es posible incluso trabajar con diferentes frameworks en cada línea de trabajo. El más habitual puede ser un equipo de discovery trabajando con kanban y un equipo de delivery trabajando con Scrum y sus sprints. Cuando una tarea se completara en discovery pasaría al backlog de delivery igual que en el modelo principal.
❤️ ¿Te gusta?
La experiencia de usuario está obteniendo una gran relevancia (menos mal) en los producto actuales. En cambio siguen surgiendo dudas de cuando es el mejor momento de hacer las tareas de UX/UI y la búsqueda de requisitos. Yo creo que este modelo podría solucionar esos problemas y engrasar los mecanismos de muchos equipos. Así como desplegar el máximo valor añadido optimizando tiempo y dinero.
¿Has pensado en incluir a perfiles de desarrollo en discovery para hacer research de nuevas tecnologías y su posible implementación, con la ayuda de producto para dar el mayor valor al usuario? ¿Has implementado esta metodología alguna vez? ¡Cuéntame!
🥰 ¡Gracias por llegar hasta aquí!
¿Te ha resultado útil? Como siempre, cualquier feedback es bienvenido. No dudes en contactarme por Linkedin para charlar sobre cualquier cosa.
Y si crees que le puede ser útil a alguien más, puedes compartirla desde el botón de abajo 😉