En los últimos dos años se ha producido un gran cambio cultural en las empresas provocado por la pandemia de la COVID-19. El teletrabajo ha tenido un impacto directo en nuestra cultura y, por supuesto, en Agile. Últimamente, vemos nuevos roles o etiquetas en diferentes empresas: Engineering Manager, Agile Train Manager, Service Delivery Manager… Posiblemente el que más se repite es el Agile Delivery Manager. ¿Estafa o utilidad?
Agile son solo principios y valores
Agile tiene poco más de 20 años y, en este tiempo, se ha producido una gran revolución en los equipos de desarrollo software. En primer lugar, porque en muchas empresas se ha producido un cambio cultural sobre cómo desarrollar software. En segundo lugar, este cambio se ha expandido a otras áreas de las organizaciones, lo que ha convertido a Agile en una especie de estándar organizativo. Y en tercer lugar, Agile ha dado pie a la expansión y creación de nuevos marcos y métodos de trabajo.
Hace unos años, estábamos trabajando con un comercial de proyectos software sobre cómo podríamos estimar un proyecto a tres años vista. En aquella conversación, un compañero dijo con claridad: “Agile son solo cuatro valores y doce principios, no existe una técnica de estimación que te garantice lo que va a pasar a tres años vista”.
Sin embargo, por alguna extraña manera, hemos asociado Agile a “hacer lo que me dé la gana” y lo justificamos con frases como:
- Lo importante es la esencia
- No hay que atarse a un método concreto
- Tenemos que aplicar el sentido común
- Evitemos a los talibanes
Todas estas frases pueden parecer positivas hasta que se descubre la realidad de las empresas.
El Scrum Master caducó
Hace poco leí un artículo sobre el Scrum Master cuyo autor afirmaba que las empresas se arrepienten de Scrum y que renuncian a tener Scrum Masters. En parte, esta afirmación es correcta. Muchas empresas apostaron por Scrum y no han visto una ventaja competitiva rotunda que les permita continuar con ello.
Por un lado, las consultoras que apostaron por Scrum “obligaron” a sus clientes a firmar un Scrum Master en sus equipos. Al principio, esta figura hacía de “Jefe de Proyectos Agile” y, desde su punto de vista, funcionaba. Es decir, teníamos una figura que garantizaba que el proyecto se iba a cumplir.
Otro factor clave es el bajo nivel de entendimiento de la labor del Scrum Master y, sobre todo, de Scrum. Scrum busca la construcción de productos para resolver problemas complejos que entregan valor contínuamente. Muchas empresas han contado con Scrum Master sin medir valor, vendiendo proyectos tradicionales con fecha y alcance cerrados y, además, sin entender el concepto de complejidad.
Por otra parte, si una empresa consultora forzaba que se hiciera Scrum, obligaba a su cliente a cambiar su estructura o sus roles internos al necesitar de un Product Owner. Estos clientes no contaban con preparación ni tampoco querían pagar el “precio” para poder hacer Scrum, esa no era su finalidad.
Sumando estas características, la figura del Scrum Master se ha deteriorado y, aplicando la agilidad a la consultoría, muchas han decidido adaptarse hacia otras soluciones que encajen mejor con sus clientes: El Agile Delivery Manager.
¿Qué hace un Agile Delivery Manager?
Dado que la figura del Agile Delivery Manager no pertenece a ningún marco concreto como puede ser Scrum, Kanban o XP, cada empresa ha hecho su propia definición. Por tanto, vamos a analizar las ofertas de trabajo que podemos ver actualmente en Linkedin para entender qué se propone.
Proyectos cerrados
Este tipo de funciones buscan que el Agile Delivery Manager sea más protector que el Scrum Master que, usando la autogestión por bandera, dejaba al equipo expuesto ante el cliente.
Cuando hablamos de mentalidad Agile, introducimos una serie de valores que Agile no explicita, por tanto el Agile Delivery Manager tendrá los valores que se consideren. Además, piden Scrum, es decir, hagamos Scrum hasta que nos dejen porque, en el fondo, tendremos que lidiar con proyectos cerrados ¿Es una realidad manifiesta o es ausencia de valores para rechazar clientes?
Gestión de entregas
En este ejemplo, claramente piden un Scrum Master con pequeños matices. El que más llama la atención es el de gestionar las entregas. ¿No debería ser el Scrum Team el que las gestionara?
Un Product Owner encubierto
En este ejemplo, el Agile Delivery Manager se parece más a la figura del Product Owner. Por un lado, aterrizando la estrategia y convirtiéndolo en un backlog accionable que el equipo pueda usar para focalizarse.
Agile Coach
En esta organización, podemos asemejar el Agile Delivery Manager a un Agile Coach que trabaja con múltiples herramientas, además de Scrum, y que aplica en cada momento la idónea. A pesar de que un Scrum Master podría hacerlo, es curioso que prefiramos la palabra “manager” a “coach”.
Lo que diga el cliente
Por último, en este caso parece que el Agile Delivery Manager se centra más en una consultoría al cliente para que sepa maximizar el valor de su inversión. Quizás esto debía hacerlo un Product Owner entrenado, una figura que no abunda hoy en día en las empresas.
Agile Delivery Manager, ¿en qué quedamos?
Tras analizar todas estas ofertas, empezamos a tener dudas de qué significa este rol. Dependiendo de la empresa, se asemeja más a un Scrum Master, un Product Owner, un Consultor o un Agile Coach. Por tanto, tiene pinta de que es una figura que gestiona pero desde los valores Ágiles. ¿Qué significa eso?
Parece que, después de más de 20 años de Agile, solo hemos aprendido a tener jefes-buen-rollo que no gritan a sus equipos y que solo se preocupan de darles full-remote para evitar que se vayan de sus empresas. A esto, lo llamamos la esencia de Agile.
Las empresas siguen dependiendo de que una persona se haga responsable del equipo y que tire de él, es más fácil y rápido. Conseguir la autogestión de resultados lleva tiempo, entrenamiento y muchos liderazgo sirviente, lo que nos lleva a pagar un alto precio.
Sin embargo, queda una pregunta abierta, ¿dónde está la mejora para las empresas que nos contratan en esta figura de jefe cercano?
Scrum o… ¿muerte?
Scrum es difícil, mucho. Hemos visto muy pocos equipos haciendo Scrum. Cuando algo es difícil, pueden ocurrir dos cosas: que nos frustremos ante la dificultad y abandonemos o que nos lo tomemos como un reto y luchemos por alcanzarlo. Una vez más, quizás hemos pegado de ser excesivamente duros y esto ha generado dolor en los clientes, en los equipos y en los propios Scrum Master, que han terminado por adaptarse hacia otras opciones menos dolosas.
Ahora bien, si queríamos un mundo donde las empresas crearan productos digitales de éxito, ¿no debería ser doloroso abordar un cambio tan grande? Quizás pensemos que “está todo bien” y que somos capaces de hacer productos maravillosos. Pero si miramos hacia nuestros dispositivos móviles veremos pocos productos de España o Latinoamérica o Europa, estamos totalmente fuera del mundo digital, no competimos, no estamos preparados.
Por tanto, esto no es una cuestión de Scrum, de hecho en nuestra empresa (NeuronForest) hace tiempo que no usamos Scrum como bandera. Nosotros nos centramos en la esencia de Scrum y, si me apuras, de Agile: la entrega de valor. Nuestro trabajo se centra en medir y maximizar el valor de los productos que nuestros clientes quieren crear, ahí reside el verdadero cambio. Y, personalmente, estamos convencidos de que Scrum tiene mucho que decir en un mundo donde construímos productos.
Y tú, ¿prefieres Scrum o variar?
