Contra la ortodoxia en las metodologías de producto
En los últimos años he leído, practicado y aprendido mucho sobre desarrollo y gestión de producto, proyectos, desarrollo de negocio y en definitiva todo aquello en lo que me involucro como CEO. En lo que respecta a producto, hemos evolucionado como equipo, y nos ha ayudado adoptar el trabajo con Kanban y con OKRs. No ha sido un cambio de la noche a la mañana, sino que ha sido un proceso.
Partíamos de la necesidad de definir hacia dónde estábamos caminando y de poder coordinarnos para caminar todos en la misma dirección, minimizando el ruido y las distracciones que nos hacen desviarnos del destino que buscamos. En otras palabras, OKRs para marcar nuestro horizonte y medir los avances, y Kanban para visualizar el flujo de trabajo y coordinarnos.
Sobre OKRs, a parte del archiconocido “Measure What Matters” de John Doerr, me gustó mucho “Radical Focus”, de Christina Wodtke, pues es casi una guía de cómo poner en marcha los OKRs en una empresa. Así que una vez estudiada la teoría (recomendada por nuestro board member Ritz Steytler) nos pusimos a la práctica. Y qué pasó? Pues que nos estrellamos.
La primera vez es muy difícil que salga bien. Algunas cosas a tener en cuenta:
A veces tu camino de producto/negocio es uno pero algunos fuegos pueden hacer que te desvíes de tu camino y los KRs alineados con ese objetivo queden en segundo lugar por la emergencia de apagar esos fuegos.
Cuando estás testeando cosas nuevas a nivel de negocio/producto, puede que saques conclusiones que te hagan virar el rumbo y tu KRs dejen de ser útiles.
Los KRs deberían estar ligados al negocio y ser medibles. ¿Pero qué pasa cuando justo empiezas a desarrollar algo nuevo y no tendrás un MVP en el tiempo que dure el OKR? Una posible métrica podría ser que stakeholders internos valoren el producto desarrollado; ¿pero qué pasa si es un producto hardware y no tendrás algo físico hasta pasado más tiempo?
Es complicado dar con la clave de los OKRs para que funcione a la primera. Lo importante es tener la mentalidad de mejora continua e iterar sobre lo aprendido en cada ciclo de OKRs. Dicho eso, ¿y si los OKRs que hacemos no encajan a la perfección en la teoría que explican los libros qué pasa?
Con Kanban nos pasó algo parecido. Empezamos con ello porque teníamos un desarrollo anárquico, con personas trabajando como islas, con cuellos de botella constantes y demasiadas distracciones de nuestra hoja de ruta.
Tenemos dos equipos, Embedded y Apps, y nos hallábamos en un momento en que íbamos a empezar a desarrollar un producto nuevo en el equipo de Apps y a la vez queríamos mantener el existente, tanto en Apps como en Embedded. Esto requería diferentes maneras de abordar el trabajo, pues no es lo mismo tratar de sacar un MVP, testearlo y posteriormente evolucionarlo, que mantener una solución existente. Para lo primero muchos pensarían en trabajar con Scrum, y tendría sentido, pero para lo segundo, esto no sería tan útil. Es como si tuviéramos que ser ambidiestros en ese momento. Para la adopción de Kanban nos apoyamos en un especialista Agile externo.
Primero empezamos por simplemente visualizar el trabajo realizado - el nivel 3, de operaciones. Continuamos definiendo políticas explícitas, trabajando en pull en vez de push, manteniendo un delivery constante y eliminado cuellos de botella. Luego, del segundo nivel, el de iniciativas, cuelgan las tareas, y del primer nivel, es de estrategia, cuelgan las iniciativas. Luego hemos ido evolucionando y mejorando el proceso, no sin una buena dosis de errores y cosas que podríamos haber hecho mejor, pero llegando a algo funcional.
Conclusiones
Entonces, ¿es nuestro Kanban 100% puro? No lo creo, pero el núcleo sí lo es, y mantenemos los principios, entre los cuáles están:
Trabajar en pull, no en push.
Políticas explícitas claras a todos los niveles.
Delivery constante
Sin cuellos de botella
Resumiendo, ni somos ejemplo de pureza en Kanban ni en OKRs, pero entregamos más valor ahora que antes.
¿Significa esto que las metodologías y formas de trabajo estandarizadas para desarrollo de un producto son malas y no hay que seguirlas? No. Estas metodologías son un gran avance y aprecio enormemente conocerlas. Lo que concluyo es que porque algo funciona de cierta manera a cierta organización no quiere decir que vaya a funcionar 100% igual haciendo lo mismo en otra organización, de ahí el título del artículo.
No todas las organizaciones están listas o en el estado correcto para aplicar según qué metodologías de desarrollo de producto. Habrá casos en los que podamos conseguir los mejores resultados haciendo variaciones de esas metodologías. Esto es, haciéndolas nuestras.
La mayoría de la literatura sobre estos temas se enfoca en negocios b2c o en SaaS (tanto b2b como b2c). ¿Qué pasa cuando no encajas en ese molde? Si hubiera un método perfecto para mi caso concreto, probablemente ya lo habría seguido alguien y dominaría el sector. Que tengamos que trabajar nuestros procesos da pie a que podamos trabajar mejor que los demás y podamos tener éxito. Si algo no te funciona, ¡cámbialo! Pero trata de mantener siempre los principios de esa metodología.
¿Cómo lo ves? Te leo abajo en los comentarios.