¿Qué es un Scrum Master?

El Scrum Master es una de las responsabilidades definidas dentro de Scrum y su función está relacionada con ayudar al Scrum Team y a la organización a comprender y aplicar el framework de forma efectiva.

No debería ser el jefe del equipo, no distribuye tareas como un gerente tradicional y tampoco debería convertirse en una especie de policía de la Daily Scrum. Su trabajo está mucho más relacionado con facilitar Scrum, apoyar la autogestión del equipo, ayudar a eliminar impedimentos y contribuir a que el Scrum Team sea cada vez más efectivo.

La distinción es importante porque existe una situación que he visto repetirse muchas veces: una empresa adopta Scrum, elimina al gerente de proyectos de la estructura y, algunas semanas después, empieza a preguntarle al Scrum Master por presupuesto, cronograma, riesgos, dependencias, proveedores, stakeholders, capacidad, previsibilidad y reportes ejecutivos.

Es decir: eliminamos al gerente de proyectos, pero aparentemente olvidamos eliminar todos los problemas que gestionaba.

¿Qué hace un Scrum Master?

Cuando alguien pregunta qué hace un Scrum Master, la respuesta parece sencilla hasta que observamos lo que ocurre realmente dentro de las empresas.

Dentro de Scrum, el rol está orientado a ayudar al equipo a trabajar mejor con el framework. Esto incluye apoyar la autogestión, mejorar la efectividad del Scrum Team, ayudar a remover impedimentos, contribuir a que los eventos tengan propósito y colaborar con el Product Owner, los Developers y la organización para mejorar la forma en que Scrum es utilizado.

El problema empieza cuando la expresión “remover impedimentos” se convierte en una categoría universal donde colocamos cualquier cosa que nadie sabe exactamente a quién asignar.

Si un proveedor se retrasa, alguien llama al Scrum Master. Si existe una dependencia con otro equipo, el Scrum Master empieza a perseguirla. Si un stakeholder está presionando, se espera que ayude a resolver la situación. Si la sprint está comprometida, se le pregunta qué hará al respecto. Si un ejecutivo quiere saber cuándo terminará la iniciativa, no sería extraño que el Scrum Master terminara preparando parte de la respuesta.

Poco a poco, “ayudar al equipo a utilizar Scrum y ser más efectivo” empieza a transformarse silenciosamente en “ocúpate de todo lo que está dificultando la entrega”.

Y eso empieza a parecerse bastante a otra profesión que conocemos desde hace décadas.

¿Cuáles son las responsabilidades del Scrum Master?

Las responsabilidades del Scrum Master están relacionadas principalmente con Scrum y con la efectividad del Scrum Team. En la práctica, podemos resumir buena parte del rol en actividades como:

• Ayudar al equipo a comprender y aplicar Scrum.
• Apoyar la autogestión y la capacidad multidisciplinaria del equipo.
• Ayudar a eliminar impedimentos que dificulten el progreso.
• Apoyar al Product Owner y a los Developers en el uso adecuado del framework.
• Contribuir a que los eventos de Scrum tengan propósito y sean productivos.
• Trabajar con la organización para mejorar la adopción de Scrum.
• Ayudar al Scrum Team a mejorar continuamente su efectividad.

Observa ahora todo lo que no aparece naturalmente dentro de esa definición: administrar el presupuesto global del proyecto, controlar contratos, gestionar proveedores, consolidar riesgos corporativos, mantener un cronograma general, responder por margen financiera o producir reporting ejecutivo para un board.

Esto no significa que esas actividades hayan dejado de existir. Significa simplemente que Scrum no las colocó bajo la responsabilidad formal del Scrum Master.

Y esa pequeña diferencia genera una cantidad sorprendente de problemas dentro de algunas organizaciones.

¿El Scrum Master es un Project Manager?

No. Al menos no según Scrum.

Esta distinción debe quedar clara porque afirmar simplemente que Scrum Master y Project Manager son lo mismo sería técnicamente incorrecto. El Scrum Master trabaja sobre Scrum y sobre la efectividad del equipo. Un Project Manager, dependiendo de la organización y del modelo utilizado, puede tener responsabilidades mucho más amplias relacionadas con presupuesto, cronograma, riesgos, comunicación, proveedores, alcance, stakeholders, gobernanza, dependencias y resultado general del proyecto.

Pero aquí aparece la parte que considero mucho más interesante: que los roles sean diferentes en la teoría no significa que sigan siendo diferentes cuando llegan a la empresa.

He visto Scrum Masters gestionando riesgos, preparando reportes ejecutivos, negociando dependencias entre equipos, coordinando proveedores, haciendo seguimiento de entregas, acompañando costos, respondiendo preguntas de stakeholders y tratando de predecir cuándo terminaría una iniciativa.

En otras palabras, realizando una cantidad bastante razonable de actividades que unos años antes probablemente habrían estado bajo la responsabilidad de un gerente de proyectos.

Scrum Master vs Project Manager: ¿cuál es realmente la diferencia?

La diferencia entre Scrum Master y Project Manager se vuelve mucho más clara cuando dejamos de mirar únicamente las ceremonias y empezamos a observar la responsabilidad sobre el resultado.

Tradicionalmente, el gerente de proyectos existe porque alguien necesita observar el proyecto como un sistema completo. Existen presupuesto, plazo, alcance, riesgos, personas, proveedores, dependencias, calidad, expectativas y diferentes áreas intentando llevar la iniciativa en direcciones distintas.

El Scrum Master, en cambio, no está definido por Scrum como la persona responsable de administrar todo ese sistema. Su foco está en ayudar al Scrum Team y a la organización a trabajar mejor utilizando el framework.

Y eso nos lleva a una pregunta que, desde mi punto de vista, muchas implementaciones Agile nunca respondieron correctamente: si eliminamos al Project Manager, ¿quién pasó a gestionar todo aquello que no desapareció con él?

En algunas organizaciones la respuesta puede ser un Program Manager. En otras será un Delivery Manager, Engineering Manager, Product Manager, PMO o alguna combinación de estas funciones. No veo ningún problema en ello.

El problema aparece cuando la empresa no asigna formalmente esas responsabilidades a nadie y espera que sean absorbidas informalmente por el Scrum Master.

Scrum puede eliminar el cargo, pero no elimina la gestión

Esta es probablemente la parte más provocativa de mi opinión sobre el tema. Durante años he visto organizaciones discutiendo si necesitan o no gerentes de proyectos en ambientes Agile como si eliminar un cargo del organigrama tuviera algún poder mágico sobre los problemas reales de una empresa.

Puedes eliminar al gerente de proyectos, pero el costo del proyecto seguirá existiendo. El stakeholder seguirá preguntando cuándo estará lista la entrega. El proveedor seguirá retrasándose. Los riesgos seguirán materializándose. Las dependencias entre equipos seguirán bloqueando trabajo. Y alguien de Finanzas seguirá queriendo saber por qué consumimos una parte enorme del presupuesto sin haber entregado una proporción equivalente del resultado esperado.

Lo que desapareció fue el cargo.

La necesidad de gestión continuó exactamente donde estaba.

Y entonces el Scrum Master empieza a convertirse en gerente de proyectos

Es aquí donde la provocación que dio origen a la primera versión de este artículo empieza a tener sentido. No estoy diciendo que Scrum Master sea Project Manager. Estoy diciendo que algunas empresas eliminan una función y empiezan, poco a poco, a trasladar partes de esa función hacia otra persona.

Primero, el Scrum Master ayuda con un impedimento. Después empieza a acompañar una dependencia externa. Más tarde alguien le pide actualizar un status. Luego empieza a hablar con stakeholders, aparece un registro de riesgos, alguien solicita una previsión de entrega y, cuando nos damos cuenta, esa persona que debía ayudar al equipo a utilizar Scrum está realizando coordinación de delivery, gestión de riesgos, comunicación ejecutiva, seguimiento de cronograma y parte de la gestión de stakeholders.

Y puede estar haciendo todo esto sin haber recibido necesariamente la formación adecuada, la autoridad necesaria o el reconocimiento formal correspondiente.

En ese momento, decir “somos Agile y ya no necesitamos gerentes de proyectos” empieza a parecer menos una transformación organizacional y más una redistribución silenciosa de trabajo.

El problema no es pedir más al Scrum Master

Quiero dejar algo claro: no veo ningún problema en que un Scrum Master desarrolle competencias de gestión de proyectos, delivery, riesgos, comunicación o stakeholders. Al contrario, considero que muchas de esas competencias pueden hacerlo mucho más efectivo dentro de una organización compleja.

El problema es contratar a una persona para una función, explicarle que su responsabilidad será una y después empezar a exigirle silenciosamente otra completamente diferente.

Si la empresa necesita que esa persona gestione cronograma, presupuesto, riesgos, proveedores, dependencias y reporting ejecutivo, quizá sea el momento de reconocer que esa función ya no es únicamente la de Scrum Master.

Puede llamarse Delivery Manager, Project Manager, Program Manager o cualquier otro nombre que tenga sentido dentro de la estructura. El nombre es probablemente lo menos importante.

Lo importante es dejar claro quién tiene la responsabilidad, la autoridad y las competencias necesarias para hacer el trabajo.

Menos autoridad, pero las mismas exigencias

Hay otro efecto que considero todavía más peligroso: hacer responsable de un resultado a una persona que no tiene autoridad suficiente para influir realmente sobre él.

Imagina un Scrum Master siendo cuestionado por el retraso de una iniciativa que depende de cuatro equipos externos, dos proveedores, un presupuesto controlado por otra área y prioridades definidas por ejecutivos con los que esa persona ni siquiera tiene acceso directo.

Puede facilitar todas las Daily Scrums del mundo. El problema seguirá existiendo.

Cuando responsabilidad y autoridad no avanzan juntas, creamos un rol que debe negociar prácticamente todo y puede decidir muy poco. Después llamamos a eso accountability, cuando en realidad es simplemente transferencia de presión hacia abajo.

¿Quién gestiona costos, riesgos, cronograma y stakeholders?

Para mí, esta pregunta es mucho más importante que discutir eternamente si Scrum Master sustituye o no a un gerente de proyectos. El nombre del cargo me interesa mucho menos que saber quién está mirando el dinero, quién acompaña los riesgos, quién entiende las dependencias entre equipos, quién puede detectar que una secuencia de pequeños retrasos probablemente comprometerá una entrega dentro de tres meses y quién conversa con los stakeholders cuando las expectativas empiezan a alejarse de la realidad.

Si la respuesta es “nadie, porque el equipo se autogestiona”, tenemos un problema.

La autogestión es extremadamente importante para definir cómo el equipo organiza y ejecuta su trabajo. Pero no hace desaparecer contratos, restricciones financieras, dependencias organizacionales, compromisos comerciales, riesgos ni expectativas ejecutivas.

Un burndown no gestiona una empresa

Uno de mis problemas con ciertas implementaciones de Agile es la reducción excesiva de la gestión a algunas métricas de sprint. Velocity puede ser útil. Un burndown puede ser útil. El Sprint Goal es importante. Las retrospectivas son importantes.

Pero ninguna de esas cosas responde por sí sola cuánto ha costado un proyecto, qué área está consumiendo más presupuesto, qué actividades están generando más rework, qué riesgos están creciendo, si estamos entregando proporcionalmente al dinero consumido, qué dependencia puede comprometer el cronograma o si la productividad del equipo está mejorando o empeorando.

Los ejecutivos siguen necesitando estas respuestas independientemente de si el equipo utiliza Scrum, Kanban, SAFe, Waterfall o cualquier combinación entre ellos.

Un framework de trabajo no sustituye la inteligencia de gestión.

Aquí entra Saint Jude

Esta falta de visibilidad es una de las razones por las que creamos Saint Jude Project Intelligence .

Cuando una empresa utiliza Jira, Azure DevOps, Asana, monday.com o ClickUp, todos los días genera una enorme cantidad de información sobre la ejecución de sus proyectos. El problema es que esos datos normalmente permanecen dispersos entre boards, dashboards, hojas de cálculo, presentaciones y diferentes interpretaciones de cada gestor.

Saint Jude utiliza esos datos para crear una capa de inteligencia sobre los proyectos, permitiendo analizar cronograma, costos, productividad, performance, riesgos, estimaciones, calidad de las actividades, comportamiento de los sprints y otras señales que ayudan a PMOs y líderes a entender lo que realmente está sucediendo.

La idea no es transformar nuevamente al Scrum Master en gerente de proyectos. De hecho, es justamente lo contrario. Cuanta más información de gestión pueda estructurarse automáticamente a partir de los datos que ya existen, menor será la necesidad de que alguien pase parte de la semana recopilando información manualmente para producir reportes que probablemente estarán desactualizados al día siguiente.

Entonces, ¿cuál es realmente el rol del Scrum Master?

El rol del Scrum Master tiene sentido cuando permitimos que sea aquello que debería ser: alguien que ayuda al Scrum Team y a la organización a trabajar mejor utilizando Scrum.

El problema empieza cuando decidimos que el gerente de proyectos quedó obsoleto, eliminamos la función y asumimos que todas las responsabilidades asociadas a la gestión desaparecieron junto con el cargo.

No desaparecieron. Alguien seguirá ocupándose de ellas. Puede ser un PMO, un Delivery Manager, un Program Manager, un Engineering Manager o incluso una combinación de personas, procesos, datos y automatización.

O, sin que nadie lo diga claramente, la empresa puede terminar colocando una parte importante de todo ese trabajo sobre los hombros del Scrum Master.

Y es en este último escenario donde mi provocación sigue siendo válida: en muchas empresas, el Scrum Master no se convirtió oficialmente en gerente de proyectos. Simplemente recibió cada vez más responsabilidades de gestión sin que nadie quisiera admitir que la gestión de proyectos seguía siendo necesaria.

El problema nunca fue el Scrum Master. El problema es creer que cambiar el nombre de los roles hace desaparecer costos, riesgos, plazos, dependencias, stakeholders y problemas de comunicación.

No los hace desaparecer.

Y tú, ¿qué opinas? En tu empresa, ¿el Scrum Master ejerce principalmente las responsabilidades previstas por Scrum o terminó absorbiendo parte del trabajo que antes pertenecía a la gestión de proyectos?

¡Hasta pronto!

Erik Scaranello