El Product Owner y el Scrum Master son dos roles tradicionales «ágiles» que, aunque en un principio se crearon dentro del marco de la metodología Scrum, ahora han evolucionado hasta llegar a representar en sí mismos toda una filosofía de desarrollo de software.

En un contexto ideal, el Scrum Master y el Product Owner conforman un binomio estrella que permite que el equipo de desarrollo se adapte con rapidez a la filosofía «ágil», asuma la parte de responsabilidad que le corresponde y construya un buen producto de la forma adecuada.

Sin embargo, la realidad muchas veces no se corresponde; por eso, hemos preparado este artículo para cualquier miembro de un equipo ágil que busque mejorar la relación entre el Scrum Máster y el Product Owner.

— ¡Oye! Que he priorizado las historias de usuario y los he puesto en el spr…
— ¡Ayer era cuando había que planear el sprint!

[Y esto es lo que hay que evitar entre el Scrum Master y Product Owner]

Historia del Scrum Master y del Product Owner

Los roles de Scrum Master y Product Owner (descritos inicialmente en la guía de Ken Schwaber y Jeff Sutherland) consisten en supervisar un equipo que trabaja con la metodología Scrum.

A diferencia del puesto de Product Owner, que es de carácter permanente en el equipo, el papel de un Scrum Master puede ser asumido por cualquier miembro del equipo, excepto por el Product Owner. Sean quienes sean, estas personas son las encargadas de que el equipo trabaje bien.

En resumen:

  • El Product Owner se asegura de que las funcionalidades adecuadas se construyan en el orden correcto.
  • El Scrum Master también es responsable del buen funcionamiento del equipo y de que se respete la metodología adoptada por la empresa.

En la teoría, estos roles parecen sencillos, pero como siempre insistimos en cada una de nuestras misiones, la colaboración entre ambos puede complicarse rápidamente en ciertos contextos, como los que detallaremos a continuación.

4 situaciones en las que no se respetan los roles de Scrum Master y Product Owner

1. Cuando el límite de la responsabilidad del Scrum Master y del Product Owner no está claramente definido

scrum-master-product-owner-chiste

Uno de los problemas más frecuentes que nos encontramos es la falta de definición de las funciones de los puestos del Product Owner y del Scrum Master.

Esto ocurre, por ejemplo, cuando se asignan de forma automática los puestos de Product Owner y Scrum Master a cada equipo de desarrollo como parte de la transición de una empresa al «modo ágil».

Nuestra propuesta

Ceñirse a la definición de los puestos que proponemos más arriba y realizar el siguiente diagnóstico cuando no esté claro si es el Product Owner o el Scrum Master quien debe asumir una o más tareas:

  • Si la tarea en cuestión está relacionada con la aplicación de Scrum y la autonomía del equipo, será el Scrum Master quien tenga que ocuparse.
  • Si la tarea está relacionada con seguir la hoja de ruta o con la calidad de lo que se entrega en cada sprint, será el Product Owner quien se haga cargo.

Cuidado: no siempre es fácil llegar a un consenso. Por ejemplo, ¿quién se encarga de la automatización de las pruebas funcionales? Esto afecta tanto a la autonomía del equipo como a la calidad de los lanzamientos.

En tal caso, creemos que es el Scrum Master es quien debe tomar las riendas y trabajar en sintonía con el Product Owner, ya que, aunque afecta directamente a la calidad de los lanzamientos, la automatización de las pruebas permitirá que el equipo adquiera a largo plazo autonomía en la gestión de la calidad de sus lanzamientos.

2. Cuando el equipo no ha comprendido el concepto Scrum

Otro síntoma de un cambio repentino a la metodología «ágil» es la dificultad de los equipos de desarrollo para comprender Scrum.

Una consecuencia clásica de esta situación son las discusiones centradas en la parte estética de los cambios, y en particular las relacionadas con el tiempo que se pierde con los rituales ágiles («La reunión diaria no sirve para nada», «¿Por qué estamos usando puntos para contabilizar? Esto parece de parvulario» …).

Nuestra propuesta

Desde el punto de vista teórico, la filosofía Shu Ha Ri es muy fácil de comprender. En la práctica, sin embargo, muchos emplean este concepto sin preocuparse de crear un espacio de discusión e identificar las necesidades reales del equipo.

El Scrum Master debe plantearse estas preguntas: ¿Cuál es la relación del equipo con el negocio y los stakeholders? ¿Con qué frecuencia se sube a producción? ¿Hasta qué punto es el equipo multidisciplinar?

Todos estos factores serán cruciales para implementar desde el principio los rituales de la metodología en el equipo.

Es cierto que requiere más esfuerzo, pero más vale tener una mínima idea de las necesidades del equipo antes de establecer esos procesos que hacer un Scrum sin fundamento e injusto «de manual» que utilice la retrospectiva para que el equipo acabe alzando la voz (lo cual puede que nunca suceda, o que pase demasiado tarde si el equipo cree que pasarlo mal es lo normal porque «Scrum es lo peor»).

3. Cuando el Product Owner no está a cargo de las tareas técnicas de su equipo

Puede darse el caso de que el Product Owner de un equipo no esté a cargo de las tareas técnicas. Cuando ocurre esto, a menudo hay un backlog dividido en dos bloques de tareas paralelos: por un lado, las historias de usuarios funcionales; por otro, las tareas técnicas. Cada uno de estos bloques tiene distintos puntos asignados.

Nosotros lo consideramos una mala práctica.

Nuestra propuesta

Si ese fuera el caso, es posible que el Product Owner no esté lo suficientemente interesado en los aspectos técnicos del backlog, lo cual es un gran problema.

Resulta imperativo que el Product Owner se muestre receptivo a los problemas del equipo y que sea capaz (haciendo uso de su legitimidad en el equipo y de sus responsabilidades) de establecer un orden de prioridad para resolverlos con todos sus miembros.

  • Por una parte, el Product Owner debe entender estas «tareas técnicas» y no verlas como una amenaza para su «backlog funcional».
  • Por otra, el equipo de desarrollo debe pensar en los resultados y ponerse en  la piel del Product Owner a la hora de estudiar cómo mejorar el producto: ¿qué pueden ganar los clientes o el equipo con esto? De no realizarse esta tarea técnica, ¿qué riesgos implica?

No es recomendable separar las tareas técnicas y funcionales/comerciales en el sprint: esta priorización debe llevarse a cabo dentro del mismo flujo de historias de usuarios; también debe solicitarse un arbitraje al Product Manager o a las partes interesadas a cargo.

Si se determina que el Product Owner presenta carencias relacionadas con los problemas técnicos, tendrá que formarse en consecuencia. Puesto que esta tarea está asociada a la autonomía del equipo, el Scrum Master se hará cargo del desarrollo de esas competencias.

4. Cuando el equipo tiene experiencia y el Scrum Master está de brazos cruzados

Cuando el papel del Scrum Master se asigna de forma sistemática en todos los equipos de desarrollo, lo habitual es que se centre en actividades de apoyo al equipo (ordenar servidores, redactar documentación, refinar las historias de usuario, revisar los commits de los desarrolladores, etc.) y no tanto en revisar su grado de implicación en el equipo e incluso cambiar de posición en la empresa.

Nuestra propuesta

No es tan raro que un equipo autónomo ofrezca calidad sin tener un Scrum Master asignado. De hecho, si los procesos ya están bien pulidos y todo va bien, incorporar otro puesto con dedicación exclusiva no aportaría demasiado.

Por otro lado, si se detectan ciertas anomalías, como sprints que nunca llegan a finalizarse o desarrolladores que no entienden las tareas que se les asignan, la figura del Scrum Master se hace necesaria para que el equipo adquiera más experiencia.

A veces, quien se hace cargo de este trabajo es un Product Owner (mala idea) o bien un desarrollador del equipo (puede hacerlo si la carga de trabajo no es demasiado grande).

En tal caso, el objetivo del Scrum Master será aclarar al equipo las tareas que no están llevándose a cabo y asegurarse de que estas se consolidan, en lugar de reemplazarlas por otras.

Una breve lista de preguntas que el Scrum Master:

  • ¿Está bien redactada la documentación?
  • ¿Se están ejecutando las pruebas adecuadamente?
  • ¿Cumplen los miembros del equipo durante los sprint con las tareas asignadas?
  • ¿Mantienen relaciones sanas con los stakeholders y otros equipos?

En el equipo, este papel puede llegar a ser importante para el cumplimiento de los rituales cotidianos (reuniones diarias, demostraciones, retrospectivas, groomings o refinamientos), puesto que no requiere ninguna habilidad particular (salvo un mínimo de fluidez oral).

En conclusión: la autonomía de los equipos debe ser prioritaria

A estas alturas, está claro que es posible resolver estas situaciones siempre que se escuche a los demás, y que el objetivo último sea que los equipos acaben siendo autónomos y eficaces.

Ahora bien, aunque escalar la agilidad acabe siendo indispensable, eso también aumentará la probabilidad de que los problemas mencionados en este artículo aparezcan en los distintos equipos.

Por eso, es importante tener presente que, aunque un marco metodológico proporcione tranquilidad y permita que los perfiles menos experimentados amplíen sus competencias, nunca será perfecto. ¡Permitamos que los equipos tengan iniciativa e ideen nuevas formas de solventar sus propias dificultades!

Artículo escrito por varios thiguys y thigirls: Romain Monclus, Mathias Frey, Nicolas Martin, Nicolas Daoud, Etienne Bousquié, Isabelle Sauer, Antoine Vallespir

descargar-libro-producr-management-product-owner

Más contenido interesante:

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Tu dosis de Cultura de Producto

Una vez al mes. Recibe una editorial y una selección a conciencia de contenidos sobre Product Management y UX Design.
¿Estás dentro?📩