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. 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. 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.
- 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
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?
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 nuestro libro Las Claves del Product Management
