Normalmente en los artículos y conferencias vinculados a la agilidad se nota mucho el enfoque de como los Scrum Master (y Agile Coaches) pueden ir mejorando, evolucionando y lograr lo mejor de los equipos para conseguir los objetivos esperados de la organización, pero… ¿cuantas veces hemos reflexionado sobre que es lo que esperamos los miembros “de base” de los equipos ágiles de nuestros respectivos SM? (*)

Es así que en la pasada reunión de Agile Perú, propuse el tema así que comparto las reflexiones de dicha reunión sumado a los comentarios de entonces y los que luego tuve en conversaciones posteriores.

Como punto de partida previo, hay que tener claro que no se esperaba que el Scrum Master fuera un “cargo” institucionalizado, si no mas bien un “rol” dentro de los integrantes del equipo; lamentablemente, por la deriva que ha tenido la “escena ágil”, la figura se ha consolidado, tanto por el movimiento de ex PMs que se acercaron a la agilidad, como por los profesionales que buscan ir a la rama de “gestión” esquivando lo técnico, esa es la realidad y si bien hay que recordar cual era la intención original del rol, también es bueno procurar canalizar de manera adecuada la situación en aras de lograr lo mejor para los equipos.

Con esto como base, soy de los que considera que el objetivo del Scrum Master es volverse prescindible para el equipo ya que ha procurado que este haya llegado a un grado de madurez que permite se pueda confiar en su auto-organización, esto implica muchos retos, pues el perfil de cada equipo es diferente, puede tratarse de profesionales con poca experiencia en las practicas ágiles (o en el dominio tecnológico respectivo) por lo que corresponderá un acompañamiento adecuado para que esto se vaya impregnando en el hacer de los miembros del equipo, o también tratarse de un equipo de rockstars con mucha experiencia tanto tecnológica como en agilidad y que por lo mismo tocara hacer los esfuerzos para que las diversas personalidades logren la sinergia y colaboración esperada. Como se ve, retos diferentes pero con el (se supone) mismo objetivo, convertir un grupo de personas en un equipo auto-organizado, así que creo que el éxito de la carrera de un SM (**) debe apreciarse por como (y a cuantos) ha contribuido a lograr que los equipos hayan llegado a ese estadio, que (por cierto esta en el Manifiesto Ágil) : “Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados“.

Desafortunadamente en una reunión anterior esta idea no fue bien recibida, pues se nos dijo que “siempre hay margen de acción para el SM” “siempre surgen cosas nuevas” en una comprensible defensa de su relevancia en los equipos, felizmente en esta ocasión el mensaje fue recibido de mejor manera.

Otro aspecto que aprendí a valorar de los SM con los que he trabajado es su capacidad de moverse razonablemente bien tanto en contextos técnicos como de negocio, no esquivando ninguno de los diálogos pertinentes, en ese sentido recordé el perfil de los dos SM que mas he respetado en mi carrera, uno que rápidamente entendía cabalmente el problema de negocio que se nos planteaba para un proyecto pero que igual entendía la complejidad del código que no era rato que hiciera pair programming con nosotros; y otro que cuando le plantee un potencial cambio radical al código me pidió que le enseñara el flujo que yo había encontrado, y en esa conversación me contó poco a poco como había ido evolucionando la aplicación (esta tenia sus añitos y yo solo unos pocos meses ahí)  y el problema de negocio concreto que se resolvía con ese modulo.

Si, soy consciente de que estos dos perfiles son algo “extremos”, pero la idea es esa: la capacidad de moverse cómodamente en ambos mundos para lograr los objetivos, no llegando al extremo que he visto de “no me hables en difícil” o “en eso no me meto porque no se de lo técnico” y por el contrario apoyando a los equipos en el entendimiento del problema que se debe resolver, en ese punto se me recordó correctamente que el SM no tiene porque ser traductor permanente entre el equipo y el área de negocio, pero es que cuando eso ocurre es porque el equipo aun no ha logrado la madurez a la que hacía referencia anteriormente.

Lo mencionado en los dos párrafos anteriores era la opinión preliminar que lleve a la mencionada reunión, pero posteriormente tuve una interesante conversación respecto a como se organizo y evaluó a equipos con SM de perfil técnico y de perfil no técnico “puro” (vamos, administradores, economistas..), notándose que los no técnicos hicieron un gran esfuerzo para entender el rol de los componentes tecnológicos dentro del problema de negocio que les era de su competencia, lo cual genero unas dinámicas de dialogo y colaboración muy potentes, esto me hizo recordar el caso de un Project Manager (años preagiles) no técnico que al menos una vez por semana se reunía con nuestro arquitecto, consecuencia de lo cual siempre tomaba un rol muy activo y valioso en nuestras reuniones de equipo, por lo que era muy querido por nosotros.

Como consecuencia de esta reflexión me atrevo a esbozar que buena parte del problema es cuando uno se aproxima al trabajo de desarrollo ágil de software solo con el mindset pero no tomando en cuenta la importancia del conocimiento del ámbito de dominio, en este caso el software y la tecnología, lo triste es que este fenómeno lo he apreciado mas en profesionales con carreras tecnológicas, siendo que (para redondear la cosa) en algunas organizaciones se ha dado carta de legitimidad a los perfiles de SM sin base técnica, volviéndose esta un handicap (en lugar de una potencial ventaja en ciertos casos) en lo que debería ser un SM, bueno… juzguen ustedes mismos.

En conclusión, espero que el perfil de los SM terminen de tomar forma para que efectivamente sean motores para lograr la auto-organización de equipos de alto desempeño, es posible.

(*) Aca utilizo el termino Scrum Master de manera amplia, incluyendo en el a quien promueva las practicas correspondiente a frameworks como Kanban o XP.

(**) Es mas, me atrevería a sugerir que parte imprescindible del profesional que evoluciona hacia la controvertida figura del Agile Coach debería ser su experiencia en lograr ese nivel en sus equipos.

Update 27/4/2019: El día de ayer tuve la oportunidad de exponer, en el Scrum Day Perú, los conceptos de este post, así que les comparto la presentación!!