Saltar al contenido
Be Agile My Friend

Qué cosas NO debe hacer un Scrum Master

El Scrum Master es un rol muy importante dentro de un equipo Scrum, su participación en cada uno de los eventos de un Sprint y haciendo de líder al servicio de los demás, lo convierten en un componente vital para la armonía del equipo.

Pero a veces se cometen errores a la hora de empezar como Scrum Masters, es por ello, que en este post revisaremos algunos puntos que consideramos incorrectos para que los Scrum Masters puedan desarrollar un mejor trabajo en su día a día.

Los errores más comunes “Anti Scrum” del Scrum Master

El Scrum Master no debe organizar el trabajo del Equipo de Desarrollo, existen muchos Scrum Masters que, según su experiencia pasada, les dice al Product Owner y al Equipo de Desarrollo las historias de usuario que puede realizar el equipo en un Sprint, calculando su capacidad, y creando un mal clima de trabajo.

El Scrum Master nunca debe organizar los eventos de un Sprint.  En muchas casos, en los Daily meetings, el Scrum Master se encarga de hacer las tres preguntas, y además de controlar el trabajo de un desarrollador, que se había comprometido con una historia de usuario el día anterior. El Scrum Master debe asegurarse que los eventos se realizan, y que se realizan dentro de los tiempos establecidos.

El Scrum Master no debe categorizar a los miembros del equipo de desarrollo en roles, no debe asignar “Programadores” o “Testers”, esto es trabajo interno del mismo equipo, que debe ser multidisciplinar.

El Scrum Master no debe proteger al equipo, aislandolo de reuniones importantes como el refinamiento del Product Backlog, por estar con mucha carga de trabajo. Esto suele terminar en un refinamiento hecho solo por el Product Owner y el Scrum Master. El objetivo de estos eventos es que participen todos los miembros del equipo Scrum.

El Scrum Master no debe obligar a esperar al Sprint Review para la inspección del incremento de producto. Ni tampoco obligar al equipo de desarrollo a no mostrar nada de lo desarrollado en medio de un Sprint. Su trabajo es encargarse de que esta labor de inspección no se convierta en un día a día.

El Scrum Master no divide los Sprints en “Sprints de incremento” y “Sprints de testing”. Tampoco trabaja con “Sprints cero” para la creación de la infraestructura de código.

El Scrum Master no debe cambiar por si mismo Scrum por “Agilidad”, tampoco eliminar eventos que considere innecesarios por falta de tiempo.

El Scrum Master no debe obligar a que el Product Owner sea el exclusivo responsable de crear las historias de usuario del Product Backlog, así como de que sea el Product Owner el único que de los detalles de cada historia de usuario. El Product Backlog es responsabilidad del Product Owner pero su organización puede ser realizada de manera colaborativa si así se considera necesario. Este tipo de acciones aísla la presión a una sola persona, creando un mal clima de trabajo.