Durante los últimos meses he observado un cierto encarnizamiento en torno al debate sempiterno de las metodologías ágiles y en especial de Scrum del que he preferido mantenerme a distancia.
Este tipo de debates no es nuevo y creo que cada dos o tres años experimentan un renacimiento a causa de la decepción que muchas personas experimentan con los métodos ágiles.
El objetivo del presente artículo hoy es dar contexto a los argumentos en contra de Scrum, en un intento de intentar ayudar a entender qué es y qué no es.
Me he centrado en cinco: La excelencia técnica, el rol del Scrum Master, el intrusismo, la mercantilización de las certificaciones y la muerte de Scrum.
Scrum no promueve la excelencia técnica.
Muy cierto. Ningún equipo de desarrollo de Software que hiciera una basura de producto con clases de mil líneas, acomplamiento extremo, spaghetti code y cuyo concepto de test es “funciona en mi máquina”, tras aplicar Scrum, han conseguido ninguna mejora.
Es más, muchos de ellos, debido a la presión inherente al proceso de Scrum, han terminado haciendo cosas incluso peores, fruto de una falta absoluta de orientación a producto y una Definition of Done.
Porque puedes coger cualquier cosa en este mundo, y de la forma más amateur del mundo, destrozarla y decir que no promueve lo que tu quieres que promueva.
Y eso está bien, porque Scrum no promueve la excelencia técnica. Son las personas que hacen Scrum las que tienen que promover la excelencia técnica. En concreto el Equipo de Desarrollo (Dev Team).
No concibo trabajar en 2020 con un equipo que no entienda cómo escribir buenas Historias de Usuario ayuda a dirigir una arquitectura hexagonal u onion. Tampoco que no entendamos las bondades que aporta reducir los ciclos de feedback a través del uso de herramientas de integración y despliegue continuo como Azure. O del uso de telemetría para identificar quick wins y el impacto que el software que escribimos tiene en el valor que nuestros usuarios perciben.
Que Scrum no hable específicamente de excelencia técnica no significa que Scrum excluya la excelencia técnica.
Significa que es un framework ligero, usado en multitud de industrias y sectores en todo el mundo; como tal, es imposible describir todas las opciones que existen para mejorar la excelencia técnica sin caer en el error de intentar hacer el diccionario Larousse del Scrum: Una iniciativa noble, épica pero inútil.
El Scrum Master es un rol, no es una persona.
Totalmente cierto. Y todavía no he encontrado quien diga lo contrario. Sin embargo, es habitual que dada la naturaleza física del mundo, el rol del Scrum Master termine realizándolo una persona y no el espíritu santo.
Es más, debido al caos que suele generar un cambio de contexto continuo en caso de que una persona comparta varios roles, muchas de esas personas querrán dedicarle tiempo completo al rol, mientras que otras no.
El tiempo que le dediquen afectará a la efectividad del rol.
También afectará a la efectividad del rol la capacidad y el conocimiento que la persona o personas que ejerzan el rol tengan sobre Scrum y sus posibles consecuencias o ramificaciones.
Si su exposición a Scrum está limitada al popular episodio: “Peppa Pig y su familia desarrollan Software usando Scrum” es posible que su capacidad de entendimiento esté limitada por una falta de conocimiento sobre las consecuencias de hacer Scrum.
E incluso así, se puede hacer Scrum.
Igual no es un Scrum maravilloso que además cae en los problemas expuestos en el punto anterior pero la naturaleza de Scrum, que es ser libre para ser usado por quien quiera, permite usarlo.
Los Scrum Masters y Product Owners no han programado nunca. Son unos intrusos.
Bingo, otra en la frente. Ahora mismo hay muchas personas ejerciendo el rol de Scrum Master, Product Owner, enseñando Scrum y certificando gente que no tienen ni idea de programar.
Es más, hay organizaciones y partes de organizaciones con cientos y miles de personas que no producen software utilizando Scrum.
E incluso hay personas que utilizan Scrum o partes de Scrum en cosas que no tienen nada que ver con la Tecnología.
Este es precisamente uno de los motivos por los que Scrum es tan popular. Porque no tiene una legión de policías diciéndote lo que no puedes hacer sino que son unas reglas de juego que puedes utilizar para múltiples cosas.
Y no sólo hay personas haciendo Scrum en equipos de tecnología que no saben programar. Hay CTOs, CIOs, Development Managers, Arquitectos de Software e incluso programadores que no tienen ni idea de programar.
Por un lado, yo nunca contrataría a un Scrum Master para trabajar con un equipo de tecnología que no tiene un conocimiento mínimo de Software. Y si ese es el caso, le invitaría a hacer al menos dos o tres cursos de los miles gratuitos que hay en línea para que aprendiera qué es programar, para qué sirve el control de versiones o por qué una arquitectura monolítica puede superar en beneficios a una de microservicios en equipos pequeños y cross-funcionales.
Por otro, los técnicos tendemos a pensar que el valor de nuestro Software reside en el código. Y el ciclo de vida del Software es mucho más que eso. Podemos hacer un código maravilloso y ofrecer cero valor a nadie. En la mayoría de los casos hacen falta personas de producto, de proceso, de operaciones, de administración de sistemas, de marketing, de ventas y de administración para ofrecerle valor a alguien.
Los programadores hemos de dejar de estar enamorados del código que escribimos y empezar a enamorarnos del valor que el código que escribimos crea.
El mercado de Scrum y las metodologías ágiles se ha mercantilizado. Las certificaciones no valen nada.
Absolutamente cierto. En la fiebre del oro del lejano Oeste quienes tenían ganancia asegurada no eran los buscadores de oro, sino los vendedores de palas.
Lo cual no quiere decir que no hubiera buscadores de oro que no se hicieran tremendamente ricos.
Hoy en día hay compañías completamente alejadas de estos debates que están usando Scrum para ser tremendamente ágiles: competitivos, adaptativos e innovadores.
Durante una reunión en 2015 a la que asistí en Boston, cuna de Scrum, descubrí que existe un acuerdo total entre las compañías certificadoras para identificar a individuos influenciables y a través de campañas dirigidas de Facebook Ads, anuncios en conferencias ágiles y una campaña orquestada por redes sociales, fabricantes de post-its, rotuladores y el lobby de las jirafas, para certificarlos a todos. Todo se hizo con conocimiento del club Bilderberg y la aprobación del Conde Drácula y Don Pimpón.
A pesar de que alguien haya leído el párrafo anterior y le haya dado un vuelco al corazón – ¡Lo sabía! – es ironía. Lo cual no cambia el hecho de que Scrum se haya mercantilizado.
No hay más que crear una sensación de demanda para dirigir un comportamiento.
No es nuevo.
En 1775 se hizo en Francia para fomentar el consumo de la patata, que se veía como un alimento para el ganado.
Las compañías, sobre todo en el último lustro, han demandado más profesionales con conocimientos de Agile. Y Agile se ha asociado tradicionalmente a Scrum. Es por ello que han surgido cientos o miles de compañías dedicadas a la fabricación en masa de certificaciones ágiles cuyo marketing es cuestionable o puede llevar a engaño.
Y hoy en día, tenemos un maravilloso y variado mercado de limones.
No es algo exclusivo de Agile, es algo inherente a cualquier sector emergente en cualquier industria en cualquier país.
Desde las mascarillas para el COVID a los másteres que no son másteres.
Un momento. ¿No soy yo, Jerónimo Palacios, parte de esa mercantilización? Por supuesto que sí, en la medida en que todo el que tiene que ver con las certificaciones cae dentro del mismo saco.
Sin embargo, creo que dado el posicionamiento que hemos tenido, intentando mantener la calidad -y por ende el precio- por encima de la media, centrándonos en hacer de la formación -y no de la certificación- una palanca de transformación en las organizaciones con las que he trabajado y aportando experiencia haciéndolo.
Como ser humano es imposible no caer en contradicciones. Estoy seguro de que he formado personas que utilizan Scrum como un báculo con el que golpear a otros. Personas que han terminado formando parte de equipos de Software como Scrum Masters sin saber de tecnología.
Siempre he creído que lo importante de mi trabajo es explicar las cosas, la importancia que tiene la tecnología y las personas en torno al valor que creamos, pero siempre lo he hecho desde la perspectiva de Scrum.
Además, no es ningún secreto que puedes ir a Scrum.org y pasar la certificación PSM sin necesidad de asistir a nuestra clase ni a la de ningún Professional Scrum Trainer. Es más, con un poco de google fu puedes buscar archivos con cientos de preguntas por la red que te ayudarán a pasar la certificación sin saber siquiera cuantas preguntas está obligado a responder el Team todos los días al Scrum Manager.
Y eso hace que la certificación no valga nada. Porque la certificación certifica -¡Sorpresa!- que en un momento dado has pasado un examen de conocimiento básico sobre Scrum. Lo que vale es el conocimiento, ideas, habilidades y capacidades de la persona que ostenta esa certificación de ejercer ese rol en una organización.
Scrum ha muerto.
Toda la razón. Llevo viendo morir a Scrum y Agile desde que empecé a aplicar técnicas de desarrollo ágil y XP en 2007, cuando me subí al carro de Ruby on Rails. Hay pocas cosas tan viejas en el desarrollo de Software moderno como Scrum, que ya tiene 25 años.
Dentro de unos años Scrum no existirá. Y con ello habrá desaparecido la mercantilización, la falta de excelencia técnica y el rol del Scrum Master.
Ojalá el motivo de la desaparición de Scrum tiene como motivo que las organizaciones que desarrollan productos complejos han entendido que todas las cosas que promueve Scrum, incluyendo la agilidad de negocio, forman parte de su ADN, y por tanto no tienen que recurrir a ningún framework, método, certificación o bala de plata para mantenerse competitivas.
