Este post, como el de ayer, ha nacido que ordenar post-it de anotaciones, ideas, etc., que tengo por ahí para el curso agilidad avanzada. Pero en este caso, después de leer mucho, pensarlo, reflexionar, hablar con gente, etc., no tengo una solución mágico-clara al problema (se aceptan ideas y referencias, por favor, déjalas en los comentarios de este post), hay mucho escrito pero nada definitivo (o yo no lo he encontrado).
Y este problema es muy muy muy común, se da en muchos sitios, el problema de que el Product Owner es un cuello de botella para el equipo y acaba frenando mucho su velocidad (o eficiencia).
Y suele ser cuello de botella porque no hace las historias bien, o no ordena por valor, o cuela historias que realmente son tareas, o no está disponible para el equipo, etc.
Y, además, lo normal, incluso lo recomendado, es que el Product Owner, de cara al equipo técnico, sea una única persona. Si nos vamos a lo que dice «el libro», la guia de Scrum, podemos leer cosas como…
El Propietario del Producto (Product Owner) es la única persona responsable de gestionar la Pila del Producto (Product Backlog)
El Propietario del Producto (Product Owner) es una única persona, no un comité
Una de las causas de sobre carga del Product Owner puede venir de que hace trabajo que no es de Product Owner, típicamente hace trabajo de Stakeholder (mucha gestión de clientes). En este caso la solución, en mi opinión, pasa por aclarar bien el rol y dejar que el PO haga de PO y los Stakeholders de Stakeholders.
Otra causa puede ser que sea tan complicado manejar el Product Backlog que no le llegue el tiempo. En este sentido, si nos volvemos a ir «al libro», mira que, ojo, también pone que:
El Propietario del Producto (Product Owner) podría hacer el trabajo anterior [refiriéndose a las tareas de mantenimiento del Product Backlog] o delegarlo en el Equipo de Desarrollo (Development Team). Sin embargo, en ambos casos el Propietario del Producto (Product Owner) sigue siendo el responsable de dicho trabajo.
Es decir, que si podéis que ayudéis un poco al pobre, o la pobre, Product Owner, que no creéis silos dentro del equipo.
Recuerda que por ahí hay una buena práctica llamada los 3 amigos (del contexto BDD), que viene a decir que los Items del Product Backlog, siendo responsabilidad del PO, se crean contando con el Tester, Desarrollo y el propio Product Owner.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
En mi caso, lo que yo he vivido acerca de los POs es la sobrecarga de trabajo y la baja formación que reciben.
Me explico:
1.- «Cualquier jefe de proyecto puede ser product owner». Así, mágicamente, de un día para otro pasa de ser Jefe de Proyecto a Product Owner, sin formación ni acompañamiento. Para mi la principal causa es que no se define bien la figura del PO y su responsabilidad, y en compañías con mucha inercia en la gestión clásica de proyectos se minusvalora el cambio que todo esto supone.
2.- «Lo importante es crear el mayor número» de equipos, porque eso nos da más capacidad (teórica). Y esto se hace sin importar si tienes gente suficiente para ello! Conclusión, POs que están en varios equipos. No digo que esto no se pueda hacer si el escalado va poco a poco y el PO y los equipos son «veteranos», que saben lidiar con este escalado. Pero si no es así, la sobrecarga de trabajo del PO es terrible, no pudiendo llegar bien a lo que demanda cada equipo.
Hablar de «cuello de botella» me hace pensar a las prácticas de gestión de proyectos tradicionales, a todos los obstáculos y los retrasos que se acumulan entre las distintas fases, y al rol del jefe de proyecto que – de forma similar a lo que comenta otro lector – termina sofocado por la sobrecarga de trabajo. ¿ Te suena a ti también ?
Pero…. ¿ Por qué nos atascamos en la agilidad ?
Uno de los errores principales pasa por querer cambiar demasiado y terminar cambiando muy pocas cosas. Aquí es donde se fomenta la sobrecarga de trabajo, el estrés y la falta de resultados (valor).
Ok, pero … estoy seguro que habrá otra explicación «menos teórica» y que se acerque más a la vida real. Por ejemplo, pienso en la presión por parte de la organización, en los hitos (compromisos), en la falta de valores, y …en la completa perdida del sentido común.
Ultimamente estoy leyendo muchísimas cosas interesantes sobre agilidad y siempre pienso lo mismo:
¿ Por qué hacemos las cosas mal ?
¿ Por qué nos cuesta tanto cambiar ?
Desde mi humilde punto de vista, es normal, y hasta bueno, que un PO tenga dificultades y que esto cause un «cuello de botella». También es comprensible que un Agile Coach o Scrum Master no pueda hacer milagros. Lo que no es normal es que en un entorno ágil no somos capaces de rectificar…
Hola! entiendo el conflicto del Product Owner sobrepasado de trabajo. Pero por lo que leo en tu post, los motivos que enumeras como causa raíz del exceso de trabajo del PO son todas malas practicas que ejecuta en su dia a dia: o bien no saber como escribir buenas USs o bien no saber como priorizar el backlog; o bien no entender hasta donde llega su responsabilidad y a partir de donde empieza la de los stakeholders. En estos contextos, veo un gran campo de acción por parte del Scrum Master. Por un lado, debería poder hacer trabajo personal con quien lleve el rol de Product Owner para poder tener una implementación de scrum cada vez mas sana. Por el otro, debería poder armar algún tipo de actividad entre Stakeholders y PO para entender donde debería entrar en acción cada parte.
El PO se convierte en un cuello de botella cuando no tiene el perfil adecuado o cuando lo han puesto como PO cuando ni si quiera conoce el entorno del proyecto y no logra ver el camino por donde transitará todo el equipo scrum para llegar a la meta.