El otro día me pasaron un artículo con el que casi se me saltan las lágrimas. Hay que tener cuidado con lo que se lee por ahí sobre Scrum, a riesgo de que quedemos totalmente confundidos. El artículo en cuestión -que prefiero no enlazar para evitar agravios o polémicas-, rezaba algo así como “Qué es, qué hace y cómo convertirse en Scrum Master”, pero venía a hacer justo lo contrario: describía lo que el Scrum Master no es -o no debe ser-. Como mucho, el post describía al project manager tradicional, aunque ni de eso estoy seguro.

Hemos aprovechado la ocasión para atajar algunos “mitos y leyendas” e intentar aclarar unas cuentas ideas sobre el rol del Scrum Master. Vamos.

Mito: El Scrum Master es el líder de los equipos ágiles. Este tipo de afirmaciones dan a entender que el Scrum Master es “el jefe”. No, no lo es. Conviene enfatizar que, en todo caso, es un servant leader, o sea, su liderazgo se materializa mediante el servicio a los demás. A nosotros nos gusta hablar de liderazgo de nivel 5.

Mito: El Scrum Master se encarga de eliminar todas las trabas que afectan a los miembros del Equipo de Desarrollo a la hora de realizar sus tareas. No elimina “trabas”, ni “todas” ellas. Elimina impedimentos, es decir, aquellos obstáculos que exceden de las capacidades de autoorganización del Equipo de Desarrollo. Si eliminara cualquier “traba” terminaría por convertirse en el babysitter del Equipo.

Mito: El Scrum Master es responsable de garantizar que se alcanzan los objetivos definidos para el Sprint. El Scrum Master no garantiza nada. La responsabilidad de alcanzar el Objetivo del Sprint es compartida por todo el Equipo Scrum, que es el que fija el Objetivo.

Mito: El Scrum Master garantiza que se siguen las pautas marcadas en la metodología o modelo Scrum. De nuevo, el Scrum Master no garantiza nada, ni Scrum son “pautas” ni una “metodología” o “modelo”. El Scrum Master vela por la correcta adopción de Scrum, eso sí, y Scrum como tal es un framework orientado a procesos, no una metodología cerrada.

Mito: El Scrum Master es el responsable de organizar el Product Backlog (lista de tareas de desarrollo). El responsable de gestionar el Product Backlog es el Product Owner, no el Scrum Master -si bien el Product Owner puede delegar ciertas tareas de gestión-. Y el Product Backlog no es una lista de tareas a desarrollar, sino una lista de todo aquello conocido que el producto puede necesitar.

Mito: El Scrum Master es el responsable de gestionar el Sprint Backlog, que consiste en la asignación de tareas a miembros del Equipo. El Sprint Backlog son los elementos del Product Backlog seleccionados para el Sprint más el plan (tareas, estimaciones, etc.) para transformar esos elementos en Incremento de Producto Terminado. Es un artefacto que pertenece al Equipo de Desarrollo, NO al Scrum Master. La asignación de tareas se produce durante el Sprint y deben realizarla los propios miembros del Equipo de Desarrollo.

Mito: El Scrum Master es el responsable de gestionar los tickets de JIRA y de configurar todos sus flows. NO. Mejor separase de JIRA. Una cosa es echar una mano con la herramienta de ticketing de turno, y otra monopolizarla para convertirnos en JIRA Master. El Scrum Master tampoco tiene que estar persiguiendo a los desarrolladores para que actualicen JIRA.

Mito: La función del Scrum Master es la de intermediar entre el cliente o Product Owner y el Equipo Scrum a su cargo. ¡NO! El Scrum Master no intermedia. Ni el Equipo Scrum está a su cargo.

Mito: El Scrum Master tiene una función gerencial de cara al cliente. No, el Scrum Master no gestiona al cliente, esta labor recae más bien en el Product Owner.

Mito: El Scrum Master prioriza los requisitos determinados por el cliente y se asegura de que estén listos para empezar la próxima iteración. Absolutamente NO. El Product Owner es quien gestiona y ordena los elementos del Product Backlog; su refinamiento corresponde al Product Owner y al Equipo de Desarrollo, y de este trabajo previo dependerá que lleguemos bien preparados a la Sprint Planning.

Mito: El Scrum Master dirige todas las reuniones dentro de Scrum. Rotundamente NO. Facilitar sí, pero su participación depende del evento que sea -por ejemplo, en la Daily Scrum ni siquiera ha de estar presente- y del estadio de autoorganización en el que el Equipo se encuentre.

Mito: El Scrum Master tiene que estar presente durante la Daily Scrum. No. Como acabamos de decir, la Daily es una reunión interna del Equipo de Desarrollo. La Daily Scrum que se convierte en “reporte” al Scrum Master es uno de los vicios comunes en el uso de Scrum.

Mito: El Scrum Master es el responsable último de entregar un resultado óptimo al cliente y de que el proyecto concluya con éxito. NO. El Scrum Master es responsable de gestionar impedimentos, de la promoción y buen uso de Scrum, de evitar despilfarros… Pero no del valor que se entrega. El valor ha de ser maximizado por el Product Owner, y el Equipo de Desarrollo debe entregar working software al final de cada Sprint. Por cierto, mejor hablar de “productos” que de “proyectos”.

Mito: El Scrum Master ha de proteger al equipo de toda posible interrupción. Este tipo de  frases me suenan a la clásica visión del Scrum Master como “protector” del Equipo, que lo aísla de cualquier interrupción. Si zumba una mosca, el Scrum Master la mata -o, mejor, la deja escapar por la ventana-. NO. El Scrum Master ayuda a los miembros de la organización a entender qué interacciones aportan o no al Equipo Scrum. Y el Equipo también tiene que aprender a gestionar interacciones que signifiquen despilfarro, sin esperar a que el Scrum Master intervenga.

Iremos actualizando mitos y leyendas a medida que nos sigamos topando con ellos. ¿Alguno más que quieras compartir? ¡Te leemos!

Vistos algunos de los mitos sobre lo que no es un Scrum Master, en este otro post hablamos sobre lo que sí que hace “el buen Scrum Master”.