Quiero que el próximo Product Owner Program ONLINE + DIRECTOS + MATERIALES + SOPORTE CONTINUO, no se quede sólo en contar (aun contándolo bien, que ya es bastante con lo que se ve por ahí), los clásicos y típicos temas del «universo» Product Owner. Quiero más, el rol en 2021 merece más.
Como no me canso de decir:
-
- La Agilidad, aunque lenta, como todo, ha evolucionado, por lo que hoy conviven prácticas del clásico Lado Oscuro (ya muy en declive), con Agilidad Viejuna (una especie de Primera Orden) que está por todos lados con Agilidad Actual/Nueva Agilidad/evoluciones/o como lo quieras llamar (de nueva Agilidad te dejé este post, este vídeo y, además, que sepas que creamos un grupo de Telegram para debatir sobre Nueva Agilidad).
- El fácil uso de la palabra Ágil esconde centenares de posibles maneras de implementarlo, las burbujas ágiles son numerosas y las interpretaciones múltiples (lo de las burbujas te lo conté en este post y, de hecho, de esa necesidad nació en junio Agilmantium.com).
El Product Owner, el famoso rol introducido por Scrum, es ya una figura clásica en multitud de organizaciones, incluso con independencia del uso que hagan de Scrum (incluyendo los usos dudosos).
El PO, de hecho, no aparece en el Manifiesto Ágil (te dejo vídeo sobre el Manifiesto), que habla de «customer» y la mención más importante relacionada que hace es la de «colaboración con el cliente sobre negociación contractual», añadiendo otras como «Nuestra mayor prioridad es satisfacer al cliente», «Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente» o «Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana».
¿Por qué se habla tanto de la evolución de PO y están apareciendo nuevas interpretaciones y estrategias?
Y me refiero a interpretaciones, adaptaciones y estrategias lejos de lo poco que dice la guía de Scrum, algunas de hecho poco ortodoxas con la sacro guía de Scrum (¡viva el Shu-Ha-Ri)
Dice la guía de Scrum que el PO es «una persona, no un comité», y cada vez discutimos más sobre los problemas presenta el rol. En el libro de Agile 2 se resumen bastante bien:
Vamos con ellos…
Los problemas derivados de su falta de disponibilidad
Ocurre en multitud de ocasiones que si tenemos un PO muy cercano a usuarios, negocio y otros Stakeholders clave en la visión del producto, sabiendo que el PO debe tener la visión de producto y ser parte activa en la misma, que eso nos lleve a que tenga disponibilidad limitada hacia el equipo y eso, en el otro lado… es un problema.
Otra causa típica del problema de la poca disponibilidad viene cuando el PO trabaja para varios equipos (situación que, incluso, se podría unir a la anterior).
El PO de la guía de Scrum… es una figura muy difícil de escalar
Así es, Scrum define una figura difícilmente escalable y que, siendo una única persona, es un punto de falla, bajo la complicada asunción de que tendrá todo el tiempo del mundo para dedicárselo al equipo de desarrollo.
Por dónde van los tiros de las posibles, y más comunes, soluciones (que, al menos, yo estoy viendo)
Por supuesto, todas ellas no son ortodoxas con la guía Scrum, obvio, donde una es la más lógica y razonable… que el PO no sea un única figura. Y, que conste que, esto, así dicho, hay que organizarlo bien, porque siempre hemos explicitado los problemas de tener más de un PO de cara al equipo, así que esto es para dedicarle un post más largo.
Y una típica solución complementaria es el clásico «comité» de Stakeholders o «comité» de POs, con un PO «portavoz» o PO «oficial».
Bueno, un tema que da para contar mucho y en el que me veo muchas diferentes maneras de abordar el problema. En post si tengo tiempo o seguro en el el próximo Product Owner Program ONLINE + DIRECTOS + MATERIALES + SOPORTE CONTINUO hablaremos con profundidad de ello.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
¿Y si dejamos de decir «Product Owner» y simplemente lo llamamos «Colaborador»?.
Creo que como seres humanos, tenemos esa necesidad e categorizar para luego tomar una decisión y si vamos a trabajar como equipo, los titulos/categorias es lo que menos importa 😀