Sobre el Scrum Master y el Product Owner

read time

4 min

Sobre el Scrum Master y el Product Owner

Los principales roles dentro de un equipo scrum son: el Product Owner, el Scrum Master y el equipo de desarrollo.

En este artículo te ayudaremos a entender las diferencias que existen entre el rol de Product Owner y Scrum Master y cómo, desgraciadamente, hoy en día es común encontrar malas prácticas y antipatrones confundiendo el alcance y labores de cada rol. Tranquilo/a, no sólo te contaremos los problemas. También te contaremos las posibles soluciones que hemos ido validando a lo largo de nuestra dilatada experiencia desarrollando productos ágilmente. Empecemos.

Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy


Diferencias y similitudes entre el Scrum Master y el Product Owner

Como ya dijimos en el párrafo anterior, ambos roles son parte de la tríada que compone el equipo Scrum descrito en la guía que crearon Ken Schwaber y Jeff Sutherland allá por 1995. 

Tienen notables diferencias aunque ambos comparten la agilidad como guía para el desarrollo de software. 

Las principales diferencias son: 

  1. 1. Responsabilidades: El product owner es responsable de la priorización y definición de los objetivos del producto, mientras que el scrum master es responsable de asegurarse de que el equipo trabaje y colabore eficientemente resolviendo cualquier tipo de problemas o bloqueos bajo el framework de Scrum.
  2.  
  3. 2. Autoridad: El product owner tiene la autoridad final sobre las decisiones relacionadas con el producto, mientras que el scrum master tiene autoridad para redirigir las ceremonias y prácticas de equipo velando siempre por facilitar que el trabajo se realice acorde al marco de trabajo de Scrum.
  4.  
  5. 3. Enfoque: El product owner se centra en el valor del producto y en cumplir con los requisitos del cliente, mientras que el scrum master se centra en mejorar la eficiencia y efectividad del equipo.

Aunque a priori parecen completamente distintos, también tienen similitudes:

  • Ambos roles comparten el objetivo de garantizar el éxito del proyecto.
  • Ambos forman parte del Scrum Team y trabajan juntos para alcanzar los objetivos del producto.
  • Ambos deben ser líderes con buenas dotes para la comunicación.

A priori, estos roles pueden parecer sencillos, ya que ambos tienen muy bien definidas sus responsabilidades. Desgraciadamente, esto no siempre es así y puede complicarse su colaboración debido a la aparición de antipatrones o malas prácticas.

¿Pensando en convertirte en Product Manager? ¡Certíficate con nuestras próximas formaciones!

 

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

1. Cuando no está bien definido el límite de la responsabilidad

scrum-master-product-owner-chiste

Este problema normalmente se debe a la asignación de rol por imposición en algún miembro del equipo porque la empresa se ha embarcado en una transición hacia la agilidad. Un buen día, alguien del equipo es nombrado Product Owner o Scrum Master sin definir claramente sus funciones.

Nuestra propuesta

Para aclarar rápidamente sobre quién recae la responsabilidad de alguna de las funciones es muy recomendable acudir a la definición que dimos líneas arriba:

  • Si la tarea o función está relacionada con la aplicación de Scrum y la autonomía del equipo, será el Scrum Master quien deba hacerse cargo.
  • Si la tarea o función está relacionada con la gestión del backlog, roadmap, sprint o la calidad de lo que se entrega, será el Product Owner quien deba ocuparse.

A priori parece muy sencillo aclarar cualquier duda acudiendo a su definición de responsabilidades pero ¡Cuidado! No siempre está tan claro.

Por ejemplo, ¿Quién deberá encargarse de la automatización de las pruebas funcionales? Este punto afectaría tanto a la autonomía del equipo como a la calidad de los lanzamientos.

Según nuestra experiencia, creemos que debe ser el Scrum Master quien deba asumir esta responsabilidad y trabajar junto al Product Owner para conseguir una automatización de las pruebas que a largo plazo permitirá que el equipo adquiera autonomía en la gestión de la calidad de sus lanzamientos.

2. Cuando el equipo no ha comprendido el concepto Scrum

Este es otro de los síntomas que puede sufrir una empresa que de un día para otro ha decidido realizar la transición hacia la agilidad. Los equipos no han terminado de comprender el concepto de Scrum y pueden cuestionar cada actuación, ceremonia o práctica.

Reconocerás este síntoma cuando empieces a escuchar frases como “Esta reunión no vale para nada”, “¿Por qué estamos usando puntos para contabilizar?”, etc…

Nuestra propuesta

Si acudimos a la solución desde la parte teórica, la filosofía Shu Ha Ri nos daría rápidamente la solución. Siento decirte que esto no es tan sencillo. Es necesario crear un espacio de discusión e identificar las necesidades reales del equipo.

El Scrum Master deberá hacerse preguntas como: ¿Cuál es la relación del equipo con el negocio y los stakeholders? ¿Cada cuánto tiempo se despliega en producción?

Sin duda, estos factores son cruciales para adaptar los rituales que tendrá el equipo desde el principio y así evitar aplicar un Scrum de manual que convierta a tu equipo en fervientes detractores.

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

Es común encontrar backlogs divididos en 2 bloques en los que por un lado están las tareas técnicas y por otro lado las historias de usuario con diferentes puntos asignados.

Creemos que esta práctica no es buena.

Nuestra propuesta

Puede darse el caso de un Product Owner que no esté demasiado interesado en las tareas técnicas del backlog porque solo le interesa la parte funcional (historias de usuario).

Esto es, sin duda, un enorme problema tanto para el equipo como para el producto.

El Product Owner debe entender las tareas técnicas y no verlas como una amenaza para su backlog funcional mientras que el equipo debe mantener  siempre una actitud de búsqueda de la mejora técnica que repercuta en el usuario y su experiencia. Las tareas técnicas deben estar dentro de las historias de usuario.

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

Cuando una empresa asigna de forma sistemática un Scrum Master en todos los equipos de desarrollo, lo más habitual es que centre sus labores en actividades de apoyo al equipo (ordenar servidores, redactar documentación, refinar historias de usuario, revisar los commits de los desarrolladores, etc…) y no se centre tanto en su grado de implicación en el equipo.

Nuestra propuesta

Cuando un equipo tiene madurez y todos sus miembros tienen perfiles senior, pueden ser muy capaces de entregar una calidad alta con una muy buena autogestión del trabajo.

Esto provocaría que la incorporación de un Scrum Master no fuera demasiado útil por lo poco que podría aportar. Esto no siempre es así y puede darse el caso de un equipo que nunca termina los sprints o que no entiende las tareas que se asignan haciendo necesaria la figura del Scrum Master. Cabe hacerse preguntas como:

  • ¿Está bien redactada la documentación?
  • ¿Se están ejecutando las pruebas adecuadamente?
  • ¿Completan las tareas de los sprints todos los miembros del equipo?
  • ¿Cómo es la relación del equipo con los stakeholders?

ES - Academy Banner 2 - 022023

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

Todos estos problemas se pueden resolver manteniendo una buena comunicación entre todo el equipo y marcando como objetivo ser un equipo autónomo y eficaz. 

Aunque se elija un framework que nos proporcione una guía para trabajar incluso con los perfiles más junior, nunca será perfecto. Es necesario permitir que los equipos tengan iniciativa y busquen la mejor forma de superar sus problemas.

 

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


Para saber más: descarga el libro Agile Product Management

 

Publicado el 30 ene 2023

Actualizado el 26 mar 2024

clipboardCopiar el enlace
Escrito por
Romain Monclus
Romain Monclus Diplômé des Arts et Métiers et de l'ESCP, Romain commence sa carrière dans le Product un peu par hasard, en tant que PO Junior dans une start-up de social gaming. Un des premiers Thiguys, il se focalise aujourd'hui sur les organisations et le coaching Produit à la tête de la tribe Advisory de Thiga. Manager, il est aussi formateur au sein de Thiga Academy et a créé la newsletter des Product Managers. Fan inconditionnel de musique, d'Arvo Pärt à Metallica, et de pasta italiana, Romain fait de la guitare et des blagues, parfois décalées (au grand dam de ses collègues).

Próximos eventos

LPCx BCN: Product Management & Product Design

calendar

20 marzo 2024

Apúntate

La Product Conf Madrid 2024

calendar

17 mayo 2024

Apúntate

Filles_ordinateur

¿Quieres compartir con el mundo tu pasión por los temas de producto?

Cada mes, más de 20.000 entusiastas del producto digital visitan nuestro media. Comentarios, opiniones controvertidas... ¡compártenos eso que tienes en mente!

 

Contactar con la redacción