Responsabilidades que no le corresponden al Scrum Master

En muchas organizaciones el rol del Scrum Master aún no está bien comprendido y es por ello que frecuentemente se le ve como el responsable que muchas cosas que no corresponden, entre ellas se puede mencionar:

Instruir que el Equipo de desarrollo trabaje horas extras

Se le pide al Scrum Master que actúe como jefe de equipo para que instruya a las personas cómo deben hacer su trabajo.

Esto no corresponde, ya que el Scrum Master:

  • Es un líder-servicial para el Equipo Scrum.
  • Entrena al Equipo de Desarrollo para que sea autoorganizado y multifuncional.

Por lo tanto, el Equipo de Desarrollo planifica su trabajo e inspecciona y adapta el plan si es necesario.

Planificar las cosas a realizar

Se le pide al Scrum Master que actúe como encargado de planificar todo lo que sea necesario: Release Plan, Sprint Backlog, definir plazos, planificar el trabajo, administrador de tareas, etc.

Esto no corresponde, ya que en Scrum la planificación se da en tres niveles:

  • Planificación del producto ordenando el Product Backlog: El Product Owner es responsable de maximizar el valor del producto y ordenar el Product Backlog.
  • Planificación de Sprint: En el Sprint Planning el Equipo Scrum define el objetivo a cumplir en el Sprint y el Equipo de Desarrollo determina cómo van a lograr el objetivo de Sprint, traducido en el Sprint Backlog.
  • Scrum diario: El Equipo de Desarrollo es responsable durante el Daily Scrum evaluar cómo está progresando para cumplir el objetivo del Sprint y cómo esto afecta al Sprint Backlog.

El Scrum Master ayudará a tener un objetivo de Sprint realista e inspirador. Esto es hasta dónde llega su responsabilidad de la planificación.

Realizar el monitoreo y control

Se le pide al Scrum Master que realice actividades como: proporcionar actualizaciones de estado sobre el progreso del Sprint, ser el PMO, proporcionar actualizaciones de estado sobre lanzamientos e informes de desempeño.

Esto no corresponde, ya que en Scrum se utiliza tres artefactos, además del Sprint Review para hacer transparente el progreso:

  • Product Backlog: Es una traducción de la visión del Product Owner para maximizar el valor del producto.
  • Sprint Backlog: Es una estimación de lo que se entregará en el Sprint y un plan para lograrlo. El Sprint Backlog es propiedad del Equipo de Desarrollo.
  • Incremento: Es la suma de todos los Ítems del Backlog completados en el Sprint y el valor de todos los incrementos de Sprints anteriores. Este Incremento es creado por el Equipo de Desarrollo e inspeccionado en el Sprint Review.
  • Sprint Review: Es donde se inspecciona el Incremento y se adapta el Product Backlog si es necesario. Es el momento en que el Equipo Scrum y los Stakeholders se unen para discutir qué hacer a continuación.

Los artefactos deben ser transparentes. Todos deberían poder tener la misma comprensión sobre el estado de un artefacto. La responsabilidad del Scrum Master es trabajar con el Equipo Scrum para garantizar que los artefactos sean transparentes.

Garantizar la calidad

Se le pide al Scrum Master que determine los objetivos de calidad, las condiciones para que un incremento se considere terminado y acortar las esquinas del delivery.

Esto no corresponde, ya que la calidad de los incrementos se deberían establecer mediante:

  • Definition of Done: El Equipo de Desarrollo define cuándo se completa el trabajo de un incremento mediante la Definition of Done (DoD).
  • Objetivos de calidad: La calidad se puede incrementar ampliando la DoD, que es responsabilidad del Equipo de Desarrollo.
  • Esquina de calidad de corte: 
  • Exigir el cumplimiento del DoD: El objetivo de un Sprint es entregar un Incremento “Listo”, utilizable y potencialmente liberable. Es por eso que no se debe aceptar incrementos que no cumplen con el DoD.

El Scrum Master no determina la DoD y tampoco participa cuando se decide si Incremento está “Listo”.

Lograr un fábrica de features

Se le pide al Scrum Master que haga lo necesario para que el equipo se concentre en mejorar la velocidad.

Esto no corresponde, ya que el Scrum Master entrena al equipo para usar efectivamente Scrum y mejorar la agilidad. El Scrum Master ayuda al equipo a crear productos de alto valor. Producir features no es lo mismo que entregar valor. Como resultado, el enfoque en mejorar la velocidad a menudo es incorrecto, cuando se ignora el valor.

Actuar como un asistente de equipo

Se le pide al Scrum Master que actúe como administrador (encargado de Jira), responsable de los eventos, planificador de reuniones (reservar sala), encargado de las configuración de teleconferencias, escriba.

Esto no corresponde, ya que la Guía Scrum dice claramente que el Scrum Master debería: “Facilitar los eventos de Scrum según se solicite o sea necesario” – Scrum Guide 2017. En ese caso si es una responsabilidad de Scrum Master. Sin embargo, a menudo se supone automáticamente que el Scrum Master siempre debe ser la persona que haga esto. Este no tiene que ser el caso, ya que cualquier miembro del Equipo Scrum podría asumir este rol. El que actúe como administrador (encargado de Jira) es un tema diferente, es el Equipo de Desarrollo el responsable del Sprint Backlog y de mantenerlo actualizado, ya que están a cargo de cómo hacen su trabajo, reflejado en el Sprint Backlog.

Facilitar todos los Daily Scrum

Se le pide al Scrum Master que organice y lidere todos los Daily Scrum.

Esto no corresponde, ya que el Daily Scrum es un evento para el Equipo de Desarrollo. Esto implica automáticamente que el Scrum Master no facilita el evento, a menos que se le solicite.

Eliminar todos los impedimentos

Se le pide al Scrum Master que sea el único individuo que elimine los impedimentos, esto incluye perseguir/resolver impedimentos, proporcionar las soluciones a los problemas.

Esto no corresponde, ya que es un error común pensar que el Scrum Master debería ser la persona a quien acudir para eliminar los impedimentos para el equipo. Naturalmente, eliminar impedimentos es una parte importante de la función del Scrum Master. Sin embargo, los Equipos de Desarrollo también deben ser autoorganizados. Un Equipo de Desarrollo puede buscar formas de eliminar impedimentos sin involucrar al Scrum Master. Scrum nunca debe ser tan rígido que solo el Scrum Master deba resolver los impedimentos.

Actuar como proxy con otros equipos y áreas de la organización

Se le pide al Scrum Master que el único individuo que interceda ante todas necesidades del equipo.

Esto no corresponde, ya que los Equipos de Desarrollo deben auto-organizarse, planificar y ejecutar su propio trabajo. Esto incluye tener conversaciones con personas ajenas a los Equipos Scrum para avanzar hacia los Objetivos de Sprint. Es muy ineficaz tener un intermediario para discutir entre el equipo y las personas externas al equipo.

Referencia

Leave a Reply

Your email address will not be published. Required fields are marked *