Cómo crear un sistema Upstream Kanban para crear Flow en el desarrollo de producto (I)

Cada vez más organizaciones intentan adoptar métodos ágiles con más o menos éxito. Lo normal es que el backlog de cosas por hacer sea increíblemente largo y el cuello de botella se concentre en la parte de desarrollo. ¿Qué ocurre cuando no es así?

Sorprendentemente, me he encontrado muchos casos en mi carrera en que los equipos de desarrollo han dejado de ser el cuello de botella y el cuello de botella se ha movido directamente a la parte de la gestión de producto. La respuesta más habitual es: Ah, ¿Que pueden hacer más? Pues yo se un montón de cosas que pueden hacer. Después de una transformación, las cosas ya no funcionan así. Los equipos de desarrollo van a exigir a producto el mismo nivel de cuidado y calidad que producto les ha pedido durante años.

Durante el tiempo que fuí Product Owner en SmartB, puse en marcha un proceso para mejorar la opcionalidad y racionalizar todo lo que mandábamos a desarrollo, lo que multiplicó el ROI de cada Sprint x3, creando unas oportunidades increíbles de trabajar con nuestros clientes.

Mejorando nuestra opcionalidad

Quizás es la primera vez que escuchas esta palabra. Es una traducción libre del inglés Optionality

The value of additional optional investment opportunities available only after having made an initial investment. The short-term payoff for this is modest, but the optionality value is enormous. Quality or state in which choice or discretion is allowed.

Cuando empecé a ver cómo gestionar el Producto que desarrollabamos en SmartB, me dí cuenta de que la mayoría de las peticiones venían por parte de la COO o la comercial que trabajaba con ella. Hasta ese momento, ella decía: Hay que hacer A y A era lo que había que hacer. Las primeras conversaciones con clientes hicieron que pusiera en duda que esa fuera la estrategia correcta.

Relacionado
Agile tiene cuatro veces mas posibilidades de éxito que Waterfall

Empecé a elaborar una manera de decidir, económicamente, si nos merecía la pena desarrollar unas opciones u otras. El problema es que realmente había pocas opciones. Un viejo Roadmap desactualizado y una comunicación con el cliente no muy fluida. No tenía muchas herramientas.

Tenía que buscar una manera de incrementar nuestro pool de opciones.

Aplicando Lean Startup

Me enamoré de Lean Startup hace muchos años. Sin embargo, lo he visto como un proceso que puede ser muy desestructurado, debido principalmente a que requiere unos feedback loops -oportunidades de inspeccionar y adaptar- y un trabajo metódico para que realmente aporte valor.

Hay dos dominios que me interesaban especialmente: ¿Por qué desarrollar algo para un cliente si ni siquiera tengo idea de si es lo que necesita? Éste es el primer dominio: Buscar una Solución a un Problema (Problem/Solution fit). El segundo dominio es, una vez encontrada una solución y validada con el cliente, ver si existe un mercado para la misma (Product/Market fit). Por último, una vez que hemos valorado que existen estos dos requisitos, podemos poner en marcha toda la maquinaria de desarrollo e inversión.

En caso contrario, simplemente podemos descartar esa opción y buscar otra. La inversión que hemos hecho ha sido mínima y hemos reducido nuestro riesgo. ¿Cómo podía aplicar esto al día a día?

Innovation Games

Tenía que buscar feedback adecuado de los clientes para ver por un lado si podíamos buscar soluciones a sus problemas y por otro lado, si las soluciones que desarrollábamos eran viables -económicamente hablando- de cara a justificar una inversión en algo más que un prototipo.

Innovation Games es el material perfecto para esto. Montones de workshops ya preparados y orientados a crear engagement con el cliente y extraer la información que teníamos de ellos. Hicimos un primer workshop de prueba en el que presentamos soluciones a problemas que habíamos identificado en nuestros clientes, además de presentarles nuestro backlog y dejar que ellos lo priorizaran con buy a feature.

Una jugada arriesgada que contó con poca presencia pero una discusión muy productiva. Nuestros clientes también son nuestros Stakeholders e involucrarlos en el proceso tuvo un efecto muy positivo para todo el mundo.

Relacionado
Los 10 libros ágiles fundamentales

El siguiente paso era buscar la manera de automatizar todo el proceso. Eso lo veremos en el siguiente post.

Posted by Jerónimo Palacios Vela

Mi misión es ayudar a mejorar la profesión del desarrollo de software. Soy Professional Scrum Trainer de Scrum.org, Accredited Kanban Trainer de Lean Kanban y facilitador de LEGO® Serious Play. Vivo entre Berlín y Granada. Me encantan la vela y el Rugby

  1. Emilio Correa Gonzalez Febrero 9, 2017 at 3:57 pm

    Muy interesante tu exposición.

    Hace algún tiempo que me hice con un ejemplar de innovation games, aunque reconozco que aun no he profundizado en el.

    Un saludo.

Comments are closed.

Suscribete a nuestra lista de correo

Suscribete a nuestra lista de correo

Recibe actualizaciones en la comodidad de tu bandeja de entrada. Un email a la semana. Sin Spam. Sin Trucos.

Suscripción con éxito

Shares
Share This