Un Scrum Master no tiene por qué saber hacer origami

Si te ha llamado la atención el título de este artículo debes de ser porque estás pensando: “¡Claro que no hace falta que un Scrum Master sepa hacer origami!”.

Si es así, vamos bien.
Permíteme entonces que te haga una pregunta: ¿por qué debería un Scrum Master saber programar (en cuantos más lenguajes de programación mejor), ser un experto de negocio y, además, estar dispuesto a hacer todo lo que haría un gestor de proyectos tradicional?
Eso es, por lo menos, lo que parece ser necesario si se echa un vistazo a la mayoría de ofertas de trabajo para ese tipo de rol.

Es más, incluso cuando la descripción del puesto está escrita de manera decente, aparentemente acorde a los valores y principios de Scrum, pueden pasar cosas bastante surrealistas, como el hecho de que, en un proceso de selección para Scrum Master, se acabe descartando a alguien por no tener “una experiencia sólida en empresas con productos online con mucho tráfico de usuarios”, por poner un ejemplo.

Vamos a ver.
De acuerdo con las fuentes oficiales*, “El Scrum Master es responsable de promover y apoyar Scrum como se define en la Guía de Scrum. Los Scrum Masters hacen esto ayudando a todos a entender la teoría, prácticas, reglas y valores de Scrum. El Scrum Master es un líder que está al servicio del Equipo Scrum. El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser útiles y cuáles no. El Scrum Master ayuda a todos a modificar estas interacciones para maximizar el valor creado por el Equipo Scrum.”

No entiendo, pues, cómo es posible que en algunas ofertas para Scrum Master se encuentren requisitos del tipo “experiencia trabajando con SOAP, Spring, Struts y J2EE”.

Me parece todavía menos acertado el hecho de que, muy a menudo, se requiera experiencia previa como gestor de proyectos y, peor aún, ganas de seguir haciendo cosas que muy poco tienen que ver con el control empírico de procesos, y mucho más con la gestión de proyectos tradicional (planificación en coste, tiempo y alcance, diagramas de Gantt, monitorización del rendimiento individual, etc.).

Tampoco me entra en la cabeza la obsesión que hay con Jira —como si no fuera posible poner en práctica los valores y principios de Scrum sin utilizar esa herramienta— y con las certificaciones —como si una prueba de opción multiple pudiera certificar que alguien realmente cree en los valores y principios de Scrum (y, más en general, de la agilidad), los practica, sabe transmitirlos, fomentarlos, etc.

Dicho de otra manera, como que la mayoría de requisitos que se suelen tener en cuenta en los procesos de selección para Scrum Master no tienen nada que ver con lo que es realmente necesario para ser un buen Scrum Master, recomendaría no utilizarlos para discriminar: ni para bien, ni para mal.

Lo que sí se debería evaluar es si la persona en cuestión tiene capacidad de liderazgo y sabe ponerla al servicio del equipo, si sabe escuchar, hacer preguntas, comunicar con todo tipo de interlocutores, y, por encima de todo, si es coherente —¿realmente cree en los valores y principios de la agilidad o sólo es capaz de repetirlos como un papagayo?

Por supuesto que no está mal que un Scrum Master sepa de SOAP, Spring, Struts y J2EE; pero no tener experiencia en eso no debería ser motivo de descarte.

De la misma manera, tener una certificación no debería ser considerada condición necesaria ni suficiente para hacer de Scrum Master.
Lo que realmente importa es la actitud.

Por eso mismo, estoy convencida de que un buen gestor de proyectos puede llegar a ser también un buen Scrum Master, siempre y cuando sea capaz de entender el cambio de actitud que se necesita para pasar de un rol a otro.

Y no, no hace falta tener un máster en Jira para ser un buen Scrum Master.
Ni saber hacer origami.

(*) He puesto el enlace a la versión de la Guía de Scrum en español de Sudamérica, porque la versión disponible en castellano es de peor calidad.