Es posible que a veces se confunda al Product Owner de un equipo Scrum con el máximo responsable del producto y de las personas del equipo ¿Pero es así? PUES NO. Los responsables del producto somos todos. Somos un equipo de responsables.

Somos un equipo de responsables

Entonces ¿qué causas podrían llevar a pensar eso? ¿Por qué motivo podría pensar un Product Owner que el equipo no tienen la misma sensación de urgencia/importancia que tiene él mismo?

En la última retrospectiva con uno de los equipos se me planteó este problema. Busqué por Internet alguna actividad con la que pudiera tratar este tema. Claro que lo hubiéramos podido hablar así sin más, pero pienso que una experiencia vale más que mil palabras 🙂 Y porque me gusta que las retrospectivas sean dinámicas.

La dinámica más adecuada que encontré se llama «El botón de ayuda», aunque cambié algunas cosas para conseguir establecer más debate.


La dinámica

El ejercicio consiste en dibujar un botón en la pizarra, y hacer que el equipo se siente enfrente, en una sola fila o en dos si son muchos. Les expliqué que pulsar el botón significaba entregar el roadmap que tenemos definido a corto plazo con el mayor valor posible y con una calidad extrema. ¿Quién iba a apretar el botón? El botón se mantiene apretado mientras todo el equipo lo mira fijamente sin reír, hablar, mirar hacia los lados o hacia atrás. En la dinámica original se establece estar un mínimo de 20 minutos, pero me parecía demasiado 🙂 , así que estuve atenta hasta que pasaron 5 minutos, haciéndoles creer que se acababa porque alguno de ellos había roto las reglas 😉

Tras el ejercicio, preparé cuatro preguntas que repartí en una hoja a cada uno para que contestaran de forma individual y anónima. Lo del anonimato es algo que hago por costumbre, pero luego hay tanta confianza en este equipo que no tienen ningún problema en explicar quién puso qué y porqué motivo. Las preguntas eran las siguientes, de tipo contestar SI/NO (os las dejo aquí por si queréis usarlas):

Pregunta 1: En algún momento se me ha pasado por la cabeza: “Si dejo de mirar yo un segundo no pasa nada, total…somos un equipo ¿no?”.

Objetivo: ser consientes que igual que lo piensa uno, lo podemos pensar todos a la vez, entonces tenemos un problema. Comentario destacado que apareció: «Entre nosotros solemos decimos cuando uno tiene un mal día, de forma que acostumbramos estar al corriente.»

Pregunta 2: “No puedo dejar de mirar el botón porque si después falla algo, será mi culpa”

Objetivo: saber cuánto de responsables nos sentimos a nivel individual. Comentario destacado que apareció: «Sabemos que tanto si las cosas van bien como si van mal todos somos los afectados. A veces es imposible no pensar que ese código lo toqué yo…» En este caso es imprescindible que no sólo la persona afectada se vea como responsable de un error, sino que es responsabilidad de todos hacerle ver que cada uno de nosotros ha podido tener algo que ver con el problema surgido.

Pregunta 3: Sabiendo quién ha podido dejar de mirar el botón una vez se ha terminado la actividad, le hubiera comentado que le he visto despistado y si le puedo ayudar en algo.

Objetivo: comentar cuánta confianza nos tenemos para ayudar a quién consideremos. Comentario destacado que apareció: «La confianza la tenemos mayoritariamente entre los miembros del equipo que tenemos más contacto en el día a día». Eso es real, aunque no queramos. En nuestro equipo hay 10 desarrolladores, más el PO y el SM. Nos sentamos en una mesa larga organizados tal y como decidió el equipo, por los roles más afines a la hora de comunicarse. Inevitablemente el contacto entre las dos puntas de la mesa es complicado y la confianza menor.

Pregunta 4: (Imagínate haber sido tú el que se ha “despistado”) ¿Hablarías de esto con el SM en un one to one?

Objetivo: tener claro el role del Scrum Master en estas situaciones. Comentario destacado que apareció: «Una de las características de mi rol es estar atenta a ver si hay alguien que necesite y quiera ser ayudado en el caso que no se encuentre al 100% en el equipo». A veces como SM no ves todo lo que pasa, y es importante que el propio me haga saber las cosas para poder encontrar la solución más adecuada.

Resultado de las preguntas

Tras comentar el resultado de las preguntas, quise dejar el debate abierto por si alguno de los presentes había notado alguna situación cercana donde aplicara lo que acabábamos de hablar. Y lo hicieron una vez más: me sorprendieron gratamente.

Tuvimos una discusión satisfactoria después de que el Product Owner nos confesara que a veces sentía que el equipo no tenía el mismo sentimiento de urgencia que él por lo que hacía al producto y las entregas. Esto derivó en conclusiones muy interesantes, pero una a tener muy en cuenta: en ocasiones es la misma organización la que da por supuesto que el Product Owner es el responsable del equipo. ¿Pero por qué? En muchos casos los actuales Product Owners son antiguos Projects Managers, y eso confunde, incluso al mismo equipo, si no se tiene un conocimiento claro de la cultura ágil. También implica el hecho de que se sigan teniendo ambos roles; para nada debería quedar sólo uno, en la organización cabemos todos, pero una vez más, dejemos clara la forma de trabajar y el alcance de responsabilidad de cada uno de ellos.

Resultados

Como acción a conclusión a la que llegamos, hemos decidido que una persona del equipo de desarrollo vaya voluntariamente a reuniones semanales que el PO tiene con los responsables del departamento. De esta manera esperamos que el equipo sea más consciente de la urgencia de algunos temas, como se tratan, qué se nos pide, etc…, que se sientan igual de implicados. Y por otro lado fomentaremos la transparencia hacia el equipo sobre cualquier tema que les implique.

También surgieron algunas dudas sobre quién es realmente el responsable del producto. Se puede pensar que es el Product Owner, pero cuidado, él es el responsable de la aportación del valor y de ordenar el Product Backlog, pero todos somos responsables del producto como tal, de preocuparnos por su calidad pero también por sus entregas y por cumplir un roadmap.

Al día siguiente hubo un comentario revelador. Uno de los miembros del equipo le dijo al Product Owner: «Ayer entraste a la retro como un jefe y saliste como uno más». ¿Creéis que esto significa que la retrospectiva fue un éxito? Yo pienso que sí. Nos hemos dado cuenta de que tenemos potencial para ser un equipo de responsables ???

Os animo a probar la dinámica, y así luego me comentáis qué tal ha ido.

Apuntes

Os dejo esta cita y la entrada de donde la he sacado porque me ha parecido muy interesante:

It takes collaboration and help from others to live up to an accountability

https://www.scrum.org/resources/blog/accountability-quality-agile
5 (2 votos)

Deja un comentario