El Scrum Master No es un Solucionador de Problemas

I

Uno de los servicios del Scrum Master es eliminar los impedimentos que tiene el equipo de desarrollo. Pero no todos los problemas son impedimentos. Hay que entender que el Scrum Master no es un solucionador de problemas.

¿Cómo afecta la auto organización y la capacidad de entrega de producto de un equipo de desarrollo 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 al equipo de desarrollo a refinar con el Product Owner y es un proxy para la comunicación con el equipo de desarrollo?

¿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 impacta en la capacidad del equipo en mejorar su auto organización, su capacidad de entrega de producto y en su mejora continua.

Por ejemplo, veamos el siguiente caso que he podido ver algunas veces: Un equipo de desarrollo no puede 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 al equipo y soluciona las dependencias y los problemas técnicos y el equipo puede entonces desplegar y estar listo para el Sprint Review.

Si el Scrum Master resuelve ese problema, pero no ayuda y enseña al equipo de desarrollo a mejorar su capacidad para resolver problemas similares y que puedan aparecer en el futuro puede provocar una dependencia que afecta la auto organización y la capacidad de mejora continua del equipo.

El problema mencionado puede tener diferentes formas de ser solucionado, pero cualquiera que sea la solución, esta debe surgir del Equipo de Desarrollo con la ayuda del Scrum Master. Enseñar al equipo a ser auto organizado es uno de los servicios del Scrum Master al equipo de desarrollo. Un síntoma que puede alertar que el Scrum Master no esta empoderando al equipo es si los mismos problemas de despliegue se repiten Sprint tras Sprint sin que el equipo de desarrollo adopte acciones de mejora para solucionarlos.

Los impedimentos son problemas que dificultan el progreso de un equipo de desarrollo y que se encuentran fuera de su capacidad de resolverlos. Pero no todos los problemas son impedimentos, pero se puede llegar a este punto si el Scrum Master soluciona los problemas y no enseña al equipo a mejorar y ser auto organizado.

Pueden ver mis siguiente entrenamientos programados en  https://tinyurl.com/y44xltvo

Me pueden contactar en jfranci[email protected] o en https://www.linkedin.com/in/joelfrancia/

This article originally appeared on the Scrum.org blog

TAGS
SOURCE
Syndication