Discovery Kanban

Discovery Kanban

¿Cansado de discusiones interminables sobre cómo integrar UX, diseño o investigación con Scrum o cualquier otra metodología de desarrollo de software ágil? Discovery Kanban es la respuesta a tus inquietudes.

Bienvenido al final de tus discusiones. Gracias a Kanban podemos integrar fácilmente el desarrollo y la entrega del producto.

Introducción Discovery Kanban

Discovery Kanban fue un término acuñado inicialmente por Patrick Steyaert.

Discovery Kanban es un sistema Kanban para la innovación y el descubrimiento de producto. Apoya el aprendizaje a través de la observación reflexiva y la experimentación activa. Si la medida del éxito para un sistema Delivery Kanban es el valor entregado, para Discovery Kanban es el aprendizaje validado en forma de soluciones que se implementarán después de un proceso de comprensión del problema y validación de la solución.

Estos son los sistemas Kanban perfectos para startups, equipos de innovación y equipos modernos de producto digital, ya que permiten el descubrimiento y la entrega de productos en el mismo equipo.

Tal como explicamos en nuestro artículo anterior, Upstream Kanban es el sistema Kanban utilizado para desarrollar opciones antes de la entrega o el desarrollo de software. Eso lo puede hacer el mismo equipo o diferentes equipos en compañías más tradicionales donde la gestión de negocios o productos está separada de los equipos de entrega.

Sin embargo, a medida que más compañías adoptan un enfoque Lean real, se organizan en equipos de producto multidisciplinares de extremo a extremo o en flujos de valor. Aquí es donde Discovery Kanban entra en acción como sistema de Upstream Kanban que permite integrar el desarrollo de producto con el desarrrollo de software.

¿Por qué Discovery Kanban?

Todo trabajo de conocimiento requiere un equilibrio delicado y continuamente cambiante entre entrega (explotación) y descubrimiento (exploración). Para los productos maduros, el descubrimiento será menor y para los nuevos productos o equipos de innovación, el descubrimiento será la mayor parte del trabajo. Pero, en general, cualquier idea o funcionalidad nueva que estés pensando agregar a tu producto debe pasar por un proceso de descubrimiento más o menos detallado, dependiendo de los riesgos asociados a la idea.

El Ciclo de Vida de Producto

El descubrimiento de producto y el descubrimiento del modelo de negocio son dos actividades clave que los equipos de producto realizan en las primeras etapas del ciclo de vida del producto. No hay entrega real, o muy poca, lo suficiente como para implementar alguna prueba de conceptos o prototipos de baja fidelidad. A medida que avanzamos en el ciclo de vida del producto hacia la etapa de ajuste producto-mercado (o validación), necesitamos descubrimiento y entrega, porque estás desarrollando y evolucionando el MVP pero aún estás explorando y descubriendo el producto y partes del modelo de negocio.

A medida que entramos en la fase de escalado y luego en la madurez, estarás principalmente realizando entrega, ajustando el motor de crecimiento, haciendo mantenimiento, mejorando las métricas y recibiendo solicitudes de las partes interesadas.

No obstante, siempre se requiere descubrimiento, incluso en productos maduros, lo que cambiará es la cantidad de trabajo de descubrimiento y la granularidad y el alcance de ese trabajo. El trabajo de descubrimiento necesario para desarrollar un modelo de negocio no será el mismo que el requerido para agregar una nueva funcionalidad o alcanzar un nuevo objetivo para un producto maduro.

Un Equilibrio Cambiante

En la mayoría de las organizaciones, todo el foco y casi toda la presión está en construir más cosas más rápido. Cuando tu organización comience a proporcionar la misma visibilidad al descubrimiento que a la entrega de producto, encontrarás que se comenzará a valorar más.

Cuando esta organización considera que el descubrimiento es igualmente valioso, las personas se preocupan menos cuando la velocidad de desarrollo disminuye para que una mayor parte del equipo pueda concentrarse en la velocidad de aprendizaje.

Discovery Kanban - Delivery Kanban - Ebb Flow - AKTIA Solutions

Esta necesidad de equilibrar el descubrimiento y la entrega es típica del desarrollo de un nuevo producto que requiere funcionalidades nuevas (descubrimiento) al mismo tiempo que se gestiona el riesgo general que implica desarrollar esas funcionalidades (entrega), o una startup que requiere un enfoque inicial en encontrar el ajuste problema-solución o el ajuste producto-mercado (descubrimiento + entrega) pero luego necesita desarrollar la organización para la entrega a escala (entrega).

Los sistemas Discovery Kanban funcionan en todo el ciclo de descubrimiento a partir de una necesidad o problema desatendido en el mercado, pasando a la validación de la solución y terminando en un prototipo MVP.

Del mismo modo que equilibramos la demanda de diferentes partes interesadas o proyectos en un sistema Kanban de entrega, gracias a Discovery Kanban podemos equilibrar el descubrimiento y la entrega a medida que avanzamos a lo largo del ciclo de vida del producto.

Diferencias entre Discovery Kanban y Delivery Kanban (Entrega)

Una de las tragedias del desarrollo de producto es que gran parte de lo que se construye no tiene éxito. Pero lleva tiempo aprender qué construir, y ese es esencialmente el propósito de Discovery Kanban. El propósito de Delivery Kanban es ayudar a construirlo.
Los sistemas Delivery Kanban se buscan la previsibilidad, la calidad, el tiempo de comercialización y el rendimiento. Los sistemas Discovery Kanban, en cambio, se enfocna en el aprendizaje rápido, descartando opciones y asegurándose de que siempre haya trabajo para desarrollar.

Discovery Kanban

Agile es excelente para ayudarte a gestionar lo que estás construyendo, coordinar entre equipos y realizar entregas de forma iterativa. Sin embargo, el enfoque de Agile está en la entrega de software funcionando, lo que significa que el diseño y la investigación tienen dificultades para integrarse en el proceso, creando mucha tensión, frustración y fluctuaciones en el flujo de valor.

Lo que sucede en muchas organizaciones es que crean una funcionalidad mientras se está diseñando, o los diseñadores se ven obligados a trabajar en el mismo sprint que los desarrolladores. Esto ejerce presión sobre los diseñadores para que produzcan maquetas de una funcionalidad con el fin de “desbloquear” a los ingenieros. Esta situación no da tiempo a los diseñadores para comprender el problema e iterar sobre soluciones, y no tienen suficiente espacio para recopilar datos, comprender el problema o hacer pruebas de usabilidad.

Esto también es un problema para los ingenieros, porque cuando construyes una característica mientras se está diseñando, las especificaciones cambian a medida que exploras soluciones. Esto ralentiza el proceso de desarrollo ya que los desarrolladores siempre tienen preguntas sobre qué construir, y las funcionalidades tendrán que reescribirse a medida que evolucionan los diseños. Esto también hace que sea difícil estimar cuánto tiempo llevará construir, lo que lleva a plazos vencidos, baja calidad y baja moral.

Para mejorar esta situación, debemos dividir el proceso de desarrollo de producto en dos fases: descubrimiento y entrega. En la fase de descubrimiento, el objetivo es comprender y resolver los problemas de nuestros clientes. La salida es diseños terminados que resuelven para todos los casos de uso.

Es el mismo equipo con los mismos objetivos, pero diferentes personas están trabajando en diferentes partes del flujo de valor.

Este proceso ofrece a los diseñadores e investigadores espacio para comprender los problemas de los clientes y explorar soluciones antes de comprometerse a enviar nuevas funciones. 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.

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.

Esto no es Waterfall

Por si acaso te lo estás preguntando. Esto no es waterfall. Porque hay un equipo haciendo todo el trabajo y no existen grandes lotes de trabajo. Obviamente, hay un proceso secuencial, y Kanban nos ayuda a visualizar el proceso e implementar políticas explícitas para administrar el flujo de trabajo.

Implementando Discovery Kanban

Lo que te mostraremos aquí es cómo modelar un Sistema Kanban para descubrimiento y entrega. Dónde Discovery sería la parte correspondiente a Upstream.

Este sería el caso de una organización de producto moderna en la que 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, 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 Discovery Kanban

El sistema Discovery Kanban se basa en el embudo de innovación típico: Idea – Explorar – Validar, pero también puedes implementar Problema – Solución – Producto o cualquier otro marco de innovación.

Lo importante es que modeles lo que haces, ya que ese es un principio esencial de Kanban.

El punto de entrada a 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.

Innovation Funnel - Product Discovery - Discovery Kanban - AKTIA Solutions

El Sistema Discovery Kanban 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 exploración es una idea, acompañada de información básica 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, riesgos de:

  • Cliente
  • Problemas / Necesidades
  • Mercado
  • Producto
  • Tecnología
  • Financiero
  • Modelo de Negocio
  • Legal
  • Regulaciones

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 de problemas 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 trabaja en una propuesta de valor y pueden 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, la salida son diseños terminados que están completamente pensados.

Validación

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

Aquí ya empezamos a construir un producto. Nuestra herramienta es el MVP, que es la plataforma donde se realizarán los experimentos con clientes reales.

Aunque ya estamos construyendo cosas, esto sigue siendo descubrimiento, porque estamos validando la solución, su viabilidad financiera y quizás aún algunas suposiciones técnicas.

Listo para Entrega

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

La columna “Listo para Entrega” es el búfer que conecta los dos flujos de valor. Este inventario de opciones tendrá que desglosarse en pequeños trozos de valor para entregarse de forma iterativa e incremental.

El Tablero de Discovery Kanban

Te recomendamos encarecidamente que analices el trabajo típico que hace tu equipo mientras descubre el producto y asegúrate de implementar políticas de visualización adecuadas para los diferentes tipos de trabajo en el tablero de Discovery Kanban.

Como explicamos en nuestra publicación anterior sobre Upstream Kanban, 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 lo es visualizar las opciones y tomar las decisiones apropiadas, así como asegurarse de que el flujo descendente no se quede sin trabajo.

A continuación, mostramos un ejemplo típico.

 

Discovery Kanban Board Example - AKTIA Solutions

Ten en cuenta que este tablero solo muestra una sugerencia de etapas en el descubrimiento de productos. Para representar un sistema Kanban adecuado, debes implementar todos los conceptos que discutimos en publicaciones anteriores: límite de opciones mínimas, límites de WIP, políticas, etc.

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