Anti Patrones del Scrum Master

Anti Patrones del Scrum Master

Algunos anti patrones de un Scrum Master que pueden no ayudar a ser un líder servicial.

Un Scrum Máster que le dice a los Desarrolladores y al Product Owner que según alguna experiencia cada desarrollador sólamente puede desarrollar como máximo hasta una capacidad de X puntos de historia por Sprint, este tipo de Scrum Master también aclara que intentar que el equipo haga más puntos de historia implicaría exceder la capacidad promedio de los desarrolladores de capacidad definida.

La realidad: En Scrum lo que importa es la entrega de valor y el impacto en los clientes. La velocidad en puntos de historia no representa una métrica que refleje la entrega de valor. La velocidad en puntos de historia no representa una predicción del futuro y tampoco representa la capacidad de lo que los desarrolladores pueden entregar en cada Sprint.

• Un Scrum Máster que dirige el Daily Scrum y establece que cada desarrollador debe seguir las tres preguntas como son, que tareas hizo ayer, que tareas va a hacer el día de hoy y que impedimentos tiene para culminar sus tareas. En este evento el Scrum Master enfatiza a ese desarrollador que tiene que cumplir con las tareas que se ha comprometido porque si no no tiene compromiso. La realidad: Los valores de Scrum fomentan un entorno cultural que fomenta el empoderamiento y la creatividad. El Scrum Master no es el policía de Scrum ni tampoco existen preguntas obligatorias que se deben seguir.
• Un Scrum Master que cee proteger a los desarrolladores estableciendo que como están sumamente ocupados no hay tiempo para interrumpirlos y por ello el Product Owner tiene que entregar los requerimientos refinados y listos para que los desarrolladores estimen y desarrollo según fue definido y sin cambios. Además, este Scrum Master establece que no se debe interrumpir a los desarrollaores con actividades de refinamiento porque esa es labor del Product Owner. La realidad: La colaboración y cocreación son importantes para mejorar y fomentar la transparencia, el refinamiento es una actividad que debe ser abordada como un trabajo de equipo.
• Un Scrum Master que enfatiza al Product Owner y a los Desarrolladores que si el equipo ha venido produciendo X puntos de historia de velocidad entonces no pueden hacer más puntos de historia o en última instancia podrían aumentar ligeramente los puntos de historia, pero en ningún caso se debe presionar al equipo porque podrían sentirse mal. En un entorno empírico se planifica para lo impredecible. La realidad: En Scrum lo que importa es la entrega de valor y el impacto en los clientes. La velocidad en puntos de historia no es una métrica que refleje la entrega de valor. La velocidad en puntos de historia no debe tomarse como la capacidad predictiva de los desarrolladores sobre lo que deben entregar en cada Sprint.
• Un Scrum Master que establece con claridad que es responsabilidad del Product Owner ingresar todas las historias de usuario y criterios de aceptación en la herramienta X, también que el Product Owner tiene que dar todo el detalle necesario porque los desarrolladores solo harán aquello que el Product Owner les dice que haga, además si el Product Owner omite algo será de responsabilidad única y exclusiva del Product Owner. La realidad: La responsabilidad del Product Owner es maximizar la entrega de valor. Todos los miembros del equipo son responsables de colaborar para realizar todas las actividades en el desarrollo de producto.
• Un Scrum Máster que le dice al Product Owner que la única reunión donde se va a inspeccionar el incremento de producto es en el “Sprint Review” por ello debe tener paciencia y esperar a esa reunión. Antes de eso los desarrolladores no pueden entregar incrementos porque tiene que terminarse el tiempo del Sprint según lo establece Scrum. La realidad: La inspección y adaptación es continua durante el Sprint y no solamente al final del Sprint Review.
• Un Scrum Máster que mapea los puntos de historia a horas. De esta manera obtiene un plan detallado de horas que todos pueden seguir para monitorear el avance. La realidad: Scrum se basa en el empirismo, la adaptación ocurre en cualquier momento, los planes se adaptan según se requiera y el avance hacia el objetivo del Sprint se consigue a través del incremento de producto terminado con valor. El empirismo se basa en aceptar los cambios y no en tratar de controlarlos o limitarlos