En el año 2012 publiqué un par de posts asociados a los roles propuestos por Scrum: "Roles de Scrum Parte I y Parte II". Me parece que todavía este tema de los roles no termina de estar adecuadamente resuelto en la práctica, y en especial el rol de Product Owner (PO).
Respecto del rol PO mi posición es bastante radical: pienso que no tiene sentido poner un equipo a trabajar si no se ha establecido un buen PO que asegure que el esfuerzo invertido por el equipo será rentabilizado (una de las responsabilidades del PO). Pero por otra parte, reconozco que es muy difícil conseguir el PO ideal. En este post comentaré cómo se puede implementar rol de PO en el mundo real, y que sin ser el PO ideal, puede ser eficaz. Comencemos con la siguiente definición de PO, que he traducido desde la Scrum Guide (visitada en abril de 2019).
--------------------------------------
"El Product Owner es responsable de maximizar el valor del producto resultante del trabajo del Equipo de Desarrollo. El cómo conseguir esto puede variar significativamente dependiendo de la organización, de los equipos, y de las personas.
El Product Owner es la única persona responsable de gestionar el Product Backlog. La gestión del Product Backlog incluye:
- Expresar claramente los ítems del Product Backlog;
- Ordenar los ítems del Product Backlog para el mejor cumplimiento de objetivos y misiones;
- Optimizar el valor del trabajo que realiza el Equipo de Desarrollo;
- Asegurar que el Product Backlog es visible, transparente, y claro para todos, y en qué es lo trabajará próximamente el Equipo Scrum;
- Asegurar que el Equipo de Desarrollo entiende los ítems del Product Backlog al nivel necesario;
El Product Owner puede hacer todo este trabajo, o puede dejar que lo haga el Equipo de Desarrollo. Sin embargo, el Product Owner sigue siendo el responsable de ello ("remains accountable").
El Product Owner es una persona, no un comité. El Product Owner puede representar los deseos de un comité respecto del Product Backlog, pero quienes quieran cambiar la prioridad de un ítem en el Product Backlog deben dirigirse al Product Owner.
Para que el Product Owner tenga éxito, toda la organización debe respetar sus decisiones. Las decisiones del Product Owner se hacen visibles en el contenido y ordenamiento del Product Backlog. Nadie puede forzar al Equipo de Desarrollo a trabajar en otros requisitos (fuera del Product Backlog). ".
------------------------------------
De esta definición remarcaría que el PO ideal de Scrum es una sola persona, que en la práctica desempeña tres roles tradicionales:
- Es un buen Cliente. Tiene autoridad para hacer respetar sus decisiones respecto de contenido y orden de realización del trabajo. Tiene visión del resultado esperado y del valor que aportará.
- Es un buen Jefe de Proyecto. Realiza la planificación y seguimiento del trabajo.
- Es un buen “Analista”. Explica con suficiente detalle el trabajo que debe realizar el equipo.
De esta forma, ya podemos hacernos una idea de lo difícil que puede ser encontrar al PO ideal. Aunque Scrum en su definición deja la posibilidad que el PO delegue sus tareas al equipo, pero no debe dejar de ser responsable de ellas. Esto no resuelve el hecho que el PO debería ser una sola persona. Desgraciadamente este PO como una sola persona no la he encontrado en ninguna empresa :-).
En el mundo real lo que hemos podido establecer como una solución eficaz, aunque no ideal, es componer la figura de Product Owner sumando a varias personas que deben trabajar muy coordinadamente. Un ejemplo de esta situación se ilustra en la siguiente imagen.
Como se observa en este ejemplo, el PO se ha compuesto por cuatro personas en sus roles tradicionales. El representante de la "Parte cliente" y que tiene autoridad sería el Product Manager, pero probablemente no tiene suficiente tiempo (ni ganas) de definir las UT a un nivel de detalle necesario para para el equipo, ni para ordenar el trabajo. Así, el Analista de Negocio se encargará de proporcionar dicha información y priorizarla, pero probablemente no podrá hacerlo en los términos técnicos requeridos por el equipo, con lo cual alguna persona del equipo actuará como Analista para realizar las especificaciones de las UT. Finalmente, alguien debe encargarse de gestionar plazos, costos y recursos, si el Product Manager no lo hace podríamos asignar esa responsabilidad al Jefe de Proyectos (el tradicional) que en este ejemplo hemos supuesto que es de la parte del proveedor. Obviamente este ejemplo de tratamiento PO no es el ideal, deja en evidencia estamos prácticamente manteniendo los roles tradicionales :-), pero al menos nos señala esta debilidad y se destaca que estas personas deben trabajar de forma muy coordinada. A partir de una solución como esta, una evolución hacia una solución más ágil en cuanto al PO sería que el Product Manager (o equivalente) delegue solo el trabajo en otras personas pero se mantenga responsable y muy involucrado en todo el trabajo, asumiendo que esto le significará mucha más dedicación a ello.
Otro usual desafío respecto del PO son los conflictos de intereses entre Product Owners que comparten la Capacidad de un mismo equipo. Veamos primero una situación que NO presenta este problema, ilustrada en la siguiente imagen.
En esta imagen se muestran tres Líneas de trabajo, cada una con sus correspondientes PO, Backlog y equipo asignado. Si la Línea de trabajo tiene asignado un equipo totalmente dedicado a ella no hay ningún inconveniente. Tampoco habrá conflicto de intereses si el equipo tiene asignada más de una Línea de trabajo pero todas tienen el mismo PO, pues será él quien decida la distribución de Capacidad del equipo a cada Línea de trabajo. La siguiente imagen ilustra la situación en la cual SÍ que se presentarán conflictos entre Product Owners.
En este caso tres Líneas de trabajo están encargadas al mismo equipo, pero cada una de ellas tiene un PO diferente. Un caso así, con PO diferentes y distintas Líneas de trabajo ocurre normalmente cuando las solicitudes de trabajo provienen de diferentes fuentes. Por ejemplo, cuando los PO son comerciales que tienen carteras de clientes separadas. Por otra parte y desgraciadamente también es usual que un mismo equipo se encargue de varias Líneas de trabajo. Hay que ser consciente de la degradación del desempeño del equipo que puede provocar el cambio de contexto al trabajar cambiando de una Línea de trabajo a otra. Así pues en este caso: diferentes PO en líneas que comparten el mismo equipo, probablemente tengamos que establecer el PO como una instancia superior (algún tipo de comité) con autoridad para determinar la distribución de Capacidad del equipo a cada una de las Líneas de trabajo. En dicho instancia superior participarían los PO de cada Línea de trabajo. Esto se ilustra en la siguiente imagen.
En conclusión, y a pesar de lo comentado debo enfatizar que estoy totalmente de acuerdo con la propuesta de PO de Scrum :-), Es indudable que contar con el PO que define Scrum sería muy beneficioso para la eficacia y eficiencia del trabajo realizado por el equipo. Por esto, aunque sea muy difícil establecer dicho PO, debemos tomarlo más bien como una excelente referencia de lo que sería ideal e intentar acercarnos lo más posible a él. Cualquier solución que encontremos, y que probablemente no será el PO ideal, nos alertará al mismo tiempo de las carencias que tenemos al respecto y debería llevarnos a cuidar la coordinación que tienen que mantener los involucrados al desempeñar, de forma complementaria, las responsabilidades asociadas al rol de PO.
No hay comentarios:
Publicar un comentario