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.

Empecé a elaborar una m