Cuatro retos importantes de la administración del producto en la Transformación Ágil
Incorporar Scrum / Agilidad en las organizaciones no es tarea fácil; es bien conocido que Scrum es fácil de entender, pero difícil de dominar. Normalmente esta adopción conlleva que las personas piensen de manera diferente, que el equipo se auto-administre y estime su trabajo, no hay un líder administrando el proyecto y siempre damos la bienvenida al cambio; todo esto a diferencia de los proyectos tradicionales. Aunado a todas estas nuevas formas de trabajo, tendremos que incorporar a una persona que represente al negocio y que sea capaz de tomar decisiones importantes relacionadas con el producto que vamos a construir. A este rol lo llamamos el “Product Owner (Dueño del Producto)”.
En mi opinión personal, incorporar este rol es uno de los retos más grandes en las empresas que desean aventurarse en hacer una transformación ágil, y es por esto que quiero compartir los retos comunes a los que me he enfrentado y las recomendaciones que deben tomar en cuenta.
1. NO HAY UNA COMUNICACIÓN CLARA HACIA LAS ÁREAS DEL NEGOCIO
Es común ver que al comenzar un proyecto de transformación ágil se busca arrancar rápido para terminar lo antes posible y así cumplir con las metas anuales que estableció el negocio. La realidad es que una transformación ágil no funciona así, y es común ver que por querer hacer las cosas rápido solo se involucra al área de TI y no a las áreas de negocio (Comercial, Legal, Finanzas, Capital Humano, entre otras), las cuales son clave para la correcta adopción.
RECOMENDACIÓN
Ten como prioridad en todo momento planear pláticas con las áreas del negocio en donde se expliquen los beneficios de que dichas áreas sean parte del proyecto de transformación, dejando clara su responsabilidad y cómo este involucramiento llevará al éxito de la trasformación. Es común que al inicio no tengan el interés de asistir, pero si dejamos claro los beneficios de trabajar de esta nueva forma, garantizo que se sumarán al esfuerzo. Recomiendo de igual forma invitar a la dirección general, de sistemas y del negocio a estas reuniones para tener un mayor impacto.
2. NO SE CUENTA CON UN PRODUCT OWNER DESDE EL INICIO DEL PROYECTO
Otro problema que viene relacionado al anterior, es que al no involucrar al negocio en la transformación ágil, no contamos con su apoyo y por consecuencia, las áreas de sistemas terminan asignando a un “Analista de Negocios” o a un “Analista de Sistemas” para desempeñar el rol de Product Owner. En lugar de tener al experto con el empoderamiento para tomar decisiones, tenemos a un “Proxy Product Owner” que quizás no tenga todo el conocimiento del negocio y no necesariamente tenga la autoridad para tomar decisiones importantes ocasionando cuellos de botella y desmotivación en el equipo.
RECOMENDACIÓN
Es recomendable identificar desde el inicio Product Owners que tengan el tiempo y el interés de participar en los primeros proyectos pilotos de la transformación ágil. Podríamos decir que hay que realizar la tarea de encontrar a los “Early Adopters” que administrarán los productos piloto. Crea un perfil para este rol usando herramientas como los moving motivators, 16personalities, checklists con características del perfil, entre otros, e involúcralo desde el inicio del proyecto.
Aunque no es sencillo contar con un Product Owner que realmente sea el “Cliente / Usuario Final”, hay que tratar de no tener “Proxy Product Owners”. Siempre será mejor contar con un Product Owner que sea parte del negocio y que pueda tomar decisiones clave.
3. EL PRODUCT OWNER SIN TIEMPO
Una vez que logramos conseguir que el equipo del negocio (quienes realizan las solicitudes de nuevos productos) se sume a la iniciativa, el siguiente reto es separar su tiempo para que ayuden al equipo de desarrollo a resolver dudas, crear historias de usuario, desarrollar la visión del producto, entre muchas otras cosas. Es común escuchar “no tengo tiempo, la operación ya me consume demasiado” y aunque pareciera que es un miembro más del equipo, realmente nunca está disponible.
RECOMENDACIÓN
Si el Product Owner no tiene el tiempo suficiente para apoyar en la creación del producto, es recomendable llevar a cabo las siguientes tres acciones:
- Hacerle ver la importancia de su participación.
- Negociar al menos atender al equipo de desarrollo 1 hora al día para resolución de dudas.
- Contar con un intermediario transversal que más que Proxy Product Owner, tenga un rol de apoyo al Product Owner y que esto sea claro para el equipo.
4. EL PRODUCT OWNER NO CONOCE DE AGILIDAD
En otros proyectos me ha tocado ver personas muy capaces que encajan bien en el rol. El inconveniente es que el equipo responsable de realizar la transformación ágil en la empresa, no invirtió el tiempo necesario en capacitar a esta persona para que pueda desempeñar su función tomando en cuenta la nueva forma de trabajo por iteraciones, la priorización del Backlog, su responsabilidad creando historias de usuario y la relación directa con el equipo de desarrollo.
RECOMENDACIÓN
Es necesario capacitar a las personas que fungirán de Product Owner previo al arranque de los proyectos piloto en la transformación ágil. La recomendación es comenzar con algunas de las siguientes capacitaciones:
- Conceptos de la Agilidad y marco de trabajo.
- Valores, Principios y Mindset Ágil.
- Como crear el Roadmap, la visión del producto y priorizar el Backlog.
- Como crear historias de Usuario.
Aunque podemos realizar más capacitaciones, creo que estos puntos son de gran importancia para para comenzar a trabajar en un proyecto piloto.
Querer realizar una transformación ágil en la organización sin la figura de Product Owner es complicado y traerá riesgos a la iniciativa. Hay que darnos el tiempo de identificar bien a la persona que tomará este papel e involucrarla desde el inicio, ya que como dice Roman Pichler guru en administración del producto: “innovation requires dedication, hard work, and discipline.”
