Scrum Masters: El bueno, el feo y el malo

Hay una secuencia lógica que aquellos alumnos que han asistido al curso de Professional Scrum Master experimentan: Darse cuenta que Scrum no es en muchas ocasiones lo que ellos pensaban. Preguntarse qué hace el Scrum Master todo el día. Y una tercera que revelaré más adelante.

La mayoría de las organizaciones entienden al Scrum Master en un rango que va del Jefe de Proyecto latigador clásico al Psicólogo de equipo, pasando por el entretenedor y facilitador oficial. Sin embargo, esas no son sus funciones.

Lo que dice la guía de Scrum es: El Scrum Master se encarga de gestionar y mantener Scrum y de eliminar impedimentos. La primera parte está clara. Asegurarse de que Scrum funcione, bien explicando cual es el valor de cada uno de los elementos de Scrum (+10 Scrum Master) bien organizando y forzando a la organización a seguirlos (+0 Scrum Master).

La segunda está menos clara. La mayoría de las interpretaciones van por el camino de facilitarle la vida al equipo, facilitar que el equipo pueda entregar y facilitar que el producto salga adelante. Esto, que no deja de ser correcto, da lugar a ciertos problemas.

Muchos Scrum Masters con poca experiencia de verdad en Scrum optan por centrarse en el equipo. Facilitar que el equipo haga reuniones y que tenga las herramientas que necesitan a su disposición, en ocasiones encargándose personalmente del mismo.

Sin embargo, aquellos que tienen experiencia, dejarán al equipo de desarrollo autoorganizarse y se centraran en eliminar impedimentos a la agilidad organizacional: desde explicar y hacer entender el valor de Scrum hasta la interacción con la organización de desarrollo para incorporar mejores herramientas, pasando por identificar y explorar que mejoras internas se pueden hacer para que el equipo se autogestione mejor.

Si no lo has leído bien, lo repito. Los Scrum Masters más malos son aquellos que se centran en facilitarle la vida al equipo, impidiendo que sean ellos los que se auto gestionan, mientras que no promueven el cambio organizacional para que la organización mejore.

Un ejemplo: En uno de mis clientes, mientras que uno de los Scrum Masters se afanaba en ayudar al equipo a finalizar el testing para entregar al final del Sprint, otro explicaba a la organización cual es el valor de invertir en testing automatizado.

Una vez que el mensaje había calado, los equipos de desarrollo se hicieron cargo de implementar todo el proceso. El Scrum Master del primer equipo se quejaba de que ahora no tenía mucho que hacer. ¡Claro! Nunca había hecho realmente su trabajo.

Influenciar sin autoridad

En otro cliente, los Scrum Masters habían formado una especie de sindicato donde se reunían para llorar sus penas y exigir mejoras. Se llamaba el Scrum of Scrums. Al final, consiguieron que la organización los nombrara a todos Development Leads. A los pocos meses dejaron de hacer Scrum para hacer un híbrido que se inventaron. Hoy lo anuncian en twitter como la nueva revolución ágil.

El dilema del Scrum Master es precisamente ese: Cómo influenciar a la organización sin autoridad para hacerlo. Los Scrum Masters no deben de tener autoridad en la jerarquía funcional de la organización. Hacerlo supone dar un poder que no necesitan en primer lugar.

Mi día a día como Scrum Master

Cuando ejerzo de Scrum Master, generalmente no voy a los Daily Scrums ni facilitó Retrospectivas. Estas cosas bien puede hacerlas un equipo de desarrollo que se auto organiza. Cada vez que hago algo por el equipo que pueden hacer ellos, les estoy quitando una oportunidad de aprendizaje.

Así que me centro en lo que impide que el equipo de desarrollo y el producto avance. E intento evangelizar, apoyar, mentorizar y explicar cómo las cosas se pueden hacer ágilmente. Todo el tiempo libre que -deliberadamente- tiene el rol está para eso, no para arreglar teclados a los miembros del equipo de desarrollo.

Aquí llegamos a la tercera revelación de los alumnos del PSM: Eso es tremendamente difícil Jero. Ya. Lo se. Nadie dijo que fuera fácil. Fácil es tener un rol como el de Scrum Master y pintar dibujos a lo largo de toda la empresa mientras el conocimiento sobre Scrum es nulo, el pipeline de Delivery es desconocido y la empresa sigue funcionando por proyectos.

Además de fácil, es un poco irresponsable.