Dual-Track Agile

Dual-Track Agile

Dual-track Agile es el nombre que recientemente se le ha dado a la forma en que los equipos de producto digital se organizan para gestionar el trabajo de descubrimiento y desarollo. Dual-track Agile es solo un término pegadizo para indicar el hecho de que los equipos modernos de producto digital combinan el trabajo de descubrimiento y el trabajo de desarrollo.

Aunque entiendo que la gente utilice este concepto, tengo varios problemas con él. En primer lugar, dicen Ágil, pero se refieren a Scrum, y en segundo lugar, la doble vía puede sugerir dos actividades desconectadas o independientes y no lo son.

Al igual que con muchos otros términos en la industria del software, dual-track agile es ambiguo, confuso y necesita explicación. Prefiero usar términos como Value Stream, Lean Product Development o Dual-Track Product Development, con preferencia por el primero o el segundo.

Ahora, veamos de dónde proviene este concepto y cómo puedes realmente beneficiarte de él.

Este artículo es solo una introducción a dual-track agile, si veo mucho interés agregaré explicaciones más detalladas sobre cómo implementar adecuadamente el desarrollo de productos de doble vía con Scrum y / o Kanban. Por favor comenta si quieres más;)

Los Orígenes de Dual-Track Agile

El término dual-track fue mencionado por primera vez por una diseñadora de interacción llamada Desiree Sy en un artículo titulado “Adapting Usability Investigations for Agile User-centered Design”. A partir de ahí, el término se extendió rápidamente por todo el mundo.

Te recomiendo que leas el artículo. Es muy interesante.

En su artículo de 117 páginas, Desiree dibuja la imagen que mostramos a continuación y sugiere varias prácticas para integrar adecuadamente el trabajo de diseño de interacción con el trabajo de desarrollo de software ágil. Como el diseño justo a tiempo, Sprint 0, diseño incremental, diseño fragmentado o vías paralelas.

Dual-Track Agile - Dual-Track Scrum - Lean Product Development - AKTIA Solutions
Imagen tomada del artículo de Desiree Sy titulado “Adapting Usability Investigations for Agile User-centered Design”

 

En un párrafo de su artículo, Desiree dice:

Two parallel tracks: iterating the design and implementation separately, but simultaneously. A key principle of our User Experience Team’s UCD process is design iteration; we need to be able to catch design failures early, change designs as many times as needed, and then incorporate the design fixes. Therefore, we not only need to conduct formative usability tests to check our prototypes, but we need to do so before coding begins, while the design is still malleable. Because coding begins immediately in Agile development, we needed to find a way to separate design iterations from implementation iterations. To do this, the UCD work was done in an Interaction Designer Track while developers worked in a separate and parallel Developer Track.

Y, en otro párrafo agrega lo siguiente, que es probablemente la primera mención del concepto dual-track agile:

In addition to keeping in touch with the whole Agile team through the daily scrum, we work with developers very closely throughout design and development. Although the dual tracks depicted seem separate, in reality, interaction designers need to communicate every day with developers. This is not only to ensure that designs are being implemented correctly, but also so that we have a thorough understanding of technical constraints that affect design decisions

En mi opinión, Desiree solo decía lo obvio: forzar el trabajo de diseño en paralelo con el trabajo de desarrollo en la misma iteración generalmente no es posible. Digo “generalmente” porque puede haber productos o situaciones en las que eso sea posible. Por ejemplo, si tu producto está maduro y tu equipo solo está haciendo innovación incremental y cambios menores, podría ser posible, pero si tu producto aún está antes de ajuste producto-mercado o si planeas poner añadir algo considerable en el próximo lanzamiento, entonces debes organizarte de manera diferente e intentar no obligar a los ingenieros y diseñadores o gerentes de producto a trabajar en las mismas cosas al mismo tiempo.

El problema con la imagen de Desiree y otras interpretaciones del término dual-track agile, es que la gente no lee, solo ven la imagen y entienden lo que quieren. Algunas personas pueden entender que esta imagen sugiere que los gerentes y diseñadores de producto piensan y los desarrolladores simplemente construyen, mientras que otros podrían pensar que el trabajo de descubrimiento de producto puede llevar meses antes de estar listo para el desarrollo.

Ninguno de esas interpretaciones es correcta, cuando decimos dual-track agile nos referimos a un equipo que trabaja en conjunto para lograr sus objetivos, pero queremos diferenciar y visualizar claramente diferentes tipos de trabajo con diferentes cadencias.

Los Inicios de Scrum

En los inicios de Scrum, y lamentablemente aún hoy, la mayoría de los equipos de Scrum eran solo equipos de desarrollo, por lo que solo tenían que entregar iterativamente lo que los Product Owners ponían en el backlog.

Las primeras dificultades aparecieron cuando los equipos comenzaron a querer integrar el diseño de la experiencia del usuario y el diseño visual con el desarrollo de software. No porque los diseñadores quisieran hacer grandes diseños por adelantado, sino porque la naturaleza de su trabajo hizo que fuera bastante difícil hacerlo dentro de 2-3 semanas en paralelo al desarrollo de software.

Los dogmáticos de Scrum insistían en que todo tenía que suceder dentro del mismo sprint sin importar qué, demostrando una clara falta de comprensión del contexto y aprecio por sus compañeros de equipo.

El Problema con el Dogma de Scrum

El problema con la integración de UX y Scrum es que estamos tratando de meter todo en el sprint como si todo el trabajo fuera igual. La razón de esto es que la gente confunde equipo con sprint. El hecho de que algunos miembros del equipo no estén trabajando al 100% en el trabajo de desarrollo no significa que no pertenezcan al equipo.

Lo mismo ocurre con los Product Owners, Product Managers, diseñadores de experiencia de usuario o análisis de datos. ¿Por qué se permite al Product Owner trabajar fuera del sprint y a otros miembros del equipo no?

Si lees detenidamente la guía Scrum, reconocerás que el resultado del sprint es un Incremento de Producto Potencialmente Entregable y, hasta donde yo sé, una wireframe, una maqueta, una entrevista con el cliente, un diseño de interacción o una investigación de mercado no son PSPIs. Estamos tratando de obligar a los diseñadores a trabajar en cosas que se están desarrollando actualmente sin darles suficiente tiempo para comprender los problemas de los clientes, diseñar y probar posibles soluciones.

Esto también es un problema para los ingenieros, porque trabajar en algo que se está diseñando actualmente es una molestia y puede generar un trabajo innecesario.

Dual-Track Agile no se Trata Solo de Diseño

Pero no se trata solo de UX. Todo el trabajo que los equipos de producto digital deben hacer es una combinación de exploración, descubrimiento, diseño, desarrollo y aprendizaje. Los equipos deben aprender qué problemas deben resolverse, luego aprender cómo resolverlos, luego ofrecer soluciones para resolverlos y luego medir y aprender sobre eso.

Parte del trabajo puede realizarse en paralelo con el desarrollo de software, pero mucho trabajo simplemente no se pueden hacer y no se debe hacer.

No todo el trabajo es igual, y no todo el trabajo debe ocurrir dentro de la misma cadencia.

Dual-Track Agile Significa Dos Tipos de Trabajo

Dual-Track Agile significa un flujo continuo de descubrimiento de producto y entrega de producto por el mismo equipo. Hay dos tipos de trabajo y no hay forma de evitarlo.

Si vamos a Lean Thinking House, podemos ver claramente dos tipos de trabajo: “Desarrollo de productos” y “Producción”. Lo que, hoy en día, en el desarrollo moderno de productos digitales generalmente se conoce como: Descubrimiento de producto y desarrollo de producto.

Dual-Track Agile - Lean Product Development - AKTIA Solutions
Image adaptado de “Lean Thinking House” en el libro “Scaling Lean & Agile Development”

 

El descubrimiento y el desarrollo se visualizan en dos vías porque son dos tipos de trabajo y dos tipos de pensamiento. Si bien los gerentes de producto o propietarios de producto junto con diseñadores e ingenieros pueden dirigir y organizar el descubrimiento, todo el equipo debe involucrarse en las tareas de descubrimiento siempre que sea posible.

En general, el resultado del proceso de descubrimiento de producto son elementos validados del backlog para su desarrollo. Pero, ese no es siempre el caso:

  • Algún trabajo podría ir directamente al backlog si la incertidumbre es baja
  • Algunos trabajos pueden ser solo aprender sobre el mercado o las necesidades del cliente, que podrían terminar en backlog, pero tal vez después de varios meses
  • Se espera que parte del trabajo se descarte durante el proceso de descubrimiento

Veamos todo esto con más detalle.

Descubrimiento de Producto

Descubrimiento de Producto - Lean Product Development - AKTIA Solutions

Una de las tragedias del desarrollo de productos es que gran parte de lo que construimos no tiene éxito. Si queremos aumentar las probabilidades de éxito, necesitamos hacer un trabajo de descubrimiento, y eso requiere tiempo y habilidades que no son habituales en el desarrollo de software.

Aprender sobre qué problemas debemos resolver y qué debemos construir para resolverlos es un proceso de aprendizaje que llamamos descubrimiento de producto. Para responder preguntas, probar ideas, construir prototipos, realizar pruebas de usuario y evitar, en la medida de lo posible, construir cosas que nadie quiere.

Queremos aprender de la manera más rápida, económica y segura posible. La velocidad también es importante durante el descubrimiento, pero esta es la velocidad de aprendizaje, y es tan importante aprender qué hacer como aprender qué no hacer.

El descubrimiento de producto …

  • … se centra en el aprendizaje rápido y la validación
  • … es de naturaleza muy variable
  • … es una parte necesaria del desarrollo de producto y, por lo tanto, practicamos los mismos principios ágiles y ágiles
  • … debería ayudarnos a descartar muchas ideas
  • … significa seguir midiendo y aprendiendo después de lanzar a producción

El descubrimiento de producto se realiza mejor mediante tres funciones combinadas, generalmente un gerente de producto con conocimiento de negocio y de producto, un diseñador con conocimiento sobre la interacción de usuario y el diseño visual y un ingeniero con conocimiento sobre tecnología.

El Bucle de Descubrimiento de Producto

El proceso comienza describiendo cuál es el problema que estamos resolviendo y para quién. Luego, la solución que nos gustaría construir para resolverlo y cómo mediremos el éxito.

Una vez que tenemos la imagen completa, debemos elegir los supuestos más riesgosos y diseñar experimentos para aprender más, más rápido y más barato. Después de realizar el experimento, debemos revisar nuestras suposiciones y riesgos y tal vez crear algún trabajo de desarrollo. Este es el ciclo de aprendizaje, que puede tomar algunas horas, algunos días, pero con suerte no semanas.

La pregunta que estamos tratando de responder aquí es quién tiene el problema, qué tan grande es ese segmento de clientes y si van a querer usar nuestro producto o funcionalidad, no cuánto costará ni cuánto tiempo va a durar.

Así es como funciona un ciclo de aprendizaje. Y hay algunas cosas que debes saber al respecto.

  • Hacemos todo esto tan rápido como podemos. Por lo tanto, muchos bucles de aprendizaje de descubrimiento deberían caber en un sprint de desarrollo típico de 2 semanas.
  • El trabajo de descubrimiento a menudo resulta en ideas que se descartan. Al final de cada experimento, debes tomar una decisión: construir, descartar o seguir aprendiendo. Esa es la razón por la que hay que definir criterios claros de éxito por adelantado.
  • Tenemos ciclos de descubrimiento por time-box. Para mantener a raya los costes de descubrimiento, realizamos experimentos desde unas pocas horas hasta unos pocos días. Pero siempre limitados en el tiempo.
  • No podemos predecir lo que necesitaremos aprender a continuación, al menos, no fácilmente. Cuando aprendemos algo nuevo, tiende a cambiar nuestro conjunto actual de suposiciones y seguramente cambia lo que tenemos que hacer a continuación.

Cómo Implementar Dual-Track Agile

La realidad es que el descubrimiento de producto y la entrega de producto están sucediendo en todo momento. Como mencioné antes, dependiendo de la etapa del ciclo de vida del producto o el tipo de producto o la estacionalidad, tu equipo hará más de uno u otro, pero definitivamente ambos al mismo tiempo.

Son dos vías, no dos equipos. Y a continuación hay algunos consejos importantes:

  • Centrarse en los supuestos más riesgosos
  • Realizar un diseño justo a tiempo
  • Los diseñadores deben ser miembros del equipo a tiempo completo
  • Involucra a tantos miembros del equipo como sea posible en el proceso de descubrimiento
  • Visualiza el trabajo de descubrimiento
  • Visualiza los aprendizajes
  • Si estás utilizando Scrum, el backlog de producto estará compuesto por elementos de descubrimiento y elementos de entrega, y debes definirlos adecuadamente antes de la planificación de Sprint.

Antes de saltar a los detalles de la implementación, déjame decir algo más. No todo el trabajo debe pasar por la fase de descubrimiento (o no al completo, al menos).

Imagina que eres el Product Manager de un comercio electrónico y estás pensando en diferentes opciones en preparación para el Black Friday. Una opción es hacer una campaña de descuento en el producto.

Esto es algo que has hecho antes, conoces tu producto y tu base de clientes y puedes calcular un retorno aproximado.

Dual-Track Agile - Descubrimiento de Producto - Lean Product Development - AKTIA Solutions

Con esta información, puedes enviarlo directamente a desarrollo si crees que vale la pena.

Ahora, imagina que estás pensando en introducir una nueva línea de productos en tu comercio electrónico o tal vez apuntar a un segmento de clientes o geografía diferente. Estoy bastante seguro de que tendrás que evaluar la oportunidad de mercado, la viabilidad financiera y hacer algunos experimentos antes de comprometerte plenamente con el desarrollo. Esto llevará un tiempo y probablemente requerirá varias iteraciones e incrementos del equipo de desarrollo.

La primera opción tiene baja incertidumbre y bajo rendimiento, y la segunda opción tiene alta incertidumbre y alto rendimiento.

Dual-Track Agile con Scrum

Dual-Track Agile - Descubrimiento & Desarrollo - Lean Product Development - AKTIA Solutions

El trabajo de descubrimiento utiliza longitudes de ciclo irregulares. Es bastante difícil saber cuándo vas a aprender algo, aunque nos esforzamos por realizar experimentos limitados en tiempo, aprendes algo cuando lo aprendes, no esperas dos semanas para pasar al siguiente experimento. Las ideas evolucionan y muy a menudo mueren durante el proceso de descubrimiento. Las mejores ideas se mueven hacia los ciclos de entrega donde se ejecutan dentro del sprint.

Sprint Planning

Si trabajas con Scrum, comienzas cada sprint con una reunión de planificación en la que tendrás que considerar tanto el trabajo de descubrimiento de producto como el de entrega de producto.

Es el mismo proceso, sin embargo, a lo largo del sprint habrá personas que realizarán trabajos de descubrimiento, como analizar oportunidades, realizar pruebas de usuario, prototipos o diseño de interacción, mientras que otras personas codificarán software, probarán o configurarán la integración continua.

Al igual que con Scrum tradicional, asegúrate de que todo el trabajo previo requerido para preparar la planificación del sprint se realiza para todo tipo de trabajo. Lo que también significa que el trabajo de entrega debe elegirse con algunas iteraciones de antemano para que haya tiempo para prepararse para descubrir lo que hay que hacer.

Daily Scrum

Tu reunión diaria de Scrum debe ocurrir como de costumbre, pero una vez que hayas terminado, debes realizar tu reunión de descubrimiento diaria, donde se revisa el progreso en el trabajo de descubrimiento.

Aquí el equipo debe acordar quién participa en cualquiera de las partes del Daily Scrum. En general, opino que todos deberían participar en ambos, sin embargo, a veces eso no es posible. Por lo tanto, haced un acuerdo.

Sprint Review

Si perteneces a un equipo de producto que realiza el descubrimiento y entrega, la revisión será diferente a la de un equipo que solo realiza tareas de entrega. Aquí sugiero algunas ideas, pero debes adaptarte a tu contexto.

La esencia de lo que hemos estado discutiendo hasta ahora es que, básicamente, hay dos tipos de resultados de un equipo de producto: aprendizaje y software funcionando. Entonces, esto es lo que queremos revisar al final de la iteración.

Además de eso, los grandes equipos de producto también revisan el rendimiento del proceso, las métricas de rendimiento del producto y actualizan el progreso hacia OKR o planes.

Reserva de 1 a 3 horas para esta reunión y también ten en cuenta que una discusión tan detallada podría no ser de interés para los clientes y los stakeholders, por lo que debes planificar con ellos otra revisión más breve y centrada en los resultados del sprint.

Retrospectiva

Mi recomendación es que celebres tu reunión de mejora justo después de tu reunión de revisión. Aquí debes hacer lo que sueles hacer, pero también debes incluir el proceso de descubrimiento en la discusión.

Como de costumbre, revisa cómo habéis trabajado durante la última iteración e identifique oportunidades de mejora para la próxima iteración.

Revisa también los cambios realizados en la iteración anterior, evalúa los resultados y decide si deseas mantener el cambio, modificarlo o eliminarlo.

Visualización

Debes visualizar el trabajo de descubrimiento para que te ayude a mejorar el proceso y aporte información a todo el equipo y a stakeholders sobre lo que está sucediendo.

En términos generales, la mayoría de los equipos de producto digital siguen un proceso similar. Todo comienza con una idea o un problema. Luego hay una etapa para comprender el problema y luego una etapa para explorar soluciones, finalizando con elementos validados para la entrega o eliminando la idea.

La duración de estas etapas dependerá del tamaño del trabajo y la incertidumbre / riesgo relacionado. Diseñar una campaña para el Black Friday no es lo mismo que presentar una nueva línea de productos o una nueva funcionalidad enorme para resolver un problema del cliente.

Por lo tanto, habrá trabajo pasando rápidamente a través del panel de descubrimiento, mientras que otro trabajo llevará más tiempo. Lo que nos lleva a la siguiente sección sobre Kanban.

Dual-Track Agile con Kanban

Cuando la gente habla sobre dual-track agile, generalmente dan por sentado a Scrum, pero en mi opinión Kanban puede ser de gran ayuda aquí.

Desiree también muestra en su artículo cómo estaban usando un Tablero de Experiencia del Usuario para gestionar el progreso del diseño de interacción. Como puedes ver, al final del flujo de trabajo hay una celda que dice “Next Release”. Esto representa los elementos que están listos para el desarrollo de software.

Dual-Track Agile - Product Discovery Board Sample - Lean Product Development - AKTIA Solutions
Image tomada del artículo de Desiree Sy titulado “Adapting Usability Investigations for Agile User-centered Design”

El proceso de desarrollo de producto puede verse como un proceso continuo para reducir la incertidumbre. Desde una idea hasta que entrgamos el software, está ocurriendo un proceso de aprendizaje. Aprendemos sobre clientes, sobre tecnología, sobre oportunidades de mercado y sobre nosotros mismos.

En ese proceso hay un punto que todavía marca la diferencia. Construir software sigue siendo lo más costoso que tendrás que hacer, y debes maximizar las probabilidades de construir lo correcto. Por lo tanto, es imprescindible un proceso de descubrimiento de producto.

El concepto de doble vía pierde todo significado si se mira desde la perspectiva de Kanban. En Scrum tiene sentido porque tanto el backlog como el sprint backlog incluyen elementos de descubrimiento y entrega, pero en Kanban recomendamos visualizar el proceso de descubrimiento y el proceso de entrega en secuencia y conectarlos usando el búfer “Ready to Pull“.

Upstream Kanban Sample - Connecting Upstream and Downstream Kanban Systems - AKTIA Solutions

De esta forma, desacoplamos el descubrimiento, la planificación y la entrega y permitimos que cada tipo de trabajo fluya al ritmo requerido y visualicemos los detalles de todo lo que sucede en el equipo.

El problema que veo con Scrum son múltiples elementos que abarcan más de un sprint. Sin embargo, en Kanban, podemos visualizar dos backlogs diferentes, el trabajo de descubrimiento y el trabajo de entrega.

Descubrimiento de Producto con Kanban

El proceso de descubrimiento del producto debe realizarse antes del desarrollo. Forzar que todo suceda en la misma iteración es la receta para el fracaso y la frustración.

Nuestra recomendación es que separes efectivamente su proceso de desarrollo de productos en dos fases: descubrimiento y desarrollo de software. Me gustaría que pienses en el concepto de Value Stream en lugar de dual-track agile. En la fase de descubrimiento, el objetivo es comprender y resolver los problemas de nuestros clientes. El resultado son elementos validados listos para el desarrollo.

Hay un equipo, pero diferentes personas están trabajando en diferentes partes del flujo de valor. Este proceso brinda a los diseñadores, investigadores y gerentes de producto espacio para comprender los problemas de los clientes y explorar soluciones antes de que se comprometan a desarrollar nuevas funcionalidades.

Una vez que se realizan los diseños, el trabajo pasa a la fase de entrega. El objetivo de esta fase es enviar la solución final a los clientes lo más rápido posible con la mínima molestia.

La clave de este sistema es que el diseño y la investigación son una parte explícita del proceso, y hay criterios de aceptación que deben cumplirse antes de que los ingenieros escriban cualquier código.

Implementar el Descubrimiento de Producto con Kanban

Lo que te mostraremos aquí es cómo modelar un Sistema Kanban para Descubrimiento y Entrega. Donde Descubrimiento sería la parte de Upstream.

Este sería el caso de una organización moderna de producto donde los equipos de producto son totalmente responsables del descubrimiento y la entrega y necesitan equilibrar ambos tipos de trabajo.

Al igual que al modelar cualquier otro sistema Kanban, debes comprender los límites del trabajo de descubrimiento: dónde comienza y dónde termina. Y, lo que sucede en el medio. Esto dependerá del contexto de tu negocio, pero en general podemos definir un proceso típico.

El Sistema Kanban de Descubrimiento de Producto

El sistema Kanban de descubrimiento de producto se basa en el típico embudo de innovación: Idea – Explorar – Validar.

El punto de entrada a Product Discovery Kanban es una idea. Las ideas pueden ser cualquier cosa: necesidades desatendidas, problemas o posibles soluciones. Después de las ideas, cruzamos el punto de compromiso para el descubrimiento, en este punto acordamos invertir tiempo en exploración y validación. Exploraremos el problema y la solución.

El sistema Kanban de descubrimiento de producto tiene dos fases principales, que se pueden dividir en varias más según su contexto:

  • Exploración
  • Validación

Exploración

La entrada a la exploración es una idea, con algunos trabajos básicos realizados como una evaluación preliminar de viabilidad financiera y una evaluación de oportunidades. Esta idea viene con una lista de supuestos y el riesgo potencial de esos supuestos. Por ejemplo:

  • Cliente
  • Problemas / necesidades
  • Mercado
  • Producto
  • Tecnología
  • Financiero
  • Modelo de negocio
  • Regulaciones legales

Nuestra tarea durante la exploración es trabajar en los supuestos más riesgosos mientras se valida el problema y se valida la propuesta de valor. También debemos analizar la oportunidad de mercado y capturar supuestos sobre posibles soluciones y modelo de negocio.

La fase de exploración puede desglosarse aún más en Comprensión del Problema y Exploración de Soluciones.

  • En la fase de Comprensión del Problema, recopilamos datos para ayudarnos a comprender y enmarcar el problema. Los datos incluyen datos tanto cualitativos como cuantitativos, como entrevistas a clientes, encuestas, tickets de soporte, comentarios de llamadas de ventas, uso de productos y comentarios de NPS.
  • En la Exploración de Soluciones, los diseñadores usan los datos recopilados durante la Comprensión del Problema para enmarcar el problema a resolver. Los diseñadores escriben explícitamente cuál es el problema, los casos de uso y los usuarios objetivo.

Luego, el equipo define una propuesta de valor y puede comenzar a crear bocetos, esquemas y prototipos. Los ingenieros están conectados para proporcionar comentarios sobre la viabilidad técnica. Los investigadores también hacen pruebas de usabilidad en esta fase.

Finalmente, el resultado son diseños terminados que están completamente pensados.

Validación

Tu aportación a la fase de Validación es una propuesta de valor, y tu trabajo aquí consiste en validar la solución y validar el modelo de negocio.

Aunque ya estás construyendo cosas, esto sigue siendo un proceso de descubrimiento, porque estás validando tu solución, tu viabilidad financiera y quizás aún algunas suposiciones técnicas.

Listo para Desarrollo

Las soluciones terminadas pueden ser en forma de maquetas o un prototipo, una solución UX, un diseño técnico, una prueba de concepto o una solución de viabilidad técnica. La solución final luego pasa a Listo para Desarrollo, donde se prioriza frente a todos los demás trabajos potenciales que se realizarán.

La columna Listo para Desarrollo es el búfer que conecta el upstream (descubrimiento) con la entrega. Este inventario de opciones tendrá que desglosarse en pequeños trozos de valor para entregarse de forma iterativa e incremental.

Tablero Kanban de Descubrimiento de Producto

Recomendamos encarecidamente que implementes políticas de visualización adecuadas para los diferentes tipos de trabajo en tu tablero Kanban de Descubrimiento de Producto. No todo el trabajo es igual, por lo tanto, no todo el trabajo debe seguir el mismo flujo de trabajo. Asegúrate de hacer distinciones claras.

El trabajo de descubrimiento es complicado y muchas veces no sigue una línea recta y puede ir hacia atrás o saltar sobre algunas etapas. Pero, en upstream, no es tan importante el flujo perfecto como visualizar las opciones y tomar las decisiones apropiadas.

A continuación, mostramos un ejemplo típico de un tablero Kanban de Descubrimiento de Producto.

Discovery Kanban Board Example - AKTIA Solutions

Ten en cuenta que este tablero solo muestra una sugerencia de etapas en el descubrimiento de producto.

La última columna es “Listo para la entrega”, que es el búfer que se conecta con el tablero Kanban de desarrollo.

Si deseas saber más sobre descubrimiento de producto y dual-track agile, comenta el post y continuaremos con la serie.