Qué hace un Scrum Master y cuándo contratar uno externo
Un Scrum Master es la persona responsable de que el equipo que desarrolla tu software trabaje bien: no decide qué se construye ni programa, se encarga de que el método funcione y de retirar los obstáculos que frenan al equipo. Si tu proyecto se retrasa sin que nadie sepa explicar por qué, si cada reunión acaba en una lista de pendientes que nadie recoge o si tu proveedor te enseña avances que no se parecen a lo que pediste, ese es exactamente el hueco que cubre esta figura. Y sí, puede ser alguien de fuera de tu plantilla.
Qué hace un Scrum Master en el día a día
Según la Guía Scrum, el documento oficial que mantienen Ken Schwaber y Jeff Sutherland (creadores del marco de trabajo), el Scrum Master es responsable de dos cosas concretas: de que Scrum se entienda y se aplique de verdad, y de la efectividad del equipo. Traducido a un proyecto real, su jornada se parece a esto:
- Protege el ritmo de trabajo. Scrum organiza el desarrollo en ciclos cerrados llamados sprints, que duran como máximo un mes y normalmente entre una y tres semanas. El Scrum Master vela por que cada sprint empiece con un objetivo claro y acabe con algo que se pueda enseñar y usar.
- Hace que las reuniones ocurran y sirvan. La planificación del sprint, la reunión diaria de quince minutos, la revisión con el cliente y la retrospectiva del equipo. Son cuatro citas fijas; sin alguien que las cuide, se convierten en tres reuniones canceladas y una eterna.
- Retira impedimentos. El acceso que no llega, la clave del servidor que nadie encuentra, la respuesta que tu departamento financiero lleva nueve días sin dar. Son minucias que paran a un equipo entero y que no se resuelven solas.
- Enseña a trabajar así. Coloca el marco de trabajo en la organización, no solo en el equipo técnico: si tu gente de negocio no entiende cómo se prioriza, el método se cae por ese lado.
Fíjate en lo que no aparece en esa lista: asignar tareas, decidir funcionalidades, negociar el presupuesto. No es un olvido.
En qué se diferencia de un jefe de proyecto
Esta es la confusión que más dinero cuesta. Un jefe de proyecto clásico planifica, reparte el trabajo, controla el calendario y responde del resultado ante ti. Un Scrum Master no manda sobre el equipo: el equipo se organiza solo y él se ocupa de que pueda hacerlo. Lidera sirviendo, no ordenando.
La consecuencia práctica es importante para ti como cliente. Si contratas un Scrum Master esperando a alguien que te dé un diagrama de barras con todas las tareas hasta diciembre, te vas a frustrar. Lo que obtienes es otra cosa: un equipo que entrega algo funcionando cada pocas semanas, que te enseña ese avance y que corrige el rumbo contigo. La previsibilidad no viene de un plan a doce meses, viene de la cadencia.
Tampoco es un coach de empresa que da charlas. Su trabajo se mide en si el equipo entrega mejor dentro de dos meses que hoy.
Quién decide qué se construye: Scrum Master, Product Owner y desarrolladores
Scrum reparte el trabajo en tres responsabilidades y conviene que sepas cuál te toca a ti. La Guía Scrum las define así:
| Responsabilidad | De qué responde | Quién la asume en un proyecto con proveedor |
|---|---|---|
| Product Owner | Decidir qué se construye y en qué orden; maximizar el valor del producto | Normalmente alguien de tu empresa, porque conoce el negocio |
| Desarrolladores | Construirlo con calidad y decidir cómo se hace técnicamente | El equipo técnico, interno o del proveedor |
| Scrum Master | Que el método funcione y el equipo sea efectivo | Interno, del proveedor o externo independiente |
La mezcla que no funciona es que la misma persona sea Product Owner y Scrum Master. Quien tiene prisa por meter funcionalidades no puede ser a la vez quien defiende que el equipo no se ahogue. Si tu proveedor te propone eso, pregunta cómo piensa resolver el conflicto.
Cuándo tu proyecto necesita uno y cuándo no
No todos los desarrollos lo piden. Estas señales sí lo piden:
- Tu proyecto lleva más de tres meses y va para largo. En un encargo de tres semanas, el método importa menos que la ejecución.
- Hay varias personas o varios proveedores implicados. Dos equipos que se pisan necesitan alguien que coordine el proceso sin convertirse en cuello de botella.
- Nadie sabe decir en qué se fue el mes pasado. Síntoma clásico de que no hay ciclos cerrados ni entregas visibles.
- Tu equipo interno se está estrenando en ágil. Las primeras iteraciones son las que marcan si el método se asienta o se abandona.
- Las prioridades cambian cada semana y cada cambio descoloca a todo el mundo. Scrum admite el cambio, pero en los puntos previstos para ello.
Y los casos en los que no hace falta: un mantenimiento continuo con tickets sueltos, un proyecto pequeño con un único desarrollador, o un equipo veterano que ya tiene su cadencia rodada y solo necesita que le dejen trabajar. Añadir ceremonias a un equipo de dos personas no lo hace más ágil, lo hace más lento.
Interno, del proveedor o externo: cómo elegir
Hay tres maneras de cubrir la figura y cada una tiene un precio distinto, no siempre en dinero.
| Opción | A favor | En contra | Cuándo encaja |
|---|---|---|---|
| Scrum Master interno | Conoce la empresa, se queda y deja capacidad instalada | Requiere formación y dedicación real, no un rato libre | Tienes varios proyectos digitales a la vez y quieres método propio |
| Del proveedor de desarrollo | Entra ya rodado con su equipo; sin coste de selección | Su lealtad está dividida: trabaja para quien le paga la nómina | Un proyecto cerrado con un único proveedor de confianza |
| Externo independiente | Mirada neutral; dedicación parcial; sin conflicto de intereses | Tarda en entender tu negocio; si va pocas horas, pierde contexto | Varios proveedores implicados, o un proyecto que ya se ha torcido |
La opción externa es la que suele buscarse con expresiones como «Scrum Master externalizado», y tiene sentido sobre todo en dos escenarios: cuando quieres que alguien ajeno al proveedor vele por el proceso, y cuando tu volumen de proyecto no justifica una contratación a jornada completa. Una dedicación parcial estable funciona; un día al mes, no.
Cómo saber si está funcionando
Pide estas cuatro evidencias al cabo de dos o tres sprints. Si no las tienes, algo va mal:
- Entregas visibles con una cadencia fija. Cada dos o tres semanas ves algo que funciona, no una presentación de lo que se hará.
- Una lista de trabajo ordenada y pública. Puedes mirar en cualquier momento qué hay pendiente y en qué orden, y entenderlo sin que te lo traduzcan.
- Impedimentos resueltos y anotados. Si los bloqueos de hace un mes siguen abiertos, nadie los está retirando.
- Retrospectivas con consecuencias. El equipo detecta un problema y en el siguiente ciclo ha cambiado algo. Si siempre se detecta lo mismo, la reunión es un desahogo, no una mejora.
Los antipatrones más habituales son fáciles de reconocer: el Scrum Master que se convierte en secretario de actas, el que reparte tareas como un jefe de toda la vida, y el que defiende el ritual por encima del resultado. Si tu reunión diaria dura cuarenta minutos y es un informe por turnos para el jefe, el marco de trabajo está puesto del revés.
La figura importa menos que el resultado
Un Scrum Master no es un gasto de ceremonia: es quien consigue que tu inversión en desarrollo se traduzca en entregas regulares y en decisiones a tiempo. Lo que de verdad tienes que exigir es lo que acabas de leer, independientemente del nombre del puesto: ciclos cerrados, una lista de prioridades que tú entiendas, obstáculos que se retiran y un equipo que mejora visiblemente de un mes al siguiente. Si tu proyecto está en esa fase en la que no sabes si el problema es el equipo, el método o el alcance, cuéntanos cómo estáis trabajando y te diremos con franqueza qué cambiaríamos primero.