Agilidad, ¿En qué momento hay que descubrir nuevas historias? Constantemente #DualTrack #ContinuousDiscovery

De las no sé ya ni cuantas reuniones y proyectos que yo haya podido tener en mi vida, y de las otras tantas que 233 Grados de TI haya podido tener en estos últimos meses, explicando y concienciando a empresas sobre el salto a la agilidad se podría elaborar una especie de FAQ con cuestiones que salen siempre, repetida y reiterativamente, siempre.

Además de que este es uno de los temas principales del curso online sobre Product Owner.

Muchas de esas cuestiones, dudas, partes más complicadas de implantar, de concienciar, de cambiar, han dado y darán para muchos post de este blog. Y vamos con uno más, en este caso tratando una cuestión que normalmente viene a manifestarse así… “-Y si ahora no tenemos ciclo de vida en cascada, y no hay una gran y única fase de «requisitos», o de análisis… ¿cómo vamos a sacar las historias? ¿La foto global? ¿Dónde queda el trabajo que hacían analistas de negocio o similares?-“

En relación a esto, la figura del Product Owner es algo que relativamente se ha entendido bien, sus roles y responsabilidades son más o menos conocidos (te dejo una infografía), pero creo que no ha sido igual de popular la información relativa a “los procesos” cercanos al product owner, los relativos a extraer necesidades, “cargar” esas pilas de producto, etc., en general a lo que llamaremos “el ciclo de descubrimiento”.

Los intentos más populares para ir extrayendo necesidades en un ciclo de vida ágil o, simplificadamente y para que se entienda, cómo ir generando el Product Backlog

Quizá la idea más “antigua” (a lo que a agilidad se refiere, obviamente) de dónde, en qué punto, definir las necesidades, funcionalidades, etc., que debían irse incorporando al producto por parte de desarrollo, era centrarse en la “reunión de planificación del sprint”.

Esta idea, aunque popular, no dejaba de ser un error (a la reunión de planificación el Product Owner se debiera ir a explicar historias de usuario no a crearlas), ya que, lógicamente, la lista de necesidades debía estar lista antes de esa reunión, de no ser así las “reuniones de planificación del sprint” excedían en tiempo, eran frustrantes, porque los elementos del backlog no estaban bien definidos, entendidos, o validados.

Para evitar lo anterior, se popularizó el concepto de esto reuniones de refinamiento o Backlog Grooming, una la reunión previa “ a la reunión de planificación del sprint” con la idea de preparar el próximo Sprint Planning, para evitar llegar a él con las tareas a medio a hacer. No obstante, si bien esto ayuda, tampoco deja una respuesta muy clara a “cuando extraer esas necesidades que conformarán el product backlog”.

Otra popular iniciativa en este ámbito vino de los Spikes. Los spikes, que venían de eXtreme Programming, eran tareas “de investigación” que se introducían en un Sprint, típicas para extraer y comprender historias, degeneraron en “el Sprint de Spikes”, cuyo objetivo era dedicar un Sprint completo a la extracción y detección de nuevas historias. Ocupaban un papel muy similar a los El Sprint cero.

El problema de esta última estrategia era que esos Sprint de Spikes o de descubrimiento eran demasiado bruscos y rompían la secuencia de Sprint típicos, generaban la idea de que “el descubrimiento” iba por fases. Ya sean Sprint cero, Spikes o Sprints de Descubrimiento, el descubrimiento ocurre por trozos aislados, sin embargo.. el descubrimiento siempre debería estar sucediendo.

Y la idea que mejor transmite “el descubrimiento constante” (ese #ContinuousDiscovery) es la que se ha llamado “Dual-Track”.

Dual-Track Scrum o Dual-Track Ágil (que vendría a ser algo así como Scrum o Agilidad de Doble vía)

El término “Dual-Track” viene de Jeff Patton (el autor de User Story Mapping: Discover the Whole Story, Build the Right Product). La idea asume que hay dos caminos en el desarrollo de un producto: “Descubrir” y “Entregar”.

Esta manera de verlo, evita y elimina la idea de que “primero hay una fase de requisitos” y después “viene su implementación”, y que si es un ciclo de vida ágil sucede lo anterior pero muchas veces, rompe la idea de fase, ya que “Descubrir” y “Entregar” muchas veces ocurren de manera simultanea.

Bajo una visión “Dual-Track” un “equipo de descubrimiento” está continuamente en descubriendo y el equipo de desarrollo está continuamente “entregando” producto al usuario final.

En “Dual-Track” el product owner, o el equipo correspondiente, está continuamente detectando, creando y validando nuevas necesidades, siguientes historias que se agregan al Product Backlog. En muchas ocasiones por “equipo de descubrimiento” nos estamos refiriendo al “product owner”, si bien este también podría ser la “interface” hacia desarrollo de un equipo de descubrimiento mayor.

Si el equipo de desarrollo trabaja con Ingeniería Software, Construye – Prueba – Entrega y Verifica, el de descubrimiento Experimenta, Descubre-Diseña y Valida.

Si el equipo de desarrollo considera desperdicios documentación innecesaria, código innecesario, etc., el de descubrimiento considera desperdicios las Funcionalidades que no se usan

El equipo de desarrollo busca Construir el Producto correcto y el de descubrimiento construir de manera correcta.

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Las 3 matrices de priorización Ágil - 19 octubre, 2023
• Etapas del Agile Product Management - 12 octubre, 2023
• Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023