La agilidad no ha parado de extenderse en los última década e incluso las organizaciones que miraban con recelo todo este movimiento están dando sus primeros pasos y viendo cómo pueden sumarse aumentando así su competitividad. ¿Cómo está conviviendo en estas compañías mentalidades tan diferentes? ¿Cómo están respondiendo los Product Owners a las necesidades? (Extra: ¿qué es la transformación digital?)
Emma es una project manager en una gran compañía. Una telco internacional que solo en España cuenta con más de 10.000 trabajadores entre internos y externos. Ella trabaja en la parte que en su empresa llaman legacy. En otras muchas organizaciones esta parte de la compañía la llaman waterfall o tradicional. Trabajan como siempre lo han hecho y ahora tienen que convivir con una parte “agile” (el uso de las comillas no es una casualidad) que ha surgido en la compañía y ha empezado a trabajar de otra manera.
Para gestionar la parte que le toca en toda esta gran maquinaria, Emma necesita cuadrar dependencias, esfuerzos y fechas. Cuando interactúa con equipos que están en la party legacy de la empresa se entienden correctamente. Todos hablan el mismo idioma. Pero cuando se dirige a las nuevas estructuras ágiles y sus Product Owners recibe un: “No tenemos fecha concreta. Nosotros trabajamos en agile, así que no tenemos fechas”. Emma está frustrada y, con razón, duda sobre la operatividad – e incluso la profesionalidad – de los equipos ágiles.
La planificación (continua) es la clave
Existe un falso mito alrededor de la agilidad y la planificación. Analicemos por encima Scrum:
- El Product Backlog contiene el futuro del producto. Debe estar ordenado, refinado, estimado y con él es sencillo conocer cuáles serán los siguientes pasos.
- En la Sprint Planning se crea un plan para alcanzar nuestro Sprint Goal durante el Sprint.
- La Daily Scrum es un evento para crear un plan de las siguientes 24h, una vez inspeccionado como va el plan del Sprint.
- La Sprint Review es un evento de negocio que pertenece al Product Owner dónde se analiza la situación actual del producto, del mercado, obtendremos feedback de los Stakeholders y re-planificamos el futuro de nuestro producto y lo plasmamos en el Product Backlog.
- La Sprint Retrospective es una oportunidad para el Scrum Team de planificar acciones de mejora en el Definition of Done, procesos, herramientas o personas.
Como podemos comprobar existe una planificación continua. La clave del éxito de la agilidad en entornos complejos no reside en la falta de planificación. Reside en darle más importancia a la planificación en sí misma, a las conversaciones, a la transparencia que subyace tras cada planificación que al plan en sí mismo y estar dispuesto a actualizar el plan con cada nuevo descubrimiento que nos pueda aportar una ventaja competitiva. (Extra: Cómo Scrum nos ayuda a alcanzar la agilidad de negocio)
Planificando tendré oportunidad de adaptación
Tener una planificación es básico para poder desarrollar un producto o un servicio de forma profesional. El tipo de respuestas que se ven en desarrollos “ágiles” como el que le daban a Emma “Es que trabajamos en agile y no sabemos cuándo vamos a tener nada” demuestra que no es un desarrollo agile en absoluto y falta product ownership. Es un desarrollo donde se está improvisando. Improvisar y adaptar no es lo mismo. Inspeccionar y adaptar es la clave de la agilidad y eso solo puede ocurrir cuando tengo un plan y soy capaz de modificar mi plan según las necesidades del mercado o del desarrollo.
Una respuesta a Emma en un entorno ágil podría ser: “Emma, con lo que sabemos hoy y con los datos históricos que tenemos, creemos que estará este día X. Cada dos viernes es nuestra Sprint Review y damos transparencia sobre la situación que tenemos y siguientes pasos. Pásate si estás interesada. Además, en este lugar puedes visitar nuestro Product Backlog y release plan actualizado”. Bastante diferente, ¿no crees?
La falta de Product Ownership
Según mi experiencia el gran mal que azota a las empresas es la falta de liderazgo del producto. Muchas llamadas comienzan con “es que no sale el trabajo”, “es que los equipos no están comprometidos”, “es que no se hacen las cosas bien”.
Cuando escarbas descubres que no existe nada relacionado con la gestión del producto (métricas de valor, releases maps, estrategia y visión de producto alineada con estrategia y visión de compañía) o gestión de la demanda. Esto hace que todo el mundo corra, pero en círculos. Todos están exhaustos, muchas horas trabajadas, mucha presión y nada de valor generado. ¿Os suena esta sensación que todos hemos tenido?
En muchos casos puedes ver un Agile Coach que corre a trabajar para que el equipo esté unido, tengan dinámicas divertidas y buena comunicación. En mi experiencia puedo decir que me he cruzado con equipos con más necesidad de tener una gestión de producto bien aterrizada, profesionalizada y bien ejecutada que con necesidad de mejorar sus interacciones sociales. Eso es algo que se alcanza cuando el equipo (incluyendo al Product Owner) se relacionan alrededor de un objetivo claro y ponen todo su conocimiento y esfuerzo al servicio del beneficio de sus clientes y, por tanto, del revenue para la empresa.
El empoderamiento del Product Owner
Un Product Owner de una gran aseguradora se quejaba de que no tenía ningún tipo de poder de decisión sobre el producto, que le gustaría poder tomar más decisiones y tener más responsabilidad. Yo le pregunté que dónde podría ver sus diferentes horizontes de planificación, sus futuras entregas a los clientes y como esperaba que esas entregas impactaran en las métricas de negocio. “No tengo nada de eso” fue la respuesta.
Para crear productos de alto valor el Product Owner debe estar empoderado. Y aquí hay un contrato de dos partes. La empresa, claro está, debe darles capacidad de maniobra y libertad. Pero no hay que olvidar que el Product Owner debe ganarse la confianza. Tener al menos una visión de producto, un roadmap, un release map y qué métricas vamos a tomar para ver si el valor del producto es el esperado, eso es básico. Sentarse a pedir más responsabilidad con todo este plan bajo el brazo suele ser más sencillo.
Conclusion
El Product Ownership brilla por su ausencia en el desarrollo ágil de productos. Esto nos lleva a falta de planificación e improvisación que suele terminar en desastre. Este “Product Management Vacuum” ocasionado, en muchas ocasiones, por tener Product Managers (o Product Owners) más enfocados en gestión de personas, en planes de proyecto y en cumplir hitos que en tener una visión, generar valor y validar que, con los usuarios reales, que esto está ocurriendo.
El foco de un Product Owner debe estar en las tres V: Visión, Valor y Validación. Una vez que tengamos esto, podemos empezar a trabajar en un desarrollo ágil de producto que permita alcanzar agilidad empresarial a toda la organización.