Scrum Master, el PO también es de tu equipo.Guíalo.

Quisiera dar la bienvenida a este año hablando de un tema que estoy encontrando en común respecto a equipos Scrum.

En otro artículo relaté un poco sobre las tareas de un Product Owner. Cómo sus tareas no son nada fáciles lidiando con el negocio mismo (Las labores del PO no son simples).

Ahora. Hay que ser realistas. Un Scrum Master no es tal solo por llevar un curso o tener una certificación. Hay todo un camino que recorrer desde el curso o certificación ya que ese es el punto de partida hacia un destino aún no fijado. Lo mismo ocurre con el Product Owner.

Asumir que el Product Owner, por haber llevado una certificación o haber llevado un curso, ya está listo para enfrentar a su propia organización y con ello ganar su autoridad y empoderamiento que requiere para realizar bien su labor; es una ilusión.

De hecho, lo estamos sacando de su zona de confort. El PO, al ser una persona de negocio, viene de un entorno diferente al equipo de desarrollo. Un entorno que históricamente no ha estado asociado a a tecnología y que las necesidades eran derivadas a un "área de sistemas" para que se encargue. Un entorno para el que la elaboración de software es una suerte de magia.

Si bien, durante su entrenamiento/certificación, han sido influenciados respecto a las actividades que deben realizar y las ceremonias en las que deben participar; salir de su zona de confort no es tarea fácil.

El Scrum Master debe apoyar

A ver. Hay que entender que el Scrum Master tiene 3 ámbitos de acción:

• El equipo de desarrollo
• El dueño del producto o product owner
• La organización 

Dentro de su alcance está el acompañar al Product Owner en este viaje de cambio cultural. Es el Scrum Master el que debe guiar al Product Owner respecto las ceremonias que se siguen, el porqué se realizan y qué valor generan; debe guiar al Product Owner al trabajo colaborativo, a la orientación al valor, a entender la cadencia, al aprendizaje continuo y cómo todo esto en conjunto beneficia a la empresa y a su producto.

Lo bueno de la historia es que al sacar su certificación o al terminar su entrenamiento, el Product Owner va a estar con ganas de aprender más y con la curiosidad necesaria para poder darle un acompañamiento adecuado que permita al Product Owner aplicar lo aprendido en el día a día.

Es decir, vamos a tener a un PO con muchas ganas de aplicar lo aprendido y hay que aprovechar ese momento.

Ahora, el entrenarlo no es lo único que puede hacerse. Hay que sumarse a él en sus reuniones de negocio si es necesario. De manera que podamos transmitir nuestro mensaje de mejora continua hacia dentro de la organización.

Es importante recordar que nuestro PO es el nexo con el negocio, por lo que podemos usar estas reuniones para ir generando el cambio que deseamos en nuestra organización.

Otro punto importante refiere a ayudarlo ordenarse. Desde mi punto de vista existen al menos 2 refinamientos. Uno que se hace con el equipo para preparar las historias de usuario que vendrán en un siguiente sprint y otro que viene del negocio cuando solicita algo al PO.

Si no tenemos este segundo refinamiento, lo que sucede es que el PO nos enviará el pedido así como viene del negocio. Es decir, con muchas preguntas asociadas. Lo que originará que el refinamiento con el equipo y finalmente el planning demorarán mucho y no tendrán todas las respuestas que se necesitan.

Armar un kanban con el PO para que vea las ideas que le transmite el negocio, que las pondere y las vaya puliendo, hará que llegue con más conocimiento al respecto hacia los refinamientos con el equipo de desarrollo.

Este kanban dará visibilidad a las ideas que aún están pendientes de ser trabajadas como parte del producto/servicio que se está trabajando, las prioridades y permitirá además asegurar que se realice el primer refinamiento. Con el Scrum Master acompañando al PO en su proceso de captura de ideas del negocio, el PO puede estar más tranquilo y aprender a decir que NO a algunas cosas. Recordemos que no todo debe ser hecho.

El equipo de desarrollo debe apoyar

Claro. El PO es miembro del equipo Scrum y si necesita ayuda, también el equipo de desarrollo debe apoyar.

Esto tiene varios enfoques. He encontrado POs que tienen mucha carga laboral del lado de su organización que se mantiene aún trabajando en un esquema antiguo. Estos POs tienen un tiempo acotado para recibir nuevas ideas y trasmitirlas al equipo. No todas las organizaciones van a la misma velocidad en una transformación, por lo que estas cosas suceden más de lo que uno quisiera.

Una alternativa puede ser que alguien del equipo trabaje con el PO en aclarar las ideas y conversar con el negocio respecto a las mismas; de manera que el PO pueda darse tiempo tanto de organizar su trabajo, como de velar por su producto/servicio.

Entonces

Los escenarios pueden ser diversos; pero hay muchos casos de POs que son limitados por su misma organización y es ahí donde tenemos que tener mayor protagonismo. Si solo exigimos al PO que nos brinde el backlog priorizado o demandamos a la organización un PO con experiencia y al 100%, estamos, como dicen, tapando el sol con un dedo. Los POs que nos asignan son por lo general funcionarios que vienen trabajando desde hace algún tiempo en la organización y aún no están completamente convencidos de lo que Scrum ofrece, como metodología o Ágil como mindset.

Si tienes algunas otras formas de ayudar a tu PO, puedes compartirlas en los comentarios. Así seguimos aprendiendo.