En el artículo anterior explicaba cómo, a raíz de mi trabajo como Product Owner en una startup de energía, me vi abocado a tener que mejorar la predictibilidad de nuestras opciones para mejorar el retorno de inversión en nuestro producto. Ésta es la segunda parte de ese artículo.
Una vez que ya había conseguido tener opciones para mejorar la identificación de ideas potenciales y su puesta en marcha en algún Sprint, me encontré con un nuevo problema: Las ideas venían en rachas. Cuando teníamos customer workshops. En congresos de energía. Después de una nueva release. Al publicar un paper sobre NILM. Eso hacía muy difícil priorizar, especialmente ahora que teníamos claro cuál era la capacidad de entrega del equipo.
Kanban al rescate
Lo primero era ser capaz de visualizar todo el flujo de trabajo hasta que finalmente convertíamos una idea en Software. El objetivo no era hacer una idea detallada, sino optimizar el gasto en desarrollo. Al fin y al cabo, una startup tiene que buscar maneras de mejorar el rendimiento de cada euro que gasta.
La visualización funcionó… al principio. Lo que era una gran idea se convirtió en una pila de trabajo que iba aumentando exponencialmente y en la mayoría de los casos, nunca teníamos una definición concreta ni una validación por parte del cliente de muchas de las ideas. Así que introdujimos límites WIP.
Eso provocó que nuestro foco cambiara radicalmente. El objetivo ya no era identificar muchas ideas, sino centrarnos en validar las que ya teníamos en marcha. Nuestro tablero tenía varios estados: Problema, Descripción, Posibles Soluciones, Mockups y Validación con el cliente. Con esto cubríamos el dominio de Problem/Solution fit de Lean Startup. Al final del ciclo, cuando teníamos cuatro o cinco, hacíamos un workshop con clientes para presentarles las soluciones y saber si íbamos en la dirección correcta.
Llegados a este punto merece la pena comentar que llegábamos aquí sin haber hecho una línea de código. Teníamos muy claro que el desarrollo es, con diferencia, la parte más costosa del desarrollo de producto. Y no queríamos poner un euro en algo que no sabíamos si era lo que el cliente quería.
Introduciendo una segunda fase en el desarrollo de producto
Uno de los primeros problemas que descubrimos al empezar a usar este sistema era que las soluciones que encontrábamos para problemas que tenían nuestros clientes no siempre eran viables. Desarrollarlas costaría mucho, o técnicamente eran complicadas, así que teníamos que introducir una segunda validación dentro del acercamiento de Lean Startup: El Product/Market Fit.
Este segundo marco de validación está orientado precisamente a que cuando descubrimos una solución para un problema, realmente es viable y podemos llevarla al mercado. Para ello, creamos una segunda capa dentro de nuestro sistema kanban para esto. Ahora los pasos del workflow eran distintos: Análisis de mercado, desarrollo de KPIs, plan preliminar de Marketing y Comercial, User Story Mapping y por último, construir un prototipo. Dentro de cada uno de estos pasos, establecimos unas políticas distintas. Quizás la más interesante es que construir el prototipo nunca podía llevar más de un Sprint, lo cual nos permitía tener la inversión controlada.
Upstream Kanban explicado con detalle
De nuevo, tuvimos una mejora sustancial del control de lo que terminaba en desarrollo. Descubrimos un nuevo problema: Limitar el WIP al principio nos facilitó enfocarnos, pero las cosas no fluían bien a lo largo del proceso. Tendían a acumularse cosas sin terminar mientras que otros estados estaban completamente vacíos.
Así que cambiamos el enfoque del WIP: En lugar de tener un máximo de trabajo en curso, tendríamos un mínimo. Así, siempre buscábamos llenar el WIP, lo cual aseguraba un flujo de trabajo constante que desembocaba en nuevas features para nuestro producto.
Si quieres leer más sobre este enfoque de manera más detallada, puedes consultar este artículo de Patrick Steayert en el blog de Kanbanize.
Métricas del proceso
Una de las consecuencias inesperadas de todo este proceso es que nos permitió empezar a medir y a gestionar nuestro ciclo de vida de producto de principio a fin. Así, podíamos extender o reducir el número de cosas en el pipeline dependiendo de la capacidad de entrega del equipo de desarrollo. En alguna ocasión, llegamos a tener un lead time de 29 días, desde que ideamos una feature hasta que la pusimos en producción.
También nos permitió entender cual era la economía de nuestro producto y mejorarla de forma continua. Además de todo lo que he contado hasta ahora, introdujimos un proceso automático que, mediante un test A/B mostraba la nueva feature prototipada a un número de usuarios y analizaba su comportamiento, lo que luego nos permitía comprobar si estaban dispuestos a pagar por ella, algo que para nosotros era una métrica de éxito.
Conclusiones
Al tiempo de tener este proceso en marcha, uno de los desarrolladores, que había entrado como becario en la empresa después de la universidad, me dijo: Es impresionante cómo has conseguido afinar y medir el ciclo de vida de nuestro producto y convertir las decisiones en datos. Como curiosidad, este desarrollador dejó unos meses más tarde la empresa… para volver 15 días después porque lo que había visto en el otro lado no tenía nada que ver.
El gran problema que sufren las organizaciones modernas es la incapacidad de realizar todo este proceso de adaptación y mejora continua. En lugar de eso, se centran en variables circunstanciales que no informan de nada para tomar decisiones.
[…] 2017 también publiqué un artículo sobre el uso de Upstream Kanban para tratar este […]