¿Que es un Scrum Master?

El Scrum Master conecta a todas las partes implicadas en el proyecto. Participa con todos los demás actores, coordinando las actividades y los flujos de comunicación. Muchas veces esta figura es malinterpretada porque se le asocia un rol de “jefe” o responsable del proyecto, pero no es así. El Scrum Master es el facilitador para que todo el equipo pueda trabajar cómodamente y superando las eventualidades que puedan surgir durante el desarrollo. En definitiva, no es el responsable del éxito o fracaso del producto, sino el encargado de mantener al equipo motivado y activo, además del responsable de que se siga la metodología Scrum en todo momento

Funciones y características del Scrum Master

Si bien hemos comentado qué es el Scrum Master y algunas de sus funciones, no sabemos qué características debe tener un profesional con este perfil, ni de qué forma debe interactuar con los demás actores. El Scrum Master pasa la mayor parte de su tiempo solucionando posibles inconvenientes del equipo de desarrollo, y eso implica que debe ser una persona abierta, empática y asertiva. Debe saber manejar eficientemente conflictos o mejor aún, atajarlos antes de que se manifiesten, yendo en la medida de lo posible un paso por delante de todos los demás actores. Ten en cuenta que en un sprint el tiempo es oro y es importante saber resolver eventualidades de una forma eficaz y eficiente. Si por ejemplo en un sprint hay una tarea dependiente de otra, el Scrum Master debe ser capaz de establecer prioridades manteniendo a todo el equipo activo, otorgando una mayor prioridad a la tarea de la que dependen.

Es crucial que el Scrum Master conozca a su equipo a fondo, tanto profesional como personalmente. Profesionalmente porque durante el desarrollo de un producto es evidente que existirán personas que necesitarán mayor seguimiento y apoyo que otras y personalmente porque es evidente que la productividad está estrechamente ligada a la comodidad de un empleado en su puesto de trabajo.

El Scrum Master, al no poseer un carácter jerárquico puede ser virtualmente cualquier persona con las características anteriormente descritas aunque evidentemente tendrá que tener unas nociones básicas del marco profesional en el que se desarrolla el proyecto (de poca ayuda nos servirá un Scrum Master en el desarrollo de una aplicación Android que no tenga conocimientos de programación o un full-stack developer en un equipo financiero). Por supuesto el Scrum Master tiene que tener interiorizado el framework de Scrum para poder implementarlo.

A pesar de que no existir una jerarquía tradicional, el Scrum Master debe ser un líder dentro del equipo. No debe imponer ni ordenar, pero debe destacar como la punta de lanza y el referente al que acudir con confianza.

Existen cuatro tipos de Scrum Master:

• El Scum Master rotativo, asignado aleatoriamente después de la finalización de cada ciclo a una persona perteneciente al equipo. La ventaja es que favorece la implantación de Scrum y posee un amplio conocimiento personal y profesional de los desarrolladores. La desventaja es que no todas las personas tienen las características que hemos descrito anteriormente, sobre todo a nivel interpersonal.
• El Scrum Master de tiempo parcial, el cual compagina su trabajo como desarrollador del equipo con su faceta de Scrum Master. Tiene las mismas ventajas que el Scrum Master rotativo y elimina la posibilidad de que la aleatoriedad señale como responsable a una persona no enteramente capacitada para este rol.
• El Scrum Master a tiempo completo, el cual se dedica exclusivamente a este rol en un equipo, lo que permite una mayor especialización y fluidez en el desempeño en su tarea y es típico de pequeñas y medianas empresas.
• El Scrum Master a tiempo completo y compartido se diferencia del anterior en que maneja varios proyectos simultáneamente siendo más frecuente por tanto en empresas grandes.

Interacción del Scrum Master con el equipo de desarrollo

En cada ciclo existen diferentes fases en las cual el Scrum Master se relaciona con diferentes actores. Posiblemente sea en el sprint cuando su tarea se vuelve más crucial, pues es el momento en el que debe sacar a la luz todas las cualidades resolutivas que se esperan de él. Como ya hemos dicho, el Scrum Master no es un jefe, no tiene capacidades ejecutivas sobre el equipo ni autoridad para tomar decisiones empresariales, lo tiene sentido ya que minaría su capacidad para generar espacios de comunicación abiertos y comportarse como un líder. Es un igual con el equipo de desarrollo y su única autoridad efectiva radica en la planificación de los rituales Scrum. En relación con el equipo, el Scum Master debe tener en cuenta que muchas veces más no es mejor. Hablamos de que puede existir la tentación por parte del equipo de desarrollo y otros actores de planificar un sprint con un número irreal de tareas. Un buen Scrum Master vela tanto por la seguridad del proyecto como por la integridad del equipo de desarrollo. De poco nos sirve un sprint ultra exigente si va a provocar que no se presten atención a los detalles, se incremente la deuda técnica (retrasando otros sprints) y genere burnout y frustración en el equipo. Hay que tener en cuanta que después de cada ciclo, viene otro y debemos afrontarlo con los desarrolladores lo más motivados posible. Unas estimaciones poco realistas en sprints sucesivos pueden ser letales para el equipo de desarrollo.

Interacción del Scrum Master con el Product Owner

El rol del dueño del producto en Scrum es, a diferencia de otros modelos de producción no ágiles, central para llegar al objetivo común, pues es parte activa durante la construcción/evolución del producto. El Product Owner es el encargado de transmitir las nuevas funcionalidades que aumentarán el valor del mismo mientras que el Scrum Master (junto con el equipo) son los encargados de seleccionar aquellas más relevantes para el siguiente ciclo de producción. El Scrum Master debe negociar con el dueño del producto los plazos y las características a implantar en el nuevo ciclo de producción, evitando la anteriormente mencionada sobrecarga en el siguiente sprint, haciéndole ver y orientándole en función de las capacidades del equipo, cuáles pueden ser las prioridades del mismo.

El Scrum Master en el Scrum diario

El Scrum Master es el encargado de que se cumpla el ritual de Scrum diario. Su papel es el de moderar las intervenciones y hacer que se cumplan los canónicos 15 minutos que debe durar la reunión. Y ojo, porque moderar no significa se el eje en torno al cual gira la reunión. De nuevo la palabra clave es la facilitación. El Scrum diario no se hace para informar al Scrum Master sobre los avances y problemáticas que encuentra cada desarrollador cada día (eso puede hacerse en cualquier momento de la jornada laboral), sino para informar al resto del equipo de ellos. De hecho, la reunión en equipos que hayan interiorizado Scrum puede perfectamente realizarse eventualmente sin la presencia del Scrum Master, aunque su asistencia es muy útil, pues es el mejor momento para analizar las relaciones entre los miembros y enterarse del estado real del proyecto.

El Scrum Master en la planificación del Sprint

El Scrum Master es el encargado de planificar con el equipo de desarrollo y el dueño del producto el siguiente Sprint. Como ya hemos dicho, el Scrum Master tiene que ser capaz de analizar los recursos y por tanto la carga óptima de trabajo que puede mantener el equipo de desarrollo. Al mismo tiempo debe negociar con el dueño del producto las nuevas funcionalidades del software que se van a añadir en función de la carga de trabajo capaz de mantener el equipo de desarrollo. Es posible y normal que el dueño del producto quiera tener el mayor numero de funcionalidades implementadas en el menor tiempo posible, sin embargo, el Scrum Master debe poder comunicarle de forma efectiva las capacidades del equipo del desarrollo, manteniendo un ritmo de trabajo adecuado, ni endiablado ni cómodo, sino desafiante pero asequible.

El Scrum Master durante la revisión del sprint

A diferencia de otros rituales de Scrum, en la retrospectiva, el Scrum Master se hace a un lado para dar el control de la reunión al dueño del producto que se encarga de explicar cómo afecta cada tarea completada del Backlog del sprint en la nueva versión del producto. El Scrum Master se debería limitar a mantener los tiempos y facilitar un marco a la reunión, facilitando los materiales necesarios para su desarrollo a ser posible antes de su celebración. Por ejemplo, un burndown chart o un pequeño resumen del ultimo sprint pueden ayudar a guiar la reunión, además de tener una perspectiva general y actualizada del proyecto.

El Scrum Master durante la retrospectiva

Durante la retrospectiva el Scrum Master reúne al equipo de desarrollo e inicia un proceso de autoevaluación de todo el ciclo. La función principal del Scrum Master en el equipo de desarrollo es la de generar un espacio seguro para la crítica constructiva y el reforzamiento del espíritu de grupo. Debe procurar que se expongan aquellas cosas que no funcionaron bien, y a ser posible, que sean verbalizadas por los propios desarrolladores. Al mismo tiempo, debe guiar al grupo en la búsqueda de las soluciones para aquellos problemas que se puedan repetir en los siguientes ciclos.

Estas reuniones deben ser puntos de inflexión para aquellos problemas que se vengan repitiendo en varios sprints. No se trata de buscar culpables, sino soluciones, pero no hay que tener miedo a exponer los fallos de otros compañeros siempre que se haga de una forma respetuosa y constructiva. Sobre todo, es importante que la exposición de fallos y cosas a mejorar no sea la meta, sino la excusa para encontrar una solución.

Es muy recomendable exponer y hacer énfasis en aquellas cosas que se van mejorando en cada retrospectiva, sobre todo al final de la reunión, ya que sirve como bálsamo para aquellas situaciones que hayan podido minar la motivación del equipo, pero si los errores no deben ser tratados como catástrofes o errores individuales, la revisión de los puntos positivos deben evitar la autocomplacencia.

La retrospectiva es un proceso para buscar soluciones grupales, y por tanto la responsabilidad de solucionarlos debe ser grupal, por ello, es recomendable realizar un diario de retrospectivas en el que se recojan los errores, aciertos y soluciones propuestas. De esta forma es más fácil ver los patrones que se repiten en los ciclos. Además, la implementación de las soluciones debe procurar ser colectiva, salvo en los casos en los que la difusión de la responsabilidad se haya constatado en sucesivos ciclos o la propia naturaleza de la tarea lo impida.