Agilidad y gestión de proyectos
El rol del Scrum Master: coaching, facilitación e impedimentos
Intermedio9 min de lecturaActualizado
Esta página se tradujo del inglés con ayuda de IA y se cotejó con el original. Leer la versión en inglés
El Scrum Master es responsable de la efectividad del equipo, un trabajo mucho más difícil que dirigir cuatro reuniones. Esta guía trata la facilitación que produce decisiones, el coaching de un equipo hacia la autogestión, cuándo eliminar un impedimento y cuándo dejar que el equipo lo sufra, las métricas que vale la pena vigilar y los fallos más conocidos del rol.
Lo que aprenderás
- Distinguir el liderazgo de servicio tanto del ordeno y mando como de la facilitación pasiva
- Facilitar cada evento de Scrum para que produzca una decisión y no una actualización de estado
- Decidir cuándo eliminar un impedimento tú mismo y cuándo hacerlo perjudica al equipo
- Elegir métricas que ayuden al equipo y evitar las que se convierten en objetivos
- Reconocer los antipatrones del secretario, del jefe de proyecto y de la policía del proceso
Pregunta a diez organizaciones qué hacen sus Scrum Masters y obtendrás respuestas que van desde «dirige las ceremonias y actualiza el tablero» hasta «acompaña a tres equipos y negocia con nuestro comité de financiación». El propio framework es escueto al respecto: el Scrum Master es responsable de la efectividad del equipo y de que Scrum se entienda y se aplique, tanto dentro del equipo como en el resto de la organización. Esa única frase encierra mucho más trabajo que un calendario de reuniones.
Esta guía trata de la práctica, no de la definición. Si lo que buscas es el framework en sí —los eventos, artefactos y compromisos dentro de los que opera el rol—, empieza por la guía del framework Scrum. Aquí vemos en qué invierte realmente su tiempo un Scrum Master, qué decisiones exigen criterio propio y de qué maneras se tuerce el rol.
Liderar sin autoridad
El rol no tiene autoridad jerárquica. Un Scrum Master no asigna trabajo, no aprueba vacaciones, no hace evaluaciones de desempeño ni decide prioridades, y toda su influencia nace de ser útil. Esa limitación es deliberada: un equipo que recibe órdenes de alguien con poder sobre su carrera no se autogestionará, y la autogestión es precisamente el mecanismo que hace que valga la pena tener ciclos de feedback cortos.
La diferencia se aprecia mejor en el comportamiento que en la teoría.
| Situación | Ordeno y mando | Al servicio del equipo |
|---|---|---|
| El trabajo no avanza | Asignárselo a alguien y fijar una fecha | Hacer visible el flujo y preguntar al equipo qué lo está bloqueando |
| La calidad empeora | Añadir una revisión obligatoria y una checklist | Llevar los datos de defectos a la retrospectiva y dejar que el equipo diseñe la solución |
| Un miembro del equipo está desmotivado | Escalarlo a su responsable | Hablar con esa persona; averiguar si el problema es el trabajo, el equipo u otra cosa |
| Las estimaciones fallan sistemáticamente | Exigir mejores estimaciones | Mostrar el rango de la previsión y ayudar al equipo a dividir el trabajo en partes más pequeñas |
| Una dependencia llega tarde | Perseguirla a diario en nombre del equipo | Ayudar al equipo a construir la relación para que la próxima vez la persiga él mismo |
La columna de la derecha es más lenta la primera vez y más rápida todas las siguientes, y esa es toda la apuesta. También se confunde a menudo con pasividad. Servir a un equipo no significa darle la razón: un Scrum Master que ve a su equipo saltarse la definición de terminado durante tres sprints sin decir nada ha fracasado al menos tanto como uno que da órdenes.
Facilitar eventos que producen decisiones
La facilitación es la parte visible del trabajo y la más fácil de hacer mal. La prueba para cualquier evento es si algo cambió como resultado.
Sprint planning. El fallo habitual es una reunión de cuatro horas en la que el equipo discute los elementos uno a uno y nunca llega a fijar un objetivo. El Scrum Master interviene exigiendo que se redacte un borrador del objetivo antes de seleccionar elementos, cortando las discusiones técnicas interminables y dejándolas para después, y haciendo la pregunta incómoda cuando el equipo selecciona más de lo que ha terminado jamás.
Daily Scrum. La degradación clásica es una ronda de informes individuales dirigidos al Scrum Master o a un responsable. Soluciones prácticas: ponerse delante del tablero y recorrer el trabajo de derecha a izquierda en lugar de persona por persona; preguntar por el objetivo del sprint y no por cada individuo; salir de la sala de vez en cuando para que el equipo aprenda que el evento es suyo. Todo lo que requiera más de un minuto se convierte en una conversación después del evento, solo con las personas implicadas.
Sprint review. A menudo se reduce a una presentación de diapositivas. El remedio es un sistema que funcione delante de stakeholders reales, con el product owner dirigiendo la conversación sobre qué hacer a continuación y con la demostración a cargo de quien construyó la funcionalidad.
Retrospectiva. Es la más difícil de mantener viva. Los síntomas de deterioro son las mismas tres quejas cada dos semanas y ningún cambio visible. Varía el formato para que las preguntas cambien; pon la acción de la retrospectiva anterior en lo alto del tablero; limita el resultado a uno o dos cambios que el equipo controle de verdad; y separa los problemas que el equipo puede resolver de los que hay que llevar fuera, que pasan a ser trabajo del propio Scrum Master.
El refinamiento no es uno de los cinco eventos, pero en la práctica consume tiempo real. La aportación del Scrum Master ahí suele ser el time-boxing y las técnicas para dividir historias, no el contenido, que corresponde al product owner.
Impedimentos: cuándo eliminarlos y cuándo no
El registro de impedimentos es donde está la mayor parte del impacto del rol, y la clave está en decidir quién debe eliminarlos.
Algunos impedimentos están claramente fuera del alcance del equipo y le toca asumirlos al Scrum Master: un proceso de compras que tarda seis semanas en adquirir una licencia, un entorno compartido que otro departamento tiene reservado sin descanso, un comité de aprobación que se reúne una vez al mes, una política que prohíbe al equipo desplegar su propio código. Requieren conversaciones organizativas que el equipo no tiene legitimidad para mantener, y es la parte del rol que más influye en los resultados. Muchos son problemas de la cadena de entrega que un enfoque DevOps está pensado para disolver.
Otros impedimentos puede y debe gestionarlos el equipo. Un conjunto de datos de prueba que falta, un criterio de aceptación poco claro, un compañero que no ha contestado un mensaje, un build que está en rojo desde ayer: si el Scrum Master se encarga de ellos, el equipo aprende que la fricción es problema de otro y deja de desarrollar esa capacidad. Lo útil es preguntar quién lo va a resolver y para cuándo, y luego hacer el seguimiento.
Una regla práctica: elimina los impedimentos estructurales, políticos o que se repiten en varios equipos; acompaña al equipo con los que son técnicos, locales o puntuales. En caso de duda, la primera vez hazlo con el equipo y no por él, y la segunda deja que lo haga solo.
Coaching hacia la autogestión
Los equipos no llegan autogestionados, y el rol cambia de forma a medida que maduran.
Al principio. El equipo no conoce el framework y espera respuestas del Scrum Master. El trabajo consiste en enseñar: para qué sirven los eventos, cómo se escribe un objetivo de sprint, por qué el trabajo sin terminar no cuenta, qué debe contener la definición de terminado. Aquí es apropiado un comportamiento directivo, que debe ir reduciéndose de forma visible.
En la etapa intermedia. El equipo domina la mecánica pero evita el conflicto, cede ante quien más alza la voz o arrastra trabajo de un sprint a otro sin decirlo. Ahora el trabajo es facilitación y feedback honesto: sacar a la luz lo que está pasando sin juzgar, enseñar al equipo a discrepar de forma productiva y ayudarle a fijar sus propios estándares de calidad en lugar de aceptar uno impuesto desde fuera.
En la madurez. El equipo dirige sus propios eventos, plantea sus propios impedimentos y mejora sin que nadie se lo pida. La atención del Scrum Master se desplaza hacia fuera: a la relación con los stakeholders, a las dependencias con otros equipos, a las restricciones organizativas que todavía limitan al equipo y, a menudo, a ayudar a equipos más nuevos. Una buena señal de madurez es que los eventos funcionan perfectamente cuando el Scrum Master está de vacaciones.
La relación con el product owner merece atención propia en todas las etapas. Las aportaciones prácticas incluyen ayudarle a encontrar técnicas para ordenar el backlog, proteger el tiempo de refinamiento, enseñarle a decir que no a los stakeholders y mediar cuando el equipo siente que el backlog es una lista de deseos llegada de fuera. Lo que un Scrum Master no debe hacer es asumir en silencio la ordenación cuando el product owner está ausente: eso oculta el hueco en lugar de dejarlo al descubierto.
Métricas que vale la pena vigilar y métricas que hay que rechazar
Un Scrum Master necesita datos para que las conversaciones sean concretas, y el peligro es que cualquier número que se publique se convierta en un objetivo.
| Útil, para el equipo | Por qué | Peligrosa como objetivo |
|---|---|---|
| Throughput y cycle time por elemento | Muestra el flujo y dónde espera el trabajo | Comparar el cycle time entre equipos |
| Objetivo del sprint cumplido o no | Binaria, honesta y difícil de manipular | — |
| Trabajo en curso frente al límite del equipo | Explica la lentitud de la entrega mejor que el esfuerzo | — |
| Defectos escapados y retrabajo | Comprueba si la definición de terminado es real | Recuento de defectos por persona |
| Métricas de entrega como el lead time y la tasa de fallos en cambios | Conecta al equipo con los resultados en producción | Número de despliegues como criterio para el bonus |
| Velocidad | Un dato de planificación local, solo para el equipo | La velocidad como medida de productividad, o comparada entre equipos |
La velocidad merece una cautela especial. Es un subproducto de los hábitos de estimación de un equipo concreto, y en cuanto se reporta hacia arriba como productividad, los equipos inflan las estimaciones y el número deja de aportar información. Todo lo que se reporte fuera del equipo debería hablar de resultados —funcionalidades publicadas, objetivos cumplidos, defectos escapados— y no de unidades internas.
Antipatrones
- El secretario. Reserva salas, toma notas, actualiza el tablero y persigue a la gente para conocer el estado de las tareas. Todo lo visible de los eventos está hecho y nada cambia en la efectividad del equipo.
- El jefe de proyecto disfrazado. Asigna tareas, sigue el progreso individual, informa del porcentaje completado y negocia el alcance en nombre del equipo. El título cambió; el modelo de trabajo, no.
- La policía del proceso. Aplica el framework al pie de la letra, cita la guía a la mínima y trata los eventos como un trámite de cumplimiento. Los equipos cumplen y dejan de ser sinceros, lo que destruye la transparencia.
- El facilitador ausente. Dirige los cuatro eventos, no acompaña a nadie, no lleva ningún impedimento hacia fuera y lo llama liderazgo de servicio.
- El punto de contacto único. Todas las preguntas de los stakeholders pasan por el Scrum Master, lo que parece útil e impide que el equipo llegue a construir relaciones directas.
- El proveedor de métricas. Se pasa la semana elaborando gráficos de velocidad para la dirección y el resto del tiempo defendiéndolos.
La prueba más sólida del rol es contrafactual. Si el Scrum Master se fuera mañana, ¿bajaría la efectividad del equipo? Si la respuesta honesta es que otra persona tendría que reservar las reuniones, la responsabilidad nunca se ejerció de verdad. Cuando hay varios equipos implicados, la mitad organizativa del trabajo crece todavía más: consulta escalar el agilismo para ver los problemas de coordinación que aparecen.
Conclusiones clave
- La responsabilidad es la efectividad del equipo, no que cuatro reuniones transcurran sin problemas; la facilitación es un medio, no el trabajo.
- El rol no tiene autoridad sobre las personas ni sobre las prioridades a propósito, porque un equipo al que le dicen qué hacer no se autogestionará.
- Facilita para que cada evento produzca una decisión o un cambio; un evento cuyo resultado es una actualización de estado ha fracasado.
- Asume tú los impedimentos estructurales, políticos y entre equipos; acompaña al equipo con los locales y técnicos para que desarrolle esa capacidad.
- Adapta tu comportamiento a la madurez del equipo: enseña al principio, facilita en la etapa intermedia y trabaja hacia fuera cuando el equipo ya funciona solo.
- Mantén la velocidad dentro del equipo, reporta resultados hacia fuera y da por distorsionada cualquier métrica que se convierta en objetivo.
Fuentes y lecturas recomendadas
Preguntas frecuentes
- ¿Puede una misma persona ser Scrum Master de varios equipos?
- Es habitual y a veces viable, normalmente con dos o tres equipos para alguien con experiencia que trabaja con equipos maduros. Deja de funcionar cuando el rol se reduce a asistir a los eventos, porque el coaching y el trabajo con la organización —lo que de verdad cambia los resultados— es lo primero que se sacrifica. Un equipo nuevo que está aprendiendo el framework necesita, siendo realistas, casi toda la atención de una persona.
- ¿Puede un developer del equipo ser también el Scrum Master?
- Nada en el framework lo prohíbe y los equipos pequeños lo hacen a menudo. El problema es que las dos responsabilidades compiten por las mismas horas y el desarrollo siempre parece más urgente, así que la facilitación acaba degenerando en reservar salas. Además, resulta incómodo plantear un problema sobre cómo trabaja el equipo cuando tú eres una de las personas que lo provocan.
- ¿Debe el Scrum Master asignar tareas a los developers?
- No. Los developers eligen su propio trabajo; eso es lo que significa autogestión, y quitarles esa decisión elimina la responsabilidad compartida de la que depende el framework. Lo que un Scrum Master sí puede hacer legítimamente es hacer visibles las consecuencias —que hay tres elementos en curso y ninguno terminado, o que una persona es un cuello de botella— y dejar que el equipo decida qué hacer al respecto.
- ¿Qué diferencia hay entre un Scrum Master y un agile coach?
- Un Scrum Master es responsable de la efectividad de un equipo concreto y de que Scrum se aplique bien, incluido el trabajo fuera del equipo que lo bloquea. Un agile coach tiene un rol más amplio y sin definición formal, que suele abarcar varios equipos o un departamento entero y se ocupa de las formas de trabajo, la estructura y el comportamiento de los líderes. En muchas organizaciones los títulos se solapan y la diferencia es sobre todo de alcance.