El Scrum Master no es el único responsable de solucionar Impedimentos

El Scrum Master no es un solucionador de Problemas

Un Scrum Master debe crear un entorno de confianza donde los desarrolladores sientan un entorno psicológicamente seguro para hablar acerca de los impedimentos sin sentir que se les va a culpar por ellos. La primera intención del Scrum Master debe ser ayudar al equipo a través del coaching, facilitación, enseñanza, mentoría entre otras opciones a resolver los impedimentos por si mismos.

El Scrum Master también puede usar el Sprint Retrospective como una forma en que el equipo plantee mejoras de forma transparente para evitar o reducir el riesgo que aparezcan los impedimentos.

Una de las responsabilidades del Scrum Master es causar o provocar que se resuelvan los impedimentos. Esto definición es importante para aclarar que la solución de los impedimentos es una labor del equipo Scrum, pero es el Scrum Master quien ayuda y brinda soporte para que se puedan solucionar. El Scrum Master no es necesariamente el único encargado de solucionar los problemas e impedimentos. Se debe tratar de que no se vea al Scrum Master como un solucionador de problemas a quien todo recurren para llevar sus problemas.

Los impedimentos son problemas que dificultan el progreso del Equipo Scrum. No todos los problemas son impedimentos que requieran ser resueltos por el Scrum Master, pero se puede llegar a un punto en que el Scrum Master mismo es el problema cuando no enseña al equipo a mejorar y solucionar ellos mismos los impedimentos.

¿Cómo afecta a la autogestión y la capacidad de entrega de producto de los Desarrolladores si todos los problemas que surgen deben ser resueltos por el Scrum Master?

¿Qué sucede cuando sólo el Scrum Master puede resolver la ausencia de un miembro del equipo al Daily Scrum?

¿Qué sucede cuando sólo el Scrum Master puede ayudar a los Desarrolladores a refinar con el Product Owner y es un puente para la comunicación en el Equipo Scrum?

¿Qué sucede cuando sólo el Scrum Master puede resolver los problemas de infraestructura, o dependencias técnicas?

Un Scrum Master que resuelve gran parte de los problemas del Equipo Scrum impacta en su autogestión, su capacidad su capacidad de tomar decisiones sin esperar permiso y todo ello puede afectar su capacidad de entregar producto terminado y con valor en cada Sprint mejorando continuamente.

Pueden existir otros tipos de impedimentos como conflictos entre los miembros del equipo, procesos organizacionales, demora en aprobaciones, falta de disponibilidad del Product Owner, impedimentos causados por la dificultad para adoptar una mentalidad adaptativa, etc.

Algunas veces puede suceder que los Desarrolladores no pueden desplegar aplicaciones por problemas de infraestructura y dependencias de seguridad, ellos dependen de equipos externos. Dos días antes del Sprint Review estos problemas de despliegue se agravan y el equipo no puede entregar producto para el Sprint Review. Viendo esto el Scrum Master ayuda y soluciona las dependencias y los problemas técnicos y los Desarrolladores pueden entonces desplegar y estar listo para el Sprint Review. Si el Scrum Master resuelve ese problema, pero no ayuda y enseña a resolver problemas similares y que puedan aparecer en el futuro puede provocar una dependencia ya que cada vez que aparezca un problema parecido van a pedir al Scrum Master que lo resuelva.

Los impedimentos mencionados pueden tener diferentes formas de ser solucionados, pero cualquiera que sea la solución necesita involucrar a los Desarrolladores y a todo el Equipo Scrum con la ayuda del Scrum Master. Enseñar al Equipo Scrum a ser autogestionado es uno de los servicios del Scrum Master. Un síntoma que puede alertar que el Scrum Master no está empoderando al equipo es si los mismos problemas de despliegue se repiten Sprint tras Sprint sin que se adopten acciones de mejora para solucionarlos debido a que creen que deben ser resueltos por el Scrum Master.