Los efectos de no contar con un Scrum Master en un equipo Scrum

¿Qué pasaría si te dijera que en algunos equipos que están iniciando Scrum creen que pueden hacerlo sin un Scrum Master? ¿Qué crees que pasaría? ¿Te ha pasado? Si de cajón piensas que la probabilidad de éxito disminuye considerablemente, estás en lo correcto, sin embargo, ¿qué pasa si experimentas esta situación? ¿sabes qué hacer? si quieres saber más, sigue leyendo.

¿Por qué ocurre eso?

La respuesta que se nos viene en mente es porque el equipo no conoce la guía Scrum, el cual se resuelve con que el equipo lo lea y mejor si se certifica. Esta puede ser una respuesta obvia, sin embargo, hay algunos factores que intervienen en la causa de este dilema, por ejemplo, que pasa si los equipos tienen experiencia en proyectos tradicionales, ¿será suficiente ponerlos a leer la guía y que la apliquen? Puede que la solución no sea tan sencilla, dependerá de la resistencia al cambio de estas personas para adoptar Scrum, algunos no tendrán problemas en adoptarlo, mientras que otros si se resistirán y querrán aplicar prácticas tradicionales en un proyecto Scrum. Otra razón pueda ser que se asuma que el rol de un Scrum Master es equivalente a la de un gerente de proyecto, esto hace que autocráticamente (decisión de la gerencia) se asigne al gerente de proyecto con ese rol, pero en la práctica no lo ejerce, es decir, no ayuda al equipo a adoptar Scrum ni los ayuda a resolver impedimentos, puede que se ocupe en hacer lo que sabe, impactando negativamente en el desempeño del equipo. Otra razón es que el equipo no pudo encontrar a un Scrum Master y sus actividades la delegan en el Product Owner, por lo que el rendimiento de éste disminuye. En ocasiones, los proyectos arrancan sin un Scrum Master y no es una opción esperar a tenerlo.

¿Cuál son las consecuencias de no tener un Scrum Master?

Si el equipo está recién formado y no tiene experiencia en Scrum puede ocurrir varias situaciones, por ejemplo:

• No tengan claro para que funciona la Daily, la Retrospectiva y la Review. En algunos casos, no sabrán como dirigirla, harán reuniones adicionales debido que no han podido cumplir los objetivos de estos eventos ni cumplir con las cajas de tiempo.
• La Sprint Planning se extiende más de la cuenta, no utilizan prácticas como Planning póker porque no la entienden y prefieren utilizar prácticas de enfoque tradicional.
• Tienen problemas en ordenar y refinar el Product Backlog para el Sprint actual, impactando en el desempeño de los desarrolladores.
• Los usuarios finales o algún interesado(gerencia) pueden estar incomodos con no tener un alcance definido y soliciten un compromiso por parte del equipo para los siguientes Sprints, haciendo que el equipo realice actividades (predictivas) adicionales y generan atraso en los Sprints. No hay un Scrum Master que ayude a los interesados a clarificar los conceptos de Scrum.
• Los Sprints no terminan, el equipo cree que si se comprometió a entregar 20 historias (por ejemplo), debe entregarlo si o si, esto puede hacer que los Sprints no terminen, y probablemente arranquen con el siguiente Sprint para no seguir atrasándose, ocasionando muchos problemas al equipo.
• Problemas de autogestión en el equipo, hace que se improvise en la gestión, como colocar a un jefe para organizarlos, si tienen suerte, este jefe será un líder y los ayudará a mejorar en tomar decisiones y como equipo, hacerse responsable del trabajo que hacen.
• El equipo no tiene claro el objetivo del Sprint, no sabe a dónde va, solo algunos tienen una idea, pero no la comunican al resto del equipo.
• El compromiso para terminar a tiempo puede no existir, no hay alguien que les ayude a tomar consciencia de acabar el trabajo.
• No utilizar las herramientas apropiadas como Burndown, flujo acumulado o tablero Kanban.

La lista puede seguir, cada proyecto es único, ya sea por el contexto del proyecto, la cultura de la organización, los interesados o los miembros del equipo que conforman el equipo Scrum.

¿Qué hacer?

La respuesta simple seria ¡colocar a un Scrum Master! pero ¿cómo hacerlo? en especial si el equipo está ocupado en resolver problemas con las herramientas que tiene o lo que sabe hacer mejor. Algunas sugerencias son:

• Hablar con la persona que toma las decisiones gerenciales, puede ser el patrocinador, esto tiene que venir desde arriba, aunque es importante que el equipo sea consciente en la necesidad de un Scrum Master, puede llevar tiempo hacerles consciencia de ello y luego tendrán que ir a hablarlo con la gerencia, esto puede llevar mucho tiempo que no se tiene.
• Evidenciar el rendimiento del equipo o el tiempo que ocupa algún miembro del equipo Scrum (Product Owner o desarrolladores) en realizar las actividades del Scrum Master.
• Reforzar la necesidad de los roles del equipo Scrum, si se tomó la decisión que un Gerente de Proyecto es el equivalente a un Scrum Master, se puede demostrar con hechos (punto anterior) que esta estrategia está teniendo inconvenientes.
• Al contar con un Scrum Master, tendrá que trabajar en varios aspectos según sea la prioridad para ese equipo, por ejemplo:
• Asegurarse que el equipo aplique los eventos y artefactos de Scrum correctamente.
• Apoyar al equipo a tener claro el objetivo del Sprint.
• Apoyar al Product Owner para que el Product Backlog esté refinado lo necesario para que se pueda utilizar en el Sprint actual.
• Apoyar en la autogestión del equipo, esto puede llevar un tiempo.
• Ayudar al equipo a resolver impedimentos.
• Puede ser el mediador entre el Product Owner y los desarrolladores.

El rol de un Scrum Master es muy importante para que los equipos puedan adaptarse a los cambios en los proyectos y puedan tomar decisiones lo más pronto posible a través del coaching. Tener un equipo Scrum completo (Scrum Master, Product Owner y desarrolladores) mejora el rendimiento del equipo, no tenerlos generará bastantes inconvenientes para alcanzar el objetivo del proyecto. Si deseas saber más sobre la gestión de proyectos, te invito a leer el libro: «Creando valor con proyectos ágiles».

Otros artículos:

La autogestión en los equipos

¿Cómo aplicar la mejora continua en equipos agiles?

La transparencia en los proyectos agiles

Creando valor en los proyectos

Acerca del autor:

Jorge Paz es Coach, Consultor y autor de los libros «Creando valor con proyectos ágiles» y «Transforma la incertidumbre en oportunidades «. Con más de 10 años en la gestión de proyectos. Ha trabajado en proyectos en varios países de Latinoamérica apoyando a equipos de proyectos en alcanzar sus objetivos.