¿Debe ser un Scrum Master un “One-club man”?

Un integrante del “One-club Men” es un deportista que empieza y acaba su carrera en un único club. Lógicamente esto es un gran honor que hace que los aficionados de ese club tengan en muy alta estima a este deportista.

El caso más reciente en el mundo del fútbol es el del italiano Francesco Totti, que jugó en la Roma la friolera de 25 temporadas y se retiró el pasado verano.

Quizá en los tiempos que corren, pedir que alguien esté toda su vida profesional en una empresa es casi una misión imposible, pero llevándolo al tema que me ocupa, la pregunta que me hago es: ¿debe ser el Scrum Master una figura dedicada en toda su jornada laboral a un único equipo? ¿Debe jugar en un único club?

Las voces a este respecto son algo discordantes y, tanto en la red como en la calle, podemos encontrar opiniones a favor y en contra.

Incluso algunos comentarios van en la línea ya no sólo de que esté dedicado a un único equipo, sino que el Scrum Master no tiene por qué ser un rol de tiempo completo, o incluso rotar entre los diferentes integrantes del equipo de Desarrollo.

Tras un tiempo trabajando en este rol dentro de un equipo Scrum puedo, aportar algunos argumentos y dejar que el avezado lector decida (aunque al final de todo, daré mi opinión).

Argumentos que hacen pensar en una dedicación total a un equipo

El Scrum Master tiene muchas tareas que realizar, pero muchas, muchas. De hecho, con el modelo tradicional de trabajo utilizado durante años en España (jerarquizado), hemos asociado de una manera natural al antiguo jefe de proyecto en la figura del Scrum Master. Pero nada más lejos de la realidad.

El Scrum Master es líder silencioso, eliminador de impedimentos, bandera y Pepito Grillo del Scrum. Es, en ocasiones, formador y, otras veces, formado, es la escoba que va barriendo lo que otros no alcanzan.

Es un innovador nato, nunca se queda parado: ni con los tablones físicos y/o digitales, ni de dejar de mejorar las prácticas ágiles del equipo, ni de hablar de las virtudes del Agilismo. ¡Ah! y tiene algo de coaching y de mentoring que no podemos obviar.

También podríamos entrar ahora a decir lo que no es un Scrum Master (un tirano, un secretario o un correveidile, por ejemplo), pero quizá no es este el post. Así que, quizá, en otro post podamos abordar la otra visión negativa que se tiene del Scrum Master.

La tarea que parece que todos tenemos clara es que el Scrum Master asegura que los eventos de Scrum (Daily Scrum, Sprint Planning, Sprint Review, Sprint Retrospective y Sprint) se desarrollan correctamente. Ni siquiera es dirigir esos eventos, ni asistir en muchos casos. Simple y llanamente: asegurar que se producen y que se realizan tal y como marca la guía.

A esto le podríamos sumar el garantizar que los artefactos de Scrum (Product Backlog, Sprint Backlog e Incremento) existen y se enmarcan en lo definido por el equipo Scrum (Definition of Ready y Definition of Done).

Alrededor de esto podríamos hablar de los tableros y los irradiadores de información. Físicos o digitales. A cada equipo le puede valer uno u otro (incluso una conjunción de ambos), pero lo que sí tenemos que saber es que es algo vivo, actualizado y que debe cambiar cada poco para tener su efecto Wow sobre el equipo.

A menudo nos encontramos con equipos que han estado realizando un “Scrum but” (si quieres saber más de esto os recomiendo este vídeo y post, de mi compañero Javier Martín de Agar) y hay que realizar una tarea de formación y de eliminar “malas interpretaciones”.

Además, los equipos no siempre están en su fase más productiva (Performing), sino que encontramos equipos en estados más tempranos (Forming, Storming, Norming) y ahí también el Scrum Master tiene su papel que desempeñar: aupando al siguiente nivel y resolviendo conflictos. Y ayudando a alcanzar la autoorganización, cosa que desde mi experiencia, es lo más complicado de todo.

Y la tarea de ser reflejo y ejemplo de los valores de SCRUM para otros, el equipo y la organización: coraje, foco, compromiso, franqueza y respeto. ¡Se dice pronto!

Como decía anteriormente, es la escoba donde otros no llegan. El Product Owner puede ser relativamente nuevo en Agile y en su tarea de refinamiento del producto necesita ayuda para dividir historias de usuario o escribir criterios de aceptación.

Un buen Scrum Master ayudará con formación y enseñará buenas prácticas (Plan de Releases, por ejemplo) para facilitar esta tarea que luego repercutirá sobre el Equipo de Desarrollo. Hay un vídeo interesante que entra más en detalle en este tema.

También puede colaborar con el equipo en mantener los tablones o JIRA, proponer prácticas novedosas para mejorar el desempeño… Un caso mío personal ha sido la de pensar y repensar el tablón físico del Sprint hasta dar con la tecla de la mejor representación (hasta la fecha) para el equipo de Desarrollo, pero cada Sprint le damos una nueva vuelta.

Por otro lado, decimos que el Scrum Master tiene en sus tareas formar y, por tanto, debe ser formado: ¿acaso alguien puede poner coto a su formación? Esto es una tarea del día a día. Si no tengo yo conocimiento, ¿cómo voy a dar a los demás?

Al final, el Scrum Master debe estar también al día en lo técnico y ser conocedor del negocio, por tanto debe formarse en ese ámbito para ayudar más al equipo.

Y algo que no podemos olvidar: ¡el Scrum Master es un revolucionario! ¡Tiene vocación de cambiar el mundo! O al menos, de fomentar el cambio y la innovación en los equipos y sobre todo, en las organizaciones. Eso se dice (y se escribe) pronto, pero también requiere su espacio y su tiempo.

¿No te parece suficiente?

Argumentos que aportarías para dedicarse a más de un equipo

Si bien la cantidad de tareas del Scrum Master puede justificar claramente que sea un rol de tiempo completo (y eso por supuesto no lo pongo en duda), la duda que me han planteado en ocasiones es si debe estar en un único equipo. Vemos a continuación algunos de los argumentos más usados para creerlo así.

Equipos muy experimentados

En equipos con gran trayectoria alguien podría argumentar que no es necesario. Si total, ya conocen Scrum perfectamente y han ido a muchos cursos de formación y llevan años practicando algo que alguien les dijo alguna vez que era Scrum. Cuidado con esto, hay mucha gente que cree usar Scrum pero no lo hace correctamente.

Suponiendo que se realiza correctamente, la teoría dice que el Scrum Master no tiene por qué asistir a algunos eventos (como los Daily Scrum Meetings) y eso es bueno en ocasiones, para evitar la “tutela” de ciertas reuniones y fomentar la autoorganización, pero yo diría incluso lo contrario y es que con más razón estar presente en eventos en equipos contrastados: rompe las cadenas, libera las cuerdas… ¡cambia las dinámicas e innova!

Equipos muy pequeños no necesitan un Scrum Master

Otro argumento es que en equipos muy pequeños o con un desarrollo de producto de muy corta trayectoria, al existir menos diálogo en eventos, ser más clara y fluida la comunicación, menor la capacidad del equipo para construir un producto, no sería necesario tampoco un Scrum Master a tiempo completo.

A lo mejor es que Scrum no es el marco de trabajo que necesitas y te vale simplemente con unas pequeñas buenas prácticas de Agile.

Los Sprints son muy cortos

Lo mismo con Sprints muy cortos: los eventos se reducen en su duración y por tanto podría atender a varios equipos, aunque con Sprints muy cortos, el Incremento se da también cada menos, con lo que muchas veces la dinámica, la rueda gira demasiado rápido… ¡Pues más razón una persona que ayuda a adaptar la visión o a definir el producto!

Equipos con prácticas de trabajo estrictas

O en organizaciones donde los equipos trabajan de la misma manera con unas mismas reglas del juego marcadas y no requiere tanta “innovación” en las prácticas, ¿por qué no podría llevar más de un equipo en estas circunstancias?

Pues porque… ¿entonces qué autoorganización fomentamos en un entorno donde se marcan unas directrices de herramientas, prácticas ágiles, etc. de donde ningún equipo puede salirse?

Está claro que hay una parte de su trabajo que puede re-aprovechar en varios equipos (cambio organizacional, innovación, formación) y que si tiene suficiente experiencia y muchos materiales preparados o tiene una comunidad ágil detrás con una gran biblioteca de recursos.

En ese caso, quizá hay tareas a las que no dedique tanto, pero nunca puede dejar de innovar y menos aún con la velocidad en la que suceden las cosas en nuestro mundo.

Si el proyecto cuenta con Product Owner

También y por último, si hay Product Owner plenamente comprometidos y expertos en el marco de trabajo de SCRUM, la parte de ayuda a esta figura se reduce.

¿Seremos capaces de poner fin al debate?

Si todos estos condicionantes anteriores se han dado, entonces quizá lleguemos un día en el que ya no haya que cambiar el mundo y no harán falta Scrum Master. Pero hasta entonces... ¡seguiremos dando el callo!

Como digo, Scrum Master a tiempo completo sí. Y a la pregunta de la plena dedicación a un equipo creo que la lógica nos dice que sí, entre otras cosas por el coste de los cambios de contexto, que en la práctica nos harían perder a ese Scrum Master en el camino entre dos (o más) productos y ya sabemos que quien mucho abarca, poco aprieta.