Este post es de Nicolás Darriulat, parte del equipo de Abstracta, quien escribió esto en base a su experiencia trabajando en un equipo con Scrum, y luego corroboró y ajustó el contenido basado en lo que aprendió al certificarse de Scrum Master. ¡Gracias Nico por todo el esfuerzo y pienso compartido al escribir este artículo!
Scrum puede ser difícil de entender por aquellos acostumbrados a los procesos más tradicionales. La falta de jerarquías, la posibilidad que tiene el equipo de auto gestionarse, estimaciones con story points, son todas cosas nuevas que van en contra de la forma de trabajar a la que el mundo está acostumbrado. Tal vez una de las cosas más complicadas de entender, es que se propone romper jerarquías, sin tener Project Managers que funcionen como “jefes”, no hay posiciones intermedias, ni nadie indicando a nadie cómo debe trabajar. Mucha gente tiende a imaginarse los roles de Product Owner y Scrum Master en una jerarquía superior al equipo, con el poder de tomar decisiones que son irrefutables, y la autoridad de castigar a aquellos miembros del equipo que no están trabajando “correctamente”. Pero como veremos en este artículo, esto no está ni cerca de la realidad.
Desde que empecé a aprender sobre Scrum, me pareció que las responsabilidades del Product Owner eran más fáciles de comprender, ya que la definición siempre es bastante precisa, y además se puede mapear fácilmente a distintos roles tradicionales por tener semejanzas con los mismos.
Sin embargo, creo que no hay una frase o conjunto de definiciones que puedan fácilmente definir qué es un Scrum Master. Al intentar comprender su propósito, se lo suele imaginar como un rol encargado de muchas más cosas de las que realmente hace. Es un rol diferente a todo lo que estamos acostumbrados, y la mejor forma de entenderlo es con el tiempo. Creo que así fue como yo pude comprender de qué se trata, y en este post me gustaría transmitir lo que interpreté.
Al malinterpretar cuál es la verdadera responsabilidad de un Scrum Master, se crean “mitos”, falsas definiciones y teorías buscando una definición. Éstos son algunos de esos “mitos”, y una justificación de por qué están alejados del perfil ideal de un Scrum Master:
Mitos sobre el rol de Scrum Master
#1 “Un Scrum Master es como un Gerente de Proyecto”
No solo ambos roles hacen cosas totalmente distintas, sino que generalmente un Gerente de Proyecto tiene un rol jerárquico sobre el equipo, algo que no se cumple con un Scrum Master. No veo que haya un equivalente en las metodologías tradicionales, pero tal vez sería lo más parecido a un Consultor, que analiza, sugiere, pero no da órdenes a sus compañeros.
#2 “El rol de Scrum Master está por encima del equipo”
Tal como dije en el punto anterior, no es un Gerente de Proyecto ni tiene un cargo “superior” al del resto del equipo. Mucha gente lo piensa de esta forma, y tal vez sea porque se busca un jefe dentro de Scrum, cuando en realidad no lo hay. Los equipos son auto gestionados, y deciden de qué forma van a trabajar y que reglas, además de las que impone Scrum, van a establecer.
#3 “El rol de Scrum Master es menos importante que el del Product Owner”
Esto sería como comparar un Arquitecto de Software contra un SQA en una metodología tradicional, en ese caso, ¿cuál es más importante?
Así como en el ejemplo, ambos roles cumplen funciones distintas y tienen responsabilidades diferentes, lo mismo sucede entre el Scrum Master y el Product Owner. Resumidamente, el primero se encarga de que el equipo y el proceso funcionen lo mejor posible, que las cosas fluyan, sin rispideces ni bloqueos. Mientras tanto, el PO tiene una responsabilidad similar pero enfocado al producto, o sea, es el responsable de que el mismo se parezca lo más posible a lo que quiere el cliente, y es quien prioriza y ordena los requerimientos que el mismo solicita.
Entonces, ¿por qué sería menos importante la figura del Scrum Master? ¿acaso el proceso y el equipo no son tan importantes como el producto? Es verdad que muchos equipos deciden no tener el rol de Scrum Master, pero generalmente en estos casos, estos equipos cuentan con una madurez, cohesión y proactividad tal, que las responsabilidades del Scrum Master están “diluidas” en el equipo, por lo cual no se considera necesario tener un solo individuo que se encargue de las mismas.
#4 “Un Scrum Master no tiene por qué trabajar full time en ese rol”
No creo que haya una verdad absoluta sobre este punto, es muy relativo según cada situación, dado que va muy de la mano con la madurez del equipo. Como mencioné anteriormente, puede haber equipos en los cuales los integrantes se encargan de cumplir determinadas pautas que son exigidas al rol de Scrum Master, pero también existe el polo opuesto, en un equipo en el que se desconoce Scrum, que no tiene experiencia en trabajo en equipo, y que carece de la proactividad necesaria para llevar a cabo determinadas tareas o tener ciertas actitudes. En este último caso, es imprescindible contar con un Scrum Master de tiempo completo (¡hay quienes le llaman “Scrum mom”, porque pareciera una madre que está atrás del equipo todo el tiempo!).
Creo que entre estos dos extremos varía la necesidad de tener un Scrum Master full time o no.
#5 “Las ideas planteadas por el Scrum Master son siempre aceptadas e implementadas”
En otro punto, dijimos que el Scrum Master no tiene ninguna autoridad sobre el equipo; simplemente sugiere, hace las preguntas adecuadas, hace reflexionar a los demás, es mediador entre los individuos. Si bien un buen Scrum Master debería ser capaz de comprender al equipo, y sugerir ideas que logran tener una buena recepción, no siempre tiene porqué ser así, pueden llegar a ser tomadas en cuenta pero no necesariamente aceptadas por el equipo.
Entonces, ¿qué significa ser Scrum Master?
Bien, si estas frases son incorrectas, entonces ¿qué significa ser un Scrum Master? En respuesta a estos “mitos”, me gustaría plantear 5 puntos que creo que se aproximan a la definición de Scrum Master:
#1 Un Scrum Master debe ser servicial al equipo
En oposición al tradicional Gerente de Proyecto o Líder en metodologías más tradicionales, un Scrum Master debería servir al equipo, no al revés. Debe estar prestando atención en todo momento a las preocupaciones del equipo y sugerir soluciones para sanar los dolores que aparezcan.
#2 Un Scrum Master debería impulsar al equipo a llevar a cabo las tareas que se acordaron
Si el equipo acordó que cada sprint se iba a realizar entre todos una tarea X, el Scrum Master debe cuidar que el equipo no deje dicha tarea por el camino, y de ser así, impulsar a sus integrantes a concretarla.
#3 Uno de los éxitos de un Scrum Master, es que el equipo aprenda a auto gestionarse
Un Scrum Master no es un Gerente de Proyecto, así que no cuenta con objetivos esperados para cada uno de los integrantes del equipo, y no se considera exitoso únicamente cuando los mismos realizaron un buen trabajo. Entonces, una forma de darse cuenta que su labor es productiva y está dando frutos, es que el equipo haya utilizado sus impulsos, para aprender a manejarse por sí solo y saber auto gestionarse. Esto significa que su grado de madurez aumente, y cada vez dependa menos del Scrum Master para llevar a cabo el proceso de trabajo.
#4 Un Scrum Master debería asistir y enseñar al equipo sobre los principios de Scrum y sus reglas
Ésta frase habitualmente aparece dentro de la clásica definición de un Scrum Master, y no hay mucho más para agregar. Además de todas las características que requerimos que el Scrum Master tenga, también es importante que conozca y realmente confíe en Scrum como un buen marco de trabajo, de forma de poder transmitir sus conocimientos y ayudar a implementarlo.
#5 Un Scrum Master debe levantar los bloqueos en los que se encuentra el equipo
Otras de las responsabilidades del Scrum Master, es hacer lo posible porque el proceso fluya, solucionando los impedimentos que hacen que el equipo no trabaje correctamente. Esto no quiere decir que nadie más en el equipo pueda hacerlo, pero es responsabilidad del Scrum Master que estas situaciones se desbloqueen cuanto antes.
Conclusión
Está claro que entender qué es un Scrum Master puede traer confusiones; tal vez no exista una sola definición que lo explique, y cada uno puede interpretarlo de forma distinta.
Según yo lo veo, “Scrum Master” es más una actitud que un rol, como tanto se dice (y como yo lo hice en este artículo). Son un conjunto de principios que una persona puede tener o no, dependiendo de la personalidad que tenga. No es tanto un cargo que se le adjudica a un individuo y necesariamente por eso pasa a ser un Scrum Master. Me parece que una persona puede tener el rol asignado, pero no tener las aptitudes, así como puede haber alguien que no sea “declarado oficialmente” el Scrum Master de un equipo, y sin embargo tener la actitud proactiva y motivante que mueve al equipo y que tanto se precisa.
Al llevar esto a tierra, se me vienen a la cabeza gente que encaja perfecto con éste perfil, y que el trabajar con ellos me sirvió para entender de qué se trataba ser un Scrum Master. Tal vez quien esté leyendo este artículo, puede estar imaginando personas con las que trabajó o conoció, que cumplen con estas características, y tal vez sean Scrum Master sin saberlo, e incluso que nadie se lo haya dicho.
En mi opinión, creo que más importante que determinar cuántas horas tiene que trabajar un Scrum Master o no, creo que lo fundamental es contar con una, dos, N personas dentro del equipo (cuantas más mejor) con ésta actitud, con proactividad, con la energía necesaria para buscar que el equipo funcione lo mejor posible y aprenda a auto gestionarse.
Photo credit: John_Scone via VisualHunt.com / CC BY-NC-SA
