El Sprint Review fue incómodo. Nadie habló más de lo necesario. En la Retrospectiva, silencio. Fuera de las ceremonias, conversaciones en corrillos que no llegan al equipo completo. El Product Owner toma decisiones sin consultar. Los desarrolladores entregan lo que se les pide, sin más. ¿Te suena? No estás ante un problema de proceso ni de herramientas. Estás ante un equipo disfuncional. Y el Scrum Master que no lo ve, o que lo ve y no actúa, es parte del problema.
Las disfunciones no aparecen de golpe
Patrick Lencioni describió hace años cinco disfunciones que minan a cualquier equipo: ausencia de confianza, miedo al conflicto, falta de compromiso, evitación de responsabilidad y desatención a los resultados. No son categorías académicas. Son patrones que cualquier Scrum Master con experiencia reconoce en el día a día.
Lo relevante en un contexto Scrum es que el marco en sí no resuelve estas disfunciones. Scrum las hace visibles. Las ceremonias, la transparencia y los ciclos cortos actúan como amplificadores: lo que funciona bien, mejora. Lo que está roto, se ve antes.
El problema es que muchos Scrum Masters confunden visibilidad con solución. Ver el problema no es lo mismo que abordarlo. Y esperar a que «el equipo madure solo» suele ser una forma elegante de no hacer nada.
Cómo actúa un Scrum Master cuando detecta disfunciones
La intervención del Scrum Master no es terapéutica ni jerárquica. Es facilitadora y, cuando hace falta, directa. Veamos situaciones concretas:
Ausencia de confianza: el equipo no se dice la verdad
Un equipo donde nadie levanta impedimentos reales en el Daily, donde los problemas aparecen el último día del Sprint, tiene un problema de confianza. El SM no lo resuelve con un ejercicio de team building. Lo aborda creando espacios seguros de forma consistente: modelando vulnerabilidad, normalizando el error y protegiendo al equipo de reacciones punitivas externas.
Miedo al conflicto: todo el mundo está «de acuerdo»
Cuando en la Sprint Planning nadie cuestiona el alcance, cuando en la Retrospectiva las acciones son siempre superficiales, hay conflicto suprimido. El SM introduce fricción productiva: hace preguntas incómodas, saca a la luz tensiones no dichas, facilita el desacuerdo como herramienta de calidad.
Evitación de responsabilidad: «eso no era lo mío»
- Tareas que nadie recoge hasta que alguien pregunta.
- Bugs que «aparecen» sin que nadie los haya introducido.
- Compromisos del Sprint que se diluyen sin conversación.
Aquí el SM trabaja la Definition of Done como contrato colectivo y facilita que el equipo se dé feedback entre sí, sin necesitar al SM como intermediario.
Los errores que cometen los Scrum Masters ante las disfunciones
Detectar una disfunción es el primer paso. Actuar mal sobre ella puede empeorar la situación. Estos son los errores más frecuentes:
1. Intervenir demasiado rápido y demasiado fuerte Un SM que convoca una sesión de «resolución de conflictos» a los tres días de detectar tensión suele generar más resistencia que solución. Las disfunciones se trabajan con paciencia y consistencia, no con talleres de emergencia.
2. Hablar con individuos en lugar de trabajar con el equipo Cuando el SM gestiona los problemas en conversaciones privadas con cada persona, refuerza los silos. El equipo no aprende a resolver sus propias tensiones. El SM se convierte en el centro de todas las conversaciones difíciles, y eso no escala.
3. Confundir síntoma con causa Un equipo que no cumple sus compromisos de Sprint puede tener un problema de estimación, de alcance, de confianza o de compromiso real con los objetivos. Actuar sobre el síntoma sin entender la causa produce soluciones que no duran.
4. No escalar cuando toca Algunas disfunciones tienen raíz fuera del equipo: una organización que no respeta el Sprint, un Product Owner que cambia prioridades a diario, una dirección que no confía en el equipo. En esos casos, el SM tiene que actuar hacia arriba, no solo hacia dentro.
El siguiente nivel: de reactivo a preventivo
Un Scrum Master maduro no espera a que las disfunciones exploten. Diseña las ceremonias para que la confianza, el conflicto productivo y la responsabilidad compartida sean la norma, no la excepción. La Retrospectiva bien facilitada es la herramienta más potente para esto, siempre que no se convierta en un ritual vacío de quince minutos al final del Sprint.
Lo que las disfunciones de equipo revelan sobre el rol del SM
Un equipo disfuncional no es un fracaso del equipo. Es una señal de que algo en el sistema no está funcionando: la estructura, la cultura, las expectativas o el entorno. El Scrum Master que entiende esto deja de buscar culpables y empieza a trabajar el sistema.
Actuar sobre disfunciones requiere coraje, criterio y paciencia. No hay fórmula. Hay observación, hipótesis, intervención y ajuste. Exactamente el mismo ciclo empírico que Scrum propone para el producto.