Que podría «Malir Sal», si el Product Owner es el experto en el producto

Nuestro Product Owner (PO) respira y vive por el producto, cualquier pregunta que se tenga o tenga el equipo el PO tendrá la respuesta, nuestro PO no solo conoce las funcionalidades si no que también algunas partes técnicas. Con esto se podría decir que estamos en un escenario perfecto.

Pero la pregunta es, ¿es siempre ideal? lo que podría pasar, es que existen problemas potenciales para el equipo y el producto que están construyendo. A continuación quiero compartir algunas de estas «dificultades» en las cuales tenemos como protagonista a un PO experto en la materia.

▸ Supongamos que nuestro PO tiene las mejores respuestas

Si el equipo se convence que el PO tiene la mejor respuesta y no busca más, no estará abierto a ideas o alternativas que podrían surgir de una discusión o lluvia de ideas donde participen todos. No miraran fuera de la caja y no prestaran atención a otro tipo de información adicional proveniente de otros.

▸ Trabando a los demás miembros del equipo SCRUM

Puede leerse un poco fuerte, pero si tenemos un PO que en el fondo sembró en el equipo que lo sabe todo, afecta a la confianza de los otros miembros y puede que nuestro Product Owner este adoptando una postura dominante. lo que el PO dice va. El Product Owner no permite que los Desarrolladores autogestionen su trabajo, consciente o inconscientemente.

En Scrum, los desarrolladores deberían poder gestionar su propio trabajo. Esto permite realizar correcciones de rumbo cuando el equipo necesita optimizar las posibilidades de alcanzar la meta del Sprint.

▸ Haciendo el trabajado del equipo

Cuando el PO esta tan empoderado en el sentido de que conoce todo el end2end del negocio y funcionalidades, se empodera de igual forma en espacios que le corresponden al equipo de Desarrolladores, como por ejemplo el refinamiento y análisis sesgando de alguna manera la habilidad de autogestión y análisis.

Un Product Owner debe respetar a los Desarrolladores para hacer su trabajo y permitirles ser profesionales autogestionados. Un Product Owner también puede ser un Desarrollador. Pero incluso entonces, no es saludable tener un equipo apoyado en una sola persona para que haga todo el pensamiento. Es un desperdicio de creatividad y oportunidad.

El empirismo afirma que el conocimiento proviene de la experiencia y de la toma de decisiones con base en lo observado.

Guía Scrum 2020

▸ Amar su producto por sobre los otros

Un Product Owner puede tener la tendencia a ceñirse a su amado producto. Es posible que se olvide de mirar más allá del estado actual del producto hacia alternativas que podrían aportar más valor.

Quizás tenga sentido empezar a utilizar nuevas tecnologías, plataformas alternativas o relacionarse con otros equipos, otros PO ya que al fin y al cabo un equipo Scrum entrega valor a la organización, ojala, en forma conjunta y organizada con otros equipos Scrum y no de forma individual. Sería una gran pérdida si no se descubrieran estas oportunidades.

Si los Equipos Scrum consideran que las opiniones del PO son las únicas, es posible que se olviden de experimentar para encontrar evidencia de los supuestos del Product Owner. En un entorno complejo, las opiniones del PO también son suposiciones. Hasta que se prueben a través de la inspección y obviamente puesta en algún ambiente no productivo.

▸ Descuidar otros aspectos del rol del Product Owner

Un PO que confía ciegamente en su experiencia, puede descuidar otros aspectos de Responsabilidad. Es fundamental que un Product Owner:

• Se alinea con las partes interesadas.

• Aprende de esfuerzos e implementaciones anteriores.

• Inspecciona y adapta basándose en observaciones.

Si esto no está, tiene impacto negativo en el valor del producto. El Product Owner no satisface las necesidades de las partes interesadas y pierde oportunidades de crecimiento.

Además de eso, un Product Owner debe estar abierto a aprender cosas nuevas sobre el producto. Cuando un producto tiene nuevos incrementos con frecuencia, el conocimiento se vuelve obsoleto rápidamente.

El Scrum Team Esperando al PO

Experto en la Materia

Tener un propietario de producto que sea el experto en la materia del producto es genial. Es bueno tener personas en el equipo que comprendan a fondo el producto. Pero también puede ser una trampa.

Se entiende que los equipos Scrum funcionan en entornos de productos complejos. Esto significa que el Product Backlog está lleno de suposiciones que deben verificarse. Es por esta razón que los Sprints son lo más cortos posible (En lo personal, la medida justa es de 2 semanas). No desea correr el riesgo de trabajar basándose en suposiciones no verificadas durante demasiado tiempo.

Un equipo Scrum que tiene un Product Owner que es el experto en la materia se encuentra en una posición potencialmente excelente. Pero puede caer en algunas de las razones aqui mencionadas o en otras mas que no serian beneficiosas para el equipo sesgándolos a experimentar y crecer en su rol como Desarrolladores. Aquí entra en juego el Scrum Master para entrenar al Product Owner y al equipo de desarrollo para convertir este tipo de «problemas» en oportunidades para crecer.


Deja un comentario