Me encanta Scrum. Prueba de ello es que hace más de ocho años lo aplicamos en la compañía, algunas veces de manera interna y otras de cara al cliente. Pero entre más me gusta algo, más dudo de ello. Y eso me ocurrió durante la relectura que hice de la Guía Scrum 2017, más exactamente cuando me encontré con la siguiente afirmación:

“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide”, que traducido al español dice: “El Scrum Master es el responsable de promocionar y apoyar Scrum como se define en la Guía Scrum”.

Dicha afirmación me llevó a plantearme la siguiente pregunta: ¿El Scrum Master debe solo promocionar y apoyar Scrum, tal y como está definido en el Scrum Guide? La verdad, no estoy convencido de que deba ser de esa manera. Desde mi experiencia creo que deberían promoverse las maneras de pensar y trabajar e incentivar prácticas o herramientas que generen valor y bienestar en los equipos en los que participe.

¿Y qué pasa si a un equipo de trabajo le aplica mejor una práctica proveniente de otra fuente como Design thinking, Kanban, Lean, SAFe o Less? ¿No deberían implementarse? Estoy en desacuerdo. Creo que toda práctica que sea conveniente para determinado contexto debería promoverse.

Ahora bien, el argumento puede ser: entonces no debería llamarse Scrum Master. ¡Pues que no se llame Scrum Master! Podría tener un nombre como facilitador o algo por el estilo.

Acudiendo al concepto de Shu Ha Ri, propongo la siguiente aproximación: puede pensarse como el Scrum Master, con estos objetivos y actividades, mientras está en el primer estadio o fase de iniciación (SHU), pero a medida que va conociendo, madurando y creciendo en las prácticas (estadio HA o RI) debe empezar a incorporar, practicar y promover otros marcos como los antes mencionados.

Quise compartir mis inquietudes con Lucho Salazar, quien además de ser mi amigo, es el traductor de la guía Scrum al castellano. Lo primero que hizo Lucho, y con el buen conocimiento que tiene del Scrum, fue citar una serie de apartados.

“Scrum no es un proceso, una técnica o método definitivo. En lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varios procesos y técnicas. Scrum muestra la eficacia relativa de las técnicas de gestión de producto y las técnicas de trabajo de modo que podamos mejorar continuamente el producto, el equipo y el entorno de trabajo” (…) “Las reglas de Scrum relacionan los roles, eventos y artefactos y rigen las relaciones e interacciones entre ellos.”

Su lectura finalizó con la siguiente cita:

“Las estrategias específicas para usar el marco de trabajo Scrum son diversas y están descritas en otros lugares”.

“Quería llegar a este punto”, afirmó.

“La palabra clave es: ESTRATEGIAS. Es lo que tú estás definiendo. Estás diciendo que para hacer un buen Scrum y ser un buen Scrum Master se debe hacer lo que dices, entre muchas otras cosas. ¡Y estás en lo cierto! Son las estrategias. Scrum solo define unas reglas. Así como la NBA define las reglas del Baloncesto en Estados Unidos. Pero las estrategias las define cada equipo, cada organización, cada Scrum Master”.

Así continuaba su argumentación:

“por ejemplo, cuando dices que El Scrum Master es responsable de promover y apoyar Scrum como se define en la Guía de Scrum, más adelante la guía dice también que El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser útiles y cuáles no. El Scrum Master ayuda a todos a modificar estas interacciones para maximizar el valor creado por el Equipo Scrum. Y para hacer todo esto, el Scrum Master puede, entre muchas otras cosas, promover las maneras de pensar, de trabajar, de usar prácticas, herramientas que más generen valor y bienestar en los equipos en que participe, que es lo que tú dices”.

Lucho continuó con el cierre de su exposición, dándome a entender que en realidad nunca estuve en desacuerdo con el planteamiento de Scrum:

“En realidad no es que estés en desacuerdo con Scrum o con la guía de Scrum, en realidad lo que estás es de acuerdo con Scrum y con su guía. Algunos tratan a Scrum como instrucciones más que como principios rectores. Pasa que algunos malinterpretan el espíritu, lo ignoran o son obligados a romper el espíritu. Al usar Scrum, la comunidad de productos debe centrarse en crear explícitamente una cultura en la organización donde las personas conozcan y sigan el espíritu de Scrum. Finalizaba Lucho.

A manera de conclusión

Estoy de acuerdo con Lucho, pero quisiera que la guía fuera un poco más específica, diciendo que el rol del Scrum Master es el de mejorar el flujo de valor y el bienestar del equipo y de la organización, aplicando principalmente el marco de Scrum, o los marcos que considere necesario, aunque para ello debamos sacrificar su nombre o rótulo.

¿Qué piensas? ¿Te unes al debate?

Gracias a Lucho Salazar por la participación en este artículo, y por ayudarme a entender el verdadero espíritu de Scrum.

____________________________________________________________________

Las entregas pasadas las puedes ver en los siguientes links:

Primera entrega: Guía Scrum 2017. Algunas reflexiones parte I

Segunda entrega: Guía Scrum 2017. Algunas reflexiones parte II

Photo by Alex Loup on Unsplash

Mantente al tanto de nuestras publicaciones a través de nuestras redes sociales: LinkedIn, Instagram y Twitter.