Scrum Master que a la vez es Product Owner = Scrum Monster

10 nov.

Por Vanessa Amaya

Una pregunta que me hacen muy frecuentemente es ¿Alguien que funge como Scrum Master a la vez puede fungir como Product Owner para el mismo equipo?

Siendo tan frecuente la pregunta, decidí hacer este Blog para compartir mi respuesta porque creo que la duda frecuente refleja confusiones sobre las responsabilidades del Scrum Master y Product Owner, así como también malas prácticas que lamentablemente se han normalizado en el tiempo que llevamos de transformación a la agilidad y habilitando Scrum. Así que empecemos a aclarar esta duda existencial.

Contextos diferentes

Aunque existan muchos roles y responsabilidades para generar productos, a final de cuentas los dos contextos en los que nos movemos como equipo son: el QUÉ y el CÓMO.

Product Owner es responsable del contexto del QUÉ por lo que se encarga de identificar el producto o resultado correcto y sus características para el valor esperado, lo que identifica conforma el Backlog y se encarga de aclarar y refinar constantemente.

Scrum Master es responsable del contexto del CÓMO en conjunto con los Scrum Developers, por lo que se encarga de la efectividad del Scrum Team siendo quien guía sobre la implementación de Scrum, guiando sobre las prácticas complementarias que el equipo decide utilizar y FACILITANDO las acciones de los Developers a través de la solución directa o indirecta de los impedimentos que se van presentando, así como también FACILITAR el entendimiento entre Product Owners y Scrum Developers.

Cada contexto implica diferentes enfoques, conocimientos y experiencia:

Aparte de lo mostrado en la tabla anterior, hay más, pero creo que la diferencia más importante es:

Quien funge como Product Owner se enfoca al PRODUCTO y esto implica saber del mercado e industria donde el Producto exista o vaya a existir, conocer sobre los usuarios, consumidores y clientes finales y negociar hacia dentro de la empresa y hacia afuera para poder obtener un priorización adecuada a la capacidad del Scrum Team para producir con calidad.

Quien funge como Scrum Master se enfoca en las PERSONAS que harán realidad el producto y esto implica el desarrollar habilidades relacionadas al liderazgo servicial y facilitación de sesiones, facilitación del entendimiento de Scrum para poderlo habilitar, conocimiento sobre prácticas de agilidad que mejoren colaboración, gestión de conflictos y gestión de impedimentos.

Cada una de las burbujas de contexto de cada una de estas responsabilidades son muy diferentes implican conocimientos, experiencia y enfoque distinto.

Por ello, si a un Scrum Master se le pide ser Product Owner, no podrá hacer todo lo que implica el producto porque no solo es escribir requisitos, es entender el negocio y usuarios/consumidores para poder priorizar eficientemente. Por lo que el riesgo de que el equipo trabaje en algo que no era lo que se necesitaba es muy alto. Y por otro lado descuidará a las personas que hacen el producto. ¿Qué caso tiene?

¿Por qué sucede que el Scrum Master termina siendo el Product Owner?

Responderé a las preguntas aclarando que seguramente mis respuestas no sean las únicas, pero son las que con más frecuencia he podido constatar en 10 años de apoyar a equipos Scrum:

Porque quien debería de fungir como Product Owner no fue capacitado para poder llevar a cabo sus funciones.
Porque la popularidad de la responsabilidad del Scrum Master es mayor y esto se mal interpreta como que es al único que hay que capacitar y el que se encarga de todo.
Porque no hay consciencia de la capacidad del equipo para producir aunado a desalineación con quienes venden o comprometen trabajo.
Porque durante décadas hemos desarrollado malos hábitos empresariales, uno de ellos y muy impactante, es que la identificación y dimensionamiento de elementos de trabajo (requerimientos) viene con debilidad, así como la comunicación en torno a ellos, por lo que al querer cambiar la forma de trabajar es importante no solo aprender nuevos marcos o métodos, también es importante aceptar cuáles prácticas ineficientes hemos normalizado.
Porque creo que hemos normalizado la sobrecarga, no solo de trabajo sino de vivir distintos roles laborales a la vez. La sobrecarga en cualquiera de sus formas es enemiga de la productividad y la eficiencia.

¿Y si no se puede que sean dos personas diferentes?

La pregunta anterior es la que generalmente me hacen después de responder la primera pregunta sobre si un Scrum Master puede ser también el Product Owner del equipo.

Prefiero en estos casos, elegir una sola responsabilidad a que una sola persona se eche encima el paquete de las dos responsabilidades para no andar teniendo Scrum Monsters en los equipos, y si no queda de otra:

Es mejor tener solo a la figura de Product Owner y fomentar el liderazgo en el resto del equipo para compensar, siempre y cuando, esto se entienda como una solución temporal para poder llevar bien el marco Scrum.

Pero mejor no habilites Scrum hasta que puedas tener un Scrum Master y un Product Owner. Mientras tanto itera felizmente con otras propuestas de agilidad, otro marco, otros métodos. Considero que es mejor aceptar cuando algo no se puede habilitar aún y crear las condiciones para hacerlo en un futuro que hacer algo que desde su origen está mal adaptado, porque luego por eso se dice que “Scrum no funciona” cuando en realidad no se usa correctamente.

Lo curioso, para mí, es que Scrum o no Scrum, todo equipo necesita alguien que especifique lo que se necesita hacer y priorizarlo y otra persona que ayude al equipo a ser eficiente. Tal vez en una empresa pequeña con productos pequeños o demanda ligera pueda ser la misma persona, pero aún así he visto que es difícil de manejar.

Conclusiones

Cuidado con llevar al extremo y sacar conceptos fuera de contexto lo siguiente:

Que los marcos ágiles sean adaptables, no significa deformarlos para satisfacer (consciente o inconscientemente) nuestra resistencia al cambio.
Que el Product Owner le delegue todo su trabajo al Scrum Master amparándose en que en la guía oficial dice “El Propietario del Producto puede hacer el trabajo anterior o puede delegar la responsabilidad a otros.” porque en la guía también dice “En cualquier caso, el propietario del producto sigue siendo responsable.” Aunque no dice a quien delegar el trabajo, hay otros roles como el Business Analyst a quien se le puede delegar el trabajo sin impactar el trabajo del Scrum Master y sin poner en riesgo la entrega de valor.
Que el trabajo multidisciplinario se mal interprete pidiendo demasiada versatilidad a los miembros de los equipos y exigiendo que una sola persona resuelva todos los aspectos a la perfección. El trabajo multidisciplinario es unir diferentes disciplinas complementarias que se unen para lograr un objetivo, no es pedirle a una sola persona que maneje a la varias disciplinas a la vez y esperar que lo haga todo bien.
Scrum propone que un Product Owner para que la voz del cliente final y el conocimiento del producto esté inmerso en el equipo y propone que haya un Scrum Master para custodiar el marco Scrum y asegurar la efectividad del equipo. Es una excelente propuesta que nos urge para romper el trabajo en silos y ser ágiles.
El uso incorrecto de Scrum puede ser una manifestación de resistencia al cambio, y hay varios tipos de resistencia y diferentes maneras de manejarla, así como también hay otros tipos de Scrum Monster, así que espera pronto más blogs sobre estos temas.

Mientras tanto, si quieres aprender más sobre el marco ágil más utilizado y cómo alinear tus habilidades profesionales para que tu equipo aproveche todos los beneficios de Scrum, revisa nuestro calendario de cursos.

Destacado