Errores comunes en Agile – Scrum Master

En mi experiencia con equipos Scrum durante los últimos años, tanto trabajando como parte de ellos, como implementando modelos Agile en compañías, he podido comprobar diferentes grados y maneras de implementar la agilidad. Algunos buenos, otros malos y otros que ni lo uno, ni lo otro. Lo que sí puedo confirmar es que cuando una implementación ágil se tuerce, se tuerce de verdad y el resultado es francamente malo, tanto para los participantes en la iniciativa, como para las compañías.

En aquellas implementaciones en las que conseguimos que vayan por el camino adecuado, es constatable que la labor del Scrum Master es esencial. Esa labor de tutorización, entrenamiento y evangelización, no está pagada de forma alguna y es en muchos casos la pieza clave que hace que el árbol no se tuerza de manera irremediable.

Por eso, es especialmente importante contar con una figura sólida en el puesto de Scrum Master y por lo tanto debemos de tratar de huir lo más rápidamente posible de errores comunes que se cometen con la figura del Scrum Master.

A continuación, voy a listar algunos de los más comunes, para que estéis sobre aviso y podáis detectarlos y a ser posible, no cometerlos de partida.

Sin Scrum Master

No cabe decir que, si este es el caso, que los hay, tenéis un 100% de posibilidades de que vuestro árbol no sólo se tuerza, si no que nunca llegue a crecer. Sólo lograréis un estruendoso fracaso de vuestra implementación Agile.

Disponer de un Scrum Master a tiempo parcial

Si vuestro Scrum Master está asignado a varios proyectos, es difícil que pueda mantener el foco necesario en ninguno de ellos. Habría de ser un Scrum Master y equipos muy experimentados, así como proyectos muy pequeños para que pudiera funcionar adecuadamente.

Si no puede focalizar adecuadamente en el proyecto y equipo, entonces tocará sufrir. Colisionarán sus reuniones y tendrá que priorizar unos equipos y proyectos sobre otros, lo que al final redundará en problemas y en ineficiencias que se trasladarán al proceso ágil.

Como recomendación, salvo casos en los que Scrum Master y equipos de trabajo sean muy experimentados en la metodología y en el entorno en el que se desarrolla el trabajo, no se debería utilizar la figura del Scrum Master con múltiples proyectos.

Usar al Scrum Master también como Project Manager

Esta es una de mis formas favoritas de perversión de la figura del Scrum Master, bastante habitual en muchas implementaciones ágiles que conozco. Ya hemos hablado de ello en anteriores artículos. ¿No sé qué hacer con mi Project Manager? Lo nomino como Scrum Master y me hace las dos labores, control de proyecto y lo que sea que un Scrum Master haga.

Es de las cosas peores que puedes hacer en tu implementación ágil. Si el Scrum Master actúa como un responsable de proyecto, ejerce una labor de control, reporte y jefatura del equipo, traslada la imagen al equipo de que poco ha cambiado y de que sigue existiendo una figura representativa de la dirección de la empresa con la que tienen que interactuar y a la que es necesario pedir aprobación.

Un Scrum Master debe ser un maestro de ceremonias, un entrenador en la implementación ágil, no un gerente o un representante de la organización infiltrado en el equipo Scrum.

En esa doble labor, el Scrum Master Project Manager se verá presionado por el Product Owner y otros intervinientes para incluir nuevos PBIs durante el Sprint o cambiar alcances del mismo, etc., lo mismo que cuando su labor era la de responsable de proyecto en una metodología tradicional.

Este planteamiento generalmente lleva a pervertir el agile, quedándose en la forma, pero no consiguiendo cambio real alguno.

En mi opinión, esta situación es extremadamente peligrosa, ya que permite a las organizaciones engañarse con la idea de que han aplicado agile, cuando la realidad es que poco ha cambiado con respecto a la situación que se quería cambiar.

Usar al Scrum Master también como Product Owner

Esta situación es similar a la anterior, si bien es cierto que menos habitual, al menos en mi experiencia.

En este caso, la figura de Product Owner convive en el ser del Scrum Master, quién pone cercas al campo. Nadie puede actuar como representante imparcial entre el equipo y el propietario del producto. Nadie puede impedir que el Product Owner modele la forma de trabajar a su antojo, imponga trabajos no acordados o cambie planificaciones o alcances de Sprint a su antojo.

La cultura del ‘hazlo’ en su máxima expresión y sin árbitros que puedan aplicar el reglamento pactado no es para nada aconsejable. Hay que huir de esta situación si cabe aún más que de la anterior.

Usar a un miembro del Development Team también como Scrum Master

Es habitual que muchos desarrolladores tengan la certificación, experiencia o conocimientos necesarios para actuar como Scrum Master, por lo que no es raro que se pregunte a los equipos si alguno de sus miembros dispone de las habilidades para cubrir el puesto de Scrum Master.

En ese caso, es tremendamente difícil para el afortunado ganador del puesto doble de desarrollador y Scrum Master, ejercer una y otra a la vez. El Scrum Master es un líder sirviente, con lo que su prioridad es el proceso, el equipo y la evangelización, mientras que la del desarrollador es realizar el trabajo que tiene asignado de la manera más eficaz posible.

Ambas labores casan mal, de manera que si ejerce su rol de Scrum Master como debe, a disposición del equipo, difícilmente podrá alcanzar sus compromisos en el lado de desarrollador. Y viceversa, si focaliza su trabajo como desarrollador, no podrá estar a disposición del equipo o vigilante del proceso ágil, cuando cualquiera de ellos lo necesite.

Cualquiera de los escenarios planteados anteriormente son malas praxis en cualquier implantación ágil y hay que huir de estos comportamientos sin mirar atrás.

Profundizaremos en el futuro en errores comunes relacionados con otros aspectos. No sólo se van a cometer atrocidades con los Scrum Master, ¿verdad?