Alfonso Arias Aguilera, PMP
Técnico Senior de Reporting
BBVA
Linkedin: https://www.linkedin.com/in/alfonsoarias/
Participo desde hace algunos meses en un proyecto con el rol de Scrum Master y he visto en ocasiones cuestionada su importancia e incluso su necesidad en contraposición con el rol de Product Owner cuya necesidad nadie cuestiona.
Con este artículo pretendo explicar algunas de las funciones que desempeña el Scrum Master y que sea el lector el que valore la necesidad o no de este rol en la metodología agile.
Pero empecemos por el principio. ¿Qué significa el rol de Scrum Master? Cada uno lo define a su manera: facilitador del proyecto, protector del equipo, etc. A mí me gusta verlo como la persona que tiene que velar porque se cumpla la metodología agile y esto significa hacer que cada miembro del equipo cumpla con su rol. Por recurrir a una metáfora, el Scrum Master es el perro pastor que hace que el rebaño no se descarríe y que el equipo no pierda el foco del proyecto.
En la metodología agile existen una serie de reuniones o ceremonias que se repiten en cada iteración o sprint (la duración del sprint suele ser de 15 días):
- sprint planning (al comenzar el sprint)
- daily meeting (diariamente)
- refinamiento (1 o 2 por sprint)
- sprint review (al terminar el sprint)
- retrospectiva (al terminar el sprint)
Es muy importante que estas reuniones de equipo se mantengan durante toda la duración del proyecto y es una de las principales tareas que tiene el Scrum Master. Esto no significa que las reuniones las convoque el Scrum Master pero si debe asegurarse de que tengan lugar en tiempo y forma. Con tiempo y forma me refiero a que cada reunión tiene un time-box establecido o duración máxima de la reunión y unos participantes concretos.
A continuación describo brevemente en qué consiste cada ceremonia.
Sprint Planning
Es una reunión de planificación del sprint, el equipo decide que se compromete a hacer en el siguiente sprint. Esta reunión debe liderarla el producto owner y deben asistir todos los miembros del equipo.
Daily
Es una reunión diaria de 15 minuto, liderada por el Scrum Master, en la que cada miembro del equipo comenta brevemente lo que hizo ayer lo que va a hacer hoy y si tiene alguna tarea bloqueada y por qué. A esta ceremonia puede asistir cualquiera si lo desea pero es obligatoria para los miembros del equipo y el Scrum Master.
Refinamiento
Es una reunión para ir desgranando lo que se hará en el siguiente sprint. Es una reunión que debe liderar el Product Owner. Deben asistir todos los miembros del equipo afectados por los temas que se van a tratar y todas aquellas personas que no son del equipo pero que pueden ayudar a desgranar las tareas que habrá que abordar. Si lo comparamos con la metodología tradicional del PMBOK sería algo parecido a elaborar el WBS (Work Breakdown Structure) del proyecto con la diferencia principal que en este caso participa todo el equipo y no solo el Jefe de Proyecto.
Sprint Review
Es una reunión donde se revisa lo que el equipo ha hecho durante el sprint. Pueden asistir además del equipo otros Stakeholders, los Sponsor del proyecto, etc. Se trata de ver que se ha hecho de lo que se tenía previsto hacer. Esta reunión la lidera el Product Owner.
Retrospectiva
Es una reunión a la que deben asistir los miembros del equipo, el Scrum Master y el Product Owner. Esta reunión la lidera el Scrum Master. Es una reunión para dar feedback mutuamente, en la que de manera natural tienen que aflorar los problemas que ha tenido el equipo durante el sprint. Se utilizan diversas dinámicas para que los problemas se manifiesten de manera espontánea. El resultado de la reunión siempre deben ser iniciativas de mejora que se incorporen al backlog. Esta reunión está muy alineada con el espíritu de la mejora continua. Es una reunión que si no se gestiona bien puede ser tensa e incómoda para los participantes por lo que el Scrum Master debe procurar crear un ambiente distendido y cómodo.
Errores comunes
Algunos de los errores más comunes que suelen cometerse al empezar a trabajar con la metodología agile y que debe evitar el Scrum Master son los siguientes:
- Hacer refinamiento del backlog durante el sprint planning. Esto es señal de que no hemos hecho bien los refinamientos anteriores porque al sprint planning se debe llegar con las tareas claras, solo habría que estimarlas y planificarlas.
- Hacer dailys de más de 15 minutos. Es muy importante que se respete el tiempo de la daily, si surgen temas que requieran discutirse más en profundidad el Scrum Master debe conminar a los miembros del equipo involucrados a que lo hagan después de la reunión.
- Convertir la daily en una reunión de seguimiento. Si el Product Owner asiste a la daily no debe tomar el control de la reunión, no es una reunión de seguimiento, no es para fiscalizar el trabajo del equipo, es para que cada uno vea lo que los demás hacen y levantar bloqueos que impidan que alguna tarea avance.
- Refinar el backlog del proyecto en un sprint. Un error muy común del refinamiento es que empecemos refinando el sprint backlog y terminemos intentado refinar el backlog del proyecto entero.
- No incorporar las tareas que salen de la retrospectiva al backlog. Normalmente el producto owner no las considerará prioritarias. La primera condición para que se aborden estás y todas las tareas del proyecto es que estén en el backlog.
- Pocos recursos a muchas tareas en lugar de muchos recursos a pocas tareas. La consecuencia de esto último es que tenemos un WIP (work in progress) elevado, muchas tareas en curso que no se finalizan.
- Establecer silos de especialización dentro del equipo. Los miembros del equipo asumen de antemano que solo pueden hacer un determinado tipo de tareas y como consecuencia se producen picos y valles de trabajo, momentos en los que algún miembro del equipo está parado porque piensa que no puede ayudar en las tareas de los demás.
- Dirigir a los miembros del equipo. Tanto el product owner como el scrum master deben evitar la tentación de hacer de jefes de proyecto al uso y dirigir al equipo. Recordad que un equipo agile es un equipo autoorganizado.
- Convocar reuniones paralelas para informar a los stakeholders. Hay que evitar que se haga una gestión doble del proyecto, por un lado agile y por otro lado no agile. Los stakeholder que quieran hacer seguimiento del proyecto deben asistir a la sprint review.
- Tomar decisiones de manera unilateral. Las decisiones sobre el proyecto las debe tomar el equipo, salvo la de priorizar el backlog que es exclusiva del product owner. Es la única manera de que el equipo esté comprometido con el proyecto y para tomar decisiones el equipo debe estar siempre informado de todo lo que afecte al proyecto. Es muy necesario que haya transparencia y comunicación efectiva entre todos los miembros del equipo.
Como se puede ver, el Scrum Master tiene bastantes tareas en su mochila y ninguna fácil. Mantener tal cantidad de reuniones cada 15 días y que el equipo no desfallezca es una tarea ardua. Una de las principales críticas sobre agile que oigo es precisamente la de tiempo que se pierde en ceremonias. Hacer ver al equipo la importancia de estas ceremonias es nuestra principal labor como Scrum Masters.