A veces no es posible tener a un Scrum Master dedicado a tiempo completo a un único Equipo. Sería lo deseable, pero no siempre va a ser económicamente viable para la empresa. Esto hay que entenderlo, y no por ello dejamos de hacer Scrum “de manual” -la Guía Scrum nada menciona sobre el hecho de que el Scrum Master sea un rol a tiempo completo o parcial-.

¿Qué opciones se nos plantean en estos supuestos?

1/ El Scrum Master es parte de un solo Equipo Scrum, pero es también miembro del Equipo de Desarrollo (programador, tester, diseñador, etc.). Este escenario es muy típico. Nos solemos encontrar con un lead developer o similar que asume el papel de Scrum Master. Aunque perfectamente factible, esta situación implica riesgos de los que debemos ser conscientes:

– Falta de tiempo para desempeñar ambas funciones. Casi seguro deberemos evitar que esta persona, en su faceta como miembro del Equipo de Desarrollo, asuma tareas críticas, en tanto que podrían verse afectadas si tuviera que atender a sus responsabilidades como Scrum Master.

– Conflictos de intereses. Imaginemos que el Sprint “va mal”. Que el Objetivo del Sprint está en el alambre y solo se conseguirá si terminamos varios de los elementos del Sprint Backlog aún en curso. En esta tesitura, está claro qué “sombrero” primará: el Equipo se quedará temporalmente sin Scrum Master y el desarrollador hará lo que mejor sabe hacer, programar.

– Esta dicotomía puede afectar igualmente a todo tipo de debates y conversaciones dentro del Equipo: ¿Quién habla, el Scrum Master o el miembro del Equipo de Desarrollo? Este es el mayor riesgo de todos. El Scrum Master debe guiar al Equipo, no decirle cómo hacer su trabajo. Claro que, cuando el Scrum Master es también el lead developer y empieza a sugerir cómo tiene que ser una determinada implementación técnica… De nuevo, el rol de Scrum Master puede quedar relegado con facilidad.

2/ El Scrum Master trabaja con varios Equipos Scrum. Este escenario es preferible al anterior, puesto que el Scrum Master ejerce como tal a tiempo completo, aunque distribuyendo su atención entre diversos Equipos. Además, se evitan los conflictos de intereses antes descritos relativos a la dualidad Scrum Master – miembro del Equipo de Desarrollo.

Cuando el Scrum Master “sirve” a distintos Equipos, seguramente centrará más esfuerzos en unos que en otros, según la etapa en la que se encuentren –dentro del famoso modelo de Tuckman-. Por ejemplo, si el Scrum Master trabaja con un Equipo de Desarrollo ya muy rodado, de alto rendimiento, y con otro que acaba de formarse, sin experiencia en el uso de Scrum y Agile, lo normal será que invierta más tiempo en el segundo.

No hay ninguna regla acerca de con cuántos equipos puede actuar un mismo Scrum Master. En mi opinión, dos es un buen número. Tres puede funcionar. Más allá de tres creo que es poner demasiada presión sobre el Scrum Master; haremos que pierda foco y que su impacto se diluya.

Imagen: Foto de Negocios creado por master1305 – www.freepik.es