Con muchos de nosotros trabajando desde casa estos días, he estado respondiendo más preguntas sobre si es una buena idea rotar el rol del Scrum Master.
Generalmente, no soy un fan de esto. No lo recomiendo. Es posible según la guía, pero no lo recomiendo.
Encuentro que rotar quién es el Scrum Master realmente no trata el rol con el respeto que merece. No lo honora como se debe.
Es como cuando mi esposa, mi hija y yo rotamos quién mete los platos en el lavaplatos después de la cena.
Ninguno de nosotros quiere hacer ese trabajo, por lo que rotamos quién se atasca con esta tarea.
No insistimos en que lo haga un experto en particular, porque creemos que el trabajo no requiere ninguna habilidad en particular.
Sin embargo, si soy partidario de rotar quién es el Scrum Master en dos situaciones específicas diferentes.
Primero, rotaré cuando un equipo sea completamente nuevo en Scrum y aún no sepa quién sería un buen Scrum Master. Esto tiene sentido, ya que les da a todos la oportunidad de probar el papel.
Eso ayuda a los miembros del equipo a determinar quién es bueno en eso. También ayuda a los miembros del equipo a identificar lo que encuentran beneficioso de su Scrum Master.
La otra vez que me gusta rotar el rol de Scrum Master es cuando aquellos que no son Scrum Master son irrespetuosos con el trabajo.
A veces me encuentro con miembros del equipo que actúan como si la única función del Scrum Master fuera servirlos. Esto lo podemos describir como la Scrum Police.
En esas situaciones, ocasionalmente rotaré a cada miembro del equipo a través del trabajo de Scrum Master. Esto les ayuda a relacionarse un poco mejor con los desafíos de ser un Scrum Master.
Hace unos años, le dije a un equipo que no me gustaba rotar el Scrum Master porque no trataba el rol con el debido respeto.
“Después de todo”, agregué, “no cambiamos quién es nuestro ingeniero de base de datos”.
La respuesta de una persona me sorprendió: “Quizás deberíamos”, dijo.
Procedió a explicar cómo ese equipo probablemente podría tener éxito en compartir las responsabilidades de la base de datos entre todos los miembros del equipo.
Una persona tomaría la iniciativa para realizar cambios en la base de datos en este sprint, otra persona en el siguiente.
Este argumento me inquietó: podía ver cómo funcionaría con el rol de ingeniero de bases de datos. De hecho, se lo había sugerido a numerosos equipos.
Pero algo parecía diferente entre la rotación del ingeniero de la base de datos y las tareas de Scrum Master.
Me pregunté sobre eso el resto del día. Esa noche me di cuenta de por qué veía las dos situaciones de manera tan diferente.
En el caso del ingeniero de bases de datos, el rol se compartía más de lo que se rotaba.
En el caso del Scrum Master, los equipos no intentaban compartir el rol, planeaban que una persona a la vez hiciera el trabajo por completo.
Cuando un trabajo se rota perpetuamente entre las personas, surgen varios problemas:
- Nadie se siente dueño del puesto
- La gente lo ve como una distracción de su “trabajo real”
- Un Scrum Master rotado a menudo siente menos presión para eliminar los impedimentos, ya que serán algún otro problema de Scrum Master en unas pocas semanas.
- El equipo se ve afectado por la inconsistencia de los enfoques
- Nadie pasa suficiente tiempo en el rol para volverse realmente bueno en él.
La mejor forma de evitar estos problemas es no rotar el rol. Elegir el mejor Scrum Master disponible y dejar que esa persona desarrolle las habilidades necesarias para ayudar al equipo a tener éxito con Agile.
