El Scrum Master es un gerente de proyectos con un poco menos de responsabilidad y un tercio del salario

¿Y qué le queda al Scrum Master? Imagino la conversación entre Sutherland y Schwaber sobre qué incluir como responsabilidades del Scrum Master:

- El Scrum Master va a garantizar y reforzar Scrum para todos los miembros del equipo.

- Estoy de acuerdo.

- Pero... ¿eso no es demasiado poco para hacer 8 horas al día, 5 días a la semana?

- Hmm... tienes razón.

- ¿Qué podemos asignarle al Scrum Master? Parece que todas las actividades ya están asignadas al equipo o al Product Owner.

- No sé, ¿quizás los reportes?

- No. Usamos el burndown por defecto y, aparentemente, eso es suficiente.

- ¿Organizar las invitaciones a las reuniones?

- No. Los eventos ya existen y no hay necesidad de crear más reuniones.

- Entiendo. Digamos que el Scrum Master debe remover impedimentos cuando el equipo tenga problemas.

- Considerando que una User Story debería entrar en el sprint solo cuando todos la entienden y no existen blockers conocidos, tal vez no haya mucho que remover.

- Sí, pero al menos ahora hay algo que decir.

- Ok, de acuerdo.

No sé si esa fue realmente la conversación, pero no me sorprendería que lo hubiera sido. Al final, muchas veces parece que el rol del Scrum Master fue creado con buenas intenciones, pero sin suficiente peso práctico para justificar lo que el mercado pasó a esperar de él.

Pero el mercado no es tonto. Rápidamente percibió que el camino natural para muchos exgerentes de proyecto era convertirse en Scrum Masters. ¿Por qué? Porque un buen gerente de proyectos ya remueve blockers, negocia prioridades, gestiona problemas, protege al equipo y ayuda a que el trabajo avance.

Sin embargo, un gerente de proyectos tradicionalmente hace mucho más que remover blockers. Un gerente de proyectos evalúa riesgos, gestiona stakeholders, controla el alcance, monitorea plazos de entrega, organiza la comunicación, acompaña costos, apoya la calidad y, a veces, incluso gestiona contratos. Ya he visto muchos Scrum Masters haciendo exactamente estas cosas — gestionando costos del proyecto, calidad, proveedores, riesgos, reportes ejecutivos y expectativas de los stakeholders.

En otras palabras: prácticamente un gerente de proyectos.

Y esto no pasó desapercibido para el mercado. Desde mi punto de vista, la oportunidad que el mercado vio fue simple: atribuir las responsabilidades de un gerente de proyectos a un Scrum Master, pagar menos y llamar a eso Agile.

El problema es que esto crea más problemas de los que resuelve. Aquí hay algunos motivos:

• Un Scrum Master, en muchos casos, no estudió las disciplinas más amplias de gestión de proyectos, como gestión de stakeholders, gestión de la comunicación, control de costos, gestión de riesgos, gestión de alcance y gobernanza.
• Generalmente, el Scrum Master no es formalmente responsable por los costos del proyecto. Otro gestor lo es. Esto crea una brecha entre quien ve el trabajo diario del equipo y quien es responsable por el presupuesto.
• Si el gestor responsable por los costos interviene, muchas veces no sabe qué hacer porque no está lo suficientemente cerca de las actividades diarias del equipo.
• Habrá situaciones que forzarán a un Scrum Master “by the book” a ejecutar actividades de gestión de proyectos. Esto puede convertirse en el inicio de una relación con un empleado insatisfecho, de quien se espera más de lo que el rol prometía originalmente.
• Como el Scrum Master tiene menos responsabilidades oficiales — al menos en teoría — normalmente recibe solo una parte del salario que recibiría un gerente de proyectos. Pero, en la práctica, la persona termina sobrecargada con trabajo de gestión de proyectos, sin el título, la autoridad o la remuneración de un gerente de proyectos.

El resultado es previsible: entregas con poco control, reportes que no dicen casi nada a los ejecutivos, baja visibilidad sobre costos y riesgos, y profesionales que o no ejecutan las actividades impuestas por el mercado porque no saben cómo hacerlo, o no las ejecutan bien porque están insatisfechos por ganar la mitad — o incluso el 30% — de lo que ganaba un gerente de proyectos.

Este es uno de los dolores que Saint Jude intenta ayudar a resolver. Cuando las empresas eliminan el rol del gerente de proyectos, pero todavía necesitan visibilidad sobre costos, cronograma, performance, riesgos, estimaciones, calidad de las tasks, desvíos de sprint y previsibilidad de entrega, alguien todavía necesita proporcionar esa inteligencia. Saint Jude puede actuar como una capa de inteligencia de proyectos sobre herramientas como Jira, ClickUp, Azure DevOps, Monday.com y Asana, ayudando a PMOs y liderazgos a entender qué está sucediendo en el proyecto sin fingir que un burndown chart es suficiente para gestionar costos, riesgos, alcance y expectativas ejecutivas.

Al final, el problema no es Scrum en sí. El problema es fingir que un framework eliminó la necesidad de gestión. No la eliminó. Solo cambió el lenguaje. Los costos todavía existen. Los riesgos todavía existen. Los stakeholders todavía existen. El alcance todavía existe. Los problemas de comunicación todavía existen. Los retrasos todavía existen. Y alguien todavía necesita gestionar todo eso.

Entonces sí, en muchas empresas, el Scrum Master se convirtió en un gerente de proyectos con menos autoridad, menos responsabilidad en el papel, menor salario y más confusión sobre lo que realmente se espera que haga.

Y tú, ¿qué piensas sobre esto? ¿Ya viviste situaciones parecidas a las descritas arriba? Dale like a este artículo corto, comenta en LinkedIn o compártelo en tus redes sociales.

¡Hasta pronto!

Erik Scaranello