Lo confesamos, no somos Scrum Masters.

Desde hace algunos años, el rol del Scrum Master ha vivido su época dorada, con cientos de ofertas de empleo, una gran demanda y considerado como uno de los empleos emergentes en España. Estábamos ante la revolución ágil de las empresas españolas que creían que para “ser Agile” tenían que tener entre sus filas a cuantos más profesionales certificados, mejor.

Últimamente, este crecimiento está cambiando. Aunque todavía nos encontramos con mucha demanda, la tendencia está yendo a la baja, ¿qué está pasando?, ¿ya no se trabaja de forma ágil en nuestro país?

Uno de los problemas que nos hemos encontrado en el camino ha sido el de reducir a un método de trabajo toda una forma de actuar, de pensar que Agile es Scrum (cuando abarca mucho más que eso), y de reducir aún más la idea de que no estamos trabajando de forma ágil si no tenemos una figura de Scrum Master.

Aclaremos que el agilismo no es sólo el framework Scrum (aunque es de largo el más extendido), sino que hay otras muchas prácticas o métodos ágiles valiosos como XP, Kanban, etc. que no requieren un Scrum Master. En resumen, hay mucho Agile más allá de Scrum.

Regreso al futuro

Para entender qué está ocurriendo, vamos a dar una vuelta por su trayectoria. Agile (y de su mano, Scrum) nació hace más de 20 años como respuesta a una idea muy concreta: hacer software mejor y, de esta forma, empezó a extenderse como una nueva forma de trabajo entre muchos equipos de desarrollo.

Te encontrabas con algún desarrollador que había leído sobre el tema o algún manager que había asistido a alguna conferencia y con esos mínimos conocimientos, quizá incluso mal interpretados, empezaban a implantar cambios en su forma de trabajo.

De algún modo, de mejor o peor forma, consiguieron buenos resultados que calaron en las empresas, haciendo que cada día los métodos ágiles fueran más populares en el sector.

Y como con tantas cosas, con la popularización, llegó la perversión. Hordas de personas vieron la oportunidad de mejorar su posición profesional, su salario o, incluso, cambiar de profesión gracias a una certificación bastante asequible (no olvidemos que la guía Scrum son menos de 20 páginas, no es precisamente una oposición a juez).

Nos encontramos entonces con un mercado copado de gente asegurando ser expertos, algunos de ellos que quizá ni siquiera habían participado antes en proyectos de desarrollo de software.

A partir de aquí es fácil imaginarse el resto: una gran decepción por parte de las empresas, que invertían en estos procesos, y por los equipos de desarrollo, que se encuentran con un rol por el que sienten cierto rechazo.

¿Cómo se ha vivido en los proyectos?

Pues bien, las empresas que contrataron un Scrum Master con la promesa de maximizar la productividad del equipo de desarrollo y hacer que el equipo fuera autoorganizado se encontraron, en muchas ocasiones, con algo que no esperaban.

En muchos casos se han orientado los esfuerzos en ejecutar de forma rigurosa un framework, ya de por sí laxo, perdiendo así el objetivo original. Nos hemos encontrado en este camino a auténticos fanáticos que han denostado cualquier otra práctica (a pesar de que la guía Scrum las acepta) con el argumento de que no era Agile o a gente sin conocimientos en tecnología liderando un equipo en su implantación metodológica y dejando en un segundo plano la entrega y los intereses de su cliente.

Así pues, el cliente se encontraba con que había contratado una persona que iba a potenciar el valor de su inversión, pero que en realidad no le dejaba hablar directamente con el equipo “porque le distraía”, no le dejaba aplicar cambios tras la planificación, no realizaba las tareas de gestión “porque en la guía no dice que sea una tarea del Scrum Master” o llevaba al extremo la autoorganización del equipo aunque esto supusiera que no se llegaran a los compromisos adquiridos.

Estas situaciones en las que el rol del Scrum Master había malentendido los principios más básicos de comunicación y colaboración con el cliente y adaptabilidad al cambio ponían en dirección contraria al equipo en todo lo referente a potenciar el valor, sumando riesgos para la consecución del objetivo.

En los equipos el rol se ha vivido de forma diferente. En muchos casos, contaban con una persona a la que no sentían parte de su equipo, alguien que con la autoorganización del equipo por bandera les miraba siempre desde un paso atrás y al que no sentían involucrado con el proyecto.

Los equipos que habían trabajado en métodos más clásicos pasaban de un jefe de proyecto que organizaba las tareas a otro que no conocía la funcionalidad del producto y no entendía las tareas ni los problemas a los que se enfrentaban cada día. Sentían que tenían mucha sobrecarga de reuniones que no les permitían centrarse en el desarrollo y que a veces habían perdido su objetivo y se realizaban sólo porque lo dictaba el método.

O en muchos casos se percibía como una especie de déspota ilustrado con la premisa de “todo para el equipo, pero sin el equipo”, organizando dinámicas, reuniones y procesos por el bien del equipo, pero sin entender antes las necesidades reales de su día a día.

Por nuestro lado ya que la guía Scrum, aunque aparentemente flexible, dice: “Aunque la implementación de sólo algunas partes de Scrum es posible, el resultado final no es Scrum”. Pues bien, digamos entonces sin temor que en Paradigma no hacemos Scrum. Porque cuando no tenemos un Product Owner como dice la guía (en un entorno real de cliente-proveedor es normalmente una persona de negocio con muy poca dedicación), asumimos desde el equipo parte de las funciones que no hace por el bien del proyecto; porque cuando podemos, complementamos con prácticas para mejorar el método (cosa que prescribe la guía), pero cuando no tiene sentido adaptamos el método.

Entonces… ¿Agile está muerto?

Agile tiene mucho que decir todavía no sólo en proyectos de software (como se ha demostrado en otros sectores). Y cabe decir que su gran expansión ha sido gracias a Scrum.

Scrum ha acercado el agilismo a muchas empresas que jamás lo habrían hecho de otra forma y ha ayudado a equipos a entender otras formas de trabajar. Ha permitido comprender a empresas que no hay que pensar tanto en el largo plazo, que hay que adaptarse, dividir para vencer, pero ya estamos en un punto evolutivo en el que hay que conocer otros métodos para conocer qué posibilidad encaja mejor en cada contexto y poder disponer de herramientas para aplicar las formas de trabajo más óptimas para cada proyecto.

Pero volvamos de nuevo al planteamiento inicial, ¿está la figura del Scrum Master en vías de extinción? Pues bien, como en la naturaleza, cuando una especie se encuentra en peligro, tiene dos opciones: adaptarse o morir. Paradójicamente esta es la premisa que mueve el agilismo, la adaptación.

Ha habido gente que no ha tenido que adaptarse en este punto, gente que desde el principio entendió que los métodos ágiles son un medio y no un fin. Agilistas que han sabido aportar en cada equipo al nivel que era necesario y que han adaptado su management al nivel de madurez de los equipos sabiendo cuándo dirigir y cuándo dar espacio.

Profesionales que se han centrado en métricas para ayudar a sus clientes a tomar decisiones de negocio y a su equipo a reflexionar cómo mejorar, y que han sabido entender las necesidades del proyecto, del cliente y de sus compañeros. Una definición de un auténtico líder ágil.

En Paradigma hemos vuelto a la esencia del agilismo, los principios y valores, sabemos qué funciona y qué no en nuestro contexto desarrollando proyectos con clientes que confían en nosotros como partner para evolucionar su negocio. Sabemos que Scrum no es siempre aplicable en cualquier entorno, es demasiado generalista, y por eso hemos quitado la etiqueta “Scrum Master” de nuestros agilistas del Círculo Agile, queremos ir más allá construyendo siempre desde los principios ágiles en los que confiamos y centrándonos en la entrega de soluciones.

Pero la realidad es que en el mundo Agile la figura del Scrum Master no es la de un líder que garantice la entrega, que le quite el sueño cómo hacer que el proyecto vaya mejor, un líder en el que reflejarse y que el equipo siga en los momentos de dificultad.

Por eso “Scrum Master” no es lo que representa nuestro trabajo y preferimos denominarlos Agile Delivery Leader. En primer lugar, porque en Paradigma no sólo aplicamos Scrum, hay otros métodos ágiles con los que trabajamos; pero mucho más importante es que además queremos que nuestro rol sea más allá de un responsable de asegurar que el marco de trabajo se cumpla: nosotros nos comprometemos con el proyecto, con el equipo y con los objetivos de nuestro cliente.

Queremos volver a hacer Agile en esencia, para lo que fue creado: hacer software mejor.