martes, 4 de mayo de 2021

Nuestro Product Owner NO cumple con sus responsabilidades ¿qué podemos hacer?

La respuesta rápida y fácil a una situación en la cual el Product Owner (PO) no acepta o no favorece la aplicación del enfoque ágil es: "no podemos aplicar el enfoque ágil". Sin embargo, esta decisión es demasiado radical, esta situación desfavorable aunque supone limitaciones, no tiene por qué implicar no aplicar nada del enfoque ágil. Para consuelo, la buena noticia es que en esta situación al menos tenemos identificado al PO :-), pues siempre será peor no tenerlo claramente identificado. La definición e importancia del PO la podéis consultar en mi post "Se busca Product Owner ...".
Para evaluar el impacto de tener un PO que no cumpla con sus responsabilidades podemos repasar las prácticas ágiles que están estrechamente asociadas al PO, analizando qué supondría que su participación no fuese la esperada, y ver hasta qué punto se pondría en riesgo la efectividad una práctica, y por ende una menor eficacia de la transformación ágil. 

Tomaré como referencia las prácticas ágiles de nuestro catálogo Agilev-Roadmap (en este enlace encontraréis la lista de prácticas y una explicación de cada una de ellas) y comentaré qué prácticas ágiles podrían verse más directamente afectadas por no contar con un PO "óptimo" según la definición de sus responsabilidades, y daré además algunas recomendaciones al respecto.

PRA01. Promover la sencillez en todos los aspectos. Ofrecer la solución más simple y mínima que pueda ser satisfactoria para el cliente. Estrategia MVP, y PRA02. Abordar trabajo de forma incremental.
Comentemos estas dos prácticas en conjunto pues están estrechamente relacionadas. Si el PO solo ve como alternativa las opción más ambiciosa en cuanto a todas las características del producto y/o en cuanto a cada una de ellas, es muy complicado llevar a cabo un desarrollo incremental del producto. En cada incremento del producto tendremos características grandes (Épicas) que por dicha ambición dejarán poco espacio para incluir otras características. Esto es extensible al global del proyecto, es decir, será difícil poder desarrollar todas las características cumpliendo con las restricciones de plazos y costos. El equipo de desarrollo puede intentar ayudar en esta reflexión al PO para conseguir acotar el alcance del proyecto y de cada característica, sin que la solución sea insatisfactoria, pero la decisión y responsabilidad en última instancia es del PO. 

PRA03. Realizar entregas frecuentes de unidades de trabajo terminadas.
Si el PO NO acepta que se hagan entregas parciales y solo quiere poner en producción el producto una vez esté totalmente terminado se acumularán riesgos hasta ese momento. Las entregas frecuentes (parciales) permiten validar que el proyecto va en buena dirección y no se aumenta la tensión hacia el final cuando ya queda poco margen de reacción. No es solo una cuestión de validar que estamos construyendo el producto correcto para el usuario final, sino de detectar posibles inconvenientes "externos" de forma oportuna, por ejemplo: carencias de infraestructura, de formación de los usuarios, desafíos de integración con otros sistemas, problemas de migración desde sistemas actuales, etc. Todos estos elementos suelen presentar imprevistos que a veces son difíciles de prever y necesitan esa entrega parcial para ponerlos en evidencia. Una entrega parcial no tiene por qué ser un paso a producción como tal, sino que si esto no es posible o recomendable podemos acotarlo a, por ejemplo, un paso a un entorno de preproducción donde usuarios potenciales lo prueben, o una versión Beta disponible, o un paso a producción para un conjunto acotado y controlado de usuarios.     

PRA04Realizar reuniones de planificación (y replanificación) frecuentemente (frecuencia de pocas semanas no meses). Planning Meeting.
En las reuniones de planificación el PO acuerda con el equipo el trabajo que espera que se complete en un cierto período de tiempo (en un Sprint o en el Proyecto). Además, en estas reuniones el equipo puede resolver dudas respecto de cada ítem de trabajo para asegurarse que lo interpreta correctamente. De esta forma el PO se hace protagonista en cuanto a las decisiones de negocio. Si estas reuniones de planificación no se realizan con la frecuencia necesaria se corre el riesgo que el equipo asuma decisiones de negocio y/o se vea bloqueado para continuar esperando que se establezca o confirme la planificación. En contextos de trabajo poco planificables, por ejemplo, en mantenimiento de aplicaciones (donde con frecuencia lleguen imprevistos y de carácter urgente), puede que en lugar de reuniones de planificación sea más efectivo que el PO establezca pautas detalladas respecto a priorización y forma de actuar ante los ítems de trabajo que llegan al equipo, de forma que no se requiera la intervención del PO salvo para excepciones. Si el trabajo es más bien planificable (tendrá  sentido invertir tiempo en planificar pues normalmente esa planificación no cambia significativamente) se pueden establecer la fechas de fin de Sprint con antelación, de forma que intentemos garantizar la participación del PO en esas fechas. 

PRA09. Gestión continua y multicriterio del trabajo pendiente para que esté siempre debidamente priorizado. Gestión del Backlog.
El PO por definición es quien debería gestionar el Backlog pues allí están ordenados todos los ítems de trabajo que irán incrementalmente completando el producto, todo desde una perspectiva principalmente de negocio, aunque podría tener ciertos condicionantes técnicos recomendados por el equipo de desarrollo. En esta gestión del Backlog suele ser necesario que el equipo le ayude al PO a identificar y organizar los ítems del Backlog, pero con la confirmación el PO para que esto no conlleve que el equipo tome decisiones de negocio.

PRA17. Product Owner en estrecho contacto con el equipo y altamente disponible.
Aparte de las reuniones programadas con el equipo (Reuniones de Planificación y Reuniones de Revisión) el PO debería estar altamente disponible para resolver dudas y validar el trabajo del equipo de desarrollo. La no disponibilidad provocará posiblemente bloqueo en algún ítem en el que se está trabajando y obligará a trabajar en otro ítem menos prioritario mientras se resuelva dicho bloqueo. Además, las interrupciones asociadas a dejar un ítem sin finalizar y luego retomarlo para continuar perjudican el rendimiento del equipo. Se deben establecer canales y protocolos de comunicación que reduzcan al máximo la espera del equipo por disponibilidad del PO, aunque no necesariamente tenga todo que resolverse por reuniones presenciales con el PO, hay que tener aprovechar también mensajería instantánea, comunicación telefónica y videoconferencias, todo en su justa medida respecto de lo que se requiere comentar con el PO.

PRA18. Perfil cliente del Product Owner. Una persona que prioriza el trabajo del equipo y es un buen representante de los clientes/usuarios.
Scrum define con precisión el perfil esperado del PO, que además de una persona (no un comité) requiere ser un buen representante de la parte cliente (y usuarios), y ojalá con un nivel de autoridad en ellos para impulsar el uso del producto. Si el PO no cumple con estas características puede ser un gran inconveniente puesto que podría orientar el desarrollo del producto en una dirección incorrecta, que no satisfaga las reales necesidades de los usuarios. Por esto, si el PO tiene ciertas debilidades al respecto tendrá que hacer un esfuerzo por buscar apoyos en la parte cliente que complementen su perfil pero manteniendo su papel de PO hacia el equipo de desarrollo, es decir, que esta situación sea lo más transparente posible para el equipo.  

PRA19. Realizar reuniones de revisión del trabajo entregado. Review Meeting.
Similar a los que sucede con las Reuniones de Planificación, en las Reuniones de Revisión el equipo necesita la participación del PO para validar el resultado (aunque aun sea parcial) de su trabajo. Además, estas reuniones deberían también servir para mantener la motivación del equipo cuando el PO confirma que su trabajo está siendo satisfactorio. No debería ser un problema asegurar la participación del PO en estas reuniones si se establece con bastante antelación las fechas de finalización de los Sprints, al menos de los más próximos. Desgraciadamente, en muchos casos, y particularmente cuando se trata de la revisión de una versión que pasará a producción, una revisión detallada no es factible hacerla en puntualmente en una reunión, y requiere que la confirmación del PO se realice después de que haya aplicado pruebas interactuando con la aplicación en un entorno de preproducción. Lo importante es intentar que el equipo de desarrollo no tenga que seguir avanzando mucho más que el próximo Sprint sabiendo que hay una versión de Sprint anterior aún por confirmar en cuanto a posibles flecos. De no ser así, y teniendo varias versiones por confirmar, la gestión de cambios puede complicarse y añadirse ruido durante los Sprints por incorporación tardía de flecos de versiones previas. 

PRA21. Jefe de carácter líder y facilitador en lugar de actitud del jefe autoritario y controlador. Perfil gestor del Product Owner.
Así como el PO debe tener un perfil de cliente, también debe tener un perfil de gestor del trabajo (o del proyecto). Entre las responsabilidades que propone Scrum para el PO encontrados típicas tareas realizadas por un Jefe de Proyecto en cuanto a la gestión de alcance, plazos y costos. Sin embargo, por otra parte se enfatiza que el equipo debe autogestionarse en lo técnico. Por lo tanto, se necesita un PO que sea líder y facilitador más que un jefe autoritario, pues de lo contrario afectaría dicha autogestión que se espera del equipo en cuanto a decisiones técnicas. Es un gran desafío en una transformación ágil la conversión del típico Jefe de Proyectos hacia un perfil acorde con lo que se esperaría de un PO y/o de un Scrum Master. En el caso de PO, ya no debería existir esa autoridad vertical en cuanto a los aspectos técnicos, solo se mantendría en cuanto a las decisiones de negocio y a la gestión del trabajo desde esta perspectiva. En el caso de una conversión hacia Scrum Master, es más desafiante aun pues además de transformarse en apoyo (sin relación de autoridad ni en lo técnico ni en lo de negocio), requiere para ello un profundo conocimiento y experiencia en el enfoque ágil y cómo llevar a cabo la trasformación ágil del equipo.

PRA24. Establecer y comunicar al equipo la visión del producto o servicio y reforzarla regularmente.
Este es otro ingrediente del perfil PO que es muy importante para la orientación del trabajo del equipo de desarrollo. El PO puede mantener el compromiso y motivación del equipo comunicando de forma efectiva su visión del producto y  su estrategia respecto a cómo abordar su desarrollo incremental. Especialmente cuando se producen cambios de prioridades, postergaciones o interrupciones es importante que se expliquen al equipo para mantener alineada la visión técnica con la visión de negocio. Además, el equipo necesita pistas para poder discriminar en su inversión de esfuerzo qué ítems son más críticos para el negocio, y a ellos dedicarle más esfuerzo, ya sea en especificación, en programación y/o en pruebas.  

PRA27. Trabajo centrado en satisfacer pruebas de aceptación acordadas con el Product Owner.
El criterio de éxito al terminar un ítem de trabajo debería estar establecido por la satisfacción de sus pruebas de aceptación, pruebas que el mismo PO podría comprobar, pues se refieren al comportamiento del producto desde una perspectiva externa, de uso del producto. Es más, las propias pruebas de aceptación deberían ser la parte esencial de la especificación de requisitos del producto y según esto deberían estar establecidas antes de llevar a cabo el trabajo de ejecución/implementación de un ítem. n un entorno ideal es el propio PO quien debería especificar en suficiente detalle cada ítem de trabajo que ejecutará el equipo de desarrollo. Sin embargo, lo usual es que el equipo ayude al PO a establecer esta especificación de requisitos y especialmente las pruebas de aceptación que comprobarán que el trabajo realizado ha sido satisfactorio. Cuando no se establecen claras pruebas de aceptación quien ejecuta el trabajo no tiene un "contrato" con lo cual se corres el riesgo de hacer más o menos de lo que se espera. Las pruebas de aceptación acotan el trabajo que debe realizarse. Además, obviamente sirven de guía en para comprobar exhaustivamente que el resultado obtenido es satisfactorio.     

Comentarios finales
Hemos analizado 10 de las 42 prácticas del catálogo Agilev-Roadmap, las más estrechamente asociadas a responsabilidades del PO. Las 10 prácticas son muy importantes de cara a conseguir un mayor y mejor resultado en la transformación ágil. El no poder aplicarlas o no al menos de forma total supondrá una merma en la efectividad de la metodología pero no conlleva que no aplicar el enfoque ágil en su totalidad. Además, como hemos comentado, hay algunas medidas que pueden contrarrestar deficiencias en el PO. Por otra parte, las otras 32 prácticas tienen independencia del desempeño del PO y pueden ser aplicadas por el equipo y con el apoyo del Scrum Master.

"Ser ágil es aplicar prácticas ágiles", mientras más y con más intensidad se apliquen mejor. Pero cuántas prácticas se apliquen y en qué intensidad se aplique cada una de ellas es una cuestión que depende del contexto de trabajo (no todas las prácticas pueden/deben aplicarse). Además, también dependerá del punto en el cual se encuentre la transformación ágil, pues la transformación ágil es un proceso, debería ser incremental, pues cada práctica conlleva sus desafíos y refinamientos durante su implantación (lectura recomendada: ¿Revolución o evolución hacia la agilidad? ¿Cuál es tú estrategia de Transformación Ágil? ).

No hay comentarios:

Publicar un comentario