¡Oh no, yo contraté un Scrum Master y pensaba que era otra cosa!

En un post reciente explicaba el rol de Scrum Master y muchas de las tareas que lleva a cabo. Sin embargo, reflexionando mientras lo escribía, caí en la cuenta de que, a veces, este rol es malentendido y mal usado dentro de las compañías.

Quizá es porque venimos de una concepción del mundo laboral excesivamente jerárquica donde tenemos herencias del pasado y una necesidad de encontrar jefes y responsabilidades unipersonales.

Este caldo de cultivo heredado es, entre otros factores, uno de los motivos por los que en torno a la figura del Scrum Master han surgido con fuerza falsos mitos difíciles de desmontar. En este post explicamos cuáles son los malentendidos más frecuentes tratando de corregirlos.

Error 1: El tirano

Antes, en la informática previa al Manifiesto Ágil, teníamos jefes de proyecto, que se encargaban de coordinar y, sobre todo, mandar sobre los diferentes roles que tuviese en su equipo de desarrollo: analistas, desarrolladores, testers, etc.

Estos desarrollaban “el proyecto” mediante un engranaje llamado Waterfall/RUP en el que todo “fluía” pasando por requisitos, eternos documentos de análisis, desarrollos que se iban en el tiempo y ciclos interminables de test.

El jefe de proyecto era un semi-Dios, un tirano (por supuesto había jefes buenos, el problema era que el método que utilizaban no lo era) que todo lo sabía y que orquestaba mediante preciosos diagramas de Gantt que nunca se cumplían.

Cuando el cliente tenía un problema, ahí estaba el jefe de proyecto, para azuzar al equipo en la resolución de incidencias por la vía del látigo o en el desarrollo de nuevas funcionalidades: “¿cuánto te queda? ¿cómo vas? ¿lo tienes ya?”. Como si por repetirlo muchas veces el software se desarrollara más rápido.

Cuando llegó el Manifiesto Ágil y los framework como Scrum, que nacieron desde entonces, empezamos a hablar en “otro” lenguaje: liderazgo, equipos multifuncionales, producto en lugar de proyecto, entrega temprana de valor...

Pero no toda la compañía se adaptó. Se quedó en una tendencia de “los informáticos” cuando en realidad debía ir más allá, como un cambio de mentalidad organizacional (Transformación Digital), porque si no… no lo sabes, pero estás muerto.

Cuando una organización no está adaptada a este cambio de cultura, lo más normal es que haga la conversión de jefe de proyecto a Scrum Master de manera natural. Al fin y al cabo, lo ve como un jefe de equipo, de proyecto, de unidad, etc.

Error 2: La escoba

Otro malentendido común de esta figura es el de Scrum Master escoba. He escuchado el comentario de aquellos que piensan que el Scrum Master tiene “tiempo libre”, que puede que tenga su origen también en el desconocimiento de la figura tanto en los equipos de desarrollo como en las personas que desempeñan este rol.

Entonces, el escoba, equivocadamente, tiende a ocupar ese tiempo en perseguir las tareas que nadie quiere realizar por ser tediosas o motivar poco al equipo:

• El que agenda las reuniones de los eventos de Scrum, toma notas y realiza actas cual secretario.
• El que todos los días recuerda infructuosamente las buenas prácticas de Scrum.
• El que mira logs o código de una incidencia muy urgente que no atiende nadie.
• El que se encarga de recoger los post-it o actualizar tableros.

Este punto de ser el que va barriendo lo que nadie hace tampoco encaja muy bien con este marco de trabajo.

Es cierto que somos un equipo (aunque el Scrum Master no es un miembro del equipo de desarrollo, esto es importante) y está bien que todos nos ayudemos, pero no hay que caer en esta mala práctica, sino fomentar la corresponsabilidad y la colaboración entre todos.

Error 3: El apagafuegos

Al hilo de lo anterior, y elevado a la máxima potencia, tendríamos al apagafuegos que es “el escoba” pero que además debe resolver todos los problemas que se planteen, es decir, los famosos impedimentos.

Se dice que el Scrum Master “soluciona” impedimentos, pero no todo cabe en esta definición: ¿debe ser el que si a un desarrollador le falta un monitor lo pida? ¿Es que no puede hacerlo él mismo? ¿No es nuestra organización suficientemente ágil para dar solución a esa demanda? ¿Es que todavía en estos tiempos necesitamos interlocutores válidos, intermediarios, gente que dé aprobaciones o firmas, correveidiles y teléfonos escacharrados?

Cuando llegué a Paradigma necesité un monitor y puse un post-it en un tablero con mi necesidad y correo. Tras recibirse los suministros, lo tenía en mi mesa en menos de una semana, ¡eso es Agile!

Desde mi experiencia, algo que tenemos que trabajar de manera perseverante es la autoorganización. Es muy sencillo definir cómo queremos trabajar, pero muy difícil trabajar en la práctica de esa manera, con constancia y con responsabilidad, para llegar a resultados.

¿Alguien todavía piensa que Scrum es un marco de trabajo laxo y para holgazanes? Alguno decía esto de XP en su día. Para mí, es todo lo contrario, es exigente y mantiene en tensión a cada persona del equipo.

Sin embargo, hay gente que necesita una ayuda, ya que no está acostumbrada a esa autoorganización. En ocasiones, en mis equipos, ante la pregunta mágica de “¿qué hago ahora?” formulada por algún miembro del equipo directamente hacia mí como Scrum Master, me he girado hacia atrás y he preguntado: “¿con quién hablas?¿un fantasma?”.

Hay que buscar la manera de que la gente, que anteriormente se les ha tratado como serviles ovejas y se han acostumbrado a pedir permiso, se les dé la iniciativa y actúen con responsabilidad y dirección. A la tercera vez que he hecho esa broma a alguien del equipo, ha dejado de mirarme a mí, para mirarse a sí mismo y a su equipo.

He escuchado varias veces en mi vida profesional la frase “¡para lo que me pagan, que piense otro, que ejecute otro, que se responsabilice otro!”. Y esa excusa, la del dinero, como cualquier otra que se nos ocurra, no puede valer para todo, pues la profesionalidad está delante de todo esto.

Error 4: El representante

Y es que el Scrum Master tampoco es el representante del equipo en la Tierra, de manera que si alguien tiene que hacerse responsable de las acciones del equipo de Desarrollo, sea su portavoz. Tampoco si alguien quiere hablar con el equipo, actúe el Scrum Master de intermediario o que si tengo un problema con alguien se lo digo a Papá Scrum.

También dentro de este malentendido papel podríamos tener el reverso de la moneda: el protector Scrum Master que cuida de sus mochuelos hasta que un día, que posiblemente nunca llegue, salgan de su nido.

Así que esa corriente del ¡mola tener jefe! que me saque las castañas del fuego y que ponga la cara por mí en reuniones, tiene los días contados: somos responsables todos, como equipo, para lo bueno y para lo malo.

Error 5: El policía del Sprint

Además de todos los que se han visto influenciados o por su propia iniciativa han acabado en los anteriores (tirano, escoba, apagafuegos, representante,...), están aquéllos que deciden voluntariamente ejercer el papel del policía del Sprint: *sí, conozco qué es Scrum, conozco lo que promueve, así que voy a dedicar mi tiempo del Sprint a evaluar cómo hacéis como equipo “el Scrum”. Pero eso sí, no contéis conmigo para solucionar ningún problema, ni echar un cable cuando lo necesitéis… mi labor aquí es Scrum: ese ce erre u eme… *

Una cosa es ser Pepito Grillo del Scrum, cosa que todos hemos tenido que hacer en algún momento con algún despistado, y otra es llegar a este extremo.

Si os ponéis a pensar en vuestros entornos de trabajo, se os vendrán miles de ejemplos a la cabeza también, por supuesto ésta no pretende ser una lista cerrada. Os animo en los comentarios también a poner vuestras experiencias.

¿Hay algo de positivo en todo esto?

Ahora llega el momento de la parte positiva… Sí, la hay. Poco a poco y cada vez más, todo esto se entiende mejor y se hacen cada vez mejor las cosas.

Cada vez los clientes entienden mejor que no pueden vivir sin transformarse. Cada vez los equipos piensan más veces “¡mola comprometerse! que ¡mola tener jefe!”. Cada vez los profesionales de la industria de la informática están mejor formados. Cada vez ocurre menos eso de “¡oh no, yo contraté un Scrum Master y pensaba que era otra cosa!”.